- From: Peter Thatcher <pthatcher@google.com>
- Date: Mon, 1 Feb 2016 12:48:40 -0800
- To: Iñaki Baz Castillo via GitHub <sysbot+gh@w3.org>
- Cc: "public-ortc@w3.org" <public-ortc@w3.org>
- Message-ID: <CAJrXDUGij9FkGmiPTLRgVwfYkb=Ls9M3fQYUTsKDbC-nODCS3Q@mail.gmail.com>
An RtpSender or RtpReceiver is not bound to a particular DtlsTransport permanently. The RtpSender.transport can be changed on the fly. Otherwise, you wouldn't be able to implement BUNDLE in PeerConneciton on top of ORTC. Further, that would mean that a DTLS thing know about RTP things, which is kind of weird. A DTLS thing should really only know about DTLS. On Mon, Feb 1, 2016 at 12:42 PM, Iñaki Baz Castillo via GitHub < sysbot+gh@w3.org> wrote: > ibc has just created a new issue for https://github.com/openpeer/ortc: > > == [non rtcp-mux pain] Doesn't RTCRtpReceiver belong to > RTCDtlsTransport? == > According to > [webrtcstandards.info](https://webrtcstandards.info/rtcp-mux/): > > > Google reported that only a very tiny fraction of the apps it saw > used RTCP non-mux at all, the further decision was made to allow > endpoints to refuse RTCP non-mux. It was made clear that, in > practice, Chrome and Firefox expected not to support RTCP non-mux at > all. > > Im pretty sure that, if we could remove the non rtcp-mux capabilities > from ORTC lot of stuff and relationship between classes would become > much easier and simpler. > > For example: `RTCRtpReceiver` and `RTCRtpSender` could belong to a > **single** `RTCDtlsTransport`, so instead of a constructor that > receives a transport(s) as argument, it would become: > > ```js > var dtlsTransport = new RTCDtlsTransport(...); > > var rtpReceiver = dtlsTransport.createRtpReceiver(); > var rtpSender = dtlsTransport.createRtpSender(); > ``` > > As implementor, I find the current ORTC spec regarding > `DtlsTransport`, `RtpReceiver` and `RtpSender` too weak and complex. > The relationship between them is clearly complex due the possibility > of non rtcp-mux (so two `DtlsTransport`s are required). > > Sorry, this is not an "issue" but a reflection coming to my mind while > implementing the ORTC spec. > > Please view or discuss this issue at > https://github.com/openpeer/ortc/issues/370 using your GitHub account > >
Received on Monday, 1 February 2016 20:49:48 UTC