Re: A proposal for solving non-muxed RTCP *and* ICE freezing

Hi,

I don't fully understand. WebRTC 1.0 clients (say browsers) MUST implement
rtcp-mux. Servers (which are not standardized by the WebRTC 1.0 spec) may
or may not.

Anyhow, is there any media server that implements DTLS-SRTP and allows non
rtcp-mux (which means two separate ICE, DTLS and SRTP procedures)? If not,
which "interoperability" are we talking about?

Thanks a lot for your replies. Regards.

--
Iñaki Baz Castillo
<ibc@aliax.net>
On May 6, 2014 1:47 AM, "Robin Raymond" <robin@hookflash.com> wrote:

>
> Those are fair questions... I'm not sure you'll like the answer but here
> it is:
>
> Nobody is required to use it. There are some "compatibility" reasons why
> we might need this... or so it's been told. I'm not sure who has boxes that
> don't mux RTP/RTCP but do support WebRTC compatible DTLS exchange in the
> wild. But for the sake of being able to achieve some parity with WebRTC 1.0
> this was determined as "needed". This is also the reason why it was
> somewhat hidden "feature" since it's not exactly a high priority item but
> needs to exist.
>
> -Robin
>
>
>   Iñaki Baz Castillo <ibc@aliax.net>
>  May 5, 2014 at 7:17 PM
>
> Hi, sure I've missed some previous threads about this subject but...
> why do we need non-mutex RTCP?
>
> If I'm not wrong, non-mutex RTCP means two separate DTLS connections
> with different sessions keys for SRTP and SRTCP and, of course, two
> separate ICE procedures which bring more complexity (what happens if
> the transport for RTCP gets a DTLS error alarm?).
>
> Thanks a lot.
>
> PS: Sorry if the question is too obvious. I still have to take a look
> to new topics :)
>
>

Received on Tuesday, 6 May 2014 00:00:12 UTC