Re: Rationale behind the RTCRtpTransceiver

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