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

[Iñaki Baz Castillo <[e-mail]>]

2011/10/31 Roman Shpount <[e-mail]>:
> 1. Use Case for Parallel Forking
>
> It is obviously needed for SIP interop. There are ways around it by using
> different signaling scenarios, or there are way to cheat this for some use
> cases (serial forking), but in the end of the day, to work with the widest
> possible set of end points parallel forking is highly desirable.
>
> Once again, a lot of people here raised the concern that parallel forking is
> only needed for SIP interop and nothing else. In some sense this is true,
> but in general, ability to do parallel forking should save a round trip and
> some complexity during call setup. Imagine a scenario where a call is
> answered by a single peer most of the times and by multiple peers in few
> cases. This can be the case when some of the peers are either groups or
> "shared lines" in PSTN speak. If we have parallel forking, WebRTC client
> will send an offer with media description. If the client gets a single
> answer it will setup a call as soon as this answer is available. If the
> client gets multiple answers,  it will clone the PeerConnection and process
> each of those answers independently. Now, if we do not have parallel
> forking, WebRTC client will need to start a call without an offer, get
> offers from all the potential call destinations, and then create a
> PeerConnection for each and send an answer. Extra round trip and more code,
> even when the call is setup to one destination only (since the client does
> not know in advance if the destination it is calling is a single person or a
> group). So, yes, everything can be implemented without parallel forking, but
> will be a bit more complex.
>
> 2. Complexity this will introduce to the API: I think all we need is a
> single clone method on the PeerConnection. If you do not need parallel
> forking, you never call the clone method and no additional complexity is
> introduced. If you need parallel forking, it is available to you.


Ok so, if we all agree here (since it seems not to add too much
complexity to the API), can we ask for the API to support this need?


-- 
Iñaki Baz Castillo
<[e-mail]>