<br><br><div><span class="gmail_quote">2007/8/3, Olaf Bergmann <<a href="mailto:Olaf.Bergmann@freenet-ag.de">Olaf.Bergmann@freenet-ag.de</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
samuel wrote:<br>> inline...<br>><br>> 2007/8/3, Olaf Bergmann <<a href="mailto:Olaf.Bergmann@freenet-ag.de">Olaf.Bergmann@freenet-ag.de</a><br>> <mailto:<a href="mailto:Olaf.Bergmann@freenet-ag.de">Olaf.Bergmann@freenet-ag.de
</a>>>:<br>><br>> Cesc Santa wrote:<br>><br>><br>> > I am doing some tests and it is not really a problem ... but maybe<br>> > someone has a better idea. In my configuration, the first 200 OK
<br>> > received is forwarded to the caller and the whole SIP session setup<br>> > (caller + 1st callee).<br>> > Next 200 OKs are also delivered to the caller,<br>><br>> That is the correct behavior of a SIP proxy.
<br>><br>><br>> I think the proper forking behaviour is to send a CANCEL to all branches<br>> upon receiving a 200 from one of them and I think that SER does this<br>> automatically... isn't it??<br><br>
Correct: if you used append_branch (IIRC you did) the call leg will<br>be canceled by SER. But as there is a race condition due to network<br>latency, a 200 OK might have been sent by the receiving UA before<br>the CANCEL was received.
</blockquote><div><br>You're totally right! I was speaking about the written standard.... <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
><br>> > who happily ignores them ...<br>><br>> That is broken behavior of a SIP UA.<br>><br>><br>> I think it's not specified what to do when a UA receives a second 200<br>> OK.... it can safely ignore it, it can present a mesage to the user, it
<br>> can try to mix the different audio streams, it can create a second<br>> dialog and put the first on hold, and more options.<br>><br>> Try to look at HERP and "early media and forking" topics....
<br><br>No, this has nothing to do with HERFP but is a matter of forked<br>dialog-initiating requests as you have observed. A good UAC<br>implementation waits some time after having received the first 200<br>OK (and having sent the corresponding ACK) to handle subsequent 200
<br>responses for forked requests. After some time it obviously is<br>reasonable to drop incoming 200 responses (but notice: these<br>responses could be matched with an ongoing call so there are options<br>to deal with them instead of silently dropping).
</blockquote><div><br>Right. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">><br>> > it is the task of the 2nd (and 3rd, ... ) callee to at a
<br>> > certain point give up and send a BYE, to which the caller replies with<br>> > 481 no call leg ...<br>> > It all works ... but, I wonder if ser could send CANCELs after<br>> > receiving the 1st 200 OK ... if yes, how? :)
<br>><br>> No, you cannot CANCEL an INVITE after having received a final<br>> response. This must be done by the caller after having sent the ACK.<br>> The UAC you have used is broken. The callee's UA tries to deal with
<br>> it and does the best it can. You should use a standards-compliant<br>> SIP UA for your tests.<br>><br>><br>> Hope I'm right though I think it should work "as it is" ;)<br><br>The bottom line is: SER cannot CANCEL branches after having seen an
<br>final response. If the calling UA does not handle them, the behavior<br>you observed is the best to achieve.<br><br>Regards,<br>Olaf</blockquote><div><br>Thanks!<br>Samuel.<br></div><br></div><br>