Playing Sound to Mixing Bridge and Removing/Adding Channels

Asterisk Asterisk APIs
1

I believe this is a bug but wanted to reach out to the community first to see if anyone had a workaround or thoughts.

I am using ARI to control call state, tested on versions 22.9.0 and 23.3.0. I am trying to migrate from v18 to v22.9.0 and this issue does not exist in v18.

Reproduction Steps: 2 channels and 1 mixing bridge

  1. Place call into asterisk dial plan reaching an extension that answers and hands control to a stasis application.
  2. Create a mixing bridge in the stasis application
  3. Add the new channel (channel A) from dial plan to the mixing bridge.
  4. Play a sound to the mixing bridge (this creates the issue)
  5. Originate a new channel (channel B) via ARI dial.
  6. Remove channel A from the mixing bridge (everything works if I dont remove the channel)
  7. Add channel B to the mixing bridge
  8. Add channel A to the mixing bridge
  9. Channel B can hear Channel A but not vice versa, audio does not flow correctly.

This is a simplified version reproducing the issue.

Attached is a very small .Net CLI program that shows the reproduction steps. Should be easy to read.

Program.txt (3.3 KB)

2

You need to provide logs:

And configuration.

3

Debug logs of the test app reproducing the issue.
Log deleted, see new log below.

rtp.conf only has rtpstart and rtpend set.

I am using udp for SIP/RTP so no sdes/dtls or tls

my-test-device endpoint
disallow all
allow ulaw
dtmf_mode=auto
context=from-internal

my-test-trunk endpoint

disallow=all
allow=ulaw
dtmf_mode=auto
context=from-internal

extensions_ari.conf

[from-internal]
exten => 9000,1,Answer()
same  = n, Set(JITTERBUFFER(adaptive)=default)
same  = n, Stasis(test-cli-stasis-app)
same  = n, Hangup()
4

Hopefully I captured enough info. Let me know if you want me to do something like core show channel channelId while a call is active. Every time I looked at it the state was sendrecv and not sendonly for example.

5

Forgot to clarify this is not behind a NAT or PAT, all LAN.

6

What does “rtp set debug on” show? Is media flowing? And this Asterisk was built by you?

7

Correct, media is flowing. I did a tcpdump earlier and the pcap file showed silence from asterisk to the inbound channel even though I was talking on the outbound channel.

I’ll do another capture later this evening using the new asterisk version.

I built it using the tar files from the releases page. It’s on debian 12 bookworm.

8

I’d also suggest removing the JITTERBUFFER and seeing if that alters things as a data point.

9

Here is a new log with rtp debug on, and debug/verbose at 5. I also sent a rtp pcap since its easier to work with in wireshark. Jitterbuffer was removed as well for this test.

I had to change the file extension on the pcap to txt to be able to upload it.

asterisk-test-rtp-pcap-2026-05-01.txt (212.0 KB)
asterisk-test-debug-log-2026-05-01.txt (598.3 KB)

10

You’d need to provide a guide of what the IP addresses are, what ones are expected. I would also suggest adding “direct_media=no” to your endpoints to ensure media flows through Asterisk and not directly (which may have happened).

11

And to also confirm, you have applied no patches to Asterisk - correct?

12

Correct, no modifications. Strictly the tar file and config changes.

13

I missed the reply earlier.

152.97.91.255 (asterisk)
152.97.91.205 (kamillio server ive been playing with. Not in the network path for media or signaling)
152.97.91.215 (test device)
45.134.67.1 (external sip provider)

I set the endpoints to direct_media=no and the same issue occurred

14

I’d really prefer logs and capture after the change for direct_media=no, not just a confirmation the issue still happened

15

A good next step here would be to re-run the exact same test after setting direct_media=no, but make sure the capture is done at the Asterisk box itself (not just the endpoint side) so you can prove whether RTP is actually flowing through Asterisk or still bypassing it. Also include a short annotated diagram of the call path (who is supposed to send RTP to whom), because with multiple public IPs involved it’s very easy for the real media path to differ from what you assume in config. That combination usually makes it much easier for maintainers like Joshua Colp to pinpoint whether it’s endpoint negotiation or routing behavior.

16

do apologize, should have uploaded new logs. See below:

rtp.pcap renamed to .txt (captured on asterisk)
delete file for security

asterisk log output
– rtp debug on
– pjsip set logger on
– core set debug 5
– core set verbose 5
deleted log file for security

direct_media was set to ‘no’ on the endpoint.

17

So to confirm - is “channel B” the outgoing PJSIP session with 67.231.1.170?

(Side note: You’ve got private IP addresses in the SIP signaling with them)

And that is what you can’t hear?

18

Are you running this in Docker or something with NAT? The logging shows media coming from that channel immediately being sent back out to a private IP address and port:

[2026-05-06 08:50:40] VERBOSE[1003319] res_rtp_asterisk.c: Got RTP packet from 67.231.0.4:42298 (type 00, seq 000336, ts 053760, len 000160)
[2026-05-06 08:50:40] VERBOSE[1003319] res_rtp_asterisk.c: Sent RTP P2P packet to 10.250.99.53:8000 (type 00, len 000160)

Which I can then map in the packet capture to a public IP address on that same port. I see 9 seconds of mostly silence from that side aside from ringing and no forwarding, then Asterisk starts forwarding, another second of silence, and then it looks like actual audio (“Testing”). That comes in, flows through Asterisk, and packets go out.

I also checked the reverse and see audio flowing in and out there as well as expected.

19

Correct, channel B is the outbound channel. Its all LAN routed internally minus the outbound side which reaches out to a sip provider to route the call.

Channel B speaks but Channel A hears nothing but silence. Channel B can hear Channel A.

Channel A ↔ Asterisk ↔ External Sip Provider ↔ Channel B

This does work on asterisk 18. It also works on web rtc with version 22 and 23. It works if I dont play sound to the bridge. As soon as I play sound to the bridge and then move channels around it breaks.

20

The only thing of note is that we set the marker bit when bridging so the remote side knows it is a new stream and can reset things if needed. Otherwise, the packet capture shows the media coming in from 67.231.0.4 port 42298 and Asterisk forwarding it to 152.97.91.215 port 8000 precisely as received.

They could dislike the fact it’s a new stream I guess. It’s behaved that way for a long long time though… I just checked and for 8 years or so including in 18.

Are the conditions absolutely the same between your Asterisk 18 and this? Does it also locally bridge? Same codecs?