Audio issues with DVSwitch Mobile & RepeaterPhone

AllStarLink
,
1

Setup Information

Asterisk : 22.7.0+asl3-3.7.1-1.deb13
ASL [app_rpt] : 3.7.1

Inquiry - edited 2/19/2026 3:31pm

I have reloaded this about 5x in the last 2 days, I’m running the version above, up to date as of the morning of 2/18/2026 - base install of ASL 3 - no add-on packages, 1 node is setup 68425, users using HT’s have no issues, anyone using RepeaterPhone or DVSwitch mobile have to hold down their PTT to hear me if they don’t hold down the PTT, they can only hear the end tones/telemetry but not my voice - as stated HT’s have no issues it’s only WT users, - Steps I took - fresh install of ASL 3, I setup my node (Full-Duplex 3)(Allscan ANF101/Pi 5), added my Allmon 3 pwd, have not setup Echolink, it can’t be the hardware because the HT’s have no issues at all, I triple checked with the maker also and for that hardware duplex = 3 is the correct choice, If I set it to duplex = 2 DVSwitch Mobile & RepeaterPhone work but then my voice gets transmitted back to me which is what i want to avoid, that’s the reason for duplex = 3 & ChatGPT, Gemini useless, Any help would be greatly appreciated.

KE2HNI - Jeff

2

Jeff:

I’m pretty sure I know what’s going on, and I don’t know the best way to deal with it. I know of a way, but whether you'll want to do this is up to you. Maybe someone else has better suggestions.

Specifically because you are using duplex=3, audio is not repeated by app_rpt. The IAX stanzas that are used by DVSwitch/Repeaterphone, etc. essentially follow all the audio that would be heard by a transmitter directly connected to your node, if one existed, including courtesy tones, IDs and other telemetry.

Because the transmitted audio, that is the audio sent out from your sound fob by app_rpt does not include received audio from the fob in that mode, thus, it is not being repeated, anyone on the other side using a phone client will also get that behavior.

The only way I know to work around this, other than setting another duplex mode and losing your full duplex capability, or use duplex=2 and have a delayed return of your own audio coming back to you, would be to use a second node for WT/DVSM connections, then connect the two nodes together.

You could add a second public node in asl-menu, which would be set up as DAHDI/pseudo (no radio), duplex=0, telemdefault=0, etc. and then establish a permanent connection between the two nodes, then have your WT people use that second node. Disable WT on the first one in the ASL portal so that only the second node works for those types of connections.

The best way to do this would be to extend your existing node number to 0 and 1, then host them on the same server. No need to have separate ports for multiple nodes on the same system.
Set up a startup macro on one of the nodes to connect to the other one, or just connect the two when you want WT access to work.

But, like I said, maybe there is a better way.

3

Thanks for the reply, I understand what you mean but you are correct hats a lot just to get WT working for mobile users, my brother states his full duplex doesn’t have that issue but he uses a different layout, I also updated my description of the issue just in case you want to reread it, thanks again.

KE2HNI - Jeff

4

Why can’t you just use duplex=2? The duplex=3 setting is for a specific use case with repeater hardware that you don’t seem to have.

5

duplex=2 would result in the audio received on local RF being echoed back to RF Tx, ie. the node would then be acting as a cross-band repeater rather than a cross-band full-duplex personal node.

Full-duplex personal nodes are great because you can always hear other users on the system – for example if someone doubles with you – but your own audio is not repeated back to you. ie. it works like a telephone, both sides can talk at any time but your own audio is not echoed back through the speaker. For those who have never used a personal full-duplex node and who find such a concept confusing I would encourage you to read this link - Full-Duplex Communication Benefits

If ASL is failing to forward audio to WT apps that is definitely a bug. And from Patrick’s comments it seems clear this is a known issue. I opened a bug report here ASL not forwarding audio to Web Transceiver clients when duplex=3. · Issue #938 · AllStarLink/app_rpt · GitHub

6

I understand the issue just fine. I’m not sure I agree it’s a bug, but others can weigh in. However the core issue is he is asking about full duplex semantics which is duplex=2. You can’t simultaneously claim you’re having a personal hotspot and serve full duplex audio in ad hoc circumstances because those are orthogonal use conditions based on how it works today. Perhaps we need yet another mode for this particular type of use but at some point sometimes things just are how they are.

7

(Full-Duplex 3)(Allscan ANF101) Is Full-Duplex Hardware. The hardware is meant to use duplex = 3, I don’t want to hear my voice echoing back at me, that’s the point of 3, if i wanted to hear my voice echo back i’d pick 2, but when the hardware is made for 3 , 3 is what you want and yes I fully tested it, on 2, DVSwitch Mobile/RepeaterPhone users can hear me with no issues on 2 but my voice echoes back, the second i switch to 3 they can not, some can hear me if they hold down their ptt button some can’t, so it’s an issue, 3 isn’t supposed to do that

8

Whether on a personal node, or on a repeater node with “in-cabinet” repeat, if someone connects in from WT, the intent there going back to day 1 is that they should hear audio from that node when that node is receiving audio on its local interface. A “Web Transceiver” is no longer in fact a transceiver if it is incapable of receiving audio from other nodes.