[App_rpt-users] Codec Negotiation

Benjamin Naber Benjamin at Project23D.com
Fri Feb 9 04:47:05 UTC 2018


Will et al:

Read this message please.

Given the bandwidth availability of LTE and even remaining 3G, from
cellular providers, going from 88kpbs to 18kpbs is NOT going to make a
difference. While many seem to think this is true, it is simply not the
case. Even with poor signal, but able to maintain a cellular data
connection, the bandwidth is still going to be hundreds of kbits. Just
not [UDP] reliable.

Cellular data providers don't really care about UDP, their main concern
is TCP reliability. Many streaming services are now TCP, hence lagging
and slow to buffer video and voice streams, but little to zero
"noticeable" drop-outs.

I have several friends that use cellular hotspots, with their radio
hotspots and be it DMR, allstar, echostink, it's very unreliable. The
bigger the city the more unreliable it seems. My experience with
cellular data is the same.

What I am seeing now, and have a theory is this:
Verzion and ATT now use IPv6 for their cellular data subscribers. No
cellphone in their US networks get IPv4 any more. In the middle of last
year, Verizon started issuing ONLY IPv6 addresses to their subscribers.

This means that any IPv4 address must be routed through their limited
placement, subscriber internet access gateway (overloaded) and then
through another IPv6 to IPv4 gateway. These IPv6 <-> IPv4 gateways are
getting overloaded, causes the data unreliability issues.

How to solve this? Use the open repeaters in the area you are in!!!

radio hotspots are nice, but if everyone is using a hotspot, then why
should repeaters exist? Then, that one time, when some natural disaster
takes out cellular, your cellular data connected radio hotspot is NOT
going to work, but I am pretty sure the amateur radio repeaters in the
area will - even if the internet at the repeater site doesn't work. If
there are any repeaters left when that happens. 

What does not get used, does not get maintained.

~Benjamin, KB9LFZ


On Thu, 2018-02-08 at 20:38 -0500, Will Bashlor wrote:
> Hi List,
> 
> Ok, so I have a portable node and it works great at home but on the
> road using my iPhone hotspot with Verizon it's quite jittery and
> doesn't sound very good, even when I have 2 or 3 bars. I can connect
> to the same node using echolink and it works fine even with 1 to 2
> bars.
> 
> I'm using the hamvoip image without any codec changes and I notice it
> connects to our local repeater hamvoip node with g726aal2 which makes
> sense because  g726aal2 is first in [general] which I believe
> controls outbound connections.
> 
> So I wanted to see what I sounded like so I connected to 40894 so I
> could hear my own voice. It connected using ulaw for some reason. The
> only way I could get it to change was to comment out the codecs I
> didn't want to use in [general]. Apparently it doesn't negotiate how
> I think it does.
> 
> On ulaw and  g726aal2 it sounded pretty terrible. gsm was better but
> it was still broken up. I wanted to try ilbc but codec negotiation
> failed which I'm sure means that 40894 doesn't allow ilbc.
> 
> I then connected successfully to our local repeater node with ilbc
> and it sounded just fine, even with one bar, but I need to test
> more...
> 
> Is this anyone else's experience with using hotspots?
> 
> I've modified the codec under [genera] to the below, which the way I
> understand is for outgoing connections. And the codec order is the
> order of attempted negotiation. I ordered them on my portable node in
> order of least bandwidth to greatest.
> 
> So with that said, when I connect to my local node, which allows
> ilbc, why does it negotiate to g726aal2?
> 
> And how can I setup iax.conf so it always connects using the lowest
> bandwidth codec that the other side allows?
> 
> allow=ilbc
> allow=gsm
> allow=g726aal2
> allow=ulaw
> 
> 73,
> 
> Will, KE4IAJ
> _______________________________________________
> App_rpt-users mailing list
> App_rpt-users at lists.allstarlink.org
> http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users
> 
> To unsubscribe from this list please visit http://lists.allstarlink.o
> rg/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the
> bottom of the page. Enter your email address and press the
> "Unsubscribe or edit options button"
> You do not need a password to unsubscribe, you can do it via email
> confirmation. If you have trouble unsubscribing, please send a
> message to the list detailing the problem. 



More information about the App_rpt-users mailing list