For some reason, all the other attachments did not make it to the bug, so I'm adding them with this comment.

Deleted: Screen Shot 2018-12-21 at 1.24.43 PM.png 39.3 KB

	Screen Shot 2018-12-21 at 1.24.43 PM.png 39.3 KB View Download

Deleted: cr-planb-cr-unified-sdps.rtf 23.0 KB

cr-planb-cr-unified-sdps.rtf 23.0 KB Download

Deleted: cr-unified-webrtc-dump.txt 621 KB

cr-unified-webrtc-dump.txt 621 KB View Download

The Unified Plan client uses mid:0 and mid:1, but when you're translating you're changing this to a=audio and a=video, which means a different mid is being negotiated than the one the transceivers are actually using. I'm suspecting something like this is resulting in packets being dropped on arrival, not knowing which receiver to send them to. So the ICE bytes received increases but not the RTCInboundRtpStreamStats.

Unified Plan uses mids to distinguish packets, I'm not sure how this affects the significance of the SSRCs. Chrome-SDP uses both for backwards-compatibility.

Steve, do you have more input?

mmalavalli@ what happens if you munge the local offer so that the a=mid is "audio" or "video"? Maybe the transceivers end up with the same mid as is negotiated?

I think there's two issues that are compounding to make this not work:

1. The a=mid lines are changed on the Plan B side (this shouldn't be necessary, Plan B works with any offered MID value, not just 'audio' and 'video').

2. The "send" header extensions are pulled from the remote description without modification, regardless of how they are negotiated in the answer (see https://codesearch.chromium.org/chromium/src/third_party/webrtc/pc/channel.cc?l=878&rcl=35a9c6df44461580966b6f6d725db493ff764bce).

So the Plan B side will send RTP packets with the MID header extension and payloads 'audio' and 'video' which are dropped by the Unified Plan side since it expects MIDs '0' and '1'. Funny enough the Unified Plan side will not send with the MID header extension since it gets negotiated out of the answer (which is the Unified Plan side's remote description).

In the mean time, a couple options to work around this:

1. Don't rewrite the MIDs for the Plan B side.

2. Remove the offered MID header extension line from the SDP (looks like a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid).

Thank you so much for your suggestions. Removing the MID header extension line from the translated SDP (unified plan to plan b) did the trick.

However, it is interesting that if the Plan B client is Safari, then Chrome Unified Plan has no problem playing back the remote media without having to remove the MID header extension line from the SDP. I wonder if Safari is ignoring that line and not stamping the MID in the RTP header?

Another question I had was:

If the MID is not stamped in the RTP extension header, does Chrome use the m= line index to map RTP data to a particular receiver? I ask this because, once I removed the relevant SDP line, Chrome unified plan was able to play back remote media even with the  MIDs being changed from "audio" and "video" to "0" and "1" and vice versa.

What version of Safari are you using? It's likely using an older version of libWebRTC that doesn't support the MID header extension at all. That would also happen with older versions of Chrome.

Chrome will still use the a=ssrc lines to demux incoming streams, but it will prefer the MID header extension if it is present.

Updating summary to reflect the triage.

I used Safari 12.0, which is the latest stable version. That is why I was a bit surprised that Safari behaved differently than Chrome in Plan B mode.

So is Chrome dropping packets on arrival "working as intended" and we can close this bug, or do we need to update our code not to pull of header extensions or something else?

Chrome dropping packets with MID values it does not know is required by BUNDLE, so that is working as intended.

The bug here is that a Plan B PeerConnection will send using the MID header extension if the remote side offers it, even though it will generate an answer without the MID header extension.

OK, I'm lowering the priority since this can be worked around and Plan B is about to be considered legacy.