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

Re: Rationale behind the RTCRtpTransceiver

From: Peter Thatcher <pthatcher@google.com>
Date: Fri, 13 May 2016 13:31:10 -0700
Message-ID: <CAJrXDUG4cJS-AC6LTnA5+=-ucZHraUcESbziX4Noz=HcoJa6rw@mail.gmail.com>
To: Taylor Brandstetter <deadbeef@google.com>
Cc: Iñaki Baz Castillo <ibc@aliax.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>
You are correct.  ORTC does not need an RtpTransceiver, and we's carefully
designed the RtpTransceiver to contain all of the SDP cruft so that
RtpSender/RtpReceiver don't.  You can think of RtpTransceiver as
RtpSdpMediaSection, because that's kind of what it is.  When using ORTC
(or, hopefully, WebRTC NV), you can just ignore the RtpTransceiver.
​

On Fri, May 13, 2016 at 1:07 PM, Taylor Brandstetter <deadbeef@google.com>
wrote:

> > 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.
> Pretty much. I don't think ORTC will need a transceiver object; I can't
> find any restriction saying "If an RtpSender and RtpSender share a
> transport, they need to share these parameters".
>
> On Fri, May 13, 2016 at 12:40 PM, Iñaki Baz Castillo <ibc@aliax.net>
> wrote:
>
>> 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 20:32:19 UTC

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