"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.
1 Like

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.

We can use multiple hacks there to make it work without sdes:mid

  • Signal media to bridge after all u-plan receivers will report about sucess O/A.
  • Delay media translation for some time on jvb side.
  • Re-create peerconnection on u-plan receivers using offer with new medias.
    All of this hacks is not best ideas, but can give some time.

Yeah, we thought of the first two workarounds. We tried something similar to the second option. We try setting channelLastN to 0 when a client joins the call and then only increase it when a new track is added to the peer connection.

It does appear to successfully work around the bug mentioned above but now we see another issue. If the sender stops sending (changing the transceiver direction to recvonly and calling sender.replaceTrack(null)) and then publishes again (changing the direction back to sendrecv and calling sender.replaceTrack(newTrack)), the receiver gets a gray stream (track is muted). This seems to be a bug with last-n and Chrome unified plan. The issue doesn’t seem to happen in Firefox (though we have seen other last-n related issues in Firefox)

We are unable to delete stream at some point here, and RTPSender track replacement works not correctly. So we need to signal new stream somehow i think.