Re: Rationale behind the RTCRtpTransceiver

The conclusion in your last bullet point (grouping a sender and receiver)
is definitely one of the reasons. Of course, this could be accomplished by
exposing a "mid" attribute on senders and receivers and having them
implicitly grouped. But it seems better to make it explicit.

In addition, I think the core things that would not be possible without the
transceiver API (and without SDP munging) are:

   - Stopping a transceiver (setting the port of the m= line to 0)
   - Explicitly controlling which media descriptions are used for
   senders/receivers, and controlling their directional attribute. For
   example, creating one sendonly and one recvonly media description.
   - Setting the codec preferences. Since they're shared between sender and
   receiver, it would only make sense to have this API on a transceiver.

There may be other reasons, but these are the main ones I recall.

On Fri, May 13, 2016 at 11:55 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> 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>
>
>