[Users] 484 UAC handeling

[Weiter Leiter]

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 at 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 at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kamailio.org/pipermail/users/attachments/20061101/971370f7/attachment.htm