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

Re: Rationale behind the RTCRtpTransceiver

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Fri, 13 May 2016 21:40:22 +0200
Message-ID: <CALiegfm=FRvncUiKCrTb1d0kB-Fuo1N1kgoMp1GsRz4cVdKctA@mail.gmail.com>
To: Taylor Brandstetter <deadbeef@google.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
Thanks for your reply. Comments inline:


2016-05-13 21:24 GMT+02:00 Taylor Brandstetter <deadbeef@google.com>:
> 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)

This is a just-SDP argument. In a better world I'd just need to stop
the desired sender and/or receiver.

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

This is also a just-SDP argument due the fact that a m= section means
something strange (mixture of sending and receiving stuff).

> Setting the codec preferences. Since they're shared between sender and
> receiver, it would only make sense to have this API on a transceiver.

Codec preferences are shared between sender and receiver because SDP
mandates it. Nothing prohibits a better design in which I set my
sender codecs based on the remote capabilities and viceversa, without
needed a 1-1 relationship between my sender and my receiver.

So, to be clear: WebRTC has defined a RTCRtpTransceiver class to just
satisfy some SDP needs. In ORTC there is no RTCRtpTransceiver and
negotiation is still possible.

Thanks.




-- 
Iñaki Baz Castillo
<ibc@aliax.net>
Received on Friday, 13 May 2016 19:41:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:48 UTC