[Users] 484 UAC handeling

[Helge Waastad]

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 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
> 
-- 
Helge Waastad
Senior Engineer
Systemavdelingen
Smartnet