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 <[EMAIL PROTECTED]> 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 > [email protected] > http://openser.org/cgi-bin/mailman/listinfo/users > -- Helge Waastad Senior Engineer Systemavdelingen Smartnet _______________________________________________ Users mailing list [email protected] http://openser.org/cgi-bin/mailman/listinfo/users
