I have been updating our custom client to use unified plan for Chrome and ran into an issue with how Chrome handles early media without the mid header extension (urn:ietf:params:rtp-hdrext:sdes:mid).
After a little digging, it appears this is what is happening (https://bugs.chromium.org/p/webrtc/issues/detail?id=10139). The TLDR is Chrome associates the RTP stream with an m-line using the payload type when it gets the first packet if the ssrc hasn’t been signaled. If RTP packets are received before the client receives a jingle source-add message and renegotiates the peer connection, setLocalDescription will error on that negotiation. This happens because the ssrc was associated with the first m-line that had the same payload type as the first RTP packet instead of the new m-line in the new offer.
Are there any plans to add support for the mid header extension which would help alleviate this issue? Details are below.
- I have two users join the muc room and negotiate the RTCPeerConnection without publishing a stream.
- When user 1 adds a stream, it sometimes works and sometimes Chrome fails to parse the SDP on setLocalDescription
- If that works, the second user adding a stream always causes Chrome to fail parsing the local SDP
Here’s some debug logs from the webrtc stack in Chrome:
[37811:29223:0624/145245.845669:ERROR:rtp_transport.cc(153)] Failed to register the sink for RTP demuxer. [37811:29223:0624/145245.845721:ERROR:channel.cc(259)] Failed to connect to the new RtpTransport. [37811:7195:0624/145245.846045:ERROR:peer_connection.cc(2187)] Failed to set local answer sdp: Failed to process the bundled m= section. [37811:29223:0624/145245.873785:ERROR:rtp_transport.cc(161)] Failed to unregister the sink for RTP demuxer.