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
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@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.
Hi Benjamin, I agree 100% about the small bandwidth savings not making a difference when you have great signal, however; that doesn't mean that one codec won't perform better than another given certain network conditions. I will do some more testing, but my first initial tests were that ilbc sounded much better than the others when I had 1 bar of LTE. When there's heavy network degradation throughput suffers and in certain situations you will see better results with a lower bandwidth codec. Think about it, cellular is now VOIP over LTE. And although it doesn't go through double NAT and has QoS and all that jazz, there's no reason I shouldn't be able to use AllStar without issues when I have good LTE signal (i.e. 2 bars or more). Skype, Google Voice, FaceTime Audio, Facebook Audio, and even Echolink doesn't seem to have this problem on my same commute with the same network conditions, and neither should AllStar. I mean, I can sit here at home and stream HD video with no issues on my iPhone. One thing I will test is connecting via AllStar via Echolink. I'm not sure what codec is used with AllStar connecting via Echolink. Verizon is using IPv6 and they are also giving out IPv4 via CGN, which is what I'm seeing on my phone/hotspot. This is a double NAT, yes, but that's no excuse either. I could also setup a VPN but then there's even more complexity and in some cases can make performance worse. Come to think of it, I hear Grady talking a good bit on his AllStar micro node through his cellular hotspot while driving and his sounds great. I'll like to know what cellular service he has and what codec his micro node is using. Pretty much off topic, but I do use our local repeaters via RF. When I get out of range is mainly when I use my hotspot. But I use it to connect back to our local repeater, when if I didn't have a hotspot I wouldn't be able to use it. So the way I see it, I get to use the repeater more than if I didn't have the node, because now all I need is Internet access anywhere in the world. So I guess I look at it completely different. And as you already know, it also allows me to connect to Columbus and join in on the AllStar Tech Net. If I didn't have my node and hotspot while mobile, then that's less use those repeaters would see. But for what it's worth I appreciate the time you spent to think about it and white up your reply. 73 for now. Will, KE4IAJ On Thu, Feb 8, 2018 at 11:47 PM, Benjamin Naber <Benjamin@project23d.com> wrote:
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@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.
App_rpt-users mailing list App_rpt-users@lists.allstarlink.org http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://lists.allstarlink.org/ 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.
Will, iLBC and g729 probably sound best over highly "jittery" mobile networks. Note that the hamvoip iLBC implementation is patched to use 20msec frames, NOT 30msec frames, which are the default in Asterisk. You *MUST* use 20msec frames with AllStar! My patches for Asterisk to add iLBC and use 20msec frames were published years ago. If interested, here is the link: https://hamvoip.org/downloads/patch-kit-with-ilbc.tgz And, here are example iax.conf stanzas, which only allow a specific CODEC: [radio-ulaw] type=user disallow=all allow=ulaw codecpriority=host context=radio-secure transfer=no [radio-g726] type=user disallow=all allow=g726aal2 codecpriority=host context=radio-secure transfer=no [radio-g729] type=user disallow=all allow=g729 codecpriority=host context=radio-secure transfer=no [radio-ilbc] type=user disallow=all allow=ilbc codecpriority=host context=radio-secure transfer=no ....For your setups, take a look at the CODEC definitions in the [radio] stanza. Also, you can have multiple stanzas (like above), and force various nodes to connect with a specific CODEC, etc. I run this style setup on all my systems. 73, David KB4FXC On Thu, 8 Feb 2018, 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
Fantastic, thanks David. A couple questions... How do I specify to use a particular stanza while connecting to a certain node? I thought the [radio] stanza was for incoming connections, no? Since I can't receive incoming connections using my cellular hotspot I didn't think I needed to modify [radio]. At work and home where I have ports forwarded I have a high speed connection, I don't really need to change the codecs as it works great using ulaw. Will KE4IAJ -----Original Message----- From: App_rpt-users [mailto:app_rpt-users-bounces@lists.allstarlink.org] On Behalf Of David McGough Sent: Friday, February 9, 2018 9:39 AM To: Users of Asterisk app_rpt <app_rpt-users@lists.allstarlink.org> Subject: Re: [App_rpt-users] Codec Negotiation Will, iLBC and g729 probably sound best over highly "jittery" mobile networks. Note that the hamvoip iLBC implementation is patched to use 20msec frames, NOT 30msec frames, which are the default in Asterisk. You *MUST* use 20msec frames with AllStar! My patches for Asterisk to add iLBC and use 20msec frames were published years ago. If interested, here is the link: https://hamvoip.org/downloads/patch-kit-with-ilbc.tgz And, here are example iax.conf stanzas, which only allow a specific CODEC: [radio-ulaw] type=user disallow=all allow=ulaw codecpriority=host context=radio-secure transfer=no [radio-g726] type=user disallow=all allow=g726aal2 codecpriority=host context=radio-secure transfer=no [radio-g729] type=user disallow=all allow=g729 codecpriority=host context=radio-secure transfer=no [radio-ilbc] type=user disallow=all allow=ilbc codecpriority=host context=radio-secure transfer=no ....For your setups, take a look at the CODEC definitions in the [radio] stanza. Also, you can have multiple stanzas (like above), and force various nodes to connect with a specific CODEC, etc. I run this style setup on all my systems. 73, David KB4FXC On Thu, 8 Feb 2018, 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@lists.allstarlink.org http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://lists.allstarlink.org/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.
Will, You are correct that the [radio*] stanzas are for incoming connections, at least as they are used by AllStar. I haven't looked the iax2 driver code over, but, empirically speaking, the CODECs listed in in the "allow=" don't seem to be used in any guaranteed order, even though the iax2 documentation says otherwise. I've tried combinations of "bandwidth=" and "codecpriority=" settings, etc...So, I assume this is a bug---unless I'm overlooking something obvious (anyone got any other ideas?). The only 2 ways (so far!) I've found to guarantee that a certain CODEC is used are: Method 1: ---Only specify a single allowed CODEC for outbound connections. ;;; On the portable node, allow only one CODEC you want: [general] disallow=all allow=ilbc ;;--------------------------------------------------------------- Method 2: ---Allow multiple CODECs for outbound, but connect to a destination stanza that only allows a single CODEC. ;;; On the portable node, your CODEC list: [general] disallow=all allow=ilbc allow=g729 allow=ulaw ;;; On the portable node, your defined nodes: [nodes] abcd = radio-g729@my-abcd-hub.com/abcd,NONE ; Hub stanza --- only g729 wxyz = radio-ulaw@my-wxyz-hub.com/wxyz,NONE ; Hub stanza --- only ulaw ;;; On the abcd HUB: [radio-g729] type=user disallow=all allow=g729 context=radio-secure transfer=no ;;; On the wxyz HUB: [radio-ulaw] type=user disallow=all allow=ulaw context=radio-secure transfer=no ;;;------------------------------------------------------- 73, David KB4FXC On Fri, 9 Feb 2018, Will Bashlor wrote:
Fantastic, thanks David. A couple questions...
How do I specify to use a particular stanza while connecting to a certain node? I thought the [radio] stanza was for incoming connections, no? Since I can't receive incoming connections using my cellular hotspot I didn't think I needed to modify [radio]. At work and home where I have ports forwarded I have a high speed connection, I don't really need to change the codecs as it works great using ulaw. Will KE4IAJ -----Original Message----- From: App_rpt-users [mailto:app_rpt-users-bounces@lists.allstarlink.org] On Behalf Of David McGough Sent: Friday, February 9, 2018 9:39 AM To: Users of Asterisk app_rpt <app_rpt-users@lists.allstarlink.org> Subject: Re: [App_rpt-users] Codec Negotiation Will, iLBC and g729 probably sound best over highly "jittery" mobile networks. Note that the hamvoip iLBC implementation is patched to use 20msec frames, NOT 30msec frames, which are the default in Asterisk. You *MUST* use 20msec frames with AllStar! My patches for Asterisk to add iLBC and use 20msec frames were published years ago. If interested, here is the link: https://hamvoip.org/downloads/patch-kit-with-ilbc.tgz And, here are example iax.conf stanzas, which only allow a specific CODEC: [radio-ulaw] type=user disallow=all allow=ulaw codecpriority=host context=radio-secure transfer=no [radio-g726] type=user disallow=all allow=g726aal2 codecpriority=host context=radio-secure transfer=no [radio-g729] type=user disallow=all allow=g729 codecpriority=host context=radio-secure transfer=no [radio-ilbc] type=user disallow=all allow=ilbc codecpriority=host context=radio-secure transfer=no ....For your setups, take a look at the CODEC definitions in the [radio] stanza. Also, you can have multiple stanzas (like above), and force various nodes to connect with a specific CODEC, etc. I run this style setup on all my systems. 73, David KB4FXC On Thu, 8 Feb 2018, 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@lists.allstarlink.org http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://lists.allstarlink.org/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. _______________________________________________ App_rpt-users mailing list App_rpt-users@lists.allstarlink.org http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://lists.allstarlink.org/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.
participants (3)
-
Benjamin Naber -
David McGough -
Will Bashlor