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
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@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....
- Is this cancel according to RFC?
- Is there a way to consume/drop such an cancel?
br hw
-- Helge Waastad Senior Engineer Systemavdelingen Smartnet
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi, what you say makes sense.
Right now I've had to add an t_check_trans for CANCEL messages and dropping if it does not exist. And of course if I return an reply again to the UAC (to be RFC compliant), the race starts ;-|
thnx,
hw
On ons, 2006-11-01 at 16:41 +0100, Weiter Leiter wrote:
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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-
Helge Waastad -
Weiter Leiter