23 Dec
2024
23 Dec
'24
4:19 p.m.
Hello all, moving just a bit aside of the http and async_http.
After all the real useful and interesting thread on that topic what helped me, im facing a
problem i cant deal with and need a hint at least.
Scenario
INVITE -> Kamailio
on request_route
...
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080", "HTTP_REPLY");
}
…
Kamailio -> 100 - Trying
then
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
Kamailio -> 302 Redirect
ACK -> Kamailio
This last ACK, how can i read it and use it to terminate the transaction? because Kamailio
keeps transmitting the 302 message 3 more times until the transaction is finished by a
timer
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f4c3fcd35a0
(p:0x7f4c3fad85d0/n:0x7f4c3fad85d0)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f4c3fcd35a0
from timer.c:651
in request_route i have
if(is_method("ACK")){
if(!t_check_trans()){
t_release();
}
exit;
}
23 Dec
23 Dec
4:44 p.m.
Does your 3xx message have a Contact, and does that Contact URI match the RURI in your
ACK?
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us>
[img]<https://www.siptrunk.com>
[img]<https://www.flowroute.com>
________________________________
From: Alexis Fidalgo via sr-users <sr-users(a)lists.kamailio.org>
Sent: Monday, December 23, 2024 3:19 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: Alexis Fidalgo <alzrck(a)gmail.com>
Subject: [SR-Users] help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Hello all, moving just a bit aside of the http and async_http.
After all the real useful and interesting thread on that topic what helped me, im facing a
problem i cant deal with and need a hint at least.
Scenario
INVITE -> Kamailio
on request_route
...
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080", "HTTP_REPLY");
}
…
Kamailio -> 100 - Trying
then
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
Kamailio -> 302 Redirect
ACK -> Kamailio
This last ACK, how can i read it and use it to terminate the transaction? because Kamailio
keeps transmitting the 302 message 3 more times until the transaction is finished by a
timer
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f4c3fcd35a0
(p:0x7f4c3fad85d0/n:0x7f4c3fad85d0)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f4c3fcd35a0
from timer.c:651
in request_route i have
if(is_method("ACK")){
if(!t_check_trans()){
t_release();
}
exit;
}
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
5:14 p.m.
request_route:
if(is_method("ACK")){
if(!t_check_trans()){
xlog("L_INFO","AAAA: MATCHED TRANSACTION\n"); }
else {
xlog("L_INFO","BBBB: MATCHED TRANSACTION\n");
}
exit;
}
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080", "HTTP_REPLY");
}
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
append_branch("sip:1111@otherdomain.com:5060");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
pcap list
15 173.459633617 192.168.86.250 → 192.168.86.128 SIP/SDP 588 Request: INVITE
sip:123456@192.168.86.128:5060 |
16 173.460549905 192.168.86.128 → 192.168.86.250 SIP 344 Status: 100 Trying |
17 173.762804083 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
18 173.789493070 192.168.86.250 → 192.168.86.128 SIP 415 Request: ACK
sip:123456@192.168.86.128:5060 |
19 174.213115954 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
20 175.213132963 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
21 177.213136064 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
sipp trace dump
----------------------------------------------- 2024-12-23 19:10:01.820622
UDP message sent (546 bytes):
INVITE sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456 <sip:123456@192.168.86.128:5060>
Call-ID: 1-35646(a)192.168.86.250
CSeq: 1 INVITE
Contact: sip:sipp@192.168.86.250:5060
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: 139
v=0
o=user1 53655765 2353687637 IN IP4 192.168.86.250
s=-
c=IN IP4 192.168.86.250
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
----------------------------------------------- 2024-12-23 19:10:01.847444
UDP message received [302] bytes :
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456 <sip:123456@192.168.86.128:5060>
Call-ID: 1-35646(a)192.168.86.250
CSeq: 1 INVITE
Server: kamailio (5.8.4 (x86_64/linux))
Content-Length: 0
----------------------------------------------- 2024-12-23 19:10:02.169378
UDP message received [425] bytes :
SIP/2.0 302 Redirect
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456
<sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e0f89f75
Call-ID: 1-35646(a)192.168.86.250
CSeq: 1 INVITE
Contact: <sip:1111@otherdomain.com:5060>, <sip:1111@otherdomain.com:5060>
Server: kamailio (5.8.4 (x86_64/linux))
Content-Length: 0
----------------------------------------------- 2024-12-23 19:10:02.169921
UDP message sent (373 bytes):
ACK sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-3
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456
<sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e0f89f75
Call-ID: 1-35646(a)192.168.86.250
CSeq: 1 ACK
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
sipp br.xml
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<scenario name="Basic Sipstone UAC">
<!-- In client mode (sipp placing calls), the Call-ID MUST be -->
<!-- generated by sipp. To do so, use [call_id] keyword. -->
<send retrans="500">
<![CDATA[
INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[media_ip_type] [media_ip]
t=0 0
m=audio [media_port] RTP/AVP 0
a=rtpmap:0 PCMU/8000
]]>
</send>
<recv response="100" optional="true"></recv>
<!-- By adding rrs="true" (Record Route Sets), the route sets
-->
<!-- are saved and used for following messages sent. Useful to test -->
<!-- against stateful SIP proxies/B2BUAs. -->
<recv response="302" rtd="true">
</recv>
<!-- Packet lost can be simulated in any send/recv message by -->
<!-- by adding the 'lost = "10"'. Value can be [1-100] percent.
-->
<send>
<![CDATA[
ACK sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<!-- definition of the response time repartition table (unit is ms) -->
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
<!-- definition of the call length repartition table (unit is ms) -->
<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
On 23 Dec 2024, at 6:44 PM, Ben Kaufman
<bkaufman(a)bcmone.com> wrote:
Does your 3xx message have a Contact, and does that Contact URI match the RURI in your
ACK?
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com <mailto:bkaufman@bcmone.com>
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
<https://www.sip.us/>
<https://www.siptrunk.com/>
<https://www.flowroute.com/>
From: Alexis Fidalgo via sr-users <sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>>
Sent: Monday, December 23, 2024 3:19 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>>
Cc: Alexis Fidalgo <alzrck(a)gmail.com <mailto:alzrck@gmail.com>>
Subject: [SR-Users] help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Hello all, moving just a bit aside of the http and async_http.
After all the real useful and interesting thread on that topic what helped me, im facing
a problem i cant deal with and need a hint at least.
Scenario
INVITE -> Kamailio
on request_route
...
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080 <http://nuc:8080/>",
"HTTP_REPLY");
}
…
Kamailio -> 100 - Trying
then
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
Kamailio -> 302 Redirect
ACK -> Kamailio
This last ACK, how can i read it and use it to terminate the transaction? because
Kamailio keeps transmitting the 302 message 3 more times until the transaction is finished
by a timer
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f4c3fcd35a0
(p:0x7f4c3fad85d0/n:0x7f4c3fad85d0)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f4c3fcd35a0
from timer.c:651
in request_route i have
if(is_method("ACK")){
if(!t_check_trans()){
t_release();
}
exit;
}
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
5:33 p.m.
Why is the Via branch on the ACK different to that of the INVITE or the response?
See RFC 3261 § 17.1.1.3 ("Construction of the ACK Request"):
"The ACK MUST contain a single Via header field, and
this MUST be equal to the top Via header field of the original
request."
You have:
INVITE sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
SIP/2.0 302 Redirect
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
ACK sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-3
So, it's not being matched.
-- Alex
On Dec 23, 2024, at 5:14 pm, Alexis Fidalgo via
sr-users <sr-users(a)lists.kamailio.org> wrote:
request_route:
if(is_method("ACK")){
if(!t_check_trans()){
xlog("L_INFO","AAAA: MATCHED TRANSACTION\n"); }
else {
xlog("L_INFO","BBBB: MATCHED TRANSACTION\n");
}
exit;
}
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080", "HTTP_REPLY");
}
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
append_branch("sip:1111@otherdomain.com:5060");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
pcap list
15 173.459633617 192.168.86.250 → 192.168.86.128 SIP/SDP 588 Request: INVITE
sip:123456@192.168.86.128:5060 |
16 173.460549905 192.168.86.128 → 192.168.86.250 SIP 344 Status: 100 Trying |
17 173.762804083 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
18 173.789493070 192.168.86.250 → 192.168.86.128 SIP 415 Request: ACK
sip:123456@192.168.86.128:5060 |
19 174.213115954 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
20 175.213132963 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
21 177.213136064 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
sipp trace dump
----------------------------------------------- 2024-12-23 19:10:01.820622
UDP message sent (546 bytes):
INVITE sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456 <sip:123456@192.168.86.128:5060>
Call-ID: 1-35646(a)192.168.86.250
CSeq: 1 INVITE
Contact: sip:sipp@192.168.86.250:5060
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: 139
v=0
o=user1 53655765 2353687637 IN IP4 192.168.86.250
s=-
c=IN IP4 192.168.86.250
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
----------------------------------------------- 2024-12-23 19:10:01.847444
UDP message received [302] bytes :
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456 <sip:123456@192.168.86.128:5060>
Call-ID: 1-35646(a)192.168.86.250
CSeq: 1 INVITE
Server: kamailio (5.8.4 (x86_64/linux))
Content-Length: 0
----------------------------------------------- 2024-12-23 19:10:02.169378
UDP message received [425] bytes :
SIP/2.0 302 Redirect
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456
<sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e0f89f75
Call-ID: 1-35646(a)192.168.86.250
CSeq: 1 INVITE
Contact: <sip:1111@otherdomain.com:5060>, <sip:1111@otherdomain.com:5060>
Server: kamailio (5.8.4 (x86_64/linux))
Content-Length: 0
----------------------------------------------- 2024-12-23 19:10:02.169921
UDP message sent (373 bytes):
ACK sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-3
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456
<sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e0f89f75
Call-ID: 1-35646(a)192.168.86.250
CSeq: 1 ACK
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
sipp br.xml
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<scenario name="Basic Sipstone UAC">
<!-- In client mode (sipp placing calls), the Call-ID MUST be -->
<!-- generated by sipp. To do so, use [call_id] keyword. -->
<send retrans="500">
<![CDATA[
INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp
<sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[media_ip_type] [media_ip]
t=0 0
m=audio [media_port] RTP/AVP 0
a=rtpmap:0 PCMU/8000
]]>
</send>
<recv response="100" optional="true"></recv>
<!-- By adding rrs="true" (Record Route Sets), the route sets
-->
<!-- are saved and used for following messages sent. Useful to test -->
<!-- against stateful SIP proxies/B2BUAs. -->
<recv response="302" rtd="true">
</recv>
<!-- Packet lost can be simulated in any send/recv message by -->
<!-- by adding the 'lost = "10"'. Value can be [1-100] percent.
-->
<send>
<![CDATA[
ACK sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp
<sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<!-- definition of the response time repartition table (unit is ms) -->
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
<!-- definition of the call length repartition table (unit is ms) -->
<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
On 23 Dec 2024, at 6:44 PM, Ben Kaufman
<bkaufman(a)bcmone.com> wrote:
Does your 3xx message have a Contact, and does that Contact URI match the RURI in your
ACK?
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
From: Alexis Fidalgo via sr-users <sr-users(a)lists.kamailio.org>
Sent: Monday, December 23, 2024 3:19 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: Alexis Fidalgo <alzrck(a)gmail.com>
Subject: [SR-Users] help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Hello all, moving just a bit aside of the http and async_http.
After all the real useful and interesting thread on that topic what helped me, im facing
a problem i cant deal with and need a hint at least.
Scenario
INVITE -> Kamailio
on request_route
...
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080", "HTTP_REPLY");
}
…
Kamailio -> 100 - Trying
then
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
Kamailio -> 302 Redirect
ACK -> Kamailio
This last ACK, how can i read it and use it to terminate the transaction? because
Kamailio keeps transmitting the 302 message 3 more times until the transaction is finished
by a timer
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f4c3fcd35a0
(p:0x7f4c3fad85d0/n:0x7f4c3fad85d0)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f4c3fcd35a0
from timer.c:651
in request_route i have
if(is_method("ACK")){
if(!t_check_trans()){
t_release();
}
exit;
}
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
5:55 p.m.
you’re right
for the ack the branch is built with
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
looks like sipp is increasing the branch last digit for any reason (im reading now why
this happen)
On 23 Dec 2024, at 7:33 PM, Alex Balashov via sr-users
<sr-users(a)lists.kamailio.org> wrote:
Why is the Via branch on the ACK different to that of the INVITE or the response?
See RFC 3261 § 17.1.1.3 ("Construction of the ACK Request"):
"The ACK MUST contain a single Via header field, and
this MUST be equal to the top Via header field of the original
request."
You have:
INVITE sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
SIP/2.0 302 Redirect
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
ACK sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-3
So, it's not being matched.
-- Alex
On Dec 23, 2024, at 5:14 pm, Alexis Fidalgo via
sr-users <sr-users(a)lists.kamailio.org> wrote:
request_route:
if(is_method("ACK")){
if(!t_check_trans()){
xlog("L_INFO","AAAA: MATCHED TRANSACTION\n"); }
else {
xlog("L_INFO","BBBB: MATCHED TRANSACTION\n");
}
exit;
}
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080", "HTTP_REPLY");
}
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
append_branch("sip:1111@otherdomain.com:5060");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
pcap list
15 173.459633617 192.168.86.250 → 192.168.86.128 SIP/SDP 588 Request: INVITE
sip:123456@192.168.86.128:5060 |
16 173.460549905 192.168.86.128 → 192.168.86.250 SIP 344 Status: 100 Trying |
17 173.762804083 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
18 173.789493070 192.168.86.250 → 192.168.86.128 SIP 415 Request: ACK
sip:123456@192.168.86.128:5060 |
19 174.213115954 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
20 175.213132963 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
21 177.213136064 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
sipp trace dump
----------------------------------------------- 2024-12-23 19:10:01.820622
UDP message sent (546 bytes):
INVITE sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456 <sip:123456@192.168.86.128:5060>
Call-ID: 1-35646(a)192.168.86.250
CSeq: 1 INVITE
Contact: sip:sipp@192.168.86.250:5060
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: 139
v=0
o=user1 53655765 2353687637 IN IP4 192.168.86.250
s=-
c=IN IP4 192.168.86.250
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
----------------------------------------------- 2024-12-23 19:10:01.847444
UDP message received [302] bytes :
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456 <sip:123456@192.168.86.128:5060>
Call-ID: 1-35646(a)192.168.86.250
CSeq: 1 INVITE
Server: kamailio (5.8.4 (x86_64/linux))
Content-Length: 0
----------------------------------------------- 2024-12-23 19:10:02.169378
UDP message received [425] bytes :
SIP/2.0 302 Redirect
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456
<sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e0f89f75
Call-ID: 1-35646(a)192.168.86.250
CSeq: 1 INVITE
Contact: <sip:1111@otherdomain.com:5060>, <sip:1111@otherdomain.com:5060>
Server: kamailio (5.8.4 (x86_64/linux))
Content-Length: 0
----------------------------------------------- 2024-12-23 19:10:02.169921
UDP message sent (373 bytes):
ACK sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-3
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456
<sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e0f89f75
Call-ID: 1-35646(a)192.168.86.250
CSeq: 1 ACK
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
sipp br.xml
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<scenario name="Basic Sipstone UAC">
<!-- In client mode (sipp placing calls), the Call-ID MUST be -->
<!-- generated by sipp. To do so, use [call_id] keyword. -->
<send retrans="500">
<![CDATA[
INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[media_ip_type] [media_ip]
t=0 0
m=audio [media_port] RTP/AVP 0
a=rtpmap:0 PCMU/8000
]]>
</send>
<recv response="100" optional="true"></recv>
<!-- By adding rrs="true" (Record Route Sets), the route sets
-->
<!-- are saved and used for following messages sent. Useful to test -->
<!-- against stateful SIP proxies/B2BUAs. -->
<recv response="302" rtd="true">
</recv>
<!-- Packet lost can be simulated in any send/recv message by -->
<!-- by adding the 'lost = "10"'. Value can be [1-100] percent.
-->
<send>
<![CDATA[
ACK sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<!-- definition of the response time repartition table (unit is ms) -->
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
<!-- definition of the call length repartition table (unit is ms) -->
<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
On 23 Dec 2024, at 6:44 PM, Ben Kaufman
<bkaufman(a)bcmone.com> wrote:
Does your 3xx message have a Contact, and does that Contact URI match the RURI in your
ACK?
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
From: Alexis Fidalgo via sr-users <sr-users(a)lists.kamailio.org>
Sent: Monday, December 23, 2024 3:19 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: Alexis Fidalgo <alzrck(a)gmail.com>
Subject: [SR-Users] help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Hello all, moving just a bit aside of the http and async_http.
After all the real useful and interesting thread on that topic what helped me, im facing
a problem i cant deal with and need a hint at least.
Scenario
INVITE -> Kamailio
on request_route
...
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080", "HTTP_REPLY");
}
…
Kamailio -> 100 - Trying
then
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
Kamailio -> 302 Redirect
ACK -> Kamailio
This last ACK, how can i read it and use it to terminate the transaction? because
Kamailio keeps transmitting the 302 message 3 more times until the transaction is finished
by a timer
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f4c3fcd35a0
(p:0x7f4c3fad85d0/n:0x7f4c3fad85d0)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f4c3fcd35a0
from timer.c:651
in request_route i have
if(is_method("ACK")){
if(!t_check_trans()){
t_release();
}
exit;
}
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
6:09 p.m.
I don't think you'll find a really good reason why SIPp does that, aside from
"that's how it was originally written", and sudden changes in behavior would
probably cause more problems than keeping it and using their method for off-setting the
counter.
The documentation defines it as a, "value which is a concatenation of magic cookie
(z9hG4bK) + call number + message index in scenario. An offset (like [branch-N]) can be
appended if you need to have the same branch value as a previous message." I think
it's actually magic cookie + PID + call number + message index, so you could omit the
message index, and just make it like this in every request:
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[z9hG4bK]-[pid]-[call_number]-0
And then only increment the suffix if you're actually doing a fork of the request..
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us/>
[img]<https://www.siptrunk.com/>
[img]<https://www.flowroute.com/>
________________________________
From: Alexis Fidalgo via sr-users <sr-users(a)lists.kamailio.org>
Sent: Monday, December 23, 2024 4:55 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: Alexis Fidalgo <alzrck(a)gmail.com>
Subject: [SR-Users] Re: help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
you’re right
for the ack the branch is built with
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
looks like sipp is increasing the branch last digit for any reason (im reading now why
this happen)
On 23 Dec 2024, at 7:33 PM, Alex Balashov via sr-users
<sr-users(a)lists.kamailio.org> wrote:
Why is the Via branch on the ACK different to that of the INVITE or the response?
See RFC 3261 § 17.1.1.3 ("Construction of the ACK Request"):
"The ACK MUST contain a single Via header field, and
this MUST be equal to the top Via header field of the original
request."
You have:
INVITE sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
SIP/2.0 302 Redirect
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
ACK sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-3
So, it's not being matched.
-- Alex
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
On Dec 23, 2024, at 5:14 pm, Alexis Fidalgo via
sr-users <sr-users(a)lists.kamailio.org> wrote:
request_route:
if(is_method("ACK")){
if(!t_check_trans()){
xlog("L_INFO","AAAA: MATCHED TRANSACTION\n"); }
else {
xlog("L_INFO","BBBB: MATCHED TRANSACTION\n");
}
exit;
}
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080", "HTTP_REPLY");
}
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
append_branch("sip:1111@otherdomain.com:5060");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
pcap list
15 173.459633617 192.168.86.250 → 192.168.86.128 SIP/SDP 588 Request: INVITE
sip:123456@192.168.86.128:5060 |
16 173.460549905 192.168.86.128 → 192.168.86.250 SIP 344 Status: 100 Trying |
17 173.762804083 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
18 173.789493070 192.168.86.250 → 192.168.86.128 SIP 415 Request: ACK
sip:123456@192.168.86.128:5060 |
19 174.213115954 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
20 175.213132963 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
21 177.213136064 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
sipp trace dump
----------------------------------------------- 2024-12-23 19:10:01.820622
UDP message sent (546 bytes):
INVITE sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456 <sip:123456@192.168.86.128:5060>
Call-ID: 1-35646(a)192.168.86.250
CSeq: 1 INVITE
Contact: sip:sipp@192.168.86.250:5060
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: 139
v=0
o=user1 53655765 2353687637 IN IP4 192.168.86.250
s=-
c=IN IP4 192.168.86.250
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
----------------------------------------------- 2024-12-23 19:10:01.847444
UDP message received [302] bytes :
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456 <sip:123456@192.168.86.128:5060>
Call-ID: 1-35646(a)192.168.86.250
CSeq: 1 INVITE
Server: kamailio (5.8.4 (x86_64/linux))
Content-Length: 0
----------------------------------------------- 2024-12-23 19:10:02.169378
UDP message received [425] bytes :
SIP/2.0 302 Redirect
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456
<sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e0f89f75
Call-ID: 1-35646(a)192.168.86.250
CSeq: 1 INVITE
Contact: <sip:1111@otherdomain.com:5060>, <sip:1111@otherdomain.com:5060>
Server: kamailio (5.8.4 (x86_64/linux))
Content-Length: 0
----------------------------------------------- 2024-12-23 19:10:02.169921
UDP message sent (373 bytes):
ACK sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-3
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456
<sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e0f89f75
Call-ID: 1-35646(a)192.168.86.250
CSeq: 1 ACK
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
sipp br.xml
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<scenario name="Basic Sipstone UAC">
<!-- In client mode (sipp placing calls), the Call-ID MUST be -->
<!-- generated by sipp. To do so, use [call_id] keyword. -->
<send retrans="500">
<![CDATA[
INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp
<sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[media_ip_type] [media_ip]
t=0 0
m=audio [media_port] RTP/AVP 0
a=rtpmap:0 PCMU/8000
]]>
</send>
<recv response="100" optional="true"></recv>
<!-- By adding rrs="true" (Record Route Sets), the route sets
-->
<!-- are saved and used for following messages sent. Useful to test -->
<!-- against stateful SIP proxies/B2BUAs. -->
<recv response="302" rtd="true">
</recv>
<!-- Packet lost can be simulated in any send/recv message by -->
<!-- by adding the 'lost = "10"'. Value can be [1-100] percent.
-->
<send>
<![CDATA[
ACK sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp
<sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<!-- definition of the response time repartition table (unit is ms) -->
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
<!-- definition of the call length repartition table (unit is ms) -->
<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristes…
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
On 23 Dec 2024, at 6:44 PM, Ben Kaufman
<bkaufman(a)bcmone.com> wrote:
Does your 3xx message have a Contact, and does that Contact URI match the RURI in your
ACK?
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
From: Alexis Fidalgo via sr-users <sr-users(a)lists.kamailio.org>
Sent: Monday, December 23, 2024 3:19 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: Alexis Fidalgo <alzrck(a)gmail.com>
Subject: [SR-Users] help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Hello all, moving just a bit aside of the http and async_http.
After all the real useful and interesting thread on that topic what helped me, im facing
a problem i cant deal with and need a hint at least.
Scenario
INVITE -> Kamailio
on request_route
...
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080", "HTTP_REPLY");
}
…
Kamailio -> 100 - Trying
then
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
Kamailio -> 302 Redirect
ACK -> Kamailio
This last ACK, how can i read it and use it to terminate the transaction? because
Kamailio keeps transmitting the 302 message 3 more times until the transaction is finished
by a timer
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f4c3fcd35a0
(p:0x7f4c3fad85d0/n:0x7f4c3fad85d0)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f4c3fcd35a0
from timer.c:651
in request_route i have
if(is_method("ACK")){
if(!t_check_trans()){
t_release();
}
exit;
}
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
6:22 p.m.
Yes and it worked now.
<send>
<![CDATA[
ACK [next_url] SIP/2.0
Via: SIP/2.0/[transport]
[local_ip]:[local_port];branch=z9hG4bK-[pid]-[call_number]-0
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
Contact: [next_url]
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
No more retransmission and
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} tm [t_lookup.c:1565]: t_check_msg(): msg
(0x7f05de39d4d0) id=3/16 global id=2/16 T start=0xffffffffffffffff
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} tm [t_lookup.c:781]: t_lookup_request():
start searching: hash=31760, isACK=1
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} tm [t_lookup.c:483]: matching_3261():
RFC3261 transaction matched, tid=-43346-1-0
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} tm [t_lookup.c:998]: t_lookup_request():
transaction found (T=0x7f05d8e425a0)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} tm [t_lookup.c:1637]: t_check_msg(): msg
(0x7f05de39d4d0) id=3/16 global id=3/16 T end=0x7f05d8e425a0
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} tm [t_reply.c:1782]: cleanup_uac_timers():
RETR/FR timers reset
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} tm [t_funcs.c:133]: put_on_wait(): put T
[0x7f05d8e425a0] on wait
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/timer.c:555]:
timer_add_safe(): timer_add called on an active timer 0x7f05d8e42658 (0x7f05d8bdcb60,
0x7f05d8bdcb60), flags 201
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} tm [t_funcs.c:156]: put_on_wait():
transaction 0x7f05d8e425a0 already on wait
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/receive.c:531]:
receive_msg(): request-route executed in: 94 usec
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/receive.c:635]:
receive_msg(): cleaning up
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f05d8e425a0
(p:0x7f05d8cf5eb0/n:0x7f05d8cf5eb0)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f05d8e425a0
from timer.c:651
thanks!!!
now ill run the comparison between http and async_http to compare.
On 23 Dec 2024, at 8:09 PM, Ben Kaufman
<bkaufman(a)bcmone.com> wrote:
I don't think you'll find a really good reason why SIPp does that, aside from
"that's how it was originally written", and sudden changes in behavior would
probably cause more problems than keeping it and using their method for off-setting the
counter.
The documentation defines it as a, "value which is a concatenation of magic cookie
(z9hG4bK) + call number + message index in scenario. An offset (like [branch-N]) can be
appended if you need to have the same branch value as a previous message." I think
it's actually magic cookie + PID + call number + message index, so you could omit the
message index, and just make it like this in every request:
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[z9hG4bK]-[pid]-[call_number]-0
And then only increment the suffix if you're actually doing a fork of the request..
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com <mailto:bkaufman@bcmone.com>
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
<https://www.sip.us/>
<https://www.siptrunk.com/>
<https://www.flowroute.com/>
From: Alexis Fidalgo via sr-users <sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>>
Sent: Monday, December 23, 2024 4:55 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>>
Cc: Alexis Fidalgo <alzrck(a)gmail.com <mailto:alzrck@gmail.com>>
Subject: [SR-Users] Re: help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
you’re right
for the ack the branch is built with
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
looks like sipp is increasing the branch last digit for any reason (im reading now why
this happen)
On 23 Dec 2024, at 7:33 PM, Alex Balashov via
sr-users <sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>>
wrote:
Why is the Via branch on the ACK different to that of the INVITE or the response?
See RFC 3261 § 17.1.1.3 ("Construction of the ACK Request"):
"The ACK MUST contain a single Via header field, and
this MUST be equal to the top Via header field of the original
request."
You have:
INVITE sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
SIP/2.0 302 Redirect
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
ACK sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-3
So, it's not being matched.
-- Alex
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
On Dec 23, 2024, at 5:14 pm, Alexis Fidalgo via
sr-users <sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>>
wrote:
request_route:
if(is_method("ACK")){
if(!t_check_trans()){
xlog("L_INFO","AAAA: MATCHED TRANSACTION\n"); }
else {
xlog("L_INFO","BBBB: MATCHED TRANSACTION\n");
}
exit;
}
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080 <http://nuc:8080/>",
"HTTP_REPLY");
}
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
append_branch("sip:1111@otherdomain.com:5060");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
pcap list
15 173.459633617 192.168.86.250 → 192.168.86.128 SIP/SDP 588 Request: INVITE
sip:123456@192.168.86.128:5060 |
16 173.460549905 192.168.86.128 → 192.168.86.250 SIP 344 Status: 100 Trying |
17 173.762804083 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
18 173.789493070 192.168.86.250 → 192.168.86.128 SIP 415 Request: ACK
sip:123456@192.168.86.128:5060 |
19 174.213115954 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
20 175.213132963 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
21 177.213136064 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
sipp trace dump
----------------------------------------------- 2024-12-23 19:10:01.820622
UDP message sent (546 bytes):
INVITE sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456 <sip:123456@192.168.86.128:5060>
Call-ID: 1-35646(a)192.168.86.250 <mailto:1-35646@192.168.86.250>
CSeq: 1 INVITE
Contact: sip:sipp@192.168.86.250:5060
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: 139
v=0
o=user1 53655765 2353687637 IN IP4 192.168.86.250
s=-
c=IN IP4 192.168.86.250
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
----------------------------------------------- 2024-12-23 19:10:01.847444
UDP message received [302] bytes :
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456 <sip:123456@192.168.86.128:5060>
Call-ID: 1-35646(a)192.168.86.250 <mailto:1-35646@192.168.86.250>
CSeq: 1 INVITE
Server: kamailio (5.8.4 (x86_64/linux))
Content-Length: 0
----------------------------------------------- 2024-12-23 19:10:02.169378
UDP message received [425] bytes :
SIP/2.0 302 Redirect
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456
<sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e0f89f75
Call-ID: 1-35646(a)192.168.86.250 <mailto:1-35646@192.168.86.250>
CSeq: 1 INVITE
Contact: <sip:1111@otherdomain.com:5060>, <sip:1111@otherdomain.com:5060>
Server: kamailio (5.8.4 (x86_64/linux))
Content-Length: 0
----------------------------------------------- 2024-12-23 19:10:02.169921
UDP message sent (373 bytes):
ACK sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-3
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456
<sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e0f89f75
Call-ID: 1-35646(a)192.168.86.250 <mailto:1-35646@192.168.86.250>
CSeq: 1 ACK
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
sipp br.xml
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<scenario name="Basic Sipstone UAC">
<!-- In client mode (sipp placing calls), the Call-ID MUST be -->
<!-- generated by sipp. To do so, use [call_id] keyword. -->
<send retrans="500">
<![CDATA[
INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[media_ip_type] [media_ip]
t=0 0
m=audio [media_port] RTP/AVP 0
a=rtpmap:0 PCMU/8000
]]>
</send>
<recv response="100" optional="true"></recv>
<!-- By adding rrs="true" (Record Route Sets), the route sets
-->
<!-- are saved and used for following messages sent. Useful to test -->
<!-- against stateful SIP proxies/B2BUAs. -->
<recv response="302" rtd="true">
</recv>
<!-- Packet lost can be simulated in any send/recv message by -->
<!-- by adding the 'lost = "10"'. Value can be [1-100] percent.
-->
<send>
<![CDATA[
ACK sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<!-- definition of the response time repartition table (unit is ms) -->
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
<!-- definition of the call length repartition table (unit is ms) -->
<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristes…
<https://evaristesys.com/>
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
On 23 Dec 2024, at 6:44 PM, Ben Kaufman
<bkaufman(a)bcmone.com <mailto:bkaufman@bcmone.com>> wrote:
Does your 3xx message have a Contact, and does that Contact URI match the RURI in your
ACK?
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com <mailto:bkaufman@bcmone.com>
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
From: Alexis Fidalgo via sr-users <sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>>
Sent: Monday, December 23, 2024 3:19 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>>
Cc: Alexis Fidalgo <alzrck(a)gmail.com <mailto:alzrck@gmail.com>>
Subject: [SR-Users] help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Hello all, moving just a bit aside of the http and async_http.
After all the real useful and interesting thread on that topic what helped me, im facing
a problem i cant deal with and need a hint at least.
Scenario
INVITE -> Kamailio
on request_route
...
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080 <http://nuc:8080/>",
"HTTP_REPLY");
}
…
Kamailio -> 100 - Trying
then
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
Kamailio -> 302 Redirect
ACK -> Kamailio
This last ACK, how can i read it and use it to terminate the transaction? because
Kamailio keeps transmitting the 302 message 3 more times until the transaction is finished
by a timer
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f4c3fcd35a0
(p:0x7f4c3fad85d0/n:0x7f4c3fad85d0)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f4c3fcd35a0
from timer.c:651
in request_route i have
if(is_method("ACK")){
if(!t_check_trans()){
t_release();
}
exit;
}
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
6:25 p.m.
As a note, I would replace all Via: lines in your config file with that syntax. It
derives to the same thing SIPp sets it to, but it's probably a good habit to just set
it everywhere. 🙂
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us/>
[img]<https://www.siptrunk.com/>
[img]<https://www.flowroute.com/>
________________________________
From: Alexis Fidalgo <alzrck(a)gmail.com>
Sent: Monday, December 23, 2024 5:22 PM
To: Ben Kaufman <bkaufman(a)bcmone.com>
Cc: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Yes and it worked now.
<send>
<![CDATA[
ACK [next_url] SIP/2.0
Via: SIP/2.0/[transport]
[local_ip]:[local_port];branch=z9hG4bK-[pid]-[call_number]-0
From: sipp
<sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
Contact: [next_url]
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
No more retransmission and
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} tm [t_lookup.c:1565]: t_check_msg(): msg
(0x7f05de39d4d0) id=3/16 global id=2/16 T start=0xffffffffffffffff
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} tm [t_lookup.c:781]: t_lookup_request():
start searching: hash=31760, isACK=1
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} tm [t_lookup.c:483]: matching_3261():
RFC3261 transaction matched, tid=-43346-1-0
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} tm [t_lookup.c:998]: t_lookup_request():
transaction found (T=0x7f05d8e425a0)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} tm [t_lookup.c:1637]: t_check_msg(): msg
(0x7f05de39d4d0) id=3/16 global id=3/16 T end=0x7f05d8e425a0
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} tm [t_reply.c:1782]: cleanup_uac_timers():
RETR/FR timers reset
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} tm [t_funcs.c:133]: put_on_wait(): put T
[0x7f05d8e425a0] on wait
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/timer.c:555]:
timer_add_safe(): timer_add called on an active timer 0x7f05d8e42658 (0x7f05d8bdcb60,
0x7f05d8bdcb60), flags 201
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} tm [t_funcs.c:156]: put_on_wait():
transaction 0x7f05d8e425a0 already on wait
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/receive.c:531]:
receive_msg(): request-route executed in: 94 usec
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/receive.c:635]:
receive_msg(): cleaning up
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f05d8e425a0
(p:0x7f05d8cf5eb0/n:0x7f05d8cf5eb0)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f05d8e425a0
from timer.c:651
thanks!!!
now ill run the comparison between http and async_http to compare.
On 23 Dec 2024, at 8:09 PM, Ben Kaufman <bkaufman(a)bcmone.com> wrote:
I don't think you'll find a really good reason why SIPp does that, aside from
"that's how it was originally written", and sudden changes in behavior would
probably cause more problems than keeping it and using their method for off-setting the
counter.
The documentation defines it as a, "value which is a concatenation of magic cookie
(z9hG4bK) + call number + message index in scenario. An offset (like [branch-N]) can be
appended if you need to have the same branch value as a previous message." I think
it's actually magic cookie + PID + call number + message index, so you could omit the
message index, and just make it like this in every request:
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[z9hG4bK]-[pid]-[call_number]-0
And then only increment the suffix if you're actually doing a fork of the request..
Kaufman
Senior Voice Engineer
E: bkaufman@bcmone.com<mailto:bkaufman@bcmone.com>
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us/>
[img]<https://www.siptrunk.com/>
[img]<https://www.flowroute.com/>
________________________________
From: Alexis Fidalgo via sr-users
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Sent: Monday, December 23, 2024 4:55 PM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Cc: Alexis Fidalgo <alzrck@gmail.com<mailto:alzrck@gmail.com>>
Subject: [SR-Users] Re: help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
you’re right
for the ack the branch is built with
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
looks like sipp is increasing the branch last digit for any reason (im reading now why
this happen)
On 23 Dec 2024, at 7:33 PM, Alex Balashov via sr-users
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> wrote:
Why is the Via branch on the ACK different to that of the INVITE or the response?
See RFC 3261 § 17.1.1.3 ("Construction of the ACK Request"):
"The ACK MUST contain a single Via header field, and
this MUST be equal to the top Via header field of the original
request."
You have:
INVITE sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
SIP/2.0 302 Redirect
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
ACK sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-3
So, it's not being matched.
-- Alex
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
On Dec 23, 2024, at 5:14 pm, Alexis Fidalgo via
sr-users <sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
wrote:
request_route:
if(is_method("ACK")){
if(!t_check_trans()){
xlog("L_INFO","AAAA: MATCHED TRANSACTION\n"); }
else {
xlog("L_INFO","BBBB: MATCHED TRANSACTION\n");
}
exit;
}
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080<http://nuc:8080/>",
"HTTP_REPLY");
}
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
append_branch("sip:1111@otherdomain.com:5060");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
pcap list
15 173.459633617 192.168.86.250 → 192.168.86.128 SIP/SDP 588 Request: INVITE
sip:123456@192.168.86.128:5060 |
16 173.460549905 192.168.86.128 → 192.168.86.250 SIP 344 Status: 100 Trying |
17 173.762804083 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
18 173.789493070 192.168.86.250 → 192.168.86.128 SIP 415 Request: ACK
sip:123456@192.168.86.128:5060 |
19 174.213115954 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
20 175.213132963 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
21 177.213136064 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
sipp trace dump
----------------------------------------------- 2024-12-23 19:10:01.820622
UDP message sent (546 bytes):
INVITE sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456 <sip:123456@192.168.86.128:5060>
Call-ID: 1-35646@192.168.86.250<mailto:1-35646@192.168.86.250>
CSeq: 1 INVITE
Contact: sip:sipp@192.168.86.250:5060
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: 139
v=0
o=user1 53655765 2353687637 IN IP4 192.168.86.250
s=-
c=IN IP4 192.168.86.250
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
----------------------------------------------- 2024-12-23 19:10:01.847444
UDP message received [302] bytes :
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456 <sip:123456@192.168.86.128:5060>
Call-ID: 1-35646@192.168.86.250<mailto:1-35646@192.168.86.250>
CSeq: 1 INVITE
Server: kamailio (5.8.4 (x86_64/linux))
Content-Length: 0
----------------------------------------------- 2024-12-23 19:10:02.169378
UDP message received [425] bytes :
SIP/2.0 302 Redirect
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456
<sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e0f89f75
Call-ID: 1-35646@192.168.86.250<mailto:1-35646@192.168.86.250>
CSeq: 1 INVITE
Contact: <sip:1111@otherdomain.com:5060>, <sip:1111@otherdomain.com:5060>
Server: kamailio (5.8.4 (x86_64/linux))
Content-Length: 0
----------------------------------------------- 2024-12-23 19:10:02.169921
UDP message sent (373 bytes):
ACK sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-3
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456
<sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e0f89f75
Call-ID: 1-35646@192.168.86.250<mailto:1-35646@192.168.86.250>
CSeq: 1 ACK
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
sipp br.xml
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<scenario name="Basic Sipstone UAC">
<!-- In client mode (sipp placing calls), the Call-ID MUST be -->
<!-- generated by sipp. To do so, use [call_id] keyword. -->
<send retrans="500">
<![CDATA[
INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp
<sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[media_ip_type] [media_ip]
t=0 0
m=audio [media_port] RTP/AVP 0
a=rtpmap:0 PCMU/8000
]]>
</send>
<recv response="100" optional="true"></recv>
<!-- By adding rrs="true" (Record Route Sets), the route sets
-->
<!-- are saved and used for following messages sent. Useful to test -->
<!-- against stateful SIP proxies/B2BUAs. -->
<recv response="302" rtd="true">
</recv>
<!-- Packet lost can be simulated in any send/recv message by -->
<!-- by adding the 'lost = "10"'. Value can be [1-100] percent.
-->
<send>
<![CDATA[
ACK sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp
<sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<!-- definition of the response time repartition table (unit is ms) -->
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
<!-- definition of the call length repartition table (unit is ms) -->
<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristes…
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
On 23 Dec 2024, at 6:44 PM, Ben Kaufman
<bkaufman@bcmone.com<mailto:bkaufman@bcmone.com>> wrote:
Does your 3xx message have a Contact, and does that Contact URI match the RURI in your
ACK?
Kaufman
Senior Voice Engineer
E: bkaufman@bcmone.com<mailto:bkaufman@bcmone.com>
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
From: Alexis Fidalgo via sr-users
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Sent: Monday, December 23, 2024 3:19 PM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Cc: Alexis Fidalgo <alzrck@gmail.com<mailto:alzrck@gmail.com>>
Subject: [SR-Users] help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Hello all, moving just a bit aside of the http and async_http.
After all the real useful and interesting thread on that topic what helped me, im facing
a problem i cant deal with and need a hint at least.
Scenario
INVITE -> Kamailio
on request_route
...
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080<http://nuc:8080/>",
"HTTP_REPLY");
}
…
Kamailio -> 100 - Trying
then
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
Kamailio -> 302 Redirect
ACK -> Kamailio
This last ACK, how can i read it and use it to terminate the transaction? because
Kamailio keeps transmitting the 302 message 3 more times until the transaction is finished
by a timer
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f4c3fcd35a0
(p:0x7f4c3fad85d0/n:0x7f4c3fad85d0)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f4c3fcd35a0
from timer.c:651
in request_route i have
if(is_method("ACK")){
if(!t_check_trans()){
t_release();
}
exit;
}
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
5:56 p.m.
Ah, yeah. Another bit of fun with SIPp where it's [branch] auto-increments...
To get a value of 0 there without having to manually set your own branch parameter, use
[branch-3] which should be thought of as "branch minus three".
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us/>
[img]<https://www.siptrunk.com/>
[img]<https://www.flowroute.com/>
________________________________
From: Alex Balashov via sr-users <sr-users(a)lists.kamailio.org>
Sent: Monday, December 23, 2024 4:33 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: Alex Balashov <abalashov(a)evaristesys.com>
Subject: [SR-Users] Re: help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Why is the Via branch on the ACK different to that of the INVITE or the response?
See RFC 3261 § 17.1.1.3 ("Construction of the ACK Request"):
"The ACK MUST contain a single Via header field, and
this MUST be equal to the top Via header field of the original
request."
You have:
INVITE sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
SIP/2.0 302 Redirect
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
ACK sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-3
So, it's not being matched.
-- Alex
On Dec 23, 2024, at 5:14 pm, Alexis Fidalgo via
sr-users <sr-users(a)lists.kamailio.org> wrote:
request_route:
if(is_method("ACK")){
if(!t_check_trans()){
xlog("L_INFO","AAAA: MATCHED TRANSACTION\n"); }
else {
xlog("L_INFO","BBBB: MATCHED TRANSACTION\n");
}
exit;
}
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080", "HTTP_REPLY");
}
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
append_branch("sip:1111@otherdomain.com:5060");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
pcap list
15 173.459633617 192.168.86.250 → 192.168.86.128 SIP/SDP 588 Request: INVITE
sip:123456@192.168.86.128:5060 |
16 173.460549905 192.168.86.128 → 192.168.86.250 SIP 344 Status: 100 Trying |
17 173.762804083 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
18 173.789493070 192.168.86.250 → 192.168.86.128 SIP 415 Request: ACK
sip:123456@192.168.86.128:5060 |
19 174.213115954 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
20 175.213132963 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
21 177.213136064 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
sipp trace dump
----------------------------------------------- 2024-12-23 19:10:01.820622
UDP message sent (546 bytes):
INVITE sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456 <sip:123456@192.168.86.128:5060>
Call-ID: 1-35646(a)192.168.86.250
CSeq: 1 INVITE
Contact: sip:sipp@192.168.86.250:5060
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: 139
v=0
o=user1 53655765 2353687637 IN IP4 192.168.86.250
s=-
c=IN IP4 192.168.86.250
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
----------------------------------------------- 2024-12-23 19:10:01.847444
UDP message received [302] bytes :
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456 <sip:123456@192.168.86.128:5060>
Call-ID: 1-35646(a)192.168.86.250
CSeq: 1 INVITE
Server: kamailio (5.8.4 (x86_64/linux))
Content-Length: 0
----------------------------------------------- 2024-12-23 19:10:02.169378
UDP message received [425] bytes :
SIP/2.0 302 Redirect
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456
<sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e0f89f75
Call-ID: 1-35646(a)192.168.86.250
CSeq: 1 INVITE
Contact: <sip:1111@otherdomain.com:5060>, <sip:1111@otherdomain.com:5060>
Server: kamailio (5.8.4 (x86_64/linux))
Content-Length: 0
----------------------------------------------- 2024-12-23 19:10:02.169921
UDP message sent (373 bytes):
ACK sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-3
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456
<sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e0f89f75
Call-ID: 1-35646(a)192.168.86.250
CSeq: 1 ACK
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
sipp br.xml
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<scenario name="Basic Sipstone UAC">
<!-- In client mode (sipp placing calls), the Call-ID MUST be -->
<!-- generated by sipp. To do so, use [call_id] keyword. -->
<send retrans="500">
<![CDATA[
INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp
<sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[media_ip_type] [media_ip]
t=0 0
m=audio [media_port] RTP/AVP 0
a=rtpmap:0 PCMU/8000
]]>
</send>
<recv response="100" optional="true"></recv>
<!-- By adding rrs="true" (Record Route Sets), the route sets
-->
<!-- are saved and used for following messages sent. Useful to test -->
<!-- against stateful SIP proxies/B2BUAs. -->
<recv response="302" rtd="true">
</recv>
<!-- Packet lost can be simulated in any send/recv message by -->
<!-- by adding the 'lost = "10"'. Value can be [1-100] percent.
-->
<send>
<![CDATA[
ACK sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp
<sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<!-- definition of the response time repartition table (unit is ms) -->
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
<!-- definition of the call length repartition table (unit is ms) -->
<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristes…
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
On 23 Dec 2024, at 6:44 PM, Ben Kaufman
<bkaufman(a)bcmone.com> wrote:
Does your 3xx message have a Contact, and does that Contact URI match the RURI in your
ACK?
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
From: Alexis Fidalgo via sr-users <sr-users(a)lists.kamailio.org>
Sent: Monday, December 23, 2024 3:19 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: Alexis Fidalgo <alzrck(a)gmail.com>
Subject: [SR-Users] help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Hello all, moving just a bit aside of the http and async_http.
After all the real useful and interesting thread on that topic what helped me, im facing
a problem i cant deal with and need a hint at least.
Scenario
INVITE -> Kamailio
on request_route
...
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080", "HTTP_REPLY");
}
…
Kamailio -> 100 - Trying
then
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
Kamailio -> 302 Redirect
ACK -> Kamailio
This last ACK, how can i read it and use it to terminate the transaction? because
Kamailio keeps transmitting the 302 message 3 more times until the transaction is finished
by a timer
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f4c3fcd35a0
(p:0x7f4c3fad85d0/n:0x7f4c3fad85d0)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f4c3fcd35a0
from timer.c:651
in request_route i have
if(is_method("ACK")){
if(!t_check_trans()){
t_release();
}
exit;
}
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
5:14 p.m.
Hi !
I have the exact same issue as Alexis. This is my SIP flow (which I believe
must be very similar, if not identical, to Alexis' ):
10.20.0.1:5060 10.20.20.1:5060
──────────┬───────── ──────────┬─────────
19:49:35.432327 │ INVITE (SDP) │
+0.007536 │ ──────────────────────────> │
19:49:35.439863 │ 100 trying -- your call is │
+0.006997 │ <────────────────────────── │
19:49:35.446860 │ 300 SL - Multiple Choices │
+0.001942 │ <────────────────────────── │
19:49:35.448802 │ ACK │
│ ──────────────────────────> │
│ │
INVITE sip:1@10.20.20.1:5060 SIP/2.0
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3147164-1-0
From: sipp <sip:sipp@10.20.0.1:5060>;tag=1
To: <sip:1@10.20.20.1:5060 Call-ID:
1-3147164(a)10.20.0.1
CSeq: 1 INVITE
Contact: sip:sipp@10.20.0.1:5060;transport=UDP
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
User-Agent: SIPp
Session-Expires: 3600;refresher=uas
Supported: replaces, timer
Content-Length: 129
v=0
o=user1 53655765 2353687637 IN IP4 10.20.0.1
s=-
c=IN IP4 10.20.0.1
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3147164-1-0
From: sipp <sip:sipp@10.20.0.1:5060>;tag=1
To: <sip:1@10.20.20.1:5060 Call-ID:
1-3147164(a)10.20.0.1
CSeq: 1 INVITE
Server: kamailio (5.8.2 (x86_64/linux))
Content-Length: 0
SIP/2.0 300 - Multiple Choices
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3147164-1-0
From: sipp <sip:sipp@10.20.0.1:5060>;tag=1
To: <sip:1@10.20.20.1:5060>;tag=d360f2f6fe5d9cd3912155e609771cc6-f406b8d3
Call-ID: 1-3147164(a)10.20.0.1
CSeq: 1 INVITE
Contact: <
sip:service@10.20.0.3:5060?P-Asserted-Identity=%2216001%22%3Csip%3A16001%3Bverstat%3DTN-Validation-Passed%4010.20.0.2%3A5060%3E
Server: kamailio (5.8.2 (x86_64/linux))
Content-Length: 0
(The above 300 - Multiple Choice message has a new Contact header, that
will be used by SBC to redirect the call somewhere else)
ACK sip:1@10.20.20.1:5060 SIP/2.0
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3147164-1-3
Max-Forwards: 70
From: <sip:sipp@10.20.0.1:5060>;tag=1
To: <sip:1@10.20.20.1:5060>;tag=d360f2f6fe5d9cd3912155e609771cc6-f406b8d3
Contact: <sip:sipp@10.20.0.1:5060
Call-ID: 1-3147164(a)10.20.0.1
CSeq: 1 ACK
User-Agent: SIPp
Content-Length: 0
From this point, Kamailio will re-send the 300 Multiple Choice message,
repeating until timeout...
Atenciosamente / Kind Regards / Cordialement / Un saludo,
*Sérgio Charrua*
On Mon, Dec 23, 2024 at 11:05 PM Ben Kaufman via sr-users <
sr-users(a)lists.kamailio.org> wrote:
> Does your 3xx message have a Contact, and does that Contact URI match the
> RURI in your ACK?
> *Kaufman*
> *Senior Voice Engineer *
> E: bkaufman(a)bcmone.com
> SIP.US Client Support: 800.566.9810 *|* SIPTRUNK Client Support:
> 800.250.6510 *|* Flowroute Client Support: 855.356.9768
> [image: img] <https://www.sip.us
> [image: img] <https://www.siptrunk.com
> *[image: img] <https://www.flowroute.com>*
> ------------------------------
> *From:* Alexis Fidalgo via sr-users <sr-users(a)lists.kamailio.org > *Sent:* Monday, December 23, 2024 3:19 PM
> *To:* Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org > *Cc:* Alexis Fidalgo
<alzrck(a)gmail.com > *Subject:*
[SR-Users] help on how to get ACK
> CAUTION: This email originated from outside
the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
> Hello all, moving just a bit aside of the http and async_http.
> After all the real useful and interesting
thread on that topic what helped
> me, im facing a problem i cant deal with and need a hint at least.
> Scenario
> INVITE -> Kamailio
> on request_route
> ...
> if(is_method("INVITE")){
> t_newtran();
> http_async_query("http://nuc:8080",
"HTTP_REPLY");
> }
> …
> Kamailio -> 100 - Trying
> then
> route[HTTP_REPLY] {
> if ($http_ok) {
> xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
> xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
> t_reply(302,"Redirect");
> } else {
> xlog("L_INFO", "route[HTTP_REPLY]: error
$http_err)\n");
> }
> }
> Kamailio -> 302 Redirect
> ACK -> Kamailio
> This last ACK, how can i read it and use it
to terminate the transaction?
> because Kamailio keeps transmitting the 302 message 3 more times until the
> transaction is finished by a timer
> 42(44) DEBUG: tm [t_reply.c:1723]:
t_retransmit_reply(): reply
> retransmitted. buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900:
> SIP/2.0 3
> 42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply
> retransmitted. buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900:
> SIP/2.0 3
> 42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply
> retransmitted. buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900:
> SIP/2.0 3
> 42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction:
> 0x7f4c3fcd35a0 (p:0x7f4c3fad85d0/n:0x7f4c3fad85d0)
> 42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction
> 0x7f4c3fcd35a0 from timer.c:651
> in request_route i have
> if(is_method("ACK")){
> if(!t_check_trans()){
> t_release();
> }
> exit;
> }
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions --
> sr-users(a)lists.kamailio.org
> To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions --
> sr-users(a)lists.kamailio.org
> To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
5:23 p.m.
This is the contact in your 300:
sip:service@10.20.0.3:5060?P-Asserted-Identity=%2216001%22%3Csip%3A16001%3Bverstat%3DTN-Validation-Passed%4010.20.0.2%3A5060%3E
This is the URI in your ACK:
sip:1@10.20.20.1:5060
It looks like you're using SIPp which is a pain this way. Rather than coding the URI
into the ACK of your SIPp scenario, add rss="true" to the recv line for your
300, and then use [next_url] in the template for your ACK mesasge.
Here is an example:
https://github.com/whosgonna/kamailio_http_async/blob/reply300/sipp/uac_exp…
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us/>
[img]<https://www.siptrunk.com/>
[img]<https://www.flowroute.com/>
________________________________
From: Sergio Charrua <sergio.charrua(a)voip.pt>
Sent: Monday, December 23, 2024 4:14 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: Alexis Fidalgo <alzrck(a)gmail.com>om>; Ben Kaufman <bkaufman(a)bcmone.com>
Subject: Re: [SR-Users] Re: help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Hi !
I have the exact same issue as Alexis. This is my SIP flow (which I believe must be very
similar, if not identical, to Alexis' ):
10.20.0.1:5060<http://10.20.0.1:5060/>
10.20.20.1:5060<http://10.20.20.1:5060/>
──────────┬───────── ──────────┬─────────
19:49:35.432327 │ INVITE (SDP) │
+0.007536 │ ──────────────────────────> │
19:49:35.439863 │ 100 trying -- your call is │
+0.006997 │ <────────────────────────── │
19:49:35.446860 │ 300 SL - Multiple Choices │
+0.001942 │ <────────────────────────── │
19:49:35.448802 │ ACK │
│ ──────────────────────────> │
│ │
INVITE sip:1@10.20.20.1:5060<http://sip:1@10.20.20.1:5060/> SIP/2.0
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3147164-1-0
From: sipp <sip:sipp@10.20.0.1:5060<http://sip:sipp@10.20.0.1:5060/>>;tag=1
To: <sip:1@10.20.20.1:5060<http://sip:1@10.20.20.1:5060/>>
Call-ID: 1-3147164@10.20.0.1<mailto:1-3147164@10.20.0.1>
CSeq: 1 INVITE
Contact: sip:sipp@10.20.0.1:5060;transport=UDP>
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
User-Agent: SIPp
Session-Expires: 3600;refresher=uas
Supported: replaces, timer
Content-Length: 129
v=0
o=user1 53655765 2353687637 IN IP4 10.20.0.1
s=-
c=IN IP4 10.20.0.1
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3147164-1-0
From: sipp <sip:sipp@10.20.0.1:5060<http://sip:sipp@10.20.0.1:5060/>>;tag=1
To: <sip:1@10.20.20.1:5060<http://sip:1@10.20.20.1:5060/>>
Call-ID: 1-3147164@10.20.0.1<mailto:1-3147164@10.20.0.1>
CSeq: 1 INVITE
Server: kamailio (5.8.2 (x86_64/linux))
Content-Length: 0
SIP/2.0 300 - Multiple Choices
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3147164-1-0
From: sipp <sip:sipp@10.20.0.1:5060<http://sip:sipp@10.20.0.1:5060/>>;tag=1
To:
<sip:1@10.20.20.1:5060<http://sip:1@10.20.20.1:5060/>>;tag=d360f2f6fe5d9cd3912155e609771cc6-f406b8d3
Call-ID: 1-3147164@10.20.0.1<mailto:1-3147164@10.20.0.1>
CSeq: 1 INVITE
Contact:
<sip:service@10.20.0.3:5060?P-Asserted-Identity=%2216001%22%3Csip%3A16001%3Bverstat%3DTN-Validation-Passed%4010.20.0.2%3A5060%3E<http://sip:service@10.20.0.3:5060/?P-Asserted-Identity=%2216001%22%3Csip%3A16001%3Bverstat%3DTN-Validation-Passed%4010.20.0.2%3A5060%3E>>
Server: kamailio (5.8.2 (x86_64/linux))
Content-Length: 0
(The above 300 - Multiple Choice message has a new Contact header, that will be used by
SBC to redirect the call somewhere else)
ACK sip:1@10.20.20.1:5060<http://sip:1@10.20.20.1:5060/> SIP/2.0
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3147164-1-3
Max-Forwards: 70
From: <sip:sipp@10.20.0.1:5060<http://sip:sipp@10.20.0.1:5060/>>;tag=1
To:
<sip:1@10.20.20.1:5060<http://sip:1@10.20.20.1:5060/>>;tag=d360f2f6fe5d9cd3912155e609771cc6-f406b8d3
Contact: <sip:sipp@10.20.0.1:5060<http://sip:sipp@10.20.0.1:5060/>>
Call-ID: 1-3147164@10.20.0.1<mailto:1-3147164@10.20.0.1>
CSeq: 1 ACK
User-Agent: SIPp
Content-Length: 0
From this point, Kamailio will re-send the 300 Multiple Choice message, repeating until
timeout...
Atenciosamente / Kind Regards / Cordialement / Un saludo,
Sérgio Charrua
On Mon, Dec 23, 2024 at 11:05 PM Ben Kaufman via sr-users
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> wrote:
Does your 3xx message have a Contact, and does that Contact URI match the RURI in your
ACK?
Kaufman
Senior Voice Engineer
E: bkaufman@bcmone.com<mailto:bkaufman@bcmone.com>
SIP.US<http://sip.us/> Client Support: 800.566.9810 | SIPTRUNK Client Support:
800.250.6510 | Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us/>
[img]<https://www.siptrunk.com/>
[img]<https://www.flowroute.com/>
________________________________
From: Alexis Fidalgo via sr-users
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Sent: Monday, December 23, 2024 3:19 PM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Cc: Alexis Fidalgo <alzrck@gmail.com<mailto:alzrck@gmail.com>>
Subject: [SR-Users] help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Hello all, moving just a bit aside of the http and async_http.
After all the real useful and interesting thread on that topic what helped me, im facing a
problem i cant deal with and need a hint at least.
Scenario
INVITE -> Kamailio
on request_route
...
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080", "HTTP_REPLY");
}
…
Kamailio -> 100 - Trying
then
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
Kamailio -> 302 Redirect
ACK -> Kamailio
This last ACK, how can i read it and use it to terminate the transaction? because Kamailio
keeps transmitting the 302 message 3 more times until the transaction is finished by a
timer
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f4c3fcd35a0
(p:0x7f4c3fad85d0/n:0x7f4c3fad85d0)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f4c3fcd35a0
from timer.c:651
in request_route i have
if(is_method("ACK")){
if(!t_check_trans()){
t_release();
}
exit;
}
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
1:34 p.m.
Yes, it looks like for some reason all of my messages got queued and flowed in late
yesterday (looks like something to do with the use of reply all and having additional
recipients?), so despite realizing the answer after sending, the messages hit hours later.
🙁
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us/>
[img]<https://www.siptrunk.com/>
[img]<https://www.flowroute.com/>
________________________________
From: Alex Balashov via sr-users <sr-users(a)lists.kamailio.org>
Sent: Tuesday, December 24, 2024 11:02 AM
To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org>
Cc: Alex Balashov <abalashov(a)evaristesys.com>
Subject: [SR-Users] Re: help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Ben,
From 17.1.1.3:
"The ACK request constructed by the client transaction MUST contain
values for the Call-ID, From, and Request-URI that are equal to the
values of those header fields in the request passed to the transport
by the client transaction (call this the "original request"). The To
header field in the ACK MUST equal the To header field in the
response being acknowledged, and therefore will usually differ from
the To header field in the original request by the addition of the
tag parameter. The ACK MUST contain a single Via header field, and
this MUST be equal to the top Via header field of the original
request. The CSeq header field in the ACK MUST contain the same
value for the sequence number as was present in the original request,
but the method parameter MUST be equal to "ACK"."
I think you are mistaken here. The Contact in the 300 should not be used.
—
Sent from mobile, apologies for brevity and errors.
On Dec 24, 2024, at 9:51 AM, Ben Kaufman via sr-users <sr-users(a)lists.kamailio.org>
wrote:
This is the contact in your 300:
sip:service@10.20.0.3:5060?P-Asserted-Identity=%2216001%22%3Csip%3A16001%3Bverstat%3DTN-Validation-Passed%4010.20.0.2%3A5060%3E
This is the URI in your ACK:
sip:1@10.20.20.1:5060
It looks like you're using SIPp which is a pain this way. Rather than coding the URI
into the ACK of your SIPp scenario, add rss="true" to the recv line for your
300, and then use [next_url] in the template for your ACK mesasge.
Here is an example:
https://github.com/whosgonna/kamailio_http_async/blob/reply300/sipp/uac_exp…
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us/>
[img]<https://www.siptrunk.com/>
[img]<https://www.flowroute.com/>
________________________________
From: Sergio Charrua <sergio.charrua(a)voip.pt>
Sent: Monday, December 23, 2024 4:14 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: Alexis Fidalgo <alzrck(a)gmail.com>om>; Ben Kaufman <bkaufman(a)bcmone.com>
Subject: Re: [SR-Users] Re: help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Hi !
I have the exact same issue as Alexis. This is my SIP flow (which I believe must be very
similar, if not identical, to Alexis' ):
10.20.0.1:5060<http://10.20.0.1:5060/>
10.20.20.1:5060<http://10.20.20.1:5060/>
──────────┬───────── ──────────┬─────────
19:49:35.432327 │ INVITE (SDP) │
+0.007536 │ ──────────────────────────> │
19:49:35.439863 │ 100 trying -- your call is │
+0.006997 │ <────────────────────────── │
19:49:35.446860 │ 300 SL - Multiple Choices │
+0.001942 │ <────────────────────────── │
19:49:35.448802 │ ACK │
│ ──────────────────────────> │
│ │
INVITE sip:1@10.20.20.1:5060<http://sip:1@10.20.20.1:5060/> SIP/2.0
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3147164-1-0
From: sipp <sip:sipp@10.20.0.1:5060<http://sip:sipp@10.20.0.1:5060/>>;tag=1
To: <sip:1@10.20.20.1:5060<http://sip:1@10.20.20.1:5060/>>
Call-ID: 1-3147164@10.20.0.1<mailto:1-3147164@10.20.0.1>
CSeq: 1 INVITE
Contact: sip:sipp@10.20.0.1:5060;transport=UDP>
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
User-Agent: SIPp
Session-Expires: 3600;refresher=uas
Supported: replaces, timer
Content-Length: 129
v=0
o=user1 53655765 2353687637 IN IP4 10.20.0.1
s=-
c=IN IP4 10.20.0.1
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3147164-1-0
From: sipp <sip:sipp@10.20.0.1:5060<http://sip:sipp@10.20.0.1:5060/>>;tag=1
To: <sip:1@10.20.20.1:5060<http://sip:1@10.20.20.1:5060/>>
Call-ID: 1-3147164@10.20.0.1<mailto:1-3147164@10.20.0.1>
CSeq: 1 INVITE
Server: kamailio (5.8.2 (x86_64/linux))
Content-Length: 0
SIP/2.0 300 - Multiple Choices
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3147164-1-0
From: sipp <sip:sipp@10.20.0.1:5060<http://sip:sipp@10.20.0.1:5060/>>;tag=1
To:
<sip:1@10.20.20.1:5060<http://sip:1@10.20.20.1:5060/>>;tag=d360f2f6fe5d9cd3912155e609771cc6-f406b8d3
Call-ID: 1-3147164@10.20.0.1<mailto:1-3147164@10.20.0.1>
CSeq: 1 INVITE
Contact:
<sip:service@10.20.0.3:5060?P-Asserted-Identity=%2216001%22%3Csip%3A16001%3Bverstat%3DTN-Validation-Passed%4010.20.0.2%3A5060%3E<http://sip:service@10.20.0.3:5060/?P-Asserted-Identity=%2216001%22%3Csip%3A16001%3Bverstat%3DTN-Validation-Passed%4010.20.0.2%3A5060%3E>>
Server: kamailio (5.8.2 (x86_64/linux))
Content-Length: 0
(The above 300 - Multiple Choice message has a new Contact header, that will be used by
SBC to redirect the call somewhere else)
ACK sip:1@10.20.20.1:5060<http://sip:1@10.20.20.1:5060/> SIP/2.0
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3147164-1-3
Max-Forwards: 70
From: <sip:sipp@10.20.0.1:5060<http://sip:sipp@10.20.0.1:5060/>>;tag=1
To:
<sip:1@10.20.20.1:5060<http://sip:1@10.20.20.1:5060/>>;tag=d360f2f6fe5d9cd3912155e609771cc6-f406b8d3
Contact: <sip:sipp@10.20.0.1:5060<http://sip:sipp@10.20.0.1:5060/>>
Call-ID: 1-3147164@10.20.0.1<mailto:1-3147164@10.20.0.1>
CSeq: 1 ACK
User-Agent: SIPp
Content-Length: 0
From this point, Kamailio will re-send the 300 Multiple Choice message, repeating until
timeout...
Atenciosamente / Kind Regards / Cordialement / Un saludo,
Sérgio Charrua
On Mon, Dec 23, 2024 at 11:05 PM Ben Kaufman via sr-users
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> wrote:
Does your 3xx message have a Contact, and does that Contact URI match the RURI in your
ACK?
Kaufman
Senior Voice Engineer
E: bkaufman@bcmone.com<mailto:bkaufman@bcmone.com>
SIP.US<http://sip.us/> Client Support: 800.566.9810 | SIPTRUNK Client Support:
800.250.6510 | Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us/>
[img]<https://www.siptrunk.com/>
[img]<https://www.flowroute.com/>
________________________________
From: Alexis Fidalgo via sr-users
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Sent: Monday, December 23, 2024 3:19 PM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Cc: Alexis Fidalgo <alzrck@gmail.com<mailto:alzrck@gmail.com>>
Subject: [SR-Users] help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Hello all, moving just a bit aside of the http and async_http.
After all the real useful and interesting thread on that topic what helped me, im facing a
problem i cant deal with and need a hint at least.
Scenario
INVITE -> Kamailio
on request_route
...
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080", "HTTP_REPLY");
}
…
Kamailio -> 100 - Trying
then
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
Kamailio -> 302 Redirect
ACK -> Kamailio
This last ACK, how can i read it and use it to terminate the transaction? because Kamailio
keeps transmitting the 302 message 3 more times until the transaction is finished by a
timer
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f4c3fcd35a0
(p:0x7f4c3fad85d0/n:0x7f4c3fad85d0)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f4c3fcd35a0
from timer.c:651
in request_route i have
if(is_method("ACK")){
if(!t_check_trans()){
t_release();
}
exit;
}
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
23 Dec
23 Dec
4:49 p.m.
Look very carefully at how negative ACKs are handled here:
https://github.com/kamailio/kamailio/blob/master/etc/kamailio.cfg#L716
-- Alex
On Dec 23, 2024, at 4:19 pm, Alexis Fidalgo via
sr-users <sr-users(a)lists.kamailio.org> wrote:
Hello all, moving just a bit aside of the http and async_http.
After all the real useful and interesting thread on that topic what helped me, im facing
a problem i cant deal with and need a hint at least.
Scenario
INVITE -> Kamailio
on request_route
...
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080", "HTTP_REPLY");
}
…
Kamailio -> 100 - Trying
then
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
Kamailio -> 302 Redirect
ACK -> Kamailio
This last ACK, how can i read it and use it to terminate the transaction? because
Kamailio keeps transmitting the 302 message 3 more times until the transaction is finished
by a timer
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f4c3fcd35a0
(p:0x7f4c3fad85d0/n:0x7f4c3fad85d0)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f4c3fcd35a0
from timer.c:651
in request_route i have
if(is_method("ACK")){
if(!t_check_trans()){
t_release();
}
exit;
}
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
5:16 p.m.
Yes, i’ve been reading it when you mentioned the loose_route and has_totag() in a previous
email.
if(is_method("ACK")){
if(!t_check_trans()){
xlog("L_INFO","AAAA: MATCHED TRANSACTION\n");
} else {
xlog("L_INFO","BBBB: MATCHED TRANSACTION\n");
}
exit;
}
(moving the exit; inside the else has same effect on my test)
On 23 Dec 2024, at 6:49 PM, Alex Balashov via sr-users
<sr-users(a)lists.kamailio.org> wrote:
Look very carefully at how negative ACKs are handled here:
https://github.com/kamailio/kamailio/blob/master/etc/kamailio.cfg#L716
-- Alex
On Dec 23, 2024, at 4:19 pm, Alexis Fidalgo via
sr-users <sr-users(a)lists.kamailio.org> wrote:
Hello all, moving just a bit aside of the http and async_http.
After all the real useful and interesting thread on that topic what helped me, im facing
a problem i cant deal with and need a hint at least.
Scenario
INVITE -> Kamailio
on request_route
...
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080", "HTTP_REPLY");
}
…
Kamailio -> 100 - Trying
then
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
Kamailio -> 302 Redirect
ACK -> Kamailio
This last ACK, how can i read it and use it to terminate the transaction? because
Kamailio keeps transmitting the 302 message 3 more times until the transaction is finished
by a timer
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f4c3fcd35a0
(p:0x7f4c3fad85d0/n:0x7f4c3fad85d0)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f4c3fcd35a0
from timer.c:651
in request_route i have
if(is_method("ACK")){
if(!t_check_trans()){
t_release();
}
exit;
}
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
5:28 p.m.
Which log line do you get? Also note that both of your log lines say "Matched
transaction", but the condition is negated (it starts with an exclamation mark).
Also refer to the documentation for the function to see what happens when the ACK for a
negative reply is matched.
https://kamailio.org/docs/modules/5.8.x/modules/tm#tm.f.t_check_trans
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us/>
[img]<https://www.siptrunk.com/>
[img]<https://www.flowroute.com/>
________________________________
From: Alexis Fidalgo via sr-users <sr-users(a)lists.kamailio.org>
Sent: Monday, December 23, 2024 4:16 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: Alexis Fidalgo <alzrck(a)gmail.com>
Subject: [SR-Users] Re: help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Yes, i’ve been reading it when you mentioned the loose_route and has_totag() in a previous
email.
if(is_method("ACK")){
if(!t_check_trans()){
xlog("L_INFO","AAAA: MATCHED TRANSACTION\n");
} else {
xlog("L_INFO","BBBB: MATCHED TRANSACTION\n");
}
exit;
}
(moving the exit; inside the else has same effect on my test)
On 23 Dec 2024, at 6:49 PM, Alex Balashov via sr-users
<sr-users(a)lists.kamailio.org> wrote:
Look very carefully at how negative ACKs are handled here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…
-- Alex
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
On Dec 23, 2024, at 4:19 pm, Alexis Fidalgo via
sr-users <sr-users(a)lists.kamailio.org> wrote:
Hello all, moving just a bit aside of the http and async_http.
After all the real useful and interesting thread on that topic what helped me, im facing
a problem i cant deal with and need a hint at least.
Scenario
INVITE -> Kamailio
on request_route
...
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080", "HTTP_REPLY");
}
…
Kamailio -> 100 - Trying
then
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
Kamailio -> 302 Redirect
ACK -> Kamailio
This last ACK, how can i read it and use it to terminate the transaction? because
Kamailio keeps transmitting the 302 message 3 more times until the transaction is finished
by a timer
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f4c3fcd35a0
(p:0x7f4c3fad85d0/n:0x7f4c3fad85d0)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f4c3fcd35a0
from timer.c:651
in request_route i have
if(is_method("ACK")){
if(!t_check_trans()){
t_release();
}
exit;
}
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristes…
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
5:49 p.m.
sorry about the log (changed now). my question is, if script execution is finished, the
associated transaction (red part) isnt ended too?
10(12) DEBUG: <core> [core/udp_server.c:707]: udp_rcv_loop(): received on udp
socket: (106/100/412) [[ACK sip:1111@otherdomain.com:5060 SIP/2.0 0D 0A Via: SIP/2.0/UDP
192.168.86.250:5060;branch=z9hG4bK-39430]]
10(12) DEBUG: <core> [core/parser/parse_fline.c:247]: parse_first_line(): first line
type 1 (request) flags 1
10(12) DEBUG: <core> [core/parser/msg_parser.c:722]: parse_msg(): SIP Request:
10(12) DEBUG: <core> [core/parser/msg_parser.c:723]: parse_msg(): method:
<ACK>
10(12) DEBUG: <core> [core/parser/msg_parser.c:725]: parse_msg(): uri:
<sip:1111@otherdomain.com:5060>
10(12) DEBUG: <core> [core/parser/msg_parser.c:727]: parse_msg(): version:
<SIP/2.0>
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [Via] type 1
10(12) DEBUG: <core> [core/parser/parse_via.c:1309]: parse_via_param(): Found param
type 232, <branch> = <z9hG4bK-39430-1-3>; state=16
10(12) DEBUG: <core> [core/parser/parse_via.c:2663]: parse_via(): end of header
reached, state=5
10(12) DEBUG: <core> [core/parser/msg_parser.c:592]: parse_headers(): Via found,
flags=2
10(12) DEBUG: <core> [core/parser/msg_parser.c:594]: parse_headers(): this is the
first via
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [From] type 4
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [To] type 3
10(12) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add
param: tag=a6a1c5f60faecf035a1ae5b6e96e979a-e94a2550
10(12) DEBUG: <core> [core/parser/parse_addr_spec.c:904]: parse_addr_spec(): end of
header reached, state=29
10(12) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): <To>
[87]; uri=[sip:123456@192.168.86.128:5060]
10(12) DEBUG: <core> [core/parser/msg_parser.c:174]: get_hdr_field(): to body
(39)[123456 <sip:123456@192.168.86.128:5060>], to tag
(41)[a6a1c5f60faecf035a1ae5b6e96e979a-e94a2550]
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [Call-ID] type 6
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [CSeq] type 5
10(12) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq
<CSeq>: <1> <ACK>
10(12) DEBUG: <core> [core/receive.c:392]: receive_msg(): --- received sip message -
request - call-id: [1-39430(a)192.168.86.250] - cseq: [1 ACK]
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [Contact] type 7
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [Max-Forwards] type 8
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [Subject] type 27
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [Content-Length] type 12
10(12) DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field():
content_length=0
10(12) DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of
header
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/receive.c:263]:
ksr_evrt_pre_routing(): event route core:pre-routing not defined
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/receive.c:474]:
receive_msg(): preparing to run routing scripts...
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} sl [sl_funcs.c:455]: sl_filter_ACK(): too
late to be a local ACK!
10(12) exec: {1 1 ACK 1-39430(a)192.168.86.250} *** cfgtrace:dbg_cfg_trace():
request_route=[DEFAULT_ROUTE] c=[/etc/kamailio/kamailio.cfg] l=537 a=5 n=route
10(12) exec: {1 1 ACK 1-39430(a)192.168.86.250} *** cfgtrace:dbg_cfg_trace():
request_route=[AF_SL] c=[/etc/kamailio/kamailio.cfg] l=625 a=16 n=if
10(12) exec: {1 1 ACK 1-39430(a)192.168.86.250} *** cfgtrace:dbg_cfg_trace():
request_route=[AF_SL] c=[/etc/kamailio/kamailio.cfg] l=617 a=25 n=is_method
10(12) exec: {1 1 ACK 1-39430(a)192.168.86.250} *** cfgtrace:dbg_cfg_trace():
request_route=[AF_SL] c=[/etc/kamailio/kamailio.cfg] l=623 a=16 n=if
10(12) exec: {1 1 ACK 1-39430(a)192.168.86.250} *** cfgtrace:dbg_cfg_trace():
request_route=[AF_SL] c=[/etc/kamailio/kamailio.cfg] l=618 a=24 n=t_check_trans
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} tm [t_lookup.c:1565]: t_check_msg(): msg
(0x7f05de39d4d0) id=1/12 global id=0/0 T start=0xffffffffffffffff
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} tm [t_lookup.c:781]: t_lookup_request():
start searching: hash=48094, isACK=1
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} tm [t_lookup.c:499]: matching_3261():
RFC3261 transaction matching failed - via branch [z9hG4bK-39430-1-3]
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} tm [t_lookup.c:981]: t_lookup_request(): no
transaction found
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} tm [t_lookup.c:1637]: t_check_msg(): msg
(0x7f05de39d4d0) id=1/12 global id=1/12 T end=(nil)
10(12) exec: {1 1 ACK 1-39430(a)192.168.86.250} *** cfgtrace:dbg_cfg_trace():
request_route=[AF_SL] c=[/etc/kamailio/kamailio.cfg] l=619 a=26 n=xlog
10(12) INFO: {1 1 ACK 1-39430(a)192.168.86.250} <script>: >>>>>>>
NOT MATCHED
10(12) exec: {1 1 ACK 1-39430(a)192.168.86.250} *** cfgtrace:dbg_cfg_trace():
request_route=[AF_SL] c=[/etc/kamailio/kamailio.cfg] l=620 a=2 n=exit
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/receive.c:531]:
receive_msg(): request-route executed in: 183 usec
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/receive.c:635]:
receive_msg(): cleaning up
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f05de0f5680: SIP/2.0 3..., shmem=0x7f05d8e56900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f05de0f5680: SIP/2.0 3..., shmem=0x7f05d8e56900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f05de0f5680: SIP/2.0 3..., shmem=0x7f05d8e56900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f05d8e425a0
(p:0x7f05d8d75870/n:0x7f05d8d75870)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f05d8e425a0
from timer.c:651
request_route
if(is_method("ACK")){
if(!t_check_trans()){
xlog("L_INFO",">>>>>>> NOT MATCHED\n");
exit;
} else {
xlog("L_INFO",">>>>>>> MATCHED\n");
}
}
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080", "HTTP_REPLY");
}
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
remove_hf("Contact");
append_branch("sip:1111@otherdomain.com:5060");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
sipp xml
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<scenario name="Basic Sipstone UAC">
<!-- In client mode (sipp placing calls), the Call-ID MUST be -->
<!-- generated by sipp. To do so, use [call_id] keyword. -->
<send retrans="500">
<![CDATA[
INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[media_ip_type] [media_ip]
t=0 0
m=audio [media_port] RTP/AVP 0
a=rtpmap:0 PCMU/8000
]]>
</send>
<recv response="100" optional="true"></recv>
<!-- By adding rrs="true" (Record Route Sets), the route sets
-->
<!-- are saved and used for following messages sent. Useful to test -->
<!-- against stateful SIP proxies/B2BUAs. -->
<recv response="302" rrs="true" rtd="true">
</recv>
<!-- Packet lost can be simulated in any send/recv message by -->
<!-- by adding the 'lost = "10"'. Value can be [1-100] percent.
-->
<send>
<![CDATA[
ACK [next_url] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
Contact: [next_url]
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<!-- definition of the response time repartition table (unit is ms) -->
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
<!-- definition of the call length repartition table (unit is ms) -->
<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
pcap list
22 603.965446646 192.168.86.250 → 192.168.86.128 SIP/SDP 588 Request: INVITE
sip:123456@192.168.86.128:5060 |
23 603.966309968 192.168.86.128 → 192.168.86.250 SIP 344 Status: 100 Trying |
24 604.271008247 192.168.86.128 → 192.168.86.250 SIP 434 Status: 302 Redirect |
25 604.389939182 192.168.86.250 → 192.168.86.128 SIP 454 Request: ACK
sip:1111@otherdomain.com:5060 |
26 604.760536760 192.168.86.128 → 192.168.86.250 SIP 434 Status: 302 Redirect |
27 605.760472746 192.168.86.128 → 192.168.86.250 SIP 434 Status: 302 Redirect |
28 607.760461967 192.168.86.128 → 192.168.86.250 SIP 434 Status: 302 Redirect |
sipp trace output
----------------------------------------------- 2024-12-23 19:45:32.343458
UDP message sent (546 bytes):
INVITE sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-39430-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=39430SIPpTag001
To: 123456 <sip:123456@192.168.86.128:5060>
Call-ID: 1-39430(a)192.168.86.250
CSeq: 1 INVITE
Contact: sip:sipp@192.168.86.250:5060
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: 139
v=0
o=user1 53655765 2353687637 IN IP4 192.168.86.250
s=-
c=IN IP4 192.168.86.250
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
----------------------------------------------- 2024-12-23 19:45:32.522315
UDP message received [302] bytes :
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-39430-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=39430SIPpTag001
To: 123456 <sip:123456@192.168.86.128:5060>
Call-ID: 1-39430(a)192.168.86.250
CSeq: 1 INVITE
Server: kamailio (5.8.4 (x86_64/linux))
Content-Length: 0
----------------------------------------------- 2024-12-23 19:45:32.934151
UDP message received [392] bytes :
SIP/2.0 302 Redirect
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-39430-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=39430SIPpTag001
To: 123456
<sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e94a2550
Call-ID: 1-39430(a)192.168.86.250
CSeq: 1 INVITE
Contact: <sip:1111@otherdomain.com:5060>
Server: kamailio (5.8.4 (x86_64/linux))
Content-Length: 0
----------------------------------------------- 2024-12-23 19:45:32.935234
UDP message sent (412 bytes):
ACK sip:1111@otherdomain.com:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-39430-1-3
From: sipp <sip:sipp@192.168.86.250:5060>;tag=39430SIPpTag001
To: 123456
<sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e94a2550
Call-ID: 1-39430(a)192.168.86.250
CSeq: 1 ACK
Contact: sip:1111@otherdomain.com:5060
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
On 23 Dec 2024, at 7:28 PM, Ben Kaufman
<bkaufman(a)bcmone.com> wrote:
Which log line do you get? Also note that both of your log lines say "Matched
transaction", but the condition is negated (it starts with an exclamation mark).
Also refer to the documentation for the function to see what happens when the ACK for a
negative reply is matched.
https://kamailio.org/docs/modules/5.8.x/modules/tm#tm.f.t_check_trans
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com <mailto:bkaufman@bcmone.com>
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
<https://www.sip.us/>
<https://www.siptrunk.com/>
<https://www.flowroute.com/>
From: Alexis Fidalgo via sr-users <sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>>
Sent: Monday, December 23, 2024 4:16 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>>
Cc: Alexis Fidalgo <alzrck(a)gmail.com <mailto:alzrck@gmail.com>>
Subject: [SR-Users] Re: help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Yes, i’ve been reading it when you mentioned the loose_route and has_totag() in a
previous email.
if(is_method("ACK")){
if(!t_check_trans()){
xlog("L_INFO","AAAA: MATCHED TRANSACTION\n");
} else {
xlog("L_INFO","BBBB: MATCHED TRANSACTION\n");
}
exit;
}
(moving the exit; inside the else has same effect on my test)
On 23 Dec 2024, at 6:49 PM, Alex Balashov via
sr-users <sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>>
wrote:
Look very carefully at how negative ACKs are handled here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…
<https://github.com/kamailio/kamailio/blob/master/etc/kamailio.cfg#L716>
-- Alex
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
On Dec 23, 2024, at 4:19 pm, Alexis Fidalgo via
sr-users <sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>>
wrote:
Hello all, moving just a bit aside of the http and async_http.
After all the real useful and interesting thread on that topic what helped me, im facing
a problem i cant deal with and need a hint at least.
Scenario
INVITE -> Kamailio
on request_route
...
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080 <http://nuc:8080/>",
"HTTP_REPLY");
}
…
Kamailio -> 100 - Trying
then
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
Kamailio -> 302 Redirect
ACK -> Kamailio
This last ACK, how can i read it and use it to terminate the transaction? because
Kamailio keeps transmitting the 302 message 3 more times until the transaction is finished
by a timer
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f4c3fcd35a0
(p:0x7f4c3fad85d0/n:0x7f4c3fad85d0)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f4c3fcd35a0
from timer.c:651
in request_route i have
if(is_method("ACK")){
if(!t_check_trans()){
t_release();
}
exit;
}
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristes…
<https://evaristesys.com/>
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
5:52 p.m.
IF the transaction was finished, then yes, but:
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} tm [t_lookup.c:781]: t_lookup_request():
start searching: hash=48094, isACK=1
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} tm [t_lookup.c:499]: matching_3261():
RFC3261 transaction matching failed - via branch [z9hG4bK-39430-1-3]
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} tm [t_lookup.c:981]: t_lookup_request(): no
transaction found
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us/>
[img]<https://www.siptrunk.com/>
[img]<https://www.flowroute.com/>
________________________________
From: Alexis Fidalgo <alzrck(a)gmail.com>
Sent: Monday, December 23, 2024 4:49 PM
To: Ben Kaufman <bkaufman(a)bcmone.com>
Cc: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
sorry about the log (changed now). my question is, if script execution is finished, the
associated transaction (red part) isnt ended too?
10(12) DEBUG: <core> [core/udp_server.c:707]: udp_rcv_loop(): received on udp
socket: (106/100/412) [[ACK sip:1111@otherdomain.com:5060 SIP/2.0 0D 0A Via: SIP/2.0/UDP
192.168.86.250:5060;branch=z9hG4bK-39430]]
10(12) DEBUG: <core> [core/parser/parse_fline.c:247]: parse_first_line(): first line
type 1 (request) flags 1
10(12) DEBUG: <core> [core/parser/msg_parser.c:722]: parse_msg(): SIP Request:
10(12) DEBUG: <core> [core/parser/msg_parser.c:723]: parse_msg(): method:
<ACK>
10(12) DEBUG: <core> [core/parser/msg_parser.c:725]: parse_msg(): uri:
<sip:1111@otherdomain.com:5060>
10(12) DEBUG: <core> [core/parser/msg_parser.c:727]: parse_msg(): version:
<SIP/2.0>
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [Via] type 1
10(12) DEBUG: <core> [core/parser/parse_via.c:1309]: parse_via_param(): Found param
type 232, <branch> = <z9hG4bK-39430-1-3>; state=16
10(12) DEBUG: <core> [core/parser/parse_via.c:2663]: parse_via(): end of header
reached, state=5
10(12) DEBUG: <core> [core/parser/msg_parser.c:592]: parse_headers(): Via found,
flags=2
10(12) DEBUG: <core> [core/parser/msg_parser.c:594]: parse_headers(): this is the
first via
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [From] type 4
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [To] type 3
10(12) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add
param: tag=a6a1c5f60faecf035a1ae5b6e96e979a-e94a2550
10(12) DEBUG: <core> [core/parser/parse_addr_spec.c:904]: parse_addr_spec(): end of
header reached, state=29
10(12) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): <To>
[87]; uri=[sip:123456@192.168.86.128:5060]
10(12) DEBUG: <core> [core/parser/msg_parser.c:174]: get_hdr_field(): to body
(39)[123456 <sip:123456@192.168.86.128:5060>], to tag
(41)[a6a1c5f60faecf035a1ae5b6e96e979a-e94a2550]
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [Call-ID] type 6
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [CSeq] type 5
10(12) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq
<CSeq>: <1> <ACK>
10(12) DEBUG: <core> [core/receive.c:392]: receive_msg(): --- received sip message -
request - call-id: [1-39430(a)192.168.86.250] - cseq: [1 ACK]
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [Contact] type 7
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [Max-Forwards] type 8
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [Subject] type 27
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [Content-Length] type 12
10(12) DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field():
content_length=0
10(12) DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of
header
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/receive.c:263]:
ksr_evrt_pre_routing(): event route core:pre-routing not defined
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/receive.c:474]:
receive_msg(): preparing to run routing scripts...
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} sl [sl_funcs.c:455]: sl_filter_ACK(): too
late to be a local ACK!
10(12) exec: {1 1 ACK 1-39430(a)192.168.86.250} *** cfgtrace:dbg_cfg_trace():
request_route=[DEFAULT_ROUTE] c=[/etc/kamailio/kamailio.cfg] l=537 a=5 n=route
10(12) exec: {1 1 ACK 1-39430(a)192.168.86.250} *** cfgtrace:dbg_cfg_trace():
request_route=[AF_SL] c=[/etc/kamailio/kamailio.cfg] l=625 a=16 n=if
10(12) exec: {1 1 ACK 1-39430(a)192.168.86.250} *** cfgtrace:dbg_cfg_trace():
request_route=[AF_SL] c=[/etc/kamailio/kamailio.cfg] l=617 a=25 n=is_method
10(12) exec: {1 1 ACK 1-39430(a)192.168.86.250} *** cfgtrace:dbg_cfg_trace():
request_route=[AF_SL] c=[/etc/kamailio/kamailio.cfg] l=623 a=16 n=if
10(12) exec: {1 1 ACK 1-39430(a)192.168.86.250} *** cfgtrace:dbg_cfg_trace():
request_route=[AF_SL] c=[/etc/kamailio/kamailio.cfg] l=618 a=24 n=t_check_trans
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} tm [t_lookup.c:1565]: t_check_msg(): msg
(0x7f05de39d4d0) id=1/12 global id=0/0 T start=0xffffffffffffffff
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} tm [t_lookup.c:781]: t_lookup_request():
start searching: hash=48094, isACK=1
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} tm [t_lookup.c:499]: matching_3261():
RFC3261 transaction matching failed - via branch [z9hG4bK-39430-1-3]
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} tm [t_lookup.c:981]: t_lookup_request(): no
transaction found
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} tm [t_lookup.c:1637]: t_check_msg(): msg
(0x7f05de39d4d0) id=1/12 global id=1/12 T end=(nil)
10(12) exec: {1 1 ACK 1-39430(a)192.168.86.250} *** cfgtrace:dbg_cfg_trace():
request_route=[AF_SL] c=[/etc/kamailio/kamailio.cfg] l=619 a=26 n=xlog
10(12) INFO: {1 1 ACK 1-39430(a)192.168.86.250} <script>: >>>>>>>
NOT MATCHED
10(12) exec: {1 1 ACK 1-39430(a)192.168.86.250} *** cfgtrace:dbg_cfg_trace():
request_route=[AF_SL] c=[/etc/kamailio/kamailio.cfg] l=620 a=2 n=exit
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/receive.c:531]:
receive_msg(): request-route executed in: 183 usec
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250} <core> [core/receive.c:635]:
receive_msg(): cleaning up
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f05de0f5680: SIP/2.0 3..., shmem=0x7f05d8e56900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f05de0f5680: SIP/2.0 3..., shmem=0x7f05d8e56900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f05de0f5680: SIP/2.0 3..., shmem=0x7f05d8e56900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f05d8e425a0
(p:0x7f05d8d75870/n:0x7f05d8d75870)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f05d8e425a0
from timer.c:651
request_route
if(is_method("ACK")){
if(!t_check_trans()){
xlog("L_INFO",">>>>>>> NOT MATCHED\n");
exit;
} else {
xlog("L_INFO",">>>>>>> MATCHED\n");
}
}
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080", "HTTP_REPLY");
}
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
remove_hf("Contact");
append_branch("sip:1111@otherdomain.com:5060");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
sipp xml
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<scenario name="Basic Sipstone UAC">
<!-- In client mode (sipp placing calls), the Call-ID MUST be -->
<!-- generated by sipp. To do so, use [call_id] keyword. -->
<send retrans="500">
<![CDATA[
INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp
<sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[media_ip_type] [media_ip]
t=0 0
m=audio [media_port] RTP/AVP 0
a=rtpmap:0 PCMU/8000
]]>
</send>
<recv response="100" optional="true"></recv>
<!-- By adding rrs="true" (Record Route Sets), the route sets
-->
<!-- are saved and used for following messages sent. Useful to test -->
<!-- against stateful SIP proxies/B2BUAs. -->
<recv response="302" rrs="true" rtd="true">
</recv>
<!-- Packet lost can be simulated in any send/recv message by -->
<!-- by adding the 'lost = "10"'. Value can be [1-100] percent.
-->
<send>
<![CDATA[
ACK [next_url] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp
<sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
Contact: [next_url]
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<!-- definition of the response time repartition table (unit is ms) -->
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
<!-- definition of the call length repartition table (unit is ms) -->
<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
pcap list
22 603.965446646 192.168.86.250 → 192.168.86.128 SIP/SDP 588 Request: INVITE
sip:123456@192.168.86.128:5060 |
23 603.966309968 192.168.86.128 → 192.168.86.250 SIP 344 Status: 100 Trying |
24 604.271008247 192.168.86.128 → 192.168.86.250 SIP 434 Status: 302 Redirect |
25 604.389939182 192.168.86.250 → 192.168.86.128 SIP 454 Request: ACK
sip:1111@otherdomain.com:5060 |
26 604.760536760 192.168.86.128 → 192.168.86.250 SIP 434 Status: 302 Redirect |
27 605.760472746 192.168.86.128 → 192.168.86.250 SIP 434 Status: 302 Redirect |
28 607.760461967 192.168.86.128 → 192.168.86.250 SIP 434 Status: 302 Redirect |
sipp trace output
----------------------------------------------- 2024-12-23 19:45:32.343458
UDP message sent (546 bytes):
INVITE sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-39430-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=39430SIPpTag001
To: 123456 <sip:123456@192.168.86.128:5060>
Call-ID: 1-39430(a)192.168.86.250
CSeq: 1 INVITE
Contact: sip:sipp@192.168.86.250:5060
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: 139
v=0
o=user1 53655765 2353687637 IN IP4 192.168.86.250
s=-
c=IN IP4 192.168.86.250
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
----------------------------------------------- 2024-12-23 19:45:32.522315
UDP message received [302] bytes :
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-39430-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=39430SIPpTag001
To: 123456 <sip:123456@192.168.86.128:5060>
Call-ID: 1-39430(a)192.168.86.250
CSeq: 1 INVITE
Server: kamailio (5.8.4 (x86_64/linux))
Content-Length: 0
----------------------------------------------- 2024-12-23 19:45:32.934151
UDP message received [392] bytes :
SIP/2.0 302 Redirect
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-39430-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=39430SIPpTag001
To: 123456
<sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e94a2550
Call-ID: 1-39430(a)192.168.86.250
CSeq: 1 INVITE
Contact: <sip:1111@otherdomain.com:5060>
Server: kamailio (5.8.4 (x86_64/linux))
Content-Length: 0
----------------------------------------------- 2024-12-23 19:45:32.935234
UDP message sent (412 bytes):
ACK sip:1111@otherdomain.com:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-39430-1-3
From: sipp <sip:sipp@192.168.86.250:5060>;tag=39430SIPpTag001
To: 123456
<sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e94a2550
Call-ID: 1-39430(a)192.168.86.250
CSeq: 1 ACK
Contact: sip:1111@otherdomain.com:5060
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
On 23 Dec 2024, at 7:28 PM, Ben Kaufman <bkaufman(a)bcmone.com> wrote:
Which log line do you get? Also note that both of your log lines say "Matched
transaction", but the condition is negated (it starts with an exclamation mark).
Also refer to the documentation for the function to see what happens when the ACK for a
negative reply is matched.
https://kamailio.org/docs/modules/5.8.x/modules/tm#tm.f.t_check_trans
Kaufman
Senior Voice Engineer
E: bkaufman@bcmone.com<mailto:bkaufman@bcmone.com>
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us/>
[img]<https://www.siptrunk.com/>
[img]<https://www.flowroute.com/>
________________________________
From: Alexis Fidalgo via sr-users
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Sent: Monday, December 23, 2024 4:16 PM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Cc: Alexis Fidalgo <alzrck@gmail.com<mailto:alzrck@gmail.com>>
Subject: [SR-Users] Re: help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Yes, i’ve been reading it when you mentioned the loose_route and has_totag() in a previous
email.
if(is_method("ACK")){
if(!t_check_trans()){
xlog("L_INFO","AAAA: MATCHED TRANSACTION\n");
} else {
xlog("L_INFO","BBBB: MATCHED TRANSACTION\n");
}
exit;
}
(moving the exit; inside the else has same effect on my test)
On 23 Dec 2024, at 6:49 PM, Alex Balashov via sr-users
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> wrote:
Look very carefully at how negative ACKs are handled here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…
-- Alex
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
On Dec 23, 2024, at 4:19 pm, Alexis Fidalgo via
sr-users <sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
wrote:
Hello all, moving just a bit aside of the http and async_http.
After all the real useful and interesting thread on that topic what helped me, im facing
a problem i cant deal with and need a hint at least.
Scenario
INVITE -> Kamailio
on request_route
...
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080<http://nuc:8080/>",
"HTTP_REPLY");
}
…
Kamailio -> 100 - Trying
then
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
Kamailio -> 302 Redirect
ACK -> Kamailio
This last ACK, how can i read it and use it to terminate the transaction? because
Kamailio keeps transmitting the 302 message 3 more times until the transaction is finished
by a timer
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f4c3fcd35a0
(p:0x7f4c3fad85d0/n:0x7f4c3fad85d0)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f4c3fcd35a0
from timer.c:651
in request_route i have
if(is_method("ACK")){
if(!t_check_trans()){
t_release();
}
exit;
}
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristes…
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
5:56 p.m.
and “exit;” if enough to finish it (if matched) ?
On 23 Dec 2024, at 7:52 PM, Ben Kaufman
<bkaufman(a)bcmone.com> wrote:
IF the transaction was finished, then yes, but:
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>} tm
[t_lookup.c:781]: t_lookup_request(): start searching: hash=48094, isACK=1
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>} tm
[t_lookup.c:499]: matching_3261(): RFC3261 transaction matching failed - via branch
[z9hG4bK-39430-1-3]
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>} tm
[t_lookup.c:981]: t_lookup_request(): no transaction found
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com <mailto:bkaufman@bcmone.com>
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
<https://www.sip.us/>
<https://www.siptrunk.com/>
<https://www.flowroute.com/>
From: Alexis Fidalgo <alzrck(a)gmail.com <mailto:alzrck@gmail.com>>
Sent: Monday, December 23, 2024 4:49 PM
To: Ben Kaufman <bkaufman(a)bcmone.com <mailto:bkaufman@bcmone.com>>
Cc: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
sorry about the log (changed now). my question is, if script execution is finished, the
associated transaction (red part) isnt ended too?
10(12) DEBUG: <core> [core/udp_server.c:707]: udp_rcv_loop(): received on udp
socket: (106/100/412) [[ACK sip:1111@otherdomain.com:5060 SIP/2.0 0D 0A Via: SIP/2.0/UDP
192.168.86.250:5060;branch=z9hG4bK-39430]]
10(12) DEBUG: <core> [core/parser/parse_fline.c:247]: parse_first_line(): first
line type 1 (request) flags 1
10(12) DEBUG: <core> [core/parser/msg_parser.c:722]: parse_msg(): SIP Request:
10(12) DEBUG: <core> [core/parser/msg_parser.c:723]: parse_msg(): method:
<ACK>
10(12) DEBUG: <core> [core/parser/msg_parser.c:725]: parse_msg(): uri:
<sip:1111@otherdomain.com:5060>
10(12) DEBUG: <core> [core/parser/msg_parser.c:727]: parse_msg(): version:
<SIP/2.0>
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [Via] type 1
10(12) DEBUG: <core> [core/parser/parse_via.c:1309]: parse_via_param(): Found param
type 232, <branch> = <z9hG4bK-39430-1-3>; state=16
10(12) DEBUG: <core> [core/parser/parse_via.c:2663]: parse_via(): end of header
reached, state=5
10(12) DEBUG: <core> [core/parser/msg_parser.c:592]: parse_headers(): Via found,
flags=2
10(12) DEBUG: <core> [core/parser/msg_parser.c:594]: parse_headers(): this is the
first via
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [From] type 4
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [To] type 3
10(12) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add
param: tag=a6a1c5f60faecf035a1ae5b6e96e979a-e94a2550
10(12) DEBUG: <core> [core/parser/parse_addr_spec.c:904]: parse_addr_spec(): end of
header reached, state=29
10(12) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): <To>
[87]; uri=[sip:123456@192.168.86.128:5060]
10(12) DEBUG: <core> [core/parser/msg_parser.c:174]: get_hdr_field(): to body
(39)[123456 <sip:123456@192.168.86.128:5060>], to tag
(41)[a6a1c5f60faecf035a1ae5b6e96e979a-e94a2550]
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [Call-ID] type 6
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [CSeq] type 5
10(12) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq
<CSeq>: <1> <ACK>
10(12) DEBUG: <core> [core/receive.c:392]: receive_msg(): --- received sip message
- request - call-id: [1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>] -
cseq: [1 ACK]
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [Contact] type 7
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [Max-Forwards] type 8
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [Subject] type 27
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [Content-Length] type 12
10(12) DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field():
content_length=0
10(12) DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of
header
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>}
<core> [core/receive.c:263]: ksr_evrt_pre_routing(): event route core:pre-routing
not defined
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>}
<core> [core/receive.c:474]: receive_msg(): preparing to run routing scripts...
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>} sl
[sl_funcs.c:455]: sl_filter_ACK(): too late to be a local ACK!
10(12) exec: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>} ***
cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/etc/kamailio/kamailio.cfg]
l=537 a=5 n=route
10(12) exec: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>} ***
cfgtrace:dbg_cfg_trace(): request_route=[AF_SL] c=[/etc/kamailio/kamailio.cfg] l=625 a=16
n=if
10(12) exec: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>} ***
cfgtrace:dbg_cfg_trace(): request_route=[AF_SL] c=[/etc/kamailio/kamailio.cfg] l=617 a=25
n=is_method
10(12) exec: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>} ***
cfgtrace:dbg_cfg_trace(): request_route=[AF_SL] c=[/etc/kamailio/kamailio.cfg] l=623 a=16
n=if
10(12) exec: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>} ***
cfgtrace:dbg_cfg_trace(): request_route=[AF_SL] c=[/etc/kamailio/kamailio.cfg] l=618 a=24
n=t_check_trans
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>} tm
[t_lookup.c:1565]: t_check_msg(): msg (0x7f05de39d4d0) id=1/12 global id=0/0 T
start=0xffffffffffffffff
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>} tm
[t_lookup.c:781]: t_lookup_request(): start searching: hash=48094, isACK=1
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>} tm
[t_lookup.c:499]: matching_3261(): RFC3261 transaction matching failed - via branch
[z9hG4bK-39430-1-3]
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>} tm
[t_lookup.c:981]: t_lookup_request(): no transaction found
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>} tm
[t_lookup.c:1637]: t_check_msg(): msg (0x7f05de39d4d0) id=1/12 global id=1/12 T end=(nil)
10(12) exec: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>} ***
cfgtrace:dbg_cfg_trace(): request_route=[AF_SL] c=[/etc/kamailio/kamailio.cfg] l=619 a=26
n=xlog
10(12) INFO: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>}
<script>: >>>>>>> NOT MATCHED
10(12) exec: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>} ***
cfgtrace:dbg_cfg_trace(): request_route=[AF_SL] c=[/etc/kamailio/kamailio.cfg] l=620 a=2
n=exit
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>}
<core> [core/receive.c:531]: receive_msg(): request-route executed in: 183 usec
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>}
<core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>}
<core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>}
<core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>}
<core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>}
<core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>}
<core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>}
<core> [core/xavp.c:630]: xavp_destroy_list(): destroying xavp list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>}
<core> [core/xavp.c:630]: xavp_destroy_list(): destroying xavp list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>}
<core> [core/xavp.c:630]: xavp_destroy_list(): destroying xavp list (nil)
10(12) DEBUG: {1 1 ACK 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>}
<core> [core/receive.c:635]: receive_msg(): cleaning up
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f05de0f5680: SIP/2.0 3..., shmem=0x7f05d8e56900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f05de0f5680: SIP/2.0 3..., shmem=0x7f05d8e56900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f05de0f5680: SIP/2.0 3..., shmem=0x7f05d8e56900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f05d8e425a0
(p:0x7f05d8d75870/n:0x7f05d8d75870)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f05d8e425a0
from timer.c:651
request_route
if(is_method("ACK")){
if(!t_check_trans()){
xlog("L_INFO",">>>>>>> NOT MATCHED\n");
exit;
} else {
xlog("L_INFO",">>>>>>> MATCHED\n");
}
}
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080 <http://nuc:8080/>",
"HTTP_REPLY");
}
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
remove_hf("Contact");
append_branch("sip:1111@otherdomain.com:5060");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
sipp xml
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<scenario name="Basic Sipstone UAC">
<!-- In client mode (sipp placing calls), the Call-ID MUST be -->
<!-- generated by sipp. To do so, use [call_id] keyword. -->
<send retrans="500">
<![CDATA[
INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp
<sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[media_ip_type] [media_ip]
t=0 0
m=audio [media_port] RTP/AVP 0
a=rtpmap:0 PCMU/8000
]]>
</send>
<recv response="100" optional="true"></recv>
<!-- By adding rrs="true" (Record Route Sets), the route sets
-->
<!-- are saved and used for following messages sent. Useful to test -->
<!-- against stateful SIP proxies/B2BUAs. -->
<recv response="302" rrs="true" rtd="true">
</recv>
<!-- Packet lost can be simulated in any send/recv message by -->
<!-- by adding the 'lost = "10"'. Value can be [1-100] percent.
-->
<send>
<![CDATA[
ACK [next_url] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp
<sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
Contact: [next_url]
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<!-- definition of the response time repartition table (unit is ms) -->
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
<!-- definition of the call length repartition table (unit is ms) -->
<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
pcap list
22 603.965446646 192.168.86.250 → 192.168.86.128 SIP/SDP 588 Request: INVITE
sip:123456@192.168.86.128:5060 |
23 603.966309968 192.168.86.128 → 192.168.86.250 SIP 344 Status: 100 Trying |
24 604.271008247 192.168.86.128 → 192.168.86.250 SIP 434 Status: 302 Redirect |
25 604.389939182 192.168.86.250 → 192.168.86.128 SIP 454 Request: ACK
sip:1111@otherdomain.com:5060 |
26 604.760536760 192.168.86.128 → 192.168.86.250 SIP 434 Status: 302 Redirect |
27 605.760472746 192.168.86.128 → 192.168.86.250 SIP 434 Status: 302 Redirect |
28 607.760461967 192.168.86.128 → 192.168.86.250 SIP 434 Status: 302 Redirect |
sipp trace output
----------------------------------------------- 2024-12-23 19:45:32.343458
UDP message sent (546 bytes):
INVITE sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-39430-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=39430SIPpTag001
To: 123456 <sip:123456@192.168.86.128:5060>
Call-ID: 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>
CSeq: 1 INVITE
Contact: sip:sipp@192.168.86.250:5060
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: 139
v=0
o=user1 53655765 2353687637 IN IP4 192.168.86.250
s=-
c=IN IP4 192.168.86.250
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
----------------------------------------------- 2024-12-23 19:45:32.522315
UDP message received [302] bytes :
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-39430-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=39430SIPpTag001
To: 123456 <sip:123456@192.168.86.128:5060>
Call-ID: 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>
CSeq: 1 INVITE
Server: kamailio (5.8.4 (x86_64/linux))
Content-Length: 0
----------------------------------------------- 2024-12-23 19:45:32.934151
UDP message received [392] bytes :
SIP/2.0 302 Redirect
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-39430-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=39430SIPpTag001
To: 123456
<sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e94a2550
Call-ID: 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>
CSeq: 1 INVITE
Contact: <sip:1111@otherdomain.com:5060>
Server: kamailio (5.8.4 (x86_64/linux))
Content-Length: 0
----------------------------------------------- 2024-12-23 19:45:32.935234
UDP message sent (412 bytes):
ACK sip:1111@otherdomain.com:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-39430-1-3
From: sipp <sip:sipp@192.168.86.250:5060>;tag=39430SIPpTag001
To: 123456
<sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e94a2550
Call-ID: 1-39430(a)192.168.86.250 <mailto:1-39430@192.168.86.250>
CSeq: 1 ACK
Contact: sip:1111@otherdomain.com:5060
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
> On 23 Dec 2024, at 7:28 PM, Ben Kaufman <bkaufman(a)bcmone.com
<mailto:bkaufman@bcmone.com>> wrote:
>
> Which log line do you get? Also note that both of your log lines say "Matched
transaction", but the condition is negated (it starts with an exclamation mark).
>
> Also refer to the documentation for the function to see what happens when the ACK for
a negative reply is matched.
>
> https://kamailio.org/docs/modules/5.8.x/modules/tm#tm.f.t_check_trans
>
> Kaufman
> Senior Voice Engineer
>
>
>
> E: bkaufman(a)bcmone.com <mailto:bkaufman@bcmone.com>
>
>
>
>
>
> SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
> <https://www.sip.us/>
> <https://www.siptrunk.com/>
> <https://www.flowroute.com/>
>
>
>
> From: Alexis Fidalgo via sr-users <sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>>
> Sent: Monday, December 23, 2024 4:16 PM
> To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>>
> Cc: Alexis Fidalgo <alzrck(a)gmail.com <mailto:alzrck@gmail.com>>
> Subject: [SR-Users] Re: help on how to get ACK
>
> CAUTION: This email originated from outside the organization. Do not click links or
open attachments unless you recognize the sender and know the content is safe.
>
>
> Yes, i’ve been reading it when you mentioned the loose_route and has_totag() in a
previous email.
>
> if(is_method("ACK")){
> if(!t_check_trans()){
> xlog("L_INFO","AAAA: MATCHED TRANSACTION\n");
> } else {
> xlog("L_INFO","BBBB: MATCHED TRANSACTION\n");
> }
> exit;
> }
>
> (moving the exit; inside the else has same effect on my test)
>
>
> > On 23 Dec 2024, at 6:49 PM, Alex Balashov via sr-users
<sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>> wrote:
> >
> > Look very carefully at how negative ACKs are handled here:
> >
> >
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…
<https://github.com/kamailio/kamailio/blob/master/etc/kamailio.cfg#L716>
> >
> > -- Alex
> >
> >> On Dec 23, 2024, at 4:19 pm, Alexis Fidalgo via sr-users
<sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>> wrote:
> >>
> >> Hello all, moving just a bit aside of the http and async_http.
> >>
> >> After all the real useful and interesting thread on that topic what helped
me, im facing a problem i cant deal with and need a hint at least.
> >>
> >> Scenario
> >>
> >> INVITE -> Kamailio
> >>
> >> on request_route
> >> ...
> >> if(is_method("INVITE")){
> >> t_newtran();
> >> http_async_query("http://nuc:8080 <http://nuc:8080/>",
"HTTP_REPLY");
> >> }
> >> …
> >>
> >> Kamailio -> 100 - Trying
> >>
> >>
> >> then
> >>
> >> route[HTTP_REPLY] {
> >> if ($http_ok) {
> >> xlog("L_INFO", "route[HTTP_REPLY]: status
$http_rs\n");
> >> xlog("L_INFO", "route[HTTP_REPLY]: body
$http_rb\n");
> >> t_reply(302,"Redirect");
> >> } else {
> >> xlog("L_INFO", "route[HTTP_REPLY]: error
$http_err)\n");
> >> }
> >> }
> >>
> >> Kamailio -> 302 Redirect
> >> ACK -> Kamailio
> >>
> >> This last ACK, how can i read it and use it to terminate the transaction?
because Kamailio keeps transmitting the 302 message 3 more times until the transaction is
finished by a timer
> >>
> >> 42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply
retransmitted. buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
> >> 42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply
retransmitted. buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
> >> 42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply
retransmitted. buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
> >> 42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction:
0x7f4c3fcd35a0 (p:0x7f4c3fad85d0/n:0x7f4c3fad85d0)
> >> 42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction
0x7f4c3fcd35a0 from timer.c:651
> >>
> >>
> >> in request_route i have
> >>
> >> if(is_method("ACK")){
> >> if(!t_check_trans()){
> >> t_release();
> >> }
> >> exit;
> >> }
> >>
> >>
> >> __________________________________________________________
> >> Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
> >> To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
<mailto:sr-users-leave@lists.kamailio.org>
> >> Important: keep the mailing list in the recipients, do not reply only to the
sender!
> >
> > --
> > Alex Balashov
> > Principal Consultant
> > Evariste Systems LLC
> > Web:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristes…
<https://evaristesys.com/>
> > Tel: +1-706-510-6800
> >
> > __________________________________________________________
> > Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
> > To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
<mailto:sr-users-leave@lists.kamailio.org>
> > Important: keep the mailing list in the recipients, do not reply only to the
sender!
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
> To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
<mailto:sr-users-leave@lists.kamailio.org>
> Important: keep the mailing list in the recipients, do not reply only to the sender!
6:01 p.m.
exit; will finish processing the script, but because the transaction wasn't matched,
then how would kamailio know to end the transaction processing? One thin you can look at
is that your lines in red begin with 42(44) which are the process index and PID for the
process. Those are completely different processes than the message you're handling.
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us/>
[img]<https://www.siptrunk.com/>
[img]<https://www.flowroute.com/>
________________________________
From: Alexis Fidalgo <alzrck(a)gmail.com>
Sent: Monday, December 23, 2024 4:56 PM
To: Ben Kaufman <bkaufman(a)bcmone.com>
Cc: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
and “exit;” if enough to finish it (if matched) ?
On 23 Dec 2024, at 7:52 PM, Ben Kaufman <bkaufman(a)bcmone.com> wrote:
IF the transaction was finished, then yes, but:
10(12) DEBUG: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>} tm
[t_lookup.c:781]: t_lookup_request(): start searching: hash=48094, isACK=1
10(12) DEBUG: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>} tm
[t_lookup.c:499]: matching_3261(): RFC3261 transaction matching failed - via branch
[z9hG4bK-39430-1-3]
10(12) DEBUG: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>} tm
[t_lookup.c:981]: t_lookup_request(): no transaction found
Kaufman
Senior Voice Engineer
E: bkaufman@bcmone.com<mailto:bkaufman@bcmone.com>
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us/>
[img]<https://www.siptrunk.com/>
[img]<https://www.flowroute.com/>
________________________________
From: Alexis Fidalgo <alzrck@gmail.com<mailto:alzrck@gmail.com>>
Sent: Monday, December 23, 2024 4:49 PM
To: Ben Kaufman <bkaufman@bcmone.com<mailto:bkaufman@bcmone.com>>
Cc: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
sorry about the log (changed now). my question is, if script execution is finished, the
associated transaction (red part) isnt ended too?
10(12) DEBUG: <core> [core/udp_server.c:707]: udp_rcv_loop(): received on udp
socket: (106/100/412) [[ACK sip:1111@otherdomain.com:5060 SIP/2.0 0D 0A Via: SIP/2.0/UDP
192.168.86.250:5060;branch=z9hG4bK-39430]]
10(12) DEBUG: <core> [core/parser/parse_fline.c:247]: parse_first_line(): first line
type 1 (request) flags 1
10(12) DEBUG: <core> [core/parser/msg_parser.c:722]: parse_msg(): SIP Request:
10(12) DEBUG: <core> [core/parser/msg_parser.c:723]: parse_msg(): method:
<ACK>
10(12) DEBUG: <core> [core/parser/msg_parser.c:725]: parse_msg(): uri:
<sip:1111@otherdomain.com:5060>
10(12) DEBUG: <core> [core/parser/msg_parser.c:727]: parse_msg(): version:
<SIP/2.0>
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [Via] type 1
10(12) DEBUG: <core> [core/parser/parse_via.c:1309]: parse_via_param(): Found param
type 232, <branch> = <z9hG4bK-39430-1-3>; state=16
10(12) DEBUG: <core> [core/parser/parse_via.c:2663]: parse_via(): end of header
reached, state=5
10(12) DEBUG: <core> [core/parser/msg_parser.c:592]: parse_headers(): Via found,
flags=2
10(12) DEBUG: <core> [core/parser/msg_parser.c:594]: parse_headers(): this is the
first via
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [From] type 4
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [To] type 3
10(12) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add
param: tag=a6a1c5f60faecf035a1ae5b6e96e979a-e94a2550
10(12) DEBUG: <core> [core/parser/parse_addr_spec.c:904]: parse_addr_spec(): end of
header reached, state=29
10(12) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): <To>
[87]; uri=[sip:123456@192.168.86.128:5060]
10(12) DEBUG: <core> [core/parser/msg_parser.c:174]: get_hdr_field(): to body
(39)[123456 <sip:123456@192.168.86.128:5060>], to tag
(41)[a6a1c5f60faecf035a1ae5b6e96e979a-e94a2550]
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [Call-ID] type 6
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [CSeq] type 5
10(12) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq
<CSeq>: <1> <ACK>
10(12) DEBUG: <core> [core/receive.c:392]: receive_msg(): --- received sip message -
request - call-id: [1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>] - cseq:
[1 ACK]
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [Contact] type 7
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [Max-Forwards] type 8
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [Subject] type 27
10(12) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name():
parsed header name [Content-Length] type 12
10(12) DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field():
content_length=0
10(12) DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of
header
10(12) DEBUG: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>}
<core> [core/receive.c:263]: ksr_evrt_pre_routing(): event route core:pre-routing
not defined
10(12) DEBUG: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>}
<core> [core/receive.c:474]: receive_msg(): preparing to run routing scripts...
10(12) DEBUG: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>} sl
[sl_funcs.c:455]: sl_filter_ACK(): too late to be a local ACK!
10(12) exec: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>} ***
cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/etc/kamailio/kamailio.cfg]
l=537 a=5 n=route
10(12) exec: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>} ***
cfgtrace:dbg_cfg_trace(): request_route=[AF_SL] c=[/etc/kamailio/kamailio.cfg] l=625 a=16
n=if
10(12) exec: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>} ***
cfgtrace:dbg_cfg_trace(): request_route=[AF_SL] c=[/etc/kamailio/kamailio.cfg] l=617 a=25
n=is_method
10(12) exec: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>} ***
cfgtrace:dbg_cfg_trace(): request_route=[AF_SL] c=[/etc/kamailio/kamailio.cfg] l=623 a=16
n=if
10(12) exec: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>} ***
cfgtrace:dbg_cfg_trace(): request_route=[AF_SL] c=[/etc/kamailio/kamailio.cfg] l=618 a=24
n=t_check_trans
10(12) DEBUG: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>} tm
[t_lookup.c:1565]: t_check_msg(): msg (0x7f05de39d4d0) id=1/12 global id=0/0 T
start=0xffffffffffffffff
10(12) DEBUG: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>} tm
[t_lookup.c:781]: t_lookup_request(): start searching: hash=48094, isACK=1
10(12) DEBUG: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>} tm
[t_lookup.c:499]: matching_3261(): RFC3261 transaction matching failed - via branch
[z9hG4bK-39430-1-3]
10(12) DEBUG: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>} tm
[t_lookup.c:981]: t_lookup_request(): no transaction found
10(12) DEBUG: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>} tm
[t_lookup.c:1637]: t_check_msg(): msg (0x7f05de39d4d0) id=1/12 global id=1/12 T
end=(nil)
10(12) exec: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>} ***
cfgtrace:dbg_cfg_trace(): request_route=[AF_SL] c=[/etc/kamailio/kamailio.cfg] l=619 a=26
n=xlog
10(12) INFO: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>}
<script>: >>>>>>> NOT MATCHED
10(12) exec: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>} ***
cfgtrace:dbg_cfg_trace(): request_route=[AF_SL] c=[/etc/kamailio/kamailio.cfg] l=620 a=2
n=exit
10(12) DEBUG: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>}
<core> [core/receive.c:531]: receive_msg(): request-route executed in: 183 usec
10(12) DEBUG: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>}
<core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil)
10(12) DEBUG: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>}
<core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil)
10(12) DEBUG: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>}
<core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil)
10(12) DEBUG: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>}
<core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil)
10(12) DEBUG: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>}
<core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil)
10(12) DEBUG: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>}
<core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil)
10(12) DEBUG: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>}
<core> [core/xavp.c:630]: xavp_destroy_list(): destroying xavp list (nil)
10(12) DEBUG: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>}
<core> [core/xavp.c:630]: xavp_destroy_list(): destroying xavp list (nil)
10(12) DEBUG: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>}
<core> [core/xavp.c:630]: xavp_destroy_list(): destroying xavp list (nil)
10(12) DEBUG: {1 1 ACK 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>}
<core> [core/receive.c:635]: receive_msg(): cleaning up
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f05de0f5680: SIP/2.0 3..., shmem=0x7f05d8e56900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f05de0f5680: SIP/2.0 3..., shmem=0x7f05d8e56900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f05de0f5680: SIP/2.0 3..., shmem=0x7f05d8e56900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f05d8e425a0
(p:0x7f05d8d75870/n:0x7f05d8d75870)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f05d8e425a0
from timer.c:651
request_route
if(is_method("ACK")){
if(!t_check_trans()){
xlog("L_INFO",">>>>>>> NOT MATCHED\n");
exit;
} else {
xlog("L_INFO",">>>>>>> MATCHED\n");
}
}
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080<http://nuc:8080/>",
"HTTP_REPLY");
}
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
remove_hf("Contact");
append_branch("sip:1111@otherdomain.com:5060");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
sipp xml
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<scenario name="Basic Sipstone UAC">
<!-- In client mode (sipp placing calls), the Call-ID MUST be -->
<!-- generated by sipp. To do so, use [call_id] keyword. -->
<send retrans="500">
<![CDATA[
INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp
<sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[media_ip_type] [media_ip]
t=0 0
m=audio [media_port] RTP/AVP 0
a=rtpmap:0 PCMU/8000
]]>
</send>
<recv response="100" optional="true"></recv>
<!-- By adding rrs="true" (Record Route Sets), the route sets
-->
<!-- are saved and used for following messages sent. Useful to test -->
<!-- against stateful SIP proxies/B2BUAs. -->
<recv response="302" rrs="true" rtd="true">
</recv>
<!-- Packet lost can be simulated in any send/recv message by -->
<!-- by adding the 'lost = "10"'. Value can be [1-100] percent.
-->
<send>
<![CDATA[
ACK [next_url] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp
<sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
Contact: [next_url]
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<!-- definition of the response time repartition table (unit is ms) -->
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
<!-- definition of the call length repartition table (unit is ms) -->
<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
pcap list
22 603.965446646 192.168.86.250 → 192.168.86.128 SIP/SDP 588 Request: INVITE
sip:123456@192.168.86.128:5060 |
23 603.966309968 192.168.86.128 → 192.168.86.250 SIP 344 Status: 100 Trying |
24 604.271008247 192.168.86.128 → 192.168.86.250 SIP 434 Status: 302 Redirect |
25 604.389939182 192.168.86.250 → 192.168.86.128 SIP 454 Request: ACK
sip:1111@otherdomain.com:5060 |
26 604.760536760 192.168.86.128 → 192.168.86.250 SIP 434 Status: 302 Redirect |
27 605.760472746 192.168.86.128 → 192.168.86.250 SIP 434 Status: 302 Redirect |
28 607.760461967 192.168.86.128 → 192.168.86.250 SIP 434 Status: 302 Redirect |
sipp trace output
----------------------------------------------- 2024-12-23 19:45:32.343458
UDP message sent (546 bytes):
INVITE sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-39430-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=39430SIPpTag001
To: 123456 <sip:123456@192.168.86.128:5060>
Call-ID: 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>
CSeq: 1 INVITE
Contact: sip:sipp@192.168.86.250:5060
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: 139
v=0
o=user1 53655765 2353687637 IN IP4 192.168.86.250
s=-
c=IN IP4 192.168.86.250
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
----------------------------------------------- 2024-12-23 19:45:32.522315
UDP message received [302] bytes :
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-39430-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=39430SIPpTag001
To: 123456 <sip:123456@192.168.86.128:5060>
Call-ID: 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>
CSeq: 1 INVITE
Server: kamailio (5.8.4 (x86_64/linux))
Content-Length: 0
----------------------------------------------- 2024-12-23 19:45:32.934151
UDP message received [392] bytes :
SIP/2.0 302 Redirect
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-39430-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=39430SIPpTag001
To: 123456
<sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e94a2550
Call-ID: 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>
CSeq: 1 INVITE
Contact: <sip:1111@otherdomain.com:5060>
Server: kamailio (5.8.4 (x86_64/linux))
Content-Length: 0
----------------------------------------------- 2024-12-23 19:45:32.935234
UDP message sent (412 bytes):
ACK sip:1111@otherdomain.com:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-39430-1-3
From: sipp <sip:sipp@192.168.86.250:5060>;tag=39430SIPpTag001
To: 123456
<sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e94a2550
Call-ID: 1-39430@192.168.86.250<mailto:1-39430@192.168.86.250>
CSeq: 1 ACK
Contact: sip:1111@otherdomain.com:5060
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
On 23 Dec 2024, at 7:28 PM, Ben Kaufman
<bkaufman@bcmone.com<mailto:bkaufman@bcmone.com>> wrote:
Which log line do you get? Also note that both of your log lines say "Matched
transaction", but the condition is negated (it starts with an exclamation mark).
Also refer to the documentation for the function to see what happens when the ACK for a
negative reply is matched.
https://kamailio.org/docs/modules/5.8.x/modules/tm#tm.f.t_check_trans
Kaufman
Senior Voice Engineer
E: bkaufman@bcmone.com<mailto:bkaufman@bcmone.com>
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us/>
[img]<https://www.siptrunk.com/>
[img]<https://www.flowroute.com/>
________________________________
From: Alexis Fidalgo via sr-users
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Sent: Monday, December 23, 2024 4:16 PM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Cc: Alexis Fidalgo <alzrck@gmail.com<mailto:alzrck@gmail.com>>
Subject: [SR-Users] Re: help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Yes, i’ve been reading it when you mentioned the loose_route and has_totag() in a previous
email.
if(is_method("ACK")){
if(!t_check_trans()){
xlog("L_INFO","AAAA: MATCHED TRANSACTION\n");
} else {
xlog("L_INFO","BBBB: MATCHED TRANSACTION\n");
}
exit;
}
(moving the exit; inside the else has same effect on my test)
On 23 Dec 2024, at 6:49 PM, Alex Balashov via sr-users
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> wrote:
Look very carefully at how negative ACKs are handled here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…
-- Alex
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
On Dec 23, 2024, at 4:19 pm, Alexis Fidalgo via
sr-users <sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
wrote:
Hello all, moving just a bit aside of the http and async_http.
After all the real useful and interesting thread on that topic what helped me, im facing
a problem i cant deal with and need a hint at least.
Scenario
INVITE -> Kamailio
on request_route
...
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080<http://nuc:8080/>",
"HTTP_REPLY");
}
…
Kamailio -> 100 - Trying
then
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
Kamailio -> 302 Redirect
ACK -> Kamailio
This last ACK, how can i read it and use it to terminate the transaction? because
Kamailio keeps transmitting the 302 message 3 more times until the transaction is finished
by a timer
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f4c3fcd35a0
(p:0x7f4c3fad85d0/n:0x7f4c3fad85d0)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f4c3fcd35a0
from timer.c:651
in request_route i have
if(is_method("ACK")){
if(!t_check_trans()){
t_release();
}
exit;
}
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristes…
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
23 Dec
23 Dec
6:04 p.m.
Well, in my case I have:
route{
...
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
# no loose-route, but stateful ACK;
# must be an ACK after a 487
# or e.g. 404 from upstream server
xlog("L_INFO","ACK - t_check_trans \n");
route(RELAY);
exit;
} else {
# ACK without matching transaction ... ignore and discard
xlog("L_INFO","ACK without matching transaction \n");
exit;
}
}
}
route[RELAY] {
xlog("L_INFO", " ******** RELAY *******");
xlog("L_INFO", "RELAY - $rm to $si responding back to $su");
t_on_failure("FAILED_RELAY");
t_on_reply("MANAGE_REPLY");
if (is_method("INVITE"))
send_reply("300", "Multiple Choices");
exit;
}
INVITE sip:1@10.20.20.1:5060 SIP/2.0
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3356440-1-0
SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3356440-1-0
(here I am testing a HTTP failure test case)
SIP/2.0 503 No Connection to HTTP API
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3356440-1-0
ACK sip:1@10.20.20.1:5060 SIP/2.0
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3356440-1-0
But after this ACK, Kamailio sends:
SIP/2.0 500 I'm terribly sorry, server error occurred (1/TM)
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3356440-1-0
Logs are weird too (debug = 3)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: <core>
[core/parser/msg_parser.c:91]: get_hdr_field(): found end of header
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440(a)10.20.0.1} <core> [core/receive.c:263]: ksr_evrt_pre_routing():
event route core:pre-routing not defined
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440(a)10.20.0.1} <core> [core/receive.c:474]: receive_msg(): preparing
to run routing scripts...
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440(a)10.20.0.1} sl [sl_funcs.c:472]: sl_filter_ACK(): SL local ACK
found -> dropping it!
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440(a)10.20.0.1} <core> [core/usr_avp.c:654]: destroy_avp_list():
destroying list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440(a)10.20.0.1} <core> [core/usr_avp.c:654]: destroy_avp_list():
destroying list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440(a)10.20.0.1} <core> [core/usr_avp.c:654]: destroy_avp_list():
destroying list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440(a)10.20.0.1} <core> [core/usr_avp.c:654]: destroy_avp_list():
destroying list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440(a)10.20.0.1} <core> [core/usr_avp.c:654]: destroy_avp_list():
destroying list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440(a)10.20.0.1} <core> [core/usr_avp.c:654]: destroy_avp_list():
destroying list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440(a)10.20.0.1} <core> [core/xavp.c:630]: xavp_destroy_list():
destroying xavp list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440(a)10.20.0.1} <core> [core/xavp.c:630]: xavp_destroy_list():
destroying xavp list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440(a)10.20.0.1} <core> [core/xavp.c:630]: xavp_destroy_list():
destroying xavp list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440(a)10.20.0.1} <core> [core/receive.c:635]: receive_msg(): cleaning up
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: <core> [db_query.c:72]:
db_do_submit_query(): submitted query: delete from `dialog` where
`hash_entry`=3272 AND `hash_id`=10103, result 0
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: db_cluster
[dbcl_api.c:663]: db_cluster_use_table(): use table (dialog_vars) - cluster
[k1]
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: db_cluster
[dbcl_api.c:670]: db_cluster_use_table(): set read table (dialog_vars) -
cluster [k1] (9/0)
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: db_cluster
[dbcl_api.c:680]: db_cluster_use_table(): set write table (dialog_vars) -
cluster [k1] (9/0)
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: db_cluster
[dbcl_api.c:570]: db_cluster_delete(): executing db cluster delete command
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: db_cluster
[dbcl_api.c:571]: db_cluster_delete(): round robin operation - cluster [k1]
(9/0)
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: <core> [db_query.c:72]:
db_do_submit_query(): submitted query: delete from `dialog_vars` where
`hash_entry`=3272 AND `hash_id`=10103, result 0
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: dialog
[dlg_db_handler.c:759]: remove_dialog_from_db(): callid was
1-3356440(a)10.20.0.1
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: tm [h_table.c:551]:
tm_xdata_swap(): restore X/AVPs msg context from txdata
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: tm [t_reply.c:1782]:
cleanup_uac_timers(): RETR/FR timers reset
*Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: tm [t_reply.c:634]:
_reply_light(): reply sent out - buf=0x7f4903fd57d0: SIP/2.0 500 I'm
terr... shmem=0x7f48c27177a0: SIP/2.0 500 I'm terr*
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: tm [t_funcs.c:133]:
put_on_wait(): put T [0x7f48c271cda0] on wait
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: tm [t_reply.c:650]:
_reply_light(): finished
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: http_async_client
[async_http.h:153]: free_async_query(): freeing query 0x7f48c27229b0
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: http_async_client
[http_multi.c:661]: check_multi_info(): reply: [428] HTTP/1.0 428
PRECONDITION REQUIRED#015#012Content-Type: text/html;
charset=utf-8#015#012Content-Length: 138#015#012Server: Werkzeug/2.0.3
Python/3.9.16#015#012Date: Mon, 23 Dec 2024 22:59:09
GMT#015#012#015#012<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2
Final//EN">#012<title>428 Precondition
Required</title>#012<h1>Precondition
Required</h1>#012<p>{}</p>#012 [312]
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: http_async_client
[http_multi.c:668]: check_multi_info(): cleaning up cell 0x7f48c2722d30
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: http_async_client
[http_multi.c:673]: check_multi_info(): Removing handle 0x7f48c2717e80
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: http_async_client
[http_multi.c:150]: event_cb(): last transfer done, kill timeout
Dec 23 22:59:39 kamailio1 kamailio[4060839]: DEBUG: tm [t_funcs.c:133]:
put_on_wait(): put T [0x7f48c271cda0] on wait
Dec 23 22:59:39 kamailio1 kamailio[4060839]: DEBUG: <core>
[core/timer.c:555]: timer_add_safe(): timer_add called on an active timer
0x7f48c271ce58 (0x7f48c2225bc0, 0x7f48c2225bc0), flags 201
Dec 23 22:59:39 kamailio1 kamailio[4060839]: DEBUG: tm [t_funcs.c:156]:
put_on_wait(): transaction 0x7f48c271cda0 already on wait
Running same SIP Invite from SIPp but with test case where HTTP API returns
a valid (200) response, everything works fine!
Atenciosamente / Kind Regards / Cordialement / Un saludo,
*Sérgio Charrua*
On Mon, Dec 23, 2024 at 11:49 PM Ben Kaufman via sr-users <
sr-users(a)lists.kamailio.org> wrote:
Which log line do you get? Also note that both of
your log lines say
"Matched transaction", but the condition is negated (it starts with an
exclamation mark).
Also refer to the documentation for the function to see what happens when
the ACK for a negative reply is matched.
https://kamailio.org/docs/modules/5.8.x/modules/tm#tm.f.t_check_trans
*Kaufman*
*Senior Voice Engineer *
E: bkaufman(a)bcmone.com
SIP.US Client Support: 800.566.9810 *|* SIPTRUNK Client Support:
800.250.6510 *|* Flowroute Client Support: 855.356.9768
[image: img] <https://www.sip.us/>
[image: img] <https://www.siptrunk.com/>
*[image: img] <https://www.flowroute.com/>*
------------------------------
*From:* Alexis Fidalgo via sr-users <sr-users(a)lists.kamailio.org>
*Sent:* Monday, December 23, 2024 4:16 PM
*To:* Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
*Cc:* Alexis Fidalgo <alzrck(a)gmail.com>
*Subject:* [SR-Users] Re: help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click
links or open attachments unless you recognize the sender and know the
content is safe.
Yes, i’ve been reading it when you mentioned the loose_route and
has_totag() in a previous email.
if(is_method("ACK")){
if(!t_check_trans()){
xlog("L_INFO","AAAA: MATCHED TRANSACTION\n");
} else {
xlog("L_INFO","BBBB: MATCHED TRANSACTION\n");
}
exit;
}
(moving the exit; inside the else has same effect on my test)
On 23 Dec 2024, at 6:49 PM, Alex Balashov via
sr-users <
sr-users(a)lists.kamailio.org> wrote:
Look very carefully at how negative ACKs are handled here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…
<https://github.com/kamailio/kamailio/blob/master/etc/kamailio.cfg#L716>
-- Alex
> On Dec 23, 2024, at 4:19 pm, Alexis Fidalgo via sr-users <
sr-users(a)lists.kamailio.org> wrote:
>
> Hello all, moving just a bit aside of the http and async_http.
>
> After all the real useful and interesting thread on that topic what
helped me,
im facing a problem i cant deal with and need a hint at least.
>
> Scenario
>
> INVITE -> Kamailio
>
> on request_route
> ...
> if(is_method("INVITE")){
> t_newtran();
> http_async_query("http://nuc:8080", "HTTP_REPLY");
> }
> …
>
> Kamailio -> 100 - Trying
>
>
> then
>
> route[HTTP_REPLY] {
> if ($http_ok) {
> xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
> xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
> t_reply(302,"Redirect");
> } else {
> xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
> }
> }
>
> Kamailio -> 302 Redirect
> ACK -> Kamailio
>
> This last ACK, how can i read it and use it to terminate the
transaction?
because Kamailio keeps transmitting the 302 message 3 more
times until the transaction is finished by a timer
>
> 42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply
retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900:
SIP/2.0 3
> 42(44) DEBUG: tm [t_reply.c:1723]:
t_retransmit_reply(): reply
retransmitted. buf=0x7f4c44f9d680: SIP/2.0 3...,
shmem=0x7f4c3fce7900:
SIP/2.0 3
> 42(44) DEBUG: tm [t_reply.c:1723]:
t_retransmit_reply(): reply
retransmitted. buf=0x7f4c44f9d680: SIP/2.0 3...,
shmem=0x7f4c3fce7900:
SIP/2.0 3
> 42(44) DEBUG: tm [timer.c:642]:
wait_handler(): finished transaction:
0x7f4c3fcd35a0
(p:0x7f4c3fad85d0/n:0x7f4c3fad85d0)
> 42(44) DEBUG: tm [h_table.c:133]:
free_cell_helper(): freeing
transaction 0x7f4c3fcd35a0 from timer.c:651
>
>
> in request_route i have
>
> if(is_method("ACK")){
> if(!t_check_trans()){
> t_release();
> }
> exit;
> }
>
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
> To unsubscribe send an email to
sr-users-leave(a)lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only
to the
sender!
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristes…
<https://evaristesys.com/>
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to
sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the
sender!
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender!
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender!
6:18 p.m.
While I'm hardpressed to say exactly why, it does seem like your structure is a bit
odd.
You show this as in your route - is this also after checking for a to: tag? The decision
to send a 300 reply from within a route named "RELAY" after arming the failure
and onreply routes is awkward. Finally, although the exit at the end of route[RELAY] is
implied is it intended to be explicit if the method is INVITE? Adding curly braces there
may not be necessary, but it does improve readability.
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us/>
[img]<https://www.siptrunk.com/>
[img]<https://www.flowroute.com/>
________________________________
From: Sergio Charrua <sergio.charrua(a)voip.pt>
Sent: Monday, December 23, 2024 5:04 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: Alexis Fidalgo <alzrck(a)gmail.com>om>; Ben Kaufman <bkaufman(a)bcmone.com>
Subject: Re: [SR-Users] Re: help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Well, in my case I have:
route{
...
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
# no loose-route, but stateful ACK;
# must be an ACK after a 487
# or e.g. 404 from upstream server
xlog("L_INFO","ACK - t_check_trans \n");
route(RELAY);
exit;
} else {
# ACK without matching transaction ... ignore and discard
xlog("L_INFO","ACK without matching transaction \n");
exit;
}
}
}
route[RELAY] {
xlog("L_INFO", " ******** RELAY *******");
xlog("L_INFO", "RELAY - $rm to $si responding back to $su");
t_on_failure("FAILED_RELAY");
t_on_reply("MANAGE_REPLY");
if (is_method("INVITE"))
send_reply("300", "Multiple Choices");
exit;
}
INVITE sip:1@10.20.20.1:5060<http://sip:1@10.20.20.1:5060/> SIP/2.0
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3356440-1-0
SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3356440-1-0
(here I am testing a HTTP failure test case)
SIP/2.0 503 No Connection to HTTP API
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3356440-1-0
ACK sip:1@10.20.20.1:5060<http://sip:1@10.20.20.1:5060/> SIP/2.0
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3356440-1-0
But after this ACK, Kamailio sends:
SIP/2.0 500 I'm terribly sorry, server error occurred (1/TM)
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3356440-1-0
Logs are weird too (debug = 3)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: <core>
[core/parser/msg_parser.c:91]: get_hdr_field(): found end of header
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/receive.c:263]:
ksr_evrt_pre_routing(): event route core:pre-routing not defined
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/receive.c:474]:
receive_msg(): preparing to run routing scripts...
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} sl [sl_funcs.c:472]:
sl_filter_ACK(): SL local ACK found -> dropping it!
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/receive.c:635]:
receive_msg(): cleaning up
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: <core> [db_query.c:72]:
db_do_submit_query(): submitted query: delete from `dialog` where `hash_entry`=3272 AND
`hash_id`=10103, result 0
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: db_cluster [dbcl_api.c:663]:
db_cluster_use_table(): use table (dialog_vars) - cluster [k1]
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: db_cluster [dbcl_api.c:670]:
db_cluster_use_table(): set read table (dialog_vars) - cluster [k1] (9/0)
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: db_cluster [dbcl_api.c:680]:
db_cluster_use_table(): set write table (dialog_vars) - cluster [k1] (9/0)
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: db_cluster [dbcl_api.c:570]:
db_cluster_delete(): executing db cluster delete command
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: db_cluster [dbcl_api.c:571]:
db_cluster_delete(): round robin operation - cluster [k1] (9/0)
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: <core> [db_query.c:72]:
db_do_submit_query(): submitted query: delete from `dialog_vars` where `hash_entry`=3272
AND `hash_id`=10103, result 0
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: dialog [dlg_db_handler.c:759]:
remove_dialog_from_db(): callid was
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: tm [h_table.c:551]: tm_xdata_swap():
restore X/AVPs msg context from txdata
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: tm [t_reply.c:1782]:
cleanup_uac_timers(): RETR/FR timers reset
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: tm [t_reply.c:634]: _reply_light():
reply sent out - buf=0x7f4903fd57d0: SIP/2.0 500 I'm terr... shmem=0x7f48c27177a0:
SIP/2.0 500 I'm terr
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: tm [t_funcs.c:133]: put_on_wait(): put
T [0x7f48c271cda0] on wait
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: tm [t_reply.c:650]: _reply_light():
finished
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: http_async_client [async_http.h:153]:
free_async_query(): freeing query 0x7f48c27229b0
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: http_async_client [http_multi.c:661]:
check_multi_info(): reply: [428] HTTP/1.0 428 PRECONDITION REQUIRED#015#012Content-Type:
text/html; charset=utf-8#015#012Content-Length: 138#015#012Server: Werkzeug/2.0.3
Python/3.9.16#015#012Date: Mon, 23 Dec 2024 22:59:09 GMT#015#012#015#012<!DOCTYPE HTML
PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">#012<title>428 Precondition
Required</title>#012<h1>Precondition
Required</h1>#012<p>{}</p>#012 [312]
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: http_async_client [http_multi.c:668]:
check_multi_info(): cleaning up cell 0x7f48c2722d30
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: http_async_client [http_multi.c:673]:
check_multi_info(): Removing handle 0x7f48c2717e80
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: http_async_client [http_multi.c:150]:
event_cb(): last transfer done, kill timeout
Dec 23 22:59:39 kamailio1 kamailio[4060839]: DEBUG: tm [t_funcs.c:133]: put_on_wait(): put
T [0x7f48c271cda0] on wait
Dec 23 22:59:39 kamailio1 kamailio[4060839]: DEBUG: <core> [core/timer.c:555]:
timer_add_safe(): timer_add called on an active timer 0x7f48c271ce58 (0x7f48c2225bc0,
0x7f48c2225bc0), flags 201
Dec 23 22:59:39 kamailio1 kamailio[4060839]: DEBUG: tm [t_funcs.c:156]: put_on_wait():
transaction 0x7f48c271cda0 already on wait
Running same SIP Invite from SIPp but with test case where HTTP API returns a valid (200)
response, everything works fine!
Atenciosamente / Kind Regards / Cordialement / Un saludo,
Sérgio Charrua
On Mon, Dec 23, 2024 at 11:49 PM Ben Kaufman via sr-users
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> wrote:
Which log line do you get? Also note that both of your log lines say "Matched
transaction", but the condition is negated (it starts with an exclamation mark).
Also refer to the documentation for the function to see what happens when the ACK for a
negative reply is matched.
https://kamailio.org/docs/modules/5.8.x/modules/tm#tm.f.t_check_trans
Kaufman
Senior Voice Engineer
E: bkaufman@bcmone.com<mailto:bkaufman@bcmone.com>
SIP.US<http://sip.us/> Client Support: 800.566.9810 | SIPTRUNK Client Support:
800.250.6510 | Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us/>
[img]<https://www.siptrunk.com/>
[img]<https://www.flowroute.com/>
________________________________
From: Alexis Fidalgo via sr-users
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Sent: Monday, December 23, 2024 4:16 PM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Cc: Alexis Fidalgo <alzrck@gmail.com<mailto:alzrck@gmail.com>>
Subject: [SR-Users] Re: help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Yes, i’ve been reading it when you mentioned the loose_route and has_totag() in a previous
email.
if(is_method("ACK")){
if(!t_check_trans()){
xlog("L_INFO","AAAA: MATCHED TRANSACTION\n");
} else {
xlog("L_INFO","BBBB: MATCHED TRANSACTION\n");
}
exit;
}
(moving the exit; inside the else has same effect on my test)
On 23 Dec 2024, at 6:49 PM, Alex Balashov via sr-users
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> wrote:
Look very carefully at how negative ACKs are handled here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…
-- Alex
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
On Dec 23, 2024, at 4:19 pm, Alexis Fidalgo via
sr-users <sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
wrote:
Hello all, moving just a bit aside of the http and async_http.
After all the real useful and interesting thread on that topic what helped me, im facing
a problem i cant deal with and need a hint at least.
Scenario
INVITE -> Kamailio
on request_route
...
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080", "HTTP_REPLY");
}
…
Kamailio -> 100 - Trying
then
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
Kamailio -> 302 Redirect
ACK -> Kamailio
This last ACK, how can i read it and use it to terminate the transaction? because
Kamailio keeps transmitting the 302 message 3 more times until the transaction is finished
by a timer
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f4c3fcd35a0
(p:0x7f4c3fad85d0/n:0x7f4c3fad85d0)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f4c3fcd35a0
from timer.c:651
in request_route i have
if(is_method("ACK")){
if(!t_check_trans()){
t_release();
}
exit;
}
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristes…
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
6:21 p.m.
While I'm hardpressed to say exactly why, it does seem like your structure is a bit
odd.
You show this as in your route - is this also after checking for a to: tag? The decision
to send a 300 reply from within a route named "RELAY" after arming the failure
and onreply routes is awkward. Finally, although the exit at the end of route[RELAY] is
implied is it intended to be explicit if the method is INVITE? Adding curly braces there
may not be necessary, but it does improve readability.
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us/>
[img]<https://www.siptrunk.com/>
[img]<https://www.flowroute.com/>
________________________________
From: Sergio Charrua <sergio.charrua(a)voip.pt>
Sent: Monday, December 23, 2024 5:04 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: Alexis Fidalgo <alzrck(a)gmail.com>om>; Ben Kaufman <bkaufman(a)bcmone.com>
Subject: Re: [SR-Users] Re: help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Well, in my case I have:
route{
...
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
# no loose-route, but stateful ACK;
# must be an ACK after a 487
# or e.g. 404 from upstream server
xlog("L_INFO","ACK - t_check_trans \n");
route(RELAY);
exit;
} else {
# ACK without matching transaction ... ignore and discard
xlog("L_INFO","ACK without matching transaction \n");
exit;
}
}
}
route[RELAY] {
xlog("L_INFO", " ******** RELAY *******");
xlog("L_INFO", "RELAY - $rm to $si responding back to $su");
t_on_failure("FAILED_RELAY");
t_on_reply("MANAGE_REPLY");
if (is_method("INVITE"))
send_reply("300", "Multiple Choices");
exit;
}
INVITE sip:1@10.20.20.1:5060<http://sip:1@10.20.20.1:5060/> SIP/2.0
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3356440-1-0
SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3356440-1-0
(here I am testing a HTTP failure test case)
SIP/2.0 503 No Connection to HTTP API
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3356440-1-0
ACK sip:1@10.20.20.1:5060<http://sip:1@10.20.20.1:5060/> SIP/2.0
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3356440-1-0
But after this ACK, Kamailio sends:
SIP/2.0 500 I'm terribly sorry, server error occurred (1/TM)
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3356440-1-0
Logs are weird too (debug = 3)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: <core>
[core/parser/msg_parser.c:91]: get_hdr_field(): found end of header
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/receive.c:263]:
ksr_evrt_pre_routing(): event route core:pre-routing not defined
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/receive.c:474]:
receive_msg(): preparing to run routing scripts...
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} sl [sl_funcs.c:472]:
sl_filter_ACK(): SL local ACK found -> dropping it!
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/receive.c:635]:
receive_msg(): cleaning up
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: <core> [db_query.c:72]:
db_do_submit_query(): submitted query: delete from `dialog` where `hash_entry`=3272 AND
`hash_id`=10103, result 0
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: db_cluster [dbcl_api.c:663]:
db_cluster_use_table(): use table (dialog_vars) - cluster [k1]
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: db_cluster [dbcl_api.c:670]:
db_cluster_use_table(): set read table (dialog_vars) - cluster [k1] (9/0)
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: db_cluster [dbcl_api.c:680]:
db_cluster_use_table(): set write table (dialog_vars) - cluster [k1] (9/0)
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: db_cluster [dbcl_api.c:570]:
db_cluster_delete(): executing db cluster delete command
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: db_cluster [dbcl_api.c:571]:
db_cluster_delete(): round robin operation - cluster [k1] (9/0)
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: <core> [db_query.c:72]:
db_do_submit_query(): submitted query: delete from `dialog_vars` where `hash_entry`=3272
AND `hash_id`=10103, result 0
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: dialog [dlg_db_handler.c:759]:
remove_dialog_from_db(): callid was
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: tm [h_table.c:551]: tm_xdata_swap():
restore X/AVPs msg context from txdata
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: tm [t_reply.c:1782]:
cleanup_uac_timers(): RETR/FR timers reset
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: tm [t_reply.c:634]: _reply_light():
reply sent out - buf=0x7f4903fd57d0: SIP/2.0 500 I'm terr... shmem=0x7f48c27177a0:
SIP/2.0 500 I'm terr
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: tm [t_funcs.c:133]: put_on_wait(): put
T [0x7f48c271cda0] on wait
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: tm [t_reply.c:650]: _reply_light():
finished
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: http_async_client [async_http.h:153]:
free_async_query(): freeing query 0x7f48c27229b0
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: http_async_client [http_multi.c:661]:
check_multi_info(): reply: [428] HTTP/1.0 428 PRECONDITION REQUIRED#015#012Content-Type:
text/html; charset=utf-8#015#012Content-Length: 138#015#012Server: Werkzeug/2.0.3
Python/3.9.16#015#012Date: Mon, 23 Dec 2024 22:59:09 GMT#015#012#015#012<!DOCTYPE HTML
PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">#012<title>428 Precondition
Required</title>#012<h1>Precondition
Required</h1>#012<p>{}</p>#012 [312]
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: http_async_client [http_multi.c:668]:
check_multi_info(): cleaning up cell 0x7f48c2722d30
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: http_async_client [http_multi.c:673]:
check_multi_info(): Removing handle 0x7f48c2717e80
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: http_async_client [http_multi.c:150]:
event_cb(): last transfer done, kill timeout
Dec 23 22:59:39 kamailio1 kamailio[4060839]: DEBUG: tm [t_funcs.c:133]: put_on_wait(): put
T [0x7f48c271cda0] on wait
Dec 23 22:59:39 kamailio1 kamailio[4060839]: DEBUG: <core> [core/timer.c:555]:
timer_add_safe(): timer_add called on an active timer 0x7f48c271ce58 (0x7f48c2225bc0,
0x7f48c2225bc0), flags 201
Dec 23 22:59:39 kamailio1 kamailio[4060839]: DEBUG: tm [t_funcs.c:156]: put_on_wait():
transaction 0x7f48c271cda0 already on wait
Running same SIP Invite from SIPp but with test case where HTTP API returns a valid (200)
response, everything works fine!
Atenciosamente / Kind Regards / Cordialement / Un saludo,
Sérgio Charrua
On Mon, Dec 23, 2024 at 11:49 PM Ben Kaufman via sr-users
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> wrote:
Which log line do you get? Also note that both of your log lines say "Matched
transaction", but the condition is negated (it starts with an exclamation mark).
Also refer to the documentation for the function to see what happens when the ACK for a
negative reply is matched.
https://kamailio.org/docs/modules/5.8.x/modules/tm#tm.f.t_check_trans
Kaufman
Senior Voice Engineer
E: bkaufman@bcmone.com<mailto:bkaufman@bcmone.com>
SIP.US<http://sip.us/> Client Support: 800.566.9810 | SIPTRUNK Client Support:
800.250.6510 | Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us/>
[img]<https://www.siptrunk.com/>
[img]<https://www.flowroute.com/>
________________________________
From: Alexis Fidalgo via sr-users
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Sent: Monday, December 23, 2024 4:16 PM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Cc: Alexis Fidalgo <alzrck@gmail.com<mailto:alzrck@gmail.com>>
Subject: [SR-Users] Re: help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Yes, i’ve been reading it when you mentioned the loose_route and has_totag() in a previous
email.
if(is_method("ACK")){
if(!t_check_trans()){
xlog("L_INFO","AAAA: MATCHED TRANSACTION\n");
} else {
xlog("L_INFO","BBBB: MATCHED TRANSACTION\n");
}
exit;
}
(moving the exit; inside the else has same effect on my test)
On 23 Dec 2024, at 6:49 PM, Alex Balashov via sr-users
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> wrote:
Look very carefully at how negative ACKs are handled here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…
-- Alex
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
On Dec 23, 2024, at 4:19 pm, Alexis Fidalgo via
sr-users <sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
wrote:
Hello all, moving just a bit aside of the http and async_http.
After all the real useful and interesting thread on that topic what helped me, im facing
a problem i cant deal with and need a hint at least.
Scenario
INVITE -> Kamailio
on request_route
...
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080", "HTTP_REPLY");
}
…
Kamailio -> 100 - Trying
then
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
Kamailio -> 302 Redirect
ACK -> Kamailio
This last ACK, how can i read it and use it to terminate the transaction? because
Kamailio keeps transmitting the 302 message 3 more times until the transaction is finished
by a timer
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f4c3fcd35a0
(p:0x7f4c3fad85d0/n:0x7f4c3fad85d0)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f4c3fcd35a0
from timer.c:651
in request_route i have
if(is_method("ACK")){
if(!t_check_trans()){
t_release();
}
exit;
}
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristes…
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
6:28 p.m.
Also, I still wonder if your ACK URI matches the contact from your failure response.
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us/>
[img]<https://www.siptrunk.com/>
[img]<https://www.flowroute.com/>
________________________________
From: Sergio Charrua <sergio.charrua(a)voip.pt>
Sent: Monday, December 23, 2024 5:04 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: Alexis Fidalgo <alzrck(a)gmail.com>om>; Ben Kaufman <bkaufman(a)bcmone.com>
Subject: Re: [SR-Users] Re: help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Well, in my case I have:
route{
...
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
# no loose-route, but stateful ACK;
# must be an ACK after a 487
# or e.g. 404 from upstream server
xlog("L_INFO","ACK - t_check_trans \n");
route(RELAY);
exit;
} else {
# ACK without matching transaction ... ignore and discard
xlog("L_INFO","ACK without matching transaction \n");
exit;
}
}
}
route[RELAY] {
xlog("L_INFO", " ******** RELAY *******");
xlog("L_INFO", "RELAY - $rm to $si responding back to $su");
t_on_failure("FAILED_RELAY");
t_on_reply("MANAGE_REPLY");
if (is_method("INVITE"))
send_reply("300", "Multiple Choices");
exit;
}
INVITE sip:1@10.20.20.1:5060<http://sip:1@10.20.20.1:5060/> SIP/2.0
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3356440-1-0
SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3356440-1-0
(here I am testing a HTTP failure test case)
SIP/2.0 503 No Connection to HTTP API
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3356440-1-0
ACK sip:1@10.20.20.1:5060<http://sip:1@10.20.20.1:5060/> SIP/2.0
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3356440-1-0
But after this ACK, Kamailio sends:
SIP/2.0 500 I'm terribly sorry, server error occurred (1/TM)
Via: SIP/2.0/UDP 10.20.0.1:5060;branch=z9hG4bK-3356440-1-0
Logs are weird too (debug = 3)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: <core>
[core/parser/msg_parser.c:91]: get_hdr_field(): found end of header
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/receive.c:263]:
ksr_evrt_pre_routing(): event route core:pre-routing not defined
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/receive.c:474]:
receive_msg(): preparing to run routing scripts...
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} sl [sl_funcs.c:472]:
sl_filter_ACK(): SL local ACK found -> dropping it!
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
Dec 23 22:59:38 kamailio1 kamailio[4060752]: DEBUG: {1 1 ACK
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>} <core> [core/receive.c:635]:
receive_msg(): cleaning up
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: <core> [db_query.c:72]:
db_do_submit_query(): submitted query: delete from `dialog` where `hash_entry`=3272 AND
`hash_id`=10103, result 0
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: db_cluster [dbcl_api.c:663]:
db_cluster_use_table(): use table (dialog_vars) - cluster [k1]
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: db_cluster [dbcl_api.c:670]:
db_cluster_use_table(): set read table (dialog_vars) - cluster [k1] (9/0)
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: db_cluster [dbcl_api.c:680]:
db_cluster_use_table(): set write table (dialog_vars) - cluster [k1] (9/0)
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: db_cluster [dbcl_api.c:570]:
db_cluster_delete(): executing db cluster delete command
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: db_cluster [dbcl_api.c:571]:
db_cluster_delete(): round robin operation - cluster [k1] (9/0)
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: <core> [db_query.c:72]:
db_do_submit_query(): submitted query: delete from `dialog_vars` where `hash_entry`=3272
AND `hash_id`=10103, result 0
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: dialog [dlg_db_handler.c:759]:
remove_dialog_from_db(): callid was
1-3356440@10.20.0.1<mailto:1-3356440@10.20.0.1>
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: tm [h_table.c:551]: tm_xdata_swap():
restore X/AVPs msg context from txdata
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: tm [t_reply.c:1782]:
cleanup_uac_timers(): RETR/FR timers reset
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: tm [t_reply.c:634]: _reply_light():
reply sent out - buf=0x7f4903fd57d0: SIP/2.0 500 I'm terr... shmem=0x7f48c27177a0:
SIP/2.0 500 I'm terr
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: tm [t_funcs.c:133]: put_on_wait(): put
T [0x7f48c271cda0] on wait
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: tm [t_reply.c:650]: _reply_light():
finished
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: http_async_client [async_http.h:153]:
free_async_query(): freeing query 0x7f48c27229b0
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: http_async_client [http_multi.c:661]:
check_multi_info(): reply: [428] HTTP/1.0 428 PRECONDITION REQUIRED#015#012Content-Type:
text/html; charset=utf-8#015#012Content-Length: 138#015#012Server: Werkzeug/2.0.3
Python/3.9.16#015#012Date: Mon, 23 Dec 2024 22:59:09 GMT#015#012#015#012<!DOCTYPE HTML
PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">#012<title>428 Precondition
Required</title>#012<h1>Precondition
Required</h1>#012<p>{}</p>#012 [312]
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: http_async_client [http_multi.c:668]:
check_multi_info(): cleaning up cell 0x7f48c2722d30
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: http_async_client [http_multi.c:673]:
check_multi_info(): Removing handle 0x7f48c2717e80
Dec 23 22:59:38 kamailio1 kamailio[4060844]: DEBUG: http_async_client [http_multi.c:150]:
event_cb(): last transfer done, kill timeout
Dec 23 22:59:39 kamailio1 kamailio[4060839]: DEBUG: tm [t_funcs.c:133]: put_on_wait(): put
T [0x7f48c271cda0] on wait
Dec 23 22:59:39 kamailio1 kamailio[4060839]: DEBUG: <core> [core/timer.c:555]:
timer_add_safe(): timer_add called on an active timer 0x7f48c271ce58 (0x7f48c2225bc0,
0x7f48c2225bc0), flags 201
Dec 23 22:59:39 kamailio1 kamailio[4060839]: DEBUG: tm [t_funcs.c:156]: put_on_wait():
transaction 0x7f48c271cda0 already on wait
Running same SIP Invite from SIPp but with test case where HTTP API returns a valid (200)
response, everything works fine!
Atenciosamente / Kind Regards / Cordialement / Un saludo,
Sérgio Charrua
On Mon, Dec 23, 2024 at 11:49 PM Ben Kaufman via sr-users
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> wrote:
Which log line do you get? Also note that both of your log lines say "Matched
transaction", but the condition is negated (it starts with an exclamation mark).
Also refer to the documentation for the function to see what happens when the ACK for a
negative reply is matched.
https://kamailio.org/docs/modules/5.8.x/modules/tm#tm.f.t_check_trans
Kaufman
Senior Voice Engineer
E: bkaufman@bcmone.com<mailto:bkaufman@bcmone.com>
SIP.US<http://sip.us/> Client Support: 800.566.9810 | SIPTRUNK Client Support:
800.250.6510 | Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us/>
[img]<https://www.siptrunk.com/>
[img]<https://www.flowroute.com/>
________________________________
From: Alexis Fidalgo via sr-users
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Sent: Monday, December 23, 2024 4:16 PM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
Cc: Alexis Fidalgo <alzrck@gmail.com<mailto:alzrck@gmail.com>>
Subject: [SR-Users] Re: help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Yes, i’ve been reading it when you mentioned the loose_route and has_totag() in a previous
email.
if(is_method("ACK")){
if(!t_check_trans()){
xlog("L_INFO","AAAA: MATCHED TRANSACTION\n");
} else {
xlog("L_INFO","BBBB: MATCHED TRANSACTION\n");
}
exit;
}
(moving the exit; inside the else has same effect on my test)
On 23 Dec 2024, at 6:49 PM, Alex Balashov via sr-users
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> wrote:
Look very carefully at how negative ACKs are handled here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…
-- Alex
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
On Dec 23, 2024, at 4:19 pm, Alexis Fidalgo via
sr-users <sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>
wrote:
Hello all, moving just a bit aside of the http and async_http.
After all the real useful and interesting thread on that topic what helped me, im facing
a problem i cant deal with and need a hint at least.
Scenario
INVITE -> Kamailio
on request_route
...
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080", "HTTP_REPLY");
}
…
Kamailio -> 100 - Trying
then
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
Kamailio -> 302 Redirect
ACK -> Kamailio
This last ACK, how can i read it and use it to terminate the transaction? because
Kamailio keeps transmitting the 302 message 3 more times until the transaction is finished
by a timer
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f4c3fcd35a0
(p:0x7f4c3fad85d0/n:0x7f4c3fad85d0)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f4c3fcd35a0
from timer.c:651
in request_route i have
if(is_method("ACK")){
if(!t_check_trans()){
t_release();
}
exit;
}
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristes…
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to
sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
1
days inactive
2
days old
26 comments
4 participants
participants (4)
-
Alex Balashov -
Alexis Fidalgo -
Ben Kaufman -
Sergio Charrua