Unwanted reorder or fast busy tone

K6MBY · August 24, 2026, 3:41am

Subject: Rhythmic ~2Hz "fast busy/reorder"-style tone injected into audio bridge only when linktolink duplex=0 link is established — persists across two different RIM devices, all gain/duplex settings, unrelated to downstream hardware

Setup:

ASL3, Raspberry Pi
Node 1998: Voter/1998 — receiver-voting node (BridgeCom BCR + MT500 RTCM clients), duplex = 2
Node 1996: SimpleUSB/usb_1996 — USB RIM interfacing into an Arcom RC210 port, duplex = 0 in rpt.conf, linktolink = yes (the documented special case for interfacing with an external multiport controller)
Linked via: rpt cmd 1998 ilink 3 1996 (transceive)

Symptom:
A rhythmic tone — described by ear as sounding like a telco fast-busy/reorder signal — begins the moment the 1998↔1996 link is established and continues indefinitely (only clears on a full systemctl restart asterisk). Specifics:

Absent when node 1996 is up standalone, before the link to 1998 is made — only appears once bridged
Rides on top of real, clean receive audio (tested with a calibrated RTCM, 1kHz tone at 3kHz deviation, CTCSS present) — both are audible simultaneously, unaffected by each other
Identical behavior across two different physical USB RIM devices (a generic CM108-based unit and a Masters Communications RA-33)
RPT_TXKEYED on both nodes shows a constant 1 throughout — never flaps — consistent with the documented "Special Case: Full duplex if linktolink is set to yes" behavior, so this isn't a PTT/key-state toggle
Unaffected by: txmixaset (tested 200–900), USB port, physical distance from RF sources, duplex in rpt.conf's [1996] stanza (tested 0 and 2), duplex in simpleusb.conf's [usb_1996] stanza (tested 0 and 1, inherited from [node-main]), propagate_dtmf (tested yes/commented out on both nodes), carrierfrom/ctcssfrom (tested no and usbinvert)
Zero corresponding entries in /var/log/asterisk/messages.log at NOTICE/WARNING level correlating with the tone's timing, even with continuous tail -f capture through multiple full cycling episodes
A separate, unrelated RC210-side issue (Port 1's "Repeater Mode" checkbox) was found and fixed during this troubleshooting — confirmed not the cause, since disabling it did not stop the tone

Config excerpts (rpt.conf, simpleusb.conf, modules.conf) available on request — happy to post directly or via pastebin.

Question: Given the tone only appears once bridged (never standalone), persists regardless of hardware/gain/duplex settings on both sides, and sounds like Asterisk's own Congestion()/reorder indication — is this a known interaction between chan_voter's mix-mode client protocol and the linktolink=yes/duplex=0 softmix bridge? Is there a way to get debug-level tracing on the actual bridge/dial leg between these two channels that would surface in the log?

Happy to provide a debug-level capture, full config files, or test anything else on request.

N8RAW · August 24, 2026, 1:26pm

We added a fix for this in the latest build. Please ping us if 3.10.x does not address it (when it's released, or if you want to try beta, let us know sooner )

K6MBY · August 24, 2026, 3:23pm

This is not a working system at the moment so I would try the beta. Thanks.

Bob

K6MBY

K6MBY · August 25, 2026, 12:31pm

Installed v 3.10.4-1. Confirmed with
$ apt-cache policy asl3-asterisk
asl3-asterisk:
Installed: 2:22.10.1+asl3-3.10.4-1.deb13
Candidate: 2:22.10.1+asl3-3.10.4-1.deb13
Version table:

Update: tested on the new beta release — cycling tone still present, unchanged.

Same reproduction steps as my original report: link established (rpt cmd 1998 ilink 3 1996), tone begins immediately, persists until a full Asterisk restart. No change in behavior, character, or timing that I could detect.

Bob
K6MBY

K6MBY · August 25, 2026, 6:15pm

First, I am not this smart. I am using Claude.ai to help diagnose this issue.

Update: confirmed via spectral analysis — this IS Asterisk's Congestion()/fast-busy indication tone

I recorded the cycling audio using app_rpt's archivedir feature (recording on node 1998) and ran a spectral analysis on the capture. Results:

Rhythmic bursts every ~0.5 seconds, consistent throughout a 195-second recording (354 onset events)
Dominant frequencies: 480 Hz and 620 Hz — this is the exact standard North American telco "fast busy"/reorder tone pair, matching Asterisk's own Congestion() indication as defined in indications.conf

So this isn't a hardware artifact, USB noise, or coincidental buzz — Asterisk is genuinely generating and injecting its own Congestion tone into the audio stream repeatedly while the link is up.

Also worth noting:

The tone is not 100% reproducible on every single rpt cmd 1998 ilink 3 1996 attempt — most attempts trigger it, but occasionally a link comes up clean with no tone at all. This may point to a timing/race condition rather than a purely deterministic config interaction.
Confirmed present on: two different physical USB RIM devices, a beta ASL3 release, and a completely fresh SD card flash of the current stable release with configs restored from a known-good backup — rules out hardware, package-version, and install-state causes.
IAX2 debug logging during a confirmed cycling episode shows completely normal control-plane traffic (standard LAGRQ/LAGRP/PING/PONG cadence, zero retries/errors) — the tone isn't an IAX2 transport issue, it's being generated as actual audio content somewhere in the bridge/channel logic.

Given the tone is specifically Congestion()/reorder — normally played when a call setup or dial attempt fails — this suggests something in the linktolink=yes/duplex=0 bridge path between a Voter channel and a SimpleUSB channel is intermittently hitting a failure/retry condition internally and signaling it audibly, even though the link itself (per rpt lstats) shows as ESTABLISHED and stable the whole time.

Bob

K6MBY

WA3WCO · August 25, 2026, 7:01pm

Q? have you made ANY changes to your /etc/asterisk/extensions.conf file?

Note: an unmodified copy of the file can be found @ /usr/share/doc/asl3-asterisk-config/examples/configs/asl3/extensions.conf)

K6MBY · August 25, 2026, 8:21pm

Confirmed — ran diff against the unmodified copy at /usr/share/doc/asl3-asterisk-config/examples/configs/asl3/extensions.conf and there are no differences at all. My /etc/asterisk/extensions.conf is stock, unmodified.

N8RAW · August 26, 2026, 12:22pm

OK, doing some digging. Not sure "why" this changed at the moment. It's one of those head scratchers.

W5GLE · August 26, 2026, 12:37pm

During an active tone episode:

core show channels verbose — look for a channel with an active generator
bridge show all — which member is feeding TX conf

Provide the following and it will make this easier to debug.

K6MBY · August 26, 2026, 2:27pm

Worth noting on timing: this started specifically when I was testing propagate_dtmf = yes while sending real DTMF tones through an RTCM into the voter node — not just from adding the config line itself (I later tested with propagate_dtmf commented out again, and the cycling persisted regardless). So it may be tied to something about a DTMF sequence being decoded/processed at that time, even though it's not required to reproduce it afterward.

One detail that might matter: my rpt.conf function table has the autopatch codes (61/62 → autopatchup/autopatchdn) commented out/disabled — so I wouldn't expect a DTMF sequence to be able to trigger a real autopatch request through normal function-code handling. That makes the stuck Local/Autopatch@default channel in Ring state (from the core show channels verbose output) more puzzling — not sure what's actually opening it if autopatch isn't enabled.

sudo asterisk -rx "core sudo asterisk -rx "bridge show all"
Channel Recorder/PChan-00000000;2 Recorder/PChan-00000000;1 SimpleUSB/usb_1996 Recorder/MonChan-00000002;1 Recorder/MonChan-00000002;2 Announcer/IAXLink-0000000e;1 Announcer/IAXLink-0000000e;2 Local/LocalTX@default-00000005;2 Local/LocalTX@default-00000005;1 Recorder/MonChan-00000006;1 Recorder/MonChan-00000006;2 Announcer/Telemetry-0000000f;1 Announcer/Telemetry-0000000f;2 Announcer/TXPChan-00000008;1 Announcer/TXPChan-00000009;1 Announcer/TXPChan-00000008;2 Announcer/TXPChan-00000009;2 Local/LocalTX@default-00000001;2 Local/LocalTX@default-00000001;1 Announcer/RXPChan-00000007;1 Announcer/RXPChan-00000007;2 Announcer/IAXLink-0000000c;2 Announcer/IAXLink-0000000c;1 IAX2/127.0.0.1:4569-13724 Announcer/RXPChan-00000003;1 Announcer/RXPChan-00000003;2 Local/Autopatch@default-0000000a;2 Local/Autopatch@default-0000000a;1 IAX2/127.0.0.1:4569-78 Recorder/PChan-00000004;2 Recorder/PChan-00000004;1 voter/1998 Local/GenChannel@default-0000000b;2 Local/GenChannel@default-0000000b;1 34 active channels
1 active call
1 call processed
Bridge-ID 003149f4-4d0e-4ca5-bd04-d4d5dfe1c07e 7ad6d844-481a-426e-b99c-7dce910e172d ae7f7b44-a45f-4376-a96c-42b3a243232f b7e2e667-c674-452c-b08d-9d252bee23e1 show channels verbose"
Context Extension Prio State Application Data CallerID Duration Accountcode PeerAccoun t BridgeID
default s 1 Up (None) (Empty) 00:00:18 b7e2e667-c674-452c-b
default s 1 Up (None) (Empty) 00:00:18
default 1 Up Rpt Repeater Rx 00:00:18
default s 1 Up (None) (Empty) 00:00:18
default s 1 Up (None) (Empty) 00:00:18 ae7f7b44-a45f-4376-a
default s 1 Up (None) (Empty) 00:00:11
default s 1 Up (None) (Empty) 00:00:11 003149f4-4d0e-4ca5-b
default LocalTX 1 Up (None) (Empty) 00:00:18 7ad6d844-481a-426e-b
default LocalTX 1 Up (None) (Empty) 00:00:18
default s 1 Up (None) (Empty) 00:00:18
default s 1 Up (None) (Empty) 00:00:18 7ad6d844-481a-426e-b
default s 1 Up (None) (Empty) 00:00:09
default s 1 Up (None) (Empty) 00:00:09 ae7f7b44-a45f-4376-a
default s 1 Up (None) (Empty) 00:00:18
default s 1 Up (None) (Empty) 00:00:18
default s 1 Up (None) (Empty) 00:00:18 ae7f7b44-a45f-4376-a
default s 1 Up (None) (Empty) 00:00:18 7ad6d844-481a-426e-b
default LocalTX 1 Up (None) (Empty) 00:00:18 ae7f7b44-a45f-4376-a
default LocalTX 1 Up (None) (Empty) 00:00:18
default s 1 Up (None) (Empty) 00:00:18
default s 1 Up (None) (Empty) 00:00:18 003149f4-4d0e-4ca5-b
default s 1 Up (None) (Empty) 00:00:11 b7e2e667-c674-452c-b
default s 1 Up (None) (Empty) 00:00:11
radio-secure 1996 14 Up Rpt 1996 1998 00:00:11
default s 1 Up (None) (Empty) 00:00:18
default s 1 Up (None) (Empty) 00:00:18 b7e2e667-c674-452c-b
default Autopatch 1 Ring (None) (Empty) 00:00:16
default Autopatch 1 Down (None) (Empty) 00:00:16
1996 1 Up Rpt Remote Rx 00:00:11
default s 1 Up (None) (Empty) 00:00:18 003149f4-4d0e-4ca5-b
default s 1 Up (None) (Empty) 00:00:18
default 1 Up Rpt Repeater Rx 00:00:18
default GenChanne l 1 Up (None) (Empty) 00:00:16 b7e2e667-c674-452c-b
default GenChanne l 1 Up (None) (Empty) 00:00:16
Name Chans Type Technology Dur ation
CONF 3 base softmix 00: 00:19
TXCONF 3 base softmix 00: 00:19
TXCONF 4 base softmix 00: 00:19
CONF 4 base softmix 00: 00:19

N8RAW · August 26, 2026, 3:03pm

Well, these guys (GenChannel) are only supposed to be created in the autopatch code:

Wonder how we are triggering that...

N8RAW · August 26, 2026, 3:13pm

I'm thinking our problem is here:

github.com/AllStarLink/app_rpt

apps/app_rpt.c

cad688ef6


      
          	} else { /* if simple */
          		if ((myrpt->callmode == CALLMODE_DOWN) && (c == myrpt->p.funcchar)) {
          			myrpt->callmode = CALLMODE_DIALING;
          			myrpt->patchnoct = 0;
          			myrpt->patchquiet = 0;
          			myrpt->patchfarenddisconnect = 0;
          			myrpt->patchdialtime = 0;
          			myrpt->calldigittimer = 0;
          			ast_copy_string(myrpt->patchcontext, myrpt->p.ourcontext, sizeof(myrpt->patchcontext));
          			myrpt->cidx = 0;
          			myrpt->exten[myrpt->cidx] = 0;
          			rpt_mutex_unlock(&myrpt->lock);
          			ast_pthread_create_detached(&myrpt->rpt_call_thread, NULL, rpt_call, myrpt);
          			return;
          		}

If we are in "simple" autopatch mode, the local_dtmp_helper is launching the autopatch function...
This is set to "simple" if there is no functions configured.

github.com/AllStarLink/app_rpt

apps/app_rpt/rpt_config.c

cad688ef6


      
          	RPT_CONFIG_VAR(functions, "functions");
          	if (!val) {
          		rpt_vars[n].p.functions = FUNCTIONS;
          		rpt_vars[n].p.simple = 1;
          	}

Something to check/try?

K6MBY · August 26, 2026, 3:23pm

Ran the test with both RTCMs completely disconnected — zero possible DTMF source anywhere in the system, voter node confirmed showing no connected clients. Local/Autopatch@default (Ring/Down) and Local/GenChannel@default still appear identically, ~13 seconds after establishing the link — same as before.

This rules out DTMF entirely. Whatever's opening that autopatch channel happens purely from establishing the link between the Voter node (1998) and the SimpleUSB node (1996) in duplex=0/linktolink=yes mode — no DTMF, no RTCM, no real signal of any kind required.

N8RAW · August 26, 2026, 4:25pm

Can you share your config files with us? Make sure to hide any secrets in there.

FWIW, the DTMF code path is followed with startup scripts.

There are only 2 paths to run the code which creates the GenChannel (that I see).
Option 1 is simple patch mode (shown above)l

Option 2 is using a macro that call autopatchup function under [functions]

Option 1 is "enabled" when there is no [functions] making "option 2" not possilble.

It may help to have a [functions] context and maybe even leave 61 and 62 so that *is not the "only" way to bring up the autopatch.

Another way to "prove" it's in simple mode would be to send a #* on the channel to hangup - that "should" clear the fast busy.

K6MBY · August 26, 2026, 5:12pm

rpt.conf.txt (35.0 KB)

voter.conf.txt (5.6 KB)

simpleusb.conf.txt (8.6 KB)

Sending # does stop the reorder tone.

I un-commented 61 and 62 in functions with no change.

K6MBY · August 26, 2026, 5:30pm

Leaving. Back after 3:30 pm today

N8RAW · August 26, 2026, 6:22pm

OK, I think the rpt.conf is "malformed". I believe the config for [1996] is not seeing the functions=functions config.

Move [1996] and [1998] to the end of the original [node-main](!) template. Keeping your specific config for each node.
Then add (node-main) ->
1996 and
...
1998

...

···

On Wed, Aug 26, 2026 at 2:12 PM Bob <noreply@community.allstarlink.org> wrote:

Someone replied to your post.

| K6MBY
August 26 |

| - |

rpt.conf.txt (35.0 KB)

voter.conf.txt (5.6 KB)

simpleusb.conf.txt (8.6 KB)

Sending # does stop the reorder tone.

I un-commented 61 and 62 in functions with no change.

Visit Topic or reply to this email to respond.

To unsubscribe from these emails, click here.

Bad format - add
[1996](node-main)
...
[1998](node-main)
...

WA3WCO · August 26, 2026, 6:38pm

I would also suggest that you carefully read the ASL Manual : Asterisk Templates page.

Then, take a look at the template configuration files that were packaged with ASL3 and compare those with your modified .conf files :

/usr/share/doc/asl3-asterisk-config/examples/configs/asl3/rpt.conf
/usr/share/doc/asl3-asterisk-config/examples/configs/asl3/simpleusb.conf

If you look at (and understand) your rpt.conf file, your [1998] node is only setting "6" variables.

In your simpleusb.conf file, you set a few variables for [usb_1996] but inherits none of the template settings. I'm also curious about your hiddev = /dev/hidraw0 setting, one that does not exist in ASL3.

... and those are just a few examples of where your configuration files have strayed.

K6MBY · August 27, 2026, 4:43am

Moving the 1996 and 1998 to the end into the template area and adding the [node-main] appears to have fixed the issue. I now get a voice indicating the two nodes are linked.

[1996](node-main)
rxchannel = SimpleUSB/usb_1996
duplex = 0
startup_macro = *31996
startup_macro_delay = 20
linktolink = yes
archivedir = /var/spool/asterisk/monitor
archiveformat = wav

[1998](node-main)
rxchannel = Voter/1998
duplex = 2
archivedir = /var/spool/asterisk/monitor
archiveformat = wav

And Alan, yes, had I read and understood how Asterisk uses templates it would have likely saved the time and frustration

Thank you all for hanging in with me to solve this mistake.

Bob
k6mby

WA3WCO · August 27, 2026, 12:02pm

Excellent.

The templated configurations are "different" from other/older AllStarLink software packages but they do add / offer a lot of flexibility, especially for those with multiple nodes on the same server.