[Serusers] dealing with parallel forking ...

samuel samu60 at gmail.com
Mon Aug 6 10:15:28 CEST 2007


2007/8/3, Olaf Bergmann <Olaf.Bergmann at freenet-ag.de>:
>
> samuel wrote:
> > inline...
> >
> > 2007/8/3, Olaf Bergmann <Olaf.Bergmann at freenet-ag.de
> > <mailto:Olaf.Bergmann at freenet-ag.de>>:
> >
> >     Cesc Santa wrote:
> >
> >
> >     > I am doing some tests and it is not really a problem ... but maybe
> >     > someone has a better idea. In my configuration, the first 200 OK
> >     > received is forwarded to the caller and the whole SIP session
> setup
> >     > (caller + 1st callee).
> >     > Next 200 OKs are also delivered to the caller,
> >
> >     That is the correct behavior of a SIP proxy.
> >
> >
> > I think the proper forking behaviour is to send a CANCEL to all branches
> > upon receiving a 200 from one of them and I think that SER does this
> > automatically... isn't it??
>
> Correct: if you used append_branch (IIRC you did) the call leg will
> be canceled by SER. But as there is a race condition due to network
> latency, a 200 OK might have been sent by the receiving UA before
> the CANCEL was received.


You're totally right! I was speaking about the  written standard....

>
> >     > who happily ignores them ...
> >
> >     That is broken behavior of a SIP UA.
> >
> >
> > I think it's not specified what to do when a UA receives a second  200
> > OK.... it can safely ignore it, it can present a mesage to the user, it
> > can try to mix the different audio streams, it can create a second
> > dialog and put the first on hold, and more options.
> >
> > Try to look at HERP and "early media and forking" topics....
>
> No, this has nothing to do with HERFP but is a matter of forked
> dialog-initiating requests as you have observed. A good UAC
> implementation waits some time after having received the first 200
> OK (and having sent the corresponding ACK) to handle subsequent 200
> responses for forked requests. After some time it obviously is
> reasonable to drop incoming 200 responses (but notice: these
> responses could be matched with an ongoing call so there are options
> to deal with them instead of silently dropping).


Right.

>
> >     > it is the task of the 2nd (and 3rd, ... ) callee to at a
> >     > certain point give up and send a BYE, to which the caller replies
> with
> >     > 481 no call leg ...
> >     > It all works ... but, I wonder if ser could send CANCELs after
> >     > receiving the 1st 200 OK ... if yes, how? :)
> >
> >     No, you cannot CANCEL an INVITE after having received a final
> >     response. This must be done by the caller after having sent the ACK.
> >     The UAC you have used is broken. The callee's UA tries to deal with
> >     it and does the best it can. You should use a standards-compliant
> >     SIP UA for your tests.
> >
> >
> > Hope I'm right though I think it should work "as it is"  ;)
>
> The bottom line is: SER cannot CANCEL branches after having seen an
> final response. If the calling UA does not handle them, the behavior
> you observed is the best to achieve.
>
> Regards,
> Olaf


Thanks!
Samuel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20070806/06eef661/attachment.htm>


More information about the sr-users mailing list