Since the UA received a final response to its request, which it even ACKed, sending CANCEL makes no sense as the transaction terminated on the UAC already (if ACK made it there); in this case you should simply receive a 481 for your CANCEL, the UAC should not try forward it. Howerver, I'm not sure what OpenSER does with an unconfirmed transaction to which a CANCEL is received, assuming there is a race between ACK and CANCEL.
<br><br>WL.<br><br><div><span class="gmail_quote">On 11/1/06, <b class="gmail_sendername">Helge Waastad</b> <<a href="mailto:helge@smartnet.no">helge@smartnet.no</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>I was wondering about the correct handeling of an 484 address incomplete<br>message.<br><br>I've seen different handeling from UAC to UAC<br><br>Problem:<br>My grandstreams receives a 484 and returns an ACK. This is how it
<br>should.And i hear beep-beep tones.<br><br>the moment I terminate (on hook), the UAC sends a CANCEL message which<br>generates a baaaad loop in my system....<br><br>1. Is this cancel according to RFC?<br>2. Is there a way to consume/drop such an cancel?
<br><br>br hw<br><br><br>--<br>Helge Waastad<br>Senior Engineer<br>Systemavdelingen<br>Smartnet<br><br>_______________________________________________<br>Users mailing list<br><a href="mailto:Users@openser.org">Users@openser.org
</a><br><a href="http://openser.org/cgi-bin/mailman/listinfo/users">http://openser.org/cgi-bin/mailman/listinfo/users</a><br></blockquote></div><br>