- From: Taylor Brandstetter <deadbeef@google.com>
- Date: Fri, 13 May 2016 13:07:11 -0700
- To: Iñaki Baz Castillo <ibc@aliax.net>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAK35n0bAWao8SDgF485jGED7F43WawsQbBALTGao-RiPn89Oow@mail.gmail.com>
> 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:07:39 UTC