There are still an awful lot of HamVoIP nodes out there, and, for whatever reason, HamVoIP’s default template prefers g726aal2 over ulaw. Some HamVoIP nodes, such as 2462, 60933 and others, will flat out not negotiate ulaw at all, for whatever reason.
so, with ASL’s defaults, you might find yourself using the far less fashionable GSM codec when connecting to a HamVoIP node.
If I wanted my node to sound like Echolink, I’d use Echolink. No, thanks.
To avoid this, I added g726aal2 in priority just under ulaw. The G726 line is commented out by default in ASL’s iax.conf.
Note:
For radio use, there is no practical need to use slin as a codec. You’ll never notice the difference as far as dynamic range when any RF component is involved. However, all my hub nodes connect internally using slin, and I like to do the same wherever it is available.
ASL follows the rules of asterisk as far as I know with codec priority.
Not that you can’t adjust asterisk priorities for a custom fit…
I only use ulaw and gsm as a backup.
If you can’t muster one of those, your not connecting to me.
I have, in fact, brought this silly default configuration up with them several times over the past five years, which went nowhere. It seems that HamVoIP is a dead project these days, so there is probably no chance that this will get fixed until people replace their nodes, so I’m just putting the information out there for folks to do what they will, ignore, or whatever.
FWIW, I don’t allow GSM connections on any of my nodes. I’ve never seen a need for it to exist.
Once a connection is established. How can I tell (Using supermon) which codec is being used… I have on node that a repeater I control connects to but…alas. I can not. Wondering if it’s a codec I don’t have.
I don’t know about Supermon, or Allmon for that matter. Don’t use either of them.
From asterisk cli, you can do
iax2 show channels
and as long as at least one transmission has happened in one direction, you will see the format used.
Here’s an example from one of my not quite up-to-date nodes.
root@asl:/home/patrick# asterisk -rvvv
Asterisk 20.10.0+asl3-3.1.0-1.deb12, Copyright (C) 1999 - 2022, Sangoma Technologies Corporation and others.
Created by Mark Spencer <markster@digium.com>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type 'core show license' for details.
=========================================================================
Connected to Asterisk 20.10.0+asl3-3.1.0-1.deb12 currently running on asl (pid = 472380)
asl*CLI> iax2 show channels
Channel Peer Username ID (Lo/Rem) Seq (Tx/Rx) Lag Jitter J
IAX2/176.58.122.120: 176.58.122.120 radio 15221/05775 00006/00082 00041ms 0000ms 0
040ms ulaw Tx:NEW Tx:ACK
1 active IAX channel
asl*CLI>
I just had to comment with a valid reason for narrow bandwidth protocos. I have set my nodes running that run over LTE modems, to allow only the lower bandwidth protocols. That includes remote mountaintop sites and mobile nodes. So there are valid reasons to do this. Besides, on a repeater which is running FM at 5KHz. deviation, can you really tell the difference? If I were on a VoIP phone with a really nice speaker, sure. However 99% of the time it’s over a narrowband radio.
G726AAL2, which is half the bandwidth of ulaw, still sounds pretty reasonable. I’d guess most people couldn’t tell the difference, unless there is packet loss. Then it’s pretty obvious, at least to me.
GSM, though, is quite metallic and grainy in comparison. It’s also small enough to be used on a 14.4 kbps link.
Like I said, regarding GSM, if I wanted my nodes to sound like echolin, I’d use echolink.
Thus why GSM doesn’t exist in my life, even for bandwidth-saving applications. The compromised sound isn’t worth it for me.
G726aal2 does a good job here. Low bitrate Opus would do an even better job. You could get GSM-type bandwidth usage, but better sound quality.
For mountaintop links on extremely limited bandwidth, I would go no lower than G726AAL2 given the available supported codec list now, and let a remote hub somewhere do the bulk of the work, so you are only dealing with one stream in and out, regardless of how many connections are made to your system.
I did not suggest you use gsm.
I stated that I use it for a backup for those that are under low bandwidth conditions. They will not normally enable ulaw because of that. Times have changed and mobile bandwidth is much better anymore. But I am still setup referencing that in that way.
But do remember that for a inbound connection to be successful, there has to be a matching codec handshake. Do not assume everyone has all of them enabled.
Part of the point I was making that I think you missed.
It is all a matter of personal choice, but has ramifications.
But if you have an issue with how hamviop works, you are better served to take the issue to them, and perhaps get the answers you are seeking.
IF we’re talking about codecs that are fully supported by app_rpt and don’t have additional overhead for no good reason, that would be slin (8kHz 16-bit PCM), though when radios are involved, you’ll practically never hear the difference between slin and ulaw, which is half the bandwidth of slin. You just don’t have the dynamic range over FM such that it matters too much.
So, ulaw, which is the default for ASL, not HamVoIP, is a good default to have.
G722 is twice the sampling rate. Asterisk supports it, but app_rpt is limited to 8 kHz due to limitations with DAHDI, as I understand it, so there isn’t much point beyond perhaps compatibility with some SIP devices to use it. Ditto for slin16, which is raw linear PCM at 16 kHz instead of 8 kHz.
Down at the other end of the scale, you have ilbc and GSM, both of which are obviously compromised.
To be fair though, most probably wouldn’t notice the difference between ulaw and g726, which is again half the bandwidth of ulaw. I definitely notice when there is packet loss, though. Something about the frame boundaries of that codec makes a weird sound that, once you’ve heard it, you can’t unhear it.
The largest reason to use ulaw is almost everyone has it set and you do have to handshake and negotiate a codec. Asterisk documentation explains this.
You will see the need to allow for more than one in a negotiation. But you can prioritize.
But that should not deter you if making specialized private links based on need.
I can’t speak to what hamvoip does or does not do and may be different.
I see no methods in ASL that is contrary to Asterisk codec hankshaking.