[Spce-user] Troubleshooting WebRTC issue with streams and tracks

[Chad Attermann]

Have a very obscure issue with a WebRTC client where after adding a participant to a (3 party) conference call, one of the remote parties can not hear the other remote party, even though the local (WebRTC) party can hear both remote parties. I will hold off on providing all of the gruesome details for now because my issue may just be lack of understanding the correct way to set this up.

I am using RTPEngine 8.5.11 (old version I know which may also part of my problem) with OpenSips 2.4.8, and RTPEngine is performing transcoding between a SIP PBX and WebRTC clients. Long story short, I have narrowed the issue down to the a=ssrc:... lines in the SDP received in the 200 OK from the remote party like below.

a=ssrc:1910649337 cname:LirHOpuAITzItxG3
a=ssrc:1910649337 msid:4fc3a69d-d099-4c75-9232-7999ef60dabf 2529d952-5611-4791-8971-d3c9f4995041
a=ssrc:1910649337 mslabel:4fc3a69d-d099-4c75-9232-7999ef60dabf
a=ssrc:1910649337 label:2529d952-5611-4791-8971-d3c9f4995041
When I strip these lines from the SDP then the issue disappears. What I suspect is happening is Chrome WebRTC is using the SSRC to associate the RTP stream with the initial receiver audio track in the peer connection, but the RTP that is actually received from RTPEngine has a different SSRC and is therefore seen as a different "stream". This isn't a problem for a typical call and the WebRTC party can still hear the audio stream fine. It's not until the WebRTC client tries to mix audio between tracks for a conference call, in which case I suspect that track that is being retrieved from the peer connection for mixing is associated with the SSRC from the SDP which is not receiving any packets resulting in the other party not receiving their audio.

I’m also hoping to get a better understanding of how RTPEngine is expected to behave here. What I'm seeing is that RTPEngine (at least when transcoding) is using a different SSRC for the transcoded RTP stream than the one it's receiving in the original stream. This in itself doesn't surprise me and is expected, however I would expect that if RTPEngine was changing the SSRC in the RTP stream, then it would also change all of the a=ssrc:... lines in the SDP to match the new SSRC, but this not happening. It was stated in a different issue that RTPEngine does not touch a=ssrc or a=msid-semantic lines, and I wonder why this is so if it's changing the SSRC in the stream.

Looking forward to hearing back from somebody who can help me understand what is going on here and how I can resolve it. I'm happy to provide much more detail if needed.

Cheers!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20230912/dd002731/attachment.html>