- From: Peter Thatcher <pthatcher@google.com>
- Date: Fri, 13 May 2016 13:31:10 -0700
- To: Taylor Brandstetter <deadbeef@google.com>
- Cc: Iñaki Baz Castillo <ibc@aliax.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAJrXDUG4cJS-AC6LTnA5+=-ucZHraUcESbziX4Noz=HcoJa6rw@mail.gmail.com>
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