Hi, I’m using Asterisk as the core to run end to end tests. As part of the setup I’m using external media to process the audio. The setup looks like this:
external media <----------> bridge (simple_bridge) <----- sip channel -----> target system
Asterisk is being controlled via ARI. The behaviour I’m facing is, if the target system changes the RTP SSRC, audio doesn’t make it into the bridge and events like ChannelStartedTalking and ChannelStoppedTalking stop firing on the target system channel.
RTP debug shows the marker bit being set with the log message RTP forcing Marker bit, because SSRC has changed, I also see the marker bit being sent from the target system on SSRC change. Verbose and debug don’t seem to show any indication of frames being dropped and Asterisk continues to exchange RTP.
I’ve managed to work around the behaviour by detecting lack of audio at the external media end and re-bridging (remove + add) the target system channel. This causes RTP to flow into the bridge and *Talking events to continue firing.
Is the target system being badly behaved and should Asterisk tolerate it?
First I would not use the Debian package, as they have opted to include patches that we have reverted or rejected so personally I don’t trust it. (In particular a change in transcoding for packet loss that multiple people have posted on here with where audio stops flowing due to it)
Secondly you should provide an actual SIP trace, packet capture, and debug level log.
Indeed nothing does show up, but I would still prefer Asterisk as we ship it tested instead. Additionally can you clarify this statement. What does “continues to exchange RTP” mean if audio is being dropped?
Asterisk continues to exchange RTP with the target system at the network level, but the RTP from the target system doesn’t make it into the bridge and onto the external media application, *Talking events also stop firing on the target system channel.