On Mar 28, 2007 at 12:09, Ricardo Martinez rmartinez@magenta.cl wrote:

Hello Jiri, hello Andrei. Thanks for your answers. I made a mistake posting the trace and I missed the ACK with problems. I'm attaching the full trace.

Thanks.

(ack_full_trace.cap)

Just for you to know, the setting is exactly as Jiri pointed.

.100/UAC -----NAT/.248----> SER outbound @ .246 -----> GW @ .239

Can you guide me and tell me in which part of the RFC is this "3261 style transaction matching" rule?

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@iptel.org Asunto: Re: [Serusers] Problems with ACK

On Mar 28, 2007 at 12:09, Ricardo Martinez rmartinez@magenta.cl wrote:

Hello Jiri, hello Andrei. Thanks for your answers. I made a mistake posting the trace and I missed the ACK with problems. I'm attaching the full trace.

(ack_full_trace.cap)

Just for you to know, the setting is exactly as Jiri pointed.

.100/UAC -----NAT/.248----> SER outbound @ .246 -----> GW @ .239

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.

From your logs, it looks like the ACK was sent to

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

Can you guide me and tell me in which part of the RFC is this "3261 style transaction matching" rule? Thanks guys for your help.

Best Regards, Ricardo Martinez RedVoiss Chile.

-----Mensaje original----- De: Jiri Kuthan [mailto:jiri@iptel.org] Enviado el: martes, 27 de marzo de 2007 17:24 Para: Ricardo Martinez; serusers@iptel.org Asunto: RE: [Serusers] Problems with ACK

I think the key message for problem analysis, client's ACK, is missing. This is the setting, right:?

.100/UAC -----NAT/.248----> SER outbound @ .246 -----> UAS @ .239

The ACK in your message dump is only that one sent from proxy (246) to UAS (.239). The ACK which can possibly mismatch and produce the error message you mentioned must come from upstream. To be properly formatted, it must have Via identical to that of initial INVITE ( Via: SIP/2.0/UDP 192.168.1.100:5060;rport=46127;received=100.100.100.248;branch=z9hG4bK2893084087)

-jiri

At 17:50 27/03/2007, Ricardo Martinez wrote: No. Time Source Destination Protocol Info

...

14 6.102719    100.100.100.239         100.100.100.246         SIP      Status: 487 Request Terminated

Session Initiation Protocol Status-Line: SIP/2.0 487 Request Terminated Status-Code: 487 Resent Packet: False Message Header Via: SIP/2.0/UDP 100.100.100.246;branch=z9hG4bK895c.a98d35.0 Via: SIP/2.0/UDP 192.168.1.100:5060;rport=46127;received=100.100.100.248;branch=z9hG4bK2893084087

...

No. Time Source Destination Protocol Info 15 6.103011 100.100.100.246 100.100.100.239 SIP Request: ACK sip:005622408196@100.100.100.239 Session Initiation Protocol Request-Line: ACK sip:005622408196@100.100.100.239 SIP/2.0 Method: ACK Resent Packet: False Message Header Via: SIP/2.0/UDP 100.100.100.246;branch=z9hG4bK895c.a98d35.0 f: "cl" sip:cl@sipvoiss.desa.redvoiss.net;tag=1587516403 SIP Display info: "cl" SIP from address: sip:cl@sipvoiss.desa.redvoiss.net SIP tag: 1587516403 i: mailto:e94a98aa177e8579e5242a2091c0ac5f@192.168.1.100e94a98aa177e8579e5242a2091c0ac5f@192.168.1.100 To: sip:0299005622408196@sipvoiss.desa.redvoiss.net;tag=9146c297a4 Thanks

Ricardo.- _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

-- Jiri Kuthan http://iptel.org/~jiri/