On Mar 28, 2007 at 12:09, Ricardo Martinez <rmartinez(a)magenta.cl> wrote: Thanks. Section 17.2.3: Matching Requests to Server Transactions (page 138). Andrei

Hello Andrei. First of all thanks for your help. Yes, as you mention, i realized that probably the problem is in the terminating gateway. According to my point of view it seems that the gaetway doesn't understand the final ACK for the CANCEL, exactly as you pointed too. So i contacted the gateway developers to obtain some answers ;). I was expecting a response this week to send a final post with the solution to the problem, but i'm still waiting. Anyway, i will keep you updated about this issue and again thanks for your time and help. (also to Jiri). Regards, Ricardo Martinez.- -----Mensaje original----- De: Andrei Pelinescu-Onciul [mailto:andrei@iptel.org] Enviado el: miércoles, 04 de abril de 2007 15:46 Para: Ricardo Martinez CC: Jiri Kuthan; serusers(a)iptel.org Asunto: Re: [Serusers] Problems with ACK On Mar 28, 2007 at 12:09, Ricardo Martinez <rmartinez(a)magenta.cl> wrote: Sorry for the late response, I almost forgot about the dump :-( It seems the gateway has some problems matching the ACK and you might have some small config bug (ACKs are not treated in the same way as INVITEs?). In your trace everything works ok, until the UA sends a CANCEL and the GW replies with 487. After that ser immediately sends an ACK to the gw (packet #15), forwards the 487 to the UA and the UA acks it (packets #16 & #17). From ser point of view everything is ok and the transaction was properly CANCELed. When ser receives the ACK from the UA (packet #17) it will consider the transaction ended and it will put it on "wait" (this means that in the default config it will keep it for another 5 sec and then it will delete it). What's strange is that 16 s later, out of the blue, the GW resends the 487 (packet #18). At this point the intial transaction is long deleted in ser so ser just forwards the reply back to UA, which ACKs it again. This would be the first problem: the GW either went crazy or it didn't match the initial ACK and for some reasons waited 16 s before it retransmited the reply. The new ACK reaches ser (packet #20), but there is no longer a corresponding transaction, so ser tries to forward it statelessly. That's why you get the "DEBUG: RFC3261 transaction matching failed": the transaction is no longer alive, so matching the ACK fails. However here we hit another problem, it seems the ACK is sent to some other destination. In the log you sent in an older email I can see that ser really sends the ACK (the " Sending: ACK" line), but I cannot see it in the dump. I assume the ACK is sent to some other destination and you either restricted the dump only to UA and GW or it went on some other interface. If my assumptions are correct, the ACK probably ends up on another config "path" than the INVITE. You should treat the ACKs and CANCELs exactly the same way as the INVITEs (*), so that even if you get an out of transaction ACK or CANCEL it will be properly forwarded. sipvoiss.desa.redvoiss.net instead of the GW. (*) - of course there are some exceptions, for example you don't have to record-route the ACKs and CANCELs. Andrei