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

[Roman Shpount <[e-mail]>]

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

>
> On May 10, 2012, at 3:23 PM, Roman Shpount wrote:
>
> >
> > On Thu, May 10, 2012 at 4:55 PM, Cullen Jennings <[e-mail]> wrote:
> > > 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.
> >
> > 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 theexample.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.
> >
> >
> > Let's say a standard SIP proxy (call it opensips for specificity)
> placing a forked call to two ICE enabled IP phones. Both phones answer with
> 200 OK.
>
> With a standard SIP proxy, only one of the 200 would be sent back to the
> web browser.


AFAIK a standard proxy will forward multiple 200 OK responses (see section
16.7 of RFC 3261). We have the same problem with 183 responses from two
phones anyway.
_____________
Roman Shpount