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

[Cullen Jennings <[e-mail]>]

On May 10, 2012, at 1:51 PM, Roman Shpount wrote:

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

So let me try and make sure I understand this uses case. The web browser sends some signaling to a server that convert it to a sip call to the [e-mail] address. This sends it to the example.com sip server that parallel forks it to two SIP UASs  that are so two phones ring at the same time. Now both theses phones are going to negotiate ICE by using reliably provisional responses. 

What products actually do parallel forking like this and return provisional reliable responses with ICE. I'm sort of questioning this is a common use case. The Nortel, Cisco, Avaya, Siemens etc enterprises PBX systems I have seen that support ringing multiple phones at the same time don't seem to do this way. They manage to hide the parallel forking with a B2BUA model and make it look like sequential forking.