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. WL. On 11/1/06, Helge Waastad <helge(a)smartnet.no> wrote: Hi, I was wondering about the correct handeling of an 484 address incomplete message. I've seen different handeling from UAC to UAC Problem: My grandstreams receives a 484 and returns an ACK. This is how it should.And i hear beep-beep tones. the moment I terminate (on hook), the UAC sends a CANCEL message which generates a baaaad loop in my system.... 1. Is this cancel according to RFC? 2. Is there a way to consume/drop such an cancel? br hw -- Helge Waastad Senior Engineer Systemavdelingen Smartnet _______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users