[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