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

Hi,

>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.

...unless you, when you receive an answer from a new target, terminate the leg with the previous forked target.

>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. 

I think that is unlikely to happen, as forking is normally done in a serial manner (to avoid other issues associated with parallel forking).

I am not saying that there aren't use-cases that would break, but my question is still whether we can live with that restriction.

Regards,

Christer

-----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