[Serusers] Problems with ACK

[Andrei Pelinescu-Onciul]

On Mar 28, 2007 at 12:09, Ricardo Martinez <rmartinez at 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 at iptel.org]
> Enviado el: martes, 27 de marzo de 2007 17:24
> Para: Ricardo Martinez; serusers at 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 at 100.100.100.239
> >Session Initiation Protocol
> >    Request-Line: ACK sip:005622408196 at 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 at sipvoiss.desa.redvoiss.net>;tag=1587516403
> >            SIP Display info: "cl" 
> >            SIP from address: sip:cl at sipvoiss.desa.redvoiss.net
> >            SIP tag: 1587516403
> >        i: <mailto:e94a98aa177e8579e5242a2091c0ac5f at 192.168.1.100>e94a98aa177e8579e5242a2091c0ac5f at 192.168.1.100
> >        To: <sip:0299005622408196 at sipvoiss.desa.redvoiss.net>;tag=9146c297a4
> >Thanks
> > 
> >Ricardo.-
> >_______________________________________________
> >Serusers mailing list
> >Serusers at lists.iptel.org
> >http://lists.iptel.org/mailman/listinfo/serusers
> 
> 
> 
> --
> Jiri Kuthan            http://iptel.org/~jiri/
>