Should not announce RTP MID extension support for "recv" transport

[ibc]

mediasoup can read RTP MID values in received packets to match the corresponding Producer. However we should not tell the remote Consumers that we support a=mid since the RTP MID value that the remote Consumer will receive will not match the a=mid of its internally generated remote SDP offer.

It seems that Firefox (the only browser supporting MID for now) does not complain if the RTP MID does not match any a=mid, and performs m section lookup based on SSRC. But anyway we should not announce something that we are wrongly using.

[ibc]

ALERT:

This makes Chrome to not receive media from any browser. It works fine with Firefox, and Firefox receives media from Chrome, but Chrome does not receive media from Chrome or Firefox.

[ibc]

So here the problem:

• Even if chrome negotiates MID RTP extension, it does NOT include MID RTP extension in RTP packets.
• When it comes to receive media, if the remote SDP has MID extension support, then Chrome expects to receive a MID RTP value that matches the a=mid value of some m section.
• And if it does not match, it seems that Chrome ignores the packet.

So the solution is in mediasoup-client: Don't include the MID RTP extension in "recv" transports.

[ibc]

This is fixed in mediasoup-client 2.4.2. However, I'll wait a bit before re-enabling MID support in mediasoup (otherwise it would fail for people that have not yet upgraded mediasoup-client to 2.4.2).

[fippo]

Even if chrome negotiates MID RTP extension, it does NOT include MID RTP extension in RTP packets.

Have you filed a bug for this?

[nils-ohlmeier]

How do Chrome <-> Chrome calls work at all if will negotiate it, but not send it and throw away packets with incorrect/missing MIDs?

[nils-ohlmeier]

And yes you are correct that Firefox has not implemented the last pieces for MID support: paying attention to it on received packets and route them based on that.

[ibc]

Hi all, confirmed that I did something wrong yesterday when debugging the packets sent by Chrome. Indeed they do contain MID value.

So the issue (which in fact is not an issue) is:

• If chrome negotiates MID support in the SDP and receives RTP packets with MID value that do not match any a=mid, chrome discards those packets.

I would expect that, since a=ssrc is also signaled in the remote SDP, Chrome would first check the reception SSRC table instead of looking first into the MID table. Or may be it checks first the SSRC table, but since the MID of the packet does not match the corresponding a=mid it discards the packet.

I assume Firefox will behave the same way when MID stuff finished, is this right, @nils-ohlmeier ?

NOTE: Our solution is: in mediasoup-client don't announce support for MID RTP for receiving peerconnections (transports): versatica/mediasoup-client@43e9590

[ibc]

• mediasoup 2.5.2 re-enables RTP MID support again.
• mediasoup-client 2.4.2 disables RTP MID for "recv" transports.

So it's important to upgrade to mediasoup-client 2.4.2 if you also upgrade mediasoup (server) to 2.5.2.

[nils-ohlmeier]

Since MID superseeds SSRC's I think what Chrome is doing is right. If you receive packets with unknown MID's throw them away. SSRC's are pretty pointless if everyone and everything is using MID's, with the one exception being RTX (one of the reasons I'm not a big fan of that feature).

[ibc]

Since MID superseeds SSRC's I think what Chrome is doing is right. If you receive packets with unknown MID's throw them away.

Sounds legitimate.

SSRC's are pretty pointless if everyone and everything is using MID's, with the one exception being RTX (one of the reasons I'm not a big fan of that feature).

I don't agree here:

• MID identifies the m section, which means a MediaStreamTrack.
• An m section may carry multiple streams (ssrcs) for simulcast and/or RTX and/or FLEXFEC.
• All those ssrcs should carry the same MID value.
• Then, in the receiver, once the m section has been matched (via packet's MID) it should check the ssrc to match the stream (if the ssrc is signaled) or other RTP header extensions such as RID (for simulcast) or RRID (for RTX in simulcast).