Rationale behind the RTCRtpTransceiver

Hi,

I'm trying to figure out which the rationale behind the
RTCRtpTransceiver is. Let me guess please:


- Originally, the m= sections in SDP were indexed by their position in the SDP.

- Later, when referencing m= sections within the SDP was needed (for
example, for the a=group:BUNDLE feature) the a=mid attribute was born,
so m= sections can be referenced by a string name (example:
a=mid:audio).

- But, since a m= section does not define sending or receiving stuff
but a mixture of both (I signal which SSRC values I will sent to you
and also which Payload Types you must send to me) the a=mid values
must be shared by both endpoints.

- Later it happens that demultiplexing RTP packets based on their
SSRCs is not cool. The eternal and tiresome argument is that a SSRC (a
32 bits integer!!!) can collide, so the sender can change the SSRC at
any time without having to signal it to the remote peer.

- So the RTP MID Header Extension was born. It carries, on every RTP
packet, the same value as the indicated in the SDP a=mid attribute.

- Then, WebRTC takes both the RTCRtpSender and RTCRtpReceiver objects
from ORTC, and provides some methods to the RTCPeerConnection to
retrieve the associated RTCRtpSender/RTCRtpReceiver objects.

- But, due to their definition, both RTCRtpSender and RTCRtpReceiver
can have their own MID value, so here the problem arises because SDP
requires that a=mid is shared for sending and receiving within the
same m= section.

- And here is when RTCRtpTransceiver borns. It's an artificial
combination of both a RTCRtpSender and a RTCRtpReceiver that share the
same MID (due to SDP requirements) and represents both directions of
the media flow within a m= section.



Am I right?
Thanks a lot.


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

Received on Friday, 13 May 2016 18:56:34 UTC