<html><head></head><body><div class="ydp9762299byahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div></div>
        <div dir="ltr" data-setdir="false">Thanks for your reply. </div><div dir="ltr" data-setdir="false">I can't see the ACK being relayed to MSTeams in network capture through in Relay Route</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false"><div><div><span class="ydpfd265b47Apple-tab-span" style="white-space: pre-wrap;">             </span>if(is_method("ACK|BYE")) {</div><div><span class="ydpfd265b47Apple-tab-span" style="white-space: pre-wrap;">                       </span>sip_trace();</div><div><span class="ydpfd265b47Apple-tab-span" style="white-space: pre-wrap;">                       </span>setflag(22);</div><div dir="ltr" data-setdir="false"><span class="ydpfd265b47Apple-tab-span" style="white-space: pre-wrap;">             </span>}<span class="ydpfd265b47Apple-tab-span" style="white-space: pre-wrap;"> </span></div></div></div><div dir="ltr" data-setdir="false">  but call has been established successfully. is ACK is being relayed hiddenly by Kamailio ?</div><div><br></div>
        
        </div><div id="yahoo_quoted_6436128591" class="yahoo_quoted">
            <div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
                
                <div>
                    On Tuesday, November 24, 2020, 09:35:32 PM GMT+5, Alex Balashov <abalashov@evaristesys.com> wrote:
                </div>
                <div><br></div>
                <div><br></div>
                <div><div dir="ltr">Hi,<br clear="none"><br clear="none">If you take a look at the documentation for t_check_trans(), you'll see <br clear="none">that it behaves in very different ways depending on the type of message <br clear="none">it is handling, and is supposed to return a negative/false value in some <br clear="none">scenarios or abort script execution -- context is very important:<br clear="none"><br clear="none"><a shape="rect" href="https://kamailio.org/docs/modules/stable/modules/tm.html#tm.f.t_check_trans" target="_blank">https://kamailio.org/docs/modules/stable/modules/tm.html#tm.f.t_check_trans</a><br clear="none"><br clear="none">There are two types of ACKs - hop-by-hop ACKs, which acknowledge <br clear="none">negative final replies, and end-to-end ACKs, which are for successful <br clear="none">final 2xx replies and meant to be relayed by Kamailio end-to-end, in the <br clear="none">manner of a normal in-dialog request.<br clear="none"><br clear="none">An ACK of this nature is a separate request and a separate transaction, <br clear="none">though its CSeq is identical to that of the INVITE transaction it is <br clear="none">meant to acknowledge. However, a 2xx final reply will close an INVITE <br clear="none">transaction, subject to `max_inv_lifetime` and `wt_timer`[1] and all <br clear="none">that stuff:<br clear="none"><br clear="none">The documentation speaks to this point:<br clear="none"><br clear="none">    "For end-to-end ACKs (ACKs to 2xx responses for forwarded<br clear="none">    INVITE transactions) it will return true if the corresponding<br clear="none">    INVITE transaction is found and still active and false if not.<br clear="none"><br clear="none">    Note that the e2e ACK matching is more of a hint then a<br clear="none">    certainty. A delayed e2e ACK might arrive after the<br clear="none">    transaction wait time elapses, when the INVITE transaction<br clear="none">    no longer exists and thus would not match anything. There<br clear="none">    are also cases when tm would not keep all the information<br clear="none">    needed for e2e ACK matching (since this is not needed for<br clear="none">    a stateful proxy and it requires additional memory,<br clear="none">    tm will not keep this information unless needed by<br clear="none">    some other module or callbacks)."<br clear="none"><br clear="none">So, in other words, you should not expect t_check_trans() to return true <br clear="none">for an end-to-end ACK. It is reasonable to expect that in the vast <br clear="none">majority of cases, it will return false. The ACK should be relayed in <br clear="none">the same manner as any other loose-routed in-dialog request, e.g. a <br clear="none">reinvite or a BYE. If you follow the logic of the stock configuration <br clear="none">that Kamailio ships with, this will happen correctly by default.<br clear="none"><br clear="none">-- Alex<br clear="none"><br clear="none">[1] <a shape="rect" href="https://kamailio.org/docs/modules/stable/modules/tm.html#tm.p.wt_timer" target="_blank">https://kamailio.org/docs/modules/stable/modules/tm.html#tm.p.wt_timer</a><br clear="none"><div class="yqt3965437125" id="yqtfd81174"><br clear="none">On 11/24/20 3:24 AM, <a shape="rect" ymailto="mailto:me.projects@yahoo.com" href="mailto:me.projects@yahoo.com">me.projects@yahoo.com</a> wrote:<br clear="none">> Hi When ACK is received on Kamailio from PBX t_check_trans() fails.<br clear="none">> 200 OK sent PBX from Teams and ACK from PBX is provided here.<br clear="none">> <br clear="none">> What could be the issue.<br clear="none">> <br clear="none">> SIP/2.0 200 OK<br clear="none">> FROM: "Ext1"<sip:<a shape="rect" ymailto="mailto:1102@PBX_IP" href="mailto:1102@PBX_IP">1102@PBX_IP</a>>;tag=e08f0a03-1120-4e13-b0e2-90d1a027c05f<br clear="none">> TO: <sip:<a shape="rect" ymailto="mailto:1101@KAM_IP" href="mailto:1101@KAM_IP">1101@KAM_IP</a>>;tag=e667397cb47c457a860222931e320b41<br clear="none">> CSEQ: 25772 INVITE<br clear="none">> CALL-ID: a6685754-b402-4a15-82b2-5fb2551e5b58<br clear="none">> VIA: SIP/2.0/UDP <br clear="none">> PBX_IP:7790;received=PBX_IP;branch=z9hG4bKPj170912fc-0908-40bb-8248-9f6cb560332d;rport=7790 <br clear="none">> <br clear="none">> RECORD-ROUTE: <br clear="none">> <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> <br clear="none">> <br clear="none">> CONTACT: <br clear="none">> <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> <br clear="none">> <br clear="none">> CONTENT-LENGTH: 353<br clear="none">> SUPPORTED: timer<br clear="none">> CONTENT-TYPE: application/sdp<br clear="none">> ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY<br clear="none">> REQUIRE: timer<br clear="none">> SESSION-EXPIRES: 1800;refresher=uac<br clear="none">> SERVER: Microsoft.PSTNHub.SIPProxy v.2020.11.16.5 i.USEA.5<br clear="none">> X-Siptrace-Fromip: tls:KAM_IP:7790<br clear="none">> X-Siptrace-Toip: udp:PBX_IP:7790<br clear="none">> X-Siptrace-Time: 1606205334 607029<br clear="none">> X-Siptrace-Method: INVITE<br clear="none">> X-Siptrace-Dir: out<br clear="none">> <br clear="none">> ACK <br clear="none">> 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 <br clear="none">> SIP/2.0<br clear="none">> Via: SIP/2.0/UDP <br clear="none">> PBX_IP:7790;rport;branch=z9hG4bKPjaa30c14c-c965-473d-bc49-9f223f9f634c<br clear="none">> From: "Ext1" <sip:<a shape="rect" ymailto="mailto:1102@PBX_IP" href="mailto:1102@PBX_IP">1102@PBX_IP</a>>;tag=e08f0a03-1120-4e13-b0e2-90d1a027c05f<br clear="none">> To: <sip:<a shape="rect" ymailto="mailto:1101@KAM_IP" href="mailto:1101@KAM_IP">1101@KAM_IP</a>>;tag=e667397cb47c457a860222931e320b41<br clear="none">> Call-ID: a6685754-b402-4a15-82b2-5fb2551e5b58<br clear="none">> CSeq: 25772 ACK<br clear="none">> Route: <sip:KAM_IP:7790;lr;ftag=e08f0a03-1120-4e13-b0e2-90d1a027c05f><br clear="none">> Route: <br clear="none">> <sip:sbc.callsprout.com;transport=tls;lr;ftag=e08f0a03-1120-4e13-b0e2-90d1a027c05f> <br clear="none">> <br clear="none">> Route: <sip:sip-du-a-us.pstnhub.microsoft.com:5061;transport=tls;lr><br clear="none">> Max-Forwards: 70<br clear="none">> User-Agent: Asterisk<br clear="none">> Content-Length:  0<br clear="none">> X-Siptrace-Fromip: udp:PBX_IP:7790<br clear="none">> X-Siptrace-Toip: udp:KAM_IP:7790<br clear="none">> X-Siptrace-Time: 1606205334 615495<br clear="none">> X-Siptrace-Method: ACK<br clear="none">> X-Siptrace-Dir: in</div><br clear="none">> <br clear="none">> _______________________________________________<br clear="none">> Kamailio (SER) - Users Mailing List<br clear="none">> <a shape="rect" ymailto="mailto:sr-users@lists.kamailio.org" href="mailto:sr-users@lists.kamailio.org">sr-users@lists.kamailio.org</a><br clear="none">> <a shape="rect" href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br clear="none">> <br clear="none"><br clear="none">-- <br clear="none">Alex Balashov | Principal | Evariste Systems LLC<br clear="none"><br clear="none">Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)<br clear="none">Web: <a shape="rect" href="http://www.evaristesys.com/, " target="_blank">http://www.evaristesys.com/, </a><a shape="rect" href="http://www.csrpswitch.com/" target="_blank">http://www.csrpswitch.com/</a><br clear="none"><br clear="none">_______________________________________________<br clear="none">Kamailio (SER) - Users Mailing List<br clear="none"><a shape="rect" ymailto="mailto:sr-users@lists.kamailio.org" href="mailto:sr-users@lists.kamailio.org">sr-users@lists.kamailio.org</a><br clear="none"><a shape="rect" href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><div class="yqt3965437125" id="yqtfd33926"><br clear="none"></div></div></div>
            </div>
        </div></body></html>