24 Nov
2020
24 Nov
'20
9:24 a.m.
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@PBX_IP>;tag=e08f0a03-1120-4e13-b0e2-90d1a027c05f
TO: <sip:1101@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@PBX_IP>;tag=e08f0a03-1120-4e13-b0e2-90d1a027c05f
To:
<sip:1101@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
24 Nov
24 Nov
5:34 p.m.
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(a)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@PBX_IP>;tag=e08f0a03-1120-4e13-b0e2-90d1a027c05f
TO: <sip:1101@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@PBX_IP>;tag=e08f0a03-1120-4e13-b0e2-90d1a027c05f
To: <sip:1101@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(a)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/
6:22 p.m.
Thanks for your reply. I can't see the ACK being relayed to MSTeams in network
capture through in Relay Route
if(is_method("ACK|BYE")) { sip_trace(); setflag(22); } but call has been
established successfully. is ACK is being relayed hiddenly by Kamailio ?
On Tuesday, November 24, 2020, 09:35:32 PM GMT+5, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
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(a)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@PBX_IP>;tag=e08f0a03-1120-4e13-b0e2-90d1a027c05f
TO: <sip:1101@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@PBX_IP>;tag=e08f0a03-1120-4e13-b0e2-90d1a027c05f
To: <sip:1101@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(a)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/
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
6:28 p.m.
Hiddenly? :-)
-- Alex
On 11/24/20 12:22 PM, me.projects(a)yahoo.com wrote:
Thanks for your reply.
I can't see the ACK being relayed to MSTeams in network capture through
in Relay Route
if(is_method("ACK|BYE")) {
sip_trace();
setflag(22);
}
but call has been established successfully. is ACK is being relayed
hiddenly by Kamailio ?
On Tuesday, November 24, 2020, 09:35:32 PM GMT+5, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
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
<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
<https://kamailio.org/docs/modules/stable/modules/tm.html#tm.p.wt_timer>
On 11/24/20 3:24 AM, me.projects(a)yahoo.com
<mailto:me.projects@yahoo.com> wrote:
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, <http://www.evaristesys.com/,
--
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/
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@PBX_IP
<mailto:1102@PBX_IP>>;tag=e08f0a03-1120-4e13-b0e2-90d1a027c05f
TO: <sip:1101@KAM_IP
<mailto:1101@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@PBX_IP
<mailto:1102@PBX_IP>>;tag=e08f0a03-1120-4e13-b0e2-90d1a027c05f
To: <sip:1101@KAM_IP
<mailto:1101@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(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
http://www.csrpswitch.com/
<http://www.csrpswitch.com/>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
6:35 p.m.
Hiddenly means without being captured in SIP_TRACE module
On Tuesday, November 24, 2020, 10:29:58 PM GMT+5, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Hiddenly? :-)
-- Alex
On 11/24/20 12:22 PM, me.projects(a)yahoo.com wrote:
Thanks for your reply.
I can't see the ACK being relayed to MSTeams in network capture through
in Relay Route
if(is_method("ACK|BYE")) {
sip_trace();
setflag(22);
}
but call has been established successfully. is ACK is being relayed
hiddenly by Kamailio ?
On Tuesday, November 24, 2020, 09:35:32 PM GMT+5, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
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
<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
<https://kamailio.org/docs/modules/stable/modules/tm.html#tm.p.wt_timer>
On 11/24/20 3:24 AM, me.projects(a)yahoo.com
<mailto:me.projects@yahoo.com> wrote:
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, <http://www.evaristesys.com/,
--
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/
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@PBX_IP
<mailto:1102@PBX_IP>>;tag=e08f0a03-1120-4e13-b0e2-90d1a027c05f
TO: <sip:1101@KAM_IP
<mailto:1101@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@PBX_IP
<mailto:1102@PBX_IP>>;tag=e08f0a03-1120-4e13-b0e2-90d1a027c05f
To: <sip:1101@KAM_IP
<mailto:1101@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(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
http://www.csrpswitch.com/
<http://www.csrpswitch.com/>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
6:36 p.m.
Try to do a manual packet capture and test that theory.
On 11/24/20 12:35 PM, me.projects(a)yahoo.com wrote:
Hiddenly means without being captured in SIP_TRACE
module
--
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/
6:35 p.m.
On Tuesday 24 November 2020 at 18:28:44, Alex Balashov wrote:
Hiddenly? :-)
I like the word - I can think of several contexts it would be useful in, and
the standard way of expressing the concept is so much less concise.
Antony.
--
Most people have more than the average number of legs.
Please reply to the list;
please *don't* CC me.
6:46 p.m.
On 11/24/20 12:35 PM, Antony Stone wrote:
On Tuesday 24 November 2020 at 18:28:44, Alex Balashov
wrote:
It's true; the closest and comparably terse adverb I can readily conjure
is "surreptitiously", which implies a more actively deliberate and
nefarious level of packet forwarding.
--
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/
Hiddenly? :-)
I like the word - I can think of several contexts it would be useful in, and
the standard way of expressing the concept is so much less concise. 
6:53 p.m.
The outgoing (relayed) e2e ACK is not captured by the sipcapture module in
"transaction" capture mode (the default), because of tm module internals.
You have to explicitly capture it in the onsend_route.
onsend_route {
if ($rm == 'ACK') {
sip_trace();
}
}
Cheers,
Federico
On Tue, Nov 24, 2020 at 6:47 PM Alex Balashov <abalashov(a)evaristesys.com>
wrote:
On 11/24/20 12:35 PM, Antony Stone wrote:
On Tuesday 24 November 2020 at 18:28:44, Alex
Balashov wrote:
and
Hiddenly? :-)
I like the word - I can think of several contexts it would be useful in, the standard way of expressing the concept is so
much less concise.
It's true; the closest and comparably terse adverb I can readily conjure
is "surreptitiously", which implies a more actively deliberate and
nefarious level of packet forwarding.
--
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/
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
7 p.m.
Wow great. Thanks for your help :)
On Tuesday, November 24, 2020, 10:54:25 PM GMT+5, Federico Cabiddu
<federico.cabiddu(a)gmail.com> wrote:
The outgoing (relayed) e2e ACK is not captured by the sipcapture module in
"transaction" capture mode (the default), because of tm module internals.You
have to explicitly capture it in the onsend_route.
onsend_route {
if ($rm == 'ACK') {
sip_trace();
}
}
Cheers,
Federico
On Tue, Nov 24, 2020 at 6:47 PM Alex Balashov <abalashov(a)evaristesys.com> wrote:
On 11/24/20 12:35 PM, Antony Stone wrote:
On Tuesday 24 November 2020 at 18:28:44, Alex Balashov
wrote:
It's true; the closest and comparably terse adverb I can readily conjure
is "surreptitiously", which implies a more actively deliberate and
nefarious level of packet forwarding.
--
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/
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hiddenly? :-)
I like the word - I can think of several contexts it would be useful in, and
the standard way of expressing the concept is so much less concise. 
7:51 p.m.
Or use sipdump module as an alternative
https://kamailio.org/docs/modules/stable/modules/sipdump.html
On Tue, Nov 24, 2020 at 12:55 PM Federico Cabiddu <
federico.cabiddu(a)gmail.com> wrote:
The outgoing (relayed) e2e ACK is not captured by the
sipcapture module in
"transaction" capture mode (the default), because of tm module internals.
You have to explicitly capture it in the onsend_route.
onsend_route {
if ($rm == 'ACK') {
sip_trace();
}
}
Cheers,
Federico
On Tue, Nov 24, 2020 at 6:47 PM Alex Balashov <abalashov(a)evaristesys.com>
wrote:
On 11/24/20 12:35 PM, Antony Stone wrote:
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
On Tuesday 24 November 2020 at 18:28:44, Alex
Balashov wrote:
in, and
Hiddenly? :-)
I like the word - I can think of several contexts it would be useful the standard way of expressing the concept is so
much less concise.
It's true; the closest and comparably terse adverb I can readily conjure
is "surreptitiously", which implies a more actively deliberate and
nefarious level of packet forwarding.
--
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/
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
1257
days inactive
1257
days old
10 comments
5 participants
participants (5)
-
Alex Balashov -
Antony Stone -
Federico Cabiddu -
me.projects＠yahoo.com -
Sergiu Pojoga