Re: [ortc] [non rtcp-mux pain] Doesn't RTCRtpReceiver belong to RTCDtlsTransport?

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