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

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:42:53 UTC