I have posted this on DVSwitch Mobile discussion group, and Steve is looking into it. I thought I’d post here too in case someone has some insight from the ASL3 side.
I’ve come across an issue with DVSwitch Mobile and the new ASL3 release. So far, I’ve only seen this when using DVSwitch Mobile. Previous versions of ASL seem to connect to ASL3 and without this issue. DVSM in WT Mode seems okay too.
DVSwitch Mobile Version 2.0.4(190)
ASL3 Raspbery PI image: Asterisk 20.8.1+asl3-3.0.0-1.deb12 built by builder @ allstarlink.org on a aarch64 running Linux on 2024-06-13 23:09:36 UTC
The ASL3 server is configured with SimpleUSB or dahdi/pseudo rxchannel settings. I tried both. The CODECs in iax.conf are unchanged from install, ulaw, adpcm, gsm.
In DVSM I have an account configured for IAX2 using register.allstarlink.org and my allstar node number 515401. The DVSM account CODEC can be set to server selected or uLaw.
When I connect to the ASL3 server, CPU usage goes much higher, and this warning is continuously output on the Allstar CLI console and in /var/log/asterisk/messages.log
[2024-07-05 14:37:55.105] WARNING[1441] chan_iax2.c: No voice format and no peer format available on IAX2/166.173.57.255:56864-13152, backlogging frame
If I change the DVSM account settings to use ADPCM, this warning is not logged, and CPU usage is normal on the ASL3 server. I can also use WT Mode in DVSM without seeing this issue.
I suppose, even if this ends up being a DVSM bug, perhaps ASL3 should not be logging this warning continuously with high CPU usage.
The warning is logged in messages.log so fast it fills the (32MB) asterisk log disk within seconds or minutes.
The logged warnings and high CPU stops immediately when the remote DVSwitch Mobile node transmits back to the ASL3 node. All seems to continue working normally, until the DVSM node disconnects and reconnects.
Looking at the source of this warning message, I found it in the Asterisk source for chan_iax2.c in the “__get_from_jb” function. It would seem that “voicefmt” is not being set properly, at least not until some frames are received. And the fallback code (above this code snippet) to set to the negotiated format isn’t succeeding either. I have no idea why the message loops and drives CPU usage up, but it would seem the goto cleanup isn’t cleaning up everything.
> if (!voicefmt) {
> /* Really shouldn't happen, but if it does, should be looked into */
> ast_log(LOG_WARNING, "No voice format and no peer format available on %s, backlogging frame\n", ast_channel_name(pvt->owner));
> goto cleanup; /* Don't crash if there's no voice format */
> }
DVSwitch Mobile is configured for “Server Selected” CODEC. The error message repeats until I transmit from DVSwitch Mobile, at which time the ASL3 node logs "Call accepted…(format ulaw)…
If I set the DVSwitch Mobile CODEC to ULaw, the same problem occurs. However, if I set the CODEC to ADPCM or SLIN (with SLIN enabled on the ASL3 node), then the connection completes normally without the logged error and high CPU usage.
The ASL3 log shows “requested format = Unknown,” when this issue occurs. But completes setting the connection format after I transmit from DVSwitch Mobile.
The log shows “requested format = ADPCM,” or requested format = slin," when DVSwitch Mobile is set to use ADPCM or SLIN, without first having to transmit from DVSwitch Moble…
David, once again, have you checked the codec modules
are loading/enabled in modeules .conf ?
It does not matter which side is negotiating for a format you are telling it that it could use if that does not actually exist.
Take a moment to verify in the file. Perhaps even a typo in the file.
Yes, the CODECs are enabled and loading. This is on two standard/basic ASL3 installs. No CODEC customization, other than when I allowed SLIN while testing CODEC settings on DVSwitch Mobile. One is on a Raspberry-PI. The other a Debian 12 VPS VM.
It seems DVSwitch Mobile is failing to provide proper CODEC negotiation information upon connection, except when ADPC or SLIN are selected on DVSwitch Mobile. ASL3 doesn’t seem to handle missing CODEC information gracefully, and starts continuously logging warning messages, which makes asterisk CPU bound, until DVSwitch Mobile PTT is cycled.
I"m told DVSwitch Mobile is working on a fix at their end. That was quite some time ago. ASL3 should also be updated to gracefully handle this scenario too. Otherwise, ASL3 nodes are exposed to denial of service.