inline...<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;">
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.</blockquote><div><br>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??<br><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;">> who happily ignores them ...
<br><br>That is broken behavior of a SIP UA.</blockquote><div><br>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.
<br><br>Try to look at HERP and "early media and forking" topics....<br> <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;">
> 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.</blockquote><div><br>Hope I'm right though I think it should work "as it is" ;)<br></div><br></div>sam.<br>