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?
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
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:
I used tcpdump to verify that RTP packets are reaching Asterisk.
Verified the codec conversion from PCM to ULAW is correct.
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?
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)
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.
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:
The source IP address/port of the media you get from Asterisk
The UNICASTRTP_RTP_LOCAL_PORT and UNICAST_RTP_LOCAL_ADDRESS channel variables which are returned when the external media channel is created