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

I think there is an issue with the proposal.  In the case where the RTCIceTransport is constructed from an RTCIceListener object, the “associated” transport would need to have its own RTCIceListener.  So either this has to be explicitly constructed, or it needs to be created implicitly.  If there is forking, then the RTCIceListener objects for RTP and RTCP would need to be shared by the RTCIceTransport objects created after the Answer(s) arrive.


From: Peter Thatcher [mailto:pthatcher@google.com]
Sent: Monday, May 5, 2014 4:50 PM
To: Iñaki Baz Castillo
Cc: public-ortc@w3.org
Subject: Re: A proposal for solving non-muxed RTCP *and* ICE freezing

You don't, and most people don't, so you can just ignore its existence in the API.  But interop requires it, so if we want a "1.0 on top of ORTC" shim, we need non-muxed RTCP.  But I think the proposal I made provides for this with minimal pain.

On Mon, May 5, 2014 at 4:17 PM, Iñaki Baz Castillo <ibc@aliax.net<mailto:ibc@aliax.net>> wrote:
2014-05-03 3:21 GMT+02:00 Peter Thatcher <pthatcher@google.com<mailto:pthatcher@google.com>>:
> We don't have a way for the app to express that it wants to have RTCP that isn't multiplexed with RTP
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 :)

--
Iñaki Baz Castillo
<ibc@aliax.net<mailto:ibc@aliax.net>>