Re: Rationale behind the RTCRtpTransceiver

Den 13. mai 2016 20:55, skrev Iñaki Baz Castillo:
> Hi,
> 
> I'm trying to figure out which the rationale behind the
> RTCRtpTransceiver is. Let me guess please:


I thought you'd been around longer than what your guessing indicates...

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

Correct. RFC 2327, 1998. (Note that discussions and decisions usually
occur years before RFCs are published, so quoting publication years is
just a way of saying "way before that").

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

Yes, but not because of BUNDLE.

a=mid: RFC 3388, 2002.

First BUNDLE draft (draft-holmberg): April 2012. So ten years later.

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

Yes, but this is a property of SDP. True since 1998.

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

This is a property of RTP. See "SSRC collision", RFC 1889, 1996, chapter 8.
So "later" was in fact "earlier". VERY much earlier.

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

My way of putting it: RTCRtpTransceiver is where the results of using
SDP for negotiation are surfaced. It's a way of keeping those results
away from RTPSender and RTPReceiver.

Your mileage may vary.

> 
> 
> 
> Am I right?


Read history. You may become righter.

> Thanks a lot.
> 
>

Received on Saturday, 14 May 2016 13:20:13 UTC