Interesting to learn some of the workings of iax.conf. I'm aware of the rest, however, I would encourage iax.conf is modified to have the following priorities for every connection stanza: ulaw g726aal2 gsm this is to ensure audio quality is better than IRLP and echo-stink. If you cannot tell the difference, listen to a conversation on a local repeater, and the same conversation with the convenient delay over IRLP or echo-stink. You may then remember in days-past of analog cellular listening to the person on the other end had more body and fidelity. Regarding bandwidth, be it a DSL or mobile connection, this should be a non-issue. Even 1G cellular data connection will support two full-duplex uLaw streams. For hub nodes, 30 ulaw streams is right around 2.25Mbits. If this is a concern, perhaps the owner of the hub should really consider putting the node elsewhere. That's like trying to put a Pinto engine in my E-350 and expecting it to work the same. Considering jitter and packet loss if it is thought a higher bandwidth codec will cause this, such is not the case. This is the cause of little or no implementation of Qos/ToS in the WAN facing side of a router. There are other external considerations, but those are outside the scope of this thread. While on that subject a brief description of an example is the node at my home. My connection, fortunately, has maintained +25Mbps down and 5Mbps up, I've have zero issues with jitter and packet loss with QoS implemented, even while the kids are watching netflix, skyping, and watching something on youtube.... all at the same time. On 03/06/2017 11:08 PM, David McGough wrote:
Hi Benjamin,
If you want to only use the G.711 CODEC, only allow that one CODEC at your end. But, be aware that may not be compatible with all hubs out there. Also, be aware that if you do NOT run the same CODEC as that which is preferred by a given hub, you'll likely end up with poorer audio due to transcoding.
If you only want G.711, set your config such as:
[whatever_stanza] disallow=all allow=ulaw
....On a side note, while I agree with you that the Asterisk GSM and speex CODECs presents lower quality audio, with many others (such as G.726 and iLBC), you would be hard pressed to tell the difference between them, with repeater audio. If fact, I'm not sure _I_ could tell the difference in a blind A/B test.
Another factor to consider is the hub bandwidth used for EACH audio stream. This is a BIG deal for hub out-bound bandwidth. Here are results from actual measurements on my hub:
One IAX2 half-duplex stream. All results in Kbytes-per-second:
GSM 3.2 iLBC 3.5 G726 5.5 ULAW 9.4
These data rates will be in-bound or out-bound, depending of if your local node is listening or talking to another node across the VoIP network. If you have 30 nodes connected to a hub, the total bandwidth required is 31 times the above numbers---30 out-bound listeners + 1 in-bound talker.
73, David KB4FXC
On Mon, 6 Mar 2017, Benjamin L. Naber wrote:
While reading an email from another VoIP email reflector, I got to thinking about some of the codecs we use.
Perusing through the iax.conf through a few allstar network linking distros, each seem to have their own preferred set of codecs.
I'm rather disturbed that iLBC and speex remains in any of them, while I'm sure for compatibility of older installations. However, low quality bandwidth codes sounds no better than echo-stink. This is one of the reason why we use Allstarlink, for better audio quality, is it not?
As I connect to different allstar nodes throughout the world, more-so in the US, some are using iLBC or gsm... and a majority are hub nodes. This to me, is unacceptable, and appears the codec being used are whatever the allstar box has been packaged with.
So, given than I'm not a Steve Henke or Steve Zingman, but I want to ensure that I'm doing my part to achieve high fidelity through g711 codec and proper URI <-> radio hardware interfacing techniques.
Which stanza in the iax.conf is for out-going connections?
I was under the impression [radio-proxy] was, however, when a node with: disallow=all allow=ulaw allow=g726aal2 allow=gsm
connects to my node which has the *same* key=value pairs under [radio] stanza, I got the message something along the lines of:
connected: IP codes available: g726aal2/gsm host codecs available: ulaw|g726aal2|gsm|ilbc actual codec: g726aal ...
bost sides do not have ilbc *anywhere*. The codec has been removed/deleted. Why does it still show up?
What is the ultimate deciding factor of which codec is used if both side have codecpriority=mine?
~Benjamin, KB9LFZ
_______________________________________________ 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.
Here is a link to the default iax.conf in DIAL <https://github.com/N4IRS/AllStar/blob/master/configs/iax.conf> 73, Steve N4IRS On 3/7/2017 12:59 PM, Benjamin L. Naber wrote:
Interesting to learn some of the workings of iax.conf.
I'm aware of the rest, however, I would encourage iax.conf is modified to have the following priorities for every connection stanza: ulaw g726aal2 gsm
this is to ensure audio quality is better than IRLP and echo-stink. If you cannot tell the difference, listen to a conversation on a local repeater, and the same conversation with the convenient delay over IRLP or echo-stink.
You may then remember in days-past of analog cellular listening to the person on the other end had more body and fidelity.
Regarding bandwidth, be it a DSL or mobile connection, this should be a non-issue. Even 1G cellular data connection will support two full-duplex uLaw streams.
For hub nodes, 30 ulaw streams is right around 2.25Mbits. If this is a concern, perhaps the owner of the hub should really consider putting the node elsewhere. That's like trying to put a Pinto engine in my E-350 and expecting it to work the same.
Considering jitter and packet loss if it is thought a higher bandwidth codec will cause this, such is not the case. This is the cause of little or no implementation of Qos/ToS in the WAN facing side of a router. There are other external considerations, but those are outside the scope of this thread.
While on that subject a brief description of an example is the node at my home. My connection, fortunately, has maintained +25Mbps down and 5Mbps up, I've have zero issues with jitter and packet loss with QoS implemented, even while the kids are watching netflix, skyping, and watching something on youtube.... all at the same time.
This may be of interest as well: http://docs.allstarlink.org/drupal/node/15 On Tue, Mar 7, 2017 at 10:15 AM, Steve Zingman <szingman@msgstor.com> wrote:
Here is a link to the default iax.conf in DIAL
<https://github.com/N4IRS/AllStar/blob/master/configs/iax.conf>
73, Steve N4IRS
On 3/7/2017 12:59 PM, Benjamin L. Naber wrote:
Interesting to learn some of the workings of iax.conf.
I'm aware of the rest, however, I would encourage iax.conf is modified to have the following priorities for every connection stanza: ulaw g726aal2 gsm
this is to ensure audio quality is better than IRLP and echo-stink. If you cannot tell the difference, listen to a conversation on a local repeater, and the same conversation with the convenient delay over IRLP or echo-stink.
You may then remember in days-past of analog cellular listening to the person on the other end had more body and fidelity.
Regarding bandwidth, be it a DSL or mobile connection, this should be a non-issue. Even 1G cellular data connection will support two full-duplex uLaw streams.
For hub nodes, 30 ulaw streams is right around 2.25Mbits. If this is a concern, perhaps the owner of the hub should really consider putting the node elsewhere. That's like trying to put a Pinto engine in my E-350 and expecting it to work the same.
Considering jitter and packet loss if it is thought a higher bandwidth codec will cause this, such is not the case. This is the cause of little or no implementation of Qos/ToS in the WAN facing side of a router. There are other external considerations, but those are outside the scope of this thread.
While on that subject a brief description of an example is the node at my home. My connection, fortunately, has maintained +25Mbps down and 5Mbps up, I've have zero issues with jitter and packet loss with QoS implemented, even while the kids are watching netflix, skyping, and watching something on youtube.... all at the same time.
_______________________________________________ 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/c gi-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.
-- -- Tim
Larry, The order of the codecs in the list, in the order specified by the allow statements. I think the question stems from in the fact that at the top of the Drupal the explanation is for the general section of iax.conf. Further down the where the radio stanza is explained, the order is explained. 73, Steve N4IRS On 03/08/2017 03:03 AM, larry wrote:
Steve,
Since the 2 links referred to have GSM - on the Drupal link listed as the first codec and the Github link lists GSM codec last in the allow sequence. I need to ask when nodes begin negotiating is it done using the order of the codec in the allow list?
Larry - N7FM
On 03/07/2017 07:18 PM, Tim Sawyer wrote:
This may be of interest as well: http://docs.allstarlink.org/drupal/node/15
On Tue, Mar 7, 2017 at 10:15 AM, Steve Zingman <szingman@msgstor.com <mailto:szingman@msgstor.com>> wrote:
Here is a link to the default iax.conf in DIAL
<https://github.com/N4IRS/AllStar/blob/master/configs/iax.conf <https://github.com/N4IRS/AllStar/blob/master/configs/iax.conf>>
73, Steve N4IRS
On 3/7/2017 12:59 PM, Benjamin L. Naber wrote:
Interesting to learn some of the workings of iax.conf.
I'm aware of the rest, however, I would encourage iax.conf is modified to have the following priorities for every connection stanza: ulaw g726aal2 gsm
this is to ensure audio quality is better than IRLP and echo-stink. If you cannot tell the difference, listen to a conversation on a local repeater, and the same conversation with the convenient delay over IRLP or echo-stink.
You may then remember in days-past of analog cellular listening to the person on the other end had more body and fidelity.
Regarding bandwidth, be it a DSL or mobile connection, this should be a non-issue. Even 1G cellular data connection will support two full-duplex uLaw streams.
For hub nodes, 30 ulaw streams is right around 2.25Mbits. If this is a concern, perhaps the owner of the hub should really consider putting the node elsewhere. That's like trying to put a Pinto engine in my E-350 and expecting it to work the same.
Considering jitter and packet loss if it is thought a higher bandwidth codec will cause this, such is not the case. This is the cause of little or no implementation of Qos/ToS in the WAN facing side of a router. There are other external considerations, but those are outside the scope of this thread.
While on that subject a brief description of an example is the node at my home. My connection, fortunately, has maintained +25Mbps down and 5Mbps up, I've have zero issues with jitter and packet loss with QoS implemented, even while the kids are watching netflix, skyping, and watching something on youtube.... all at the same time.
_______________________________________________ App_rpt-users mailing list App_rpt-users@lists.allstarlink.org <mailto:App_rpt-users@lists.allstarlink.org> http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users <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 <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.
-- -- Tim
_______________________________________________ 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 visithttp://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 (4)
-
Benjamin L. Naber -
larry -
Steve Zingman -
Tim Sawyer