"Failed to process the bundled m= section." in Chrome using unified plan with the JVB/jicofo

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.

The Scenario:

  • 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.

Hi there!

Thanks for the detailed bug report.

At a first glance this seems like an item we’d need to take of when moving to Unified Plan and mid + rid based simulcast. We do have plans to get there, but cannot provide an ETA, sorry.