[SR-Users] ACK Relay Issue Transaction Not Found

Alex Balashov abalashov at evaristesys.com
Tue Nov 24 17:34:37 CET 2020


Hi,

If you take a look at the documentation for t_check_trans(), you'll see 
that it behaves in very different ways depending on the type of message 
it is handling, and is supposed to return a negative/false value in some 
scenarios or abort script execution -- context is very important:

https://kamailio.org/docs/modules/stable/modules/tm.html#tm.f.t_check_trans

There are two types of ACKs - hop-by-hop ACKs, which acknowledge 
negative final replies, and end-to-end ACKs, which are for successful 
final 2xx replies and meant to be relayed by Kamailio end-to-end, in the 
manner of a normal in-dialog request.

An ACK of this nature is a separate request and a separate transaction, 
though its CSeq is identical to that of the INVITE transaction it is 
meant to acknowledge. However, a 2xx final reply will close an INVITE 
transaction, subject to `max_inv_lifetime` and `wt_timer`[1] and all 
that stuff:

The documentation speaks to this point:

    "For end-to-end ACKs (ACKs to 2xx responses for forwarded
    INVITE transactions) it will return true if the corresponding
    INVITE transaction is found and still active and false if not.

    Note that the e2e ACK matching is more of a hint then a
    certainty. A delayed e2e ACK might arrive after the
    transaction wait time elapses, when the INVITE transaction
    no longer exists and thus would not match anything. There
    are also cases when tm would not keep all the information
    needed for e2e ACK matching (since this is not needed for
    a stateful proxy and it requires additional memory,
    tm will not keep this information unless needed by
    some other module or callbacks)."

So, in other words, you should not expect t_check_trans() to return true 
for an end-to-end ACK. It is reasonable to expect that in the vast 
majority of cases, it will return false. The ACK should be relayed in 
the same manner as any other loose-routed in-dialog request, e.g. a 
reinvite or a BYE. If you follow the logic of the stock configuration 
that Kamailio ships with, this will happen correctly by default.

-- Alex

[1] https://kamailio.org/docs/modules/stable/modules/tm.html#tm.p.wt_timer

On 11/24/20 3:24 AM, me.projects at yahoo.com wrote:
> Hi When ACK is received on Kamailio from PBX t_check_trans() fails.
> 200 OK sent PBX from Teams and ACK from PBX is provided here.
> 
> What could be the issue.
> 
> SIP/2.0 200 OK
> FROM: "Ext1"<sip:1102 at PBX_IP>;tag=e08f0a03-1120-4e13-b0e2-90d1a027c05f
> TO: <sip:1101 at KAM_IP>;tag=e667397cb47c457a860222931e320b41
> CSEQ: 25772 INVITE
> CALL-ID: a6685754-b402-4a15-82b2-5fb2551e5b58
> VIA: SIP/2.0/UDP 
> PBX_IP:7790;received=PBX_IP;branch=z9hG4bKPj170912fc-0908-40bb-8248-9f6cb560332d;rport=7790 
> 
> RECORD-ROUTE: 
> <sip:sip-du-a-us.pstnhub.microsoft.com:5061;transport=tls;lr>,<sip:sbc.callsprout.com;transport=tls;ftag=e08f0a03-1120-4e13-b0e2-90d1a027c05f;lr>,<sip:KAM_IP:7790;transport=udp;ftag=e08f0a03-1120-4e13-b0e2-90d1a027c05f;lr> 
> 
> CONTACT: 
> <sip:api-du-b-usea.pstnhub.microsoft.com:443;x-i=c825abba-7203-442c-8461-994522d14365;x-c=25f3c2ce3a635971b809dc3be872e51b/s/1/63c9eea743284db99366cabf5f7dcbf5;ias=52.114.132.46~5061~3> 
> 
> CONTENT-LENGTH: 353
> SUPPORTED: timer
> CONTENT-TYPE: application/sdp
> ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
> REQUIRE: timer
> SESSION-EXPIRES: 1800;refresher=uac
> SERVER: Microsoft.PSTNHub.SIPProxy v.2020.11.16.5 i.USEA.5
> X-Siptrace-Fromip: tls:KAM_IP:7790
> X-Siptrace-Toip: udp:PBX_IP:7790
> X-Siptrace-Time: 1606205334 607029
> X-Siptrace-Method: INVITE
> X-Siptrace-Dir: out
> 
> ACK 
> sip:api-du-b-usea.pstnhub.microsoft.com:443;x-i=c825abba-7203-442c-8461-994522d14365;x-c=25f3c2ce3a635971b809dc3be872e51b/s/1/63c9eea743284db99366cabf5f7dcbf5;alias=.114.132.46~5061~3 
> SIP/2.0
> Via: SIP/2.0/UDP 
> PBX_IP:7790;rport;branch=z9hG4bKPjaa30c14c-c965-473d-bc49-9f223f9f634c
> From: "Ext1" <sip:1102 at PBX_IP>;tag=e08f0a03-1120-4e13-b0e2-90d1a027c05f
> To: <sip:1101 at KAM_IP>;tag=e667397cb47c457a860222931e320b41
> Call-ID: a6685754-b402-4a15-82b2-5fb2551e5b58
> CSeq: 25772 ACK
> Route: <sip:KAM_IP:7790;lr;ftag=e08f0a03-1120-4e13-b0e2-90d1a027c05f>
> Route: 
> <sip:sbc.callsprout.com;transport=tls;lr;ftag=e08f0a03-1120-4e13-b0e2-90d1a027c05f> 
> 
> Route: <sip:sip-du-a-us.pstnhub.microsoft.com:5061;transport=tls;lr>
> Max-Forwards: 70
> User-Agent: Asterisk
> Content-Length:  0
> X-Siptrace-Fromip: udp:PBX_IP:7790
> X-Siptrace-Toip: udp:KAM_IP:7790
> X-Siptrace-Time: 1606205334 615495
> X-Siptrace-Method: ACK
> X-Siptrace-Dir: in
> 
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/



More information about the sr-users mailing list