samuel wrote:
> inline...
>
> 2007/8/3, Olaf Bergmann <Olaf.Bergmann@freenet-ag.de
> <mailto:Olaf.Bergmann@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.

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

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