Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]

On 10/28/2011 04:00 PM, Roman Shpount wrote:
>
> On Fri, Oct 28, 2011 at 6:01 PM, Randell Jesup <randell-ietf@jesup.org 
> <mailto:randell-ietf@jesup.org>> wrote:
>
>
>     As discussed, given that users will be "logged into" a service
>     from multiple devices, and that we don't know what the application
>     desired behavior will be, we need to support multiple ANSWER
>     responses to a OFFER, and support allowing multiple of those
>     answers to become active.  (For example, OFFER sent to "my Team",
>     answered by 3 members of the team.)  As for implementation:
>     probably by cloning the PeerConnection or a Factory (this has been
>     discussed before and I haven't gone over the messages to see where
>     it ended up).
>
>
> I agree with this completely.
>
> I think the most encouraging response I got before on this list was 
> that the API should always produce the same list of ICE candidates for 
> a given Web browser session. Because of this, all the offers from the 
> WebRTC client would be the same and simultaneous forking can be 
> implemented by creating a new peer connection for each answer, 
> generating and discarding the offer (since it is the same as the offer 
> from the original peer connection in this session) and feeding a new 
> answer to it.
I considered it when we discussed this last, but I'm not sure it works.

If we support SDES, the offer also contains crypto keys. Reusing crypto 
keys for all created connections would be a huge security vulnerability.

That's why I ended up with the somewhat more complex "factory" model I 
proposed in an earlier mail; another method would be to have a 
PeerConnection constructor that takes an offer AND an answer as creation 
parameters.

Of course we could mandate DTLS-SRTP key negotiation.....

> I am not sure this behavior is defined anywhere, but this could 
> definitely work and would allow to implement all forking scenarios 
> without cloning or factory API calls. I would feel a bit more 
> comfortable if the API would actually reflect this usage (i.e. have 
> one method that always returns an offer for this web session and peer 
> connection only processing answers or responses to remote offers).
> _____________
> Roman Shpount
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb