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

[Roman Shpount <[e-mail]>]

On Thu, May 10, 2012 at 3:06 PM, Cullen Jennings <[e-mail]> wrote:

>
> Uh, I don't think we are ready to design anything yet - I am still 100%
> confused on what the use case we are trying to solve is. Is it forking on
> at the browser, in intermediate node, in SIP, parallel, sequential or what?
> I want to see the end user use cases we need to deal with. The example
> Randell gave seems reasonable but seem like it would best be handled with
> just multiple independent PeerConnection. The combination of requiring ICE
> and SIP parallel forking is very complicated - particularly without
> Reliable provisions responses and all the complexity that ensues.
>
> So before we go down this path, lets get clearer on what we are trying to
> accomplish.
>
>
One use case is interop with SIP with parallel forking, reliable
provisioning responses, UPDATE, and ICE. The big question regarding this
use case is availability of anything that supports parallel forking,
reliable provisioning and UPDATE. I actually think ICE makes implementation
of this use case easier, not harder.

The real end user use case is any type of service where calling destination
is a small group of people. This allows to initiate a single offer and send
it to all the members of the group. In most cases only one person will
reply, but, in a smaller set of cases, several people from the group will
answer. In the later case, you need a mechanism to clone the original peer
connection (or to create additional peer connections based on the original
offer) and deal with additional answers independently.

This is a very common use case for any type of service where people use
multiple devices. For instance if we add voice/video calling to a web mail
program, I can be logged in from multiple devices. It can also be a shared
account (like [e-mail]) where several different people are logged
in to the same account. When someone places a call to a shared account,
several people can answer at the same time.

I know this can be addressed by sending a separate message  and reversing
the call setup direction (each accepting party creates an offer and sends
it back), but this causes another set of issues related to slow call setup
and media clipping.
_____________
Roman Shpount