W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2016

Rationale behind the RTCRtpTransceiver

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Fri, 13 May 2016 20:55:46 +0200
Message-ID: <CALiegf=WF0ctXEPG03V39rEqYAn3HPmeM8-cVdwEaQiNBSbt6w@mail.gmail.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>

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:

- 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
Received on Friday, 13 May 2016 18:56:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:16 UTC