About (missing) "direction" in RTCRtpHeaderExtension

I understand the rationale for both, RTCRtpHeaderExtension and
RTCRtpHeaderExtensionParameters, to not include a "direction"
attribute. However I may miss something.

In mediasoup SFU, before clients connect to a room, they receive a
RTCRtpCapabilities from the server with the room capabilities. The
client will use those capabilities to understand what it can send to
the SFU and what it can receive from the SFU.

However I have problems with the RTP MID extension:

- mediasoup can receive RTP packets with MID and use it to demux.
- However, clients MUST not rely on the a=mid value since such a value
is generated locally (in client receiver side) and does not match the
RTP MID value.

The workaround I do in clients is easy: ignore the RTP MID support in
the room capabilities when it comes to receive a track. But this is a
bit ugly since it's like a local exception (trust all the room
capabilities but this one and do not announce RTP MID support in
locally generated remote SDP offers).

The thing is that, to make this more elegant, it seems that the server
room should provide the client separate capabilities for sending media
to the room and receiving media from the room. Both would be the same,
but the receiving ones would not include RTP MID support.

But honestly I do not like this approach. Anyway I understand that
ORTC provides capabilities for both RtpSender and RtpReceiver.

-- 
Iñaki Baz Castillo
<ibc@aliax.net>

Received on Tuesday, 18 December 2018 22:31:44 UTC