Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP

Christer,
Regarding whether we need to be able to simultaneously support multiple remote locations (forking), I have reluctantly concluded "yes" after thinking about it for a bit.

The UPDATE scenario from Partha is not the only reason we need the concept of peer connection cloning (or something similar), although it is sufficient in itself.  As soon as you get multiple answers from different forked targets, it is necessary to separately keep track of ICE and DTLS progress with each target, not to mention RTCP.  Otherwise ICE and DTLS results from one target will get overwritten by those from another and then need to be redone again if an earlier target is selected as the winner.  To me this is not acceptable, hence my reluctant conclusion.

Maybe it could work if we simply delay ICE, DTLS, RTCP and media until we decide on a final ANSWER, and any nested offer/answer transactions (i.e., Partha's example) are handled at the JS layer only without interaction with the peer connection.  Does anyone think this is an acceptable approach?  Not I.

Richard

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Wednesday, May 02, 2012 11:29 AM
To: Roman Shpount
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP

Hi,

>> Do people think that is not enough, and that we would need to support multiple remote locations 
>> simultanously (no matter whether it's implemented using cloning or something else)?
>
> I never thought that was enough if we are to interop with anything that support forking. Latest example from > Partha shows that this is indeed the case.
>
> I actually think that adding support for forking is trivial (order of magnitude less complcated then DTLS-
> SRTP or identity) and would simplify interop as well as enable numerous additional calling scenarios.

It's not about forking as such - I also agree we need to support that.

The question is whether we need to *simultanously* need to support multiple remote locations, or whether we only have one "active" remote location, but we allow switching from one to another (based on where the previous answer can from, or whatever policy).

Regards,

Christer
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb