ASL3 feature request: Mute transmission on DTMF detect

1

Greetings:
First of all, let me say how excited I am to see ASL3 development. Congrats to the team for doing the amazing amount of work it must have taken to get app.rpt and related modules ported to modern Asterisk, something I wasn’t sure would ever be done.

For as long as I’ve known about ASL (probably about 16 years, though I have only used it for around five), I have always wondered why transmissions continue to be sent to the network when DTMF, particularly the command code, is detected.
Would it be technically possible to just simply stop sending to IAX2/chan_echolink/USRP, etc. when * or whatever the designated command is detected, then process the rest of the string internally? The exceptions, now that I think of it, might be while command mode is activated, and the USRP channel driver.

This would cut down on hold-ups with lots of simplex nodes.
I run a fairly large system (the Blind Hams Network), and often hear people keying up and very, very slowly dialing a DTMF sequence to perhaps disconnect their node. It fails, so they key up and try again. It fails again, either because they dialed so slowly that it timed out between digits, they misdialed, one tone wasn’t recognized for some reason, etc.
Of course, the cleanest thing to do is not use DTMF at all, but not everyone has that option.

My network is mostly comprised of simplex nodes. So each long, slow, agonizing attempt to do whatever it is they’re trying to do prevents most of those nodes from being able to transmit while that is going on.

At least, if transmission to the channel driver stopped on first DTMF detected, they can take as much time as they need to send a command, and we’ll just hear a little blip from the first DTMF, if that much, then nothing. IIRC, this is exactly what echolink does.

Thanks and 73
N2DYI

2

I’ve always wondered about this myself. This would be a great feature.

To minimize my own tones being sent, I use a macro to disconnect all with *51, then re-key and enter my new connection that nobody hears.

3

I have similar mechanisms for myself. I even had a dedicated radio on a second node set up specifically to always hang out in command mode to my primary node, in monitor mode with the transmitter disabled, but that’s a lot of trouble to go through just for that.

4

Asterisk is a PBX. That is the fundamental reason DTMF does what it does. Also, keep in mind, DTMF falseing is a problem on radio circuits. If Allstar muted DTMF as suggested there would be a lot of QSO muting going on.

5

I’m not sure I’ve ever seen Asterisk false DTMF/mute on a QSO. I guess it could happen with some particularly high voices. I have experienced that on phone system installations, where typically there is wider audio coming in than you’ll get from many radios.
Even with that, if you limit mute to just the command character, or even command character plus one, it could still work, and would probably never trip out in practice.

6

If it was doable, the muting should only be performed at the source system (hotspot) and only if configured, so it would not affect upstream nodes/repeaters. The goal would be that hotspot devices could DTMF control their node without passing the audio and interrupting the upstream system.

7

Yes, exactly my point. This is what the real Windows echolink client does, so DTMF control happens locally, as it should, but the transmission is immediately muted for everyone else as soon as echolink hears it’s command tone. I’m not sure if that happens with any tone, or just that one specifically.

8

You should consider requesting this on github. It would require an option to enable and some minor changes in the channel drivers.

Danny