Re: Rationale behind the RTCRtpTransceiver

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