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

[Roman Shpount <[e-mail]>]

On Fri, Oct 28, 2011 at 6:01 PM, Randell Jesup <[e-mail]>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 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