Audio Transmission Issues with Simple_Bridge in ARI

Hi ,

I’m experiencing an issue with audio transmission in a bridge of type “simple_bridge.” I have a Python Stasis application that answers a caller’s call, with the goal of receiving the caller’s audio stream (to send it to a Speech-to-Text engine) and also sending an audio stream back to the caller (generated by Text-to-Speech).

When I try to set up a bridge with just the PJSIP channel and the External Media channel, it uses the “simple_bridge” technology, but RTP packets don’t flow in either direction. However, if I add a dummy third channel to the bridge, it switches to “softmix,” and then RTP packets start transmitting correctly.

Why do I need three channels in the bridge for RTP packets to transmit?

Additionally, in my use case where I need both incoming and outgoing audio, does it make sense to use a single bridge with the PJSIP and External Media channels to handle bidirectional audio, or could this setup cause audio conflicts?

Thanks

What does “rtp set debug on” show for the “simple_bridge” case? If you set “rtp_keepalive” on the PJSIP endpoint does it work?

Thanks @jcolp !

Setting rtp_keepalive resolved the issue without needing to add a dummy channel to the bridge.

Could you help clarify the following question? In my setup, where both incoming and outgoing audio are required, does it make sense to use a single bridge with the PJSIP and External Media channels for bidirectional audio, or might this approach lead to audio conflicts?

I’m encountering an issue with sending audio. My goal is to send an echo of the received audio (from the caller’s end), but the caller doesn’t hear anything. I’ve confirmed the RTP packets (sequence numbers and timestamps) are correct and added a 20 ms delay between each chunk. I’m also saving audio from the bridge to files, with each file representing a different audio source (from the caller and my application). Both files sound fine, yet there’s still no audio on the caller’s side.

A single bridge is fine. The fact that “rtp_keepalive” resolved the issue would indicate that something in your environment (such as a firewall) is requiring Asterisk to send media in order to allow it to be received.

You need to provide the output of “rtp set debug on” to show what Asterisk is actually receiving, as well as the ARI interaction for external media creation to confirm the address information - as the target address for Asterisk is in there.

It appears that after removing the dummy channel, audio packets are no longer being sent to the remote SIP. Previously, the dummy channel was likely sending silence packets.

Here are some logs from rtp set debug on:

Sent RTP packet to      127.0.0.1:45000 (type 00, seq 025283, ts 018560, len 000160)
Got  RTP packet from    72.1.47.173:26994 (type 00, seq 037412, ts 018720, len 000160)

The lines above repeat infinitely.

Attached are additional logs from the ARI interaction for external media creation:
audio_issue.txt (17.7 KB)

External Media channel ID in the log is : ARI.892ad.6731ea8ce0c

Also I’m looking at the log from /var/log/asterisk/debug.log
and see:

[Nov 11 11:39:48] VERBOSE[562003][C-0000000e] res_rtp_asterisk.c: Got  RTP packet from    72.1.47.173:30962 (type 00, seq 064348, ts 025440, len 000160)
**[Nov 11 11:39:48] DEBUG[562003][C-0000000e] res_rtp_asterisk.c: 1731325186.41: pkt:    76 Arrival sec:   1.220  Arrival ts:       9759  RX ts:      25440 Transit samp: -15681 Last transit samp: -15681 d:    0 Curr jitter:      -0(  0.000) Prev Jitter:       0(  0.000) New Jitter:       0(  0.000)**
[Nov 11 11:39:48] VERBOSE[561981] res_rtp_asterisk.c: Sent RTP packet to      127.0.0.1:45000 (type 00, seq 015851, ts 025440, len 000160)```

What is this jitter ? does it should be there?

That’s a debug message. If you look at debug messages you’re going to think you see issues when they’re just informational.

If Asterisk doesn’t say it “Got RTP packet from” the ARI application then:

  1. The ARI application is not sending it to the correct IP address+port
  2. A firewall is blocking it

According to the logging it should have sent RTP to:

127.0.0.1 port 39456

@jcolp - You’re totally correct, thanks

The echo functionality is working correctly. Now, I’m trying to simulate a real use case where the caller speaks first, and only then the machine responds.

Here’s my setup:

  • I have a method that reads an audio file and sends it to Asterisk after a short delay (3 seconds) from when the call is initiated.
  • During the initial 3 seconds, media flows in only one direction: PJSIP (Caller) → Asterisk → External Media.
  • After 3 seconds, the send_audio method triggers and starts sending audio back to Asterisk. However, I don’t hear any audio on the caller’s side.

Here’s what I’ve checked:

  1. I used tcpdump to verify that RTP packets are reaching Asterisk.
  2. Verified the codec conversion from PCM to ULAW is correct.
  3. In the Asterisk CLI, I don’t see any log output showing that audio is being sent to the remote SIP endpoint.

Could this issue be related to the fact that I’m not sending audio from the start of the call?

This is essentially the same issue as before echo was fixed. What is the actual output of “rtp set debug on” and provide an Asterisk debug log.

According to the Asterisk CLI, it seems that RTP packets are not arriving as expected.

Example output from the Asterisk CLI:

Got  RTP packet from    72.1.47.173:11510 (type 00, seq 047370, ts 052800, len 000160)
Sent RTP packet to      127.0.0.1:45000 (type 00, seq 003300, ts 052800, len 000160)

However, using tcpdump, I can see RTP audio flowing in both directions. (This is actually how I initially noticed an issue with echo, as the packets were previously flowing in only one direction.)

Example output from tcpdump:

13:22:53.202266 lo    In  IP localhost.45000 > localhost.45000: UDP, length 172
13:22:53.215827 lo    In  IP localhost.32996 > localhost.45000: UDP, length 172

Here’s a snippet from the Asterisk log, showing more details (full call log is attached):

[Nov 11 13:27:52] VERBOSE[564782][C-00000029] res_rtp_asterisk.c: Got  RTP packet from    72.1.47.173:30642 (type 00, seq 026719, ts 032320, len 000160)
[Nov 11 13:27:52] DEBUG[564782][C-00000029] res_rtp_asterisk.c: 1731331668.127: pkt:   121 Arrival sec:   2.120  Arrival ts:      16960  RX ts:      32320 Transit samp: -15360 Last transit samp>
[Nov 11 13:27:52] VERBOSE[564787] res_rtp_asterisk.c: Sent RTP packet to      127.0.0.1:45000 (type 00, seq 031084, ts 032320, len 000160)

updated.log.txt (188.0 KB)

Could this be the issue?

With the limited information, I would say you are not sending the packets to Asterisk. If you were then there would be packets going to localhost port 32996.

Thanks,

I’m not sure I fully understand this comment, so apologies if I’m missing something.

If I’m creating an ExternalMedia channel on port 45000, my understanding is that my client should be listening for packets on UDP port 45000 and sending packets back to the same address and port (45000).

Asterisk is handling audio exchange with the remote SIP endpoint on port 30642, but internally it should be communicating with my client over port 45000. Am I misunderstanding something here?

That is incorrect. Each side (your ARI application AND Asterisk) have independent IP address and port. The IP address and port to send packets to Asterisk can be determined either:

  1. The source IP address/port of the media you get from Asterisk
  2. The UNICASTRTP_RTP_LOCAL_PORT and UNICAST_RTP_LOCAL_ADDRESS channel variables which are returned when the external media channel is created

@jcolp

You were right again! Everything is working now. Thanks so much for your help with this issue.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.