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

Good point.  I think an easy solution is to simply create a new
IceListener, and don't allow RTCP non-mux to be used with media forking.
 An alternative would be to allow an IceListener to be passed into
createAssociatedTransport.  But I don't think it's worth the additional
complexity.  What we could do for now is disallow media forking with RTCP
non-mux, and then if anyone ever needs it, then we can look into adding
that parameter or other control that does the same thing.


On Wed, May 7, 2014 at 11:30 AM, Bernard Aboba
<Bernard.Aboba@microsoft.com>wrote:

>  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> wrote:
>
> 2014-05-03 3:21 GMT+02:00 Peter Thatcher <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>
>
>
>