1 Nov
2006
1 Nov
'06
6:41 p.m.
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