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@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@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 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 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 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@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

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 Sent: Monday, December 23, 2024 3:19 PM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Alexis Fidalgo 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 To unsubscribe send an email to 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 To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!

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

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 Sent: Monday, December 23, 2024 4:55 PM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Alexis Fidalgo 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 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@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@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 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 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 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@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

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 Sent: Monday, December 23, 2024 3:19 PM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Alexis Fidalgo 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 To unsubscribe send an email to 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 To unsubscribe send an email to 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%2Fevaristesy...https://evaristesys.com/ Tel: +1-706-510-6800

---

Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to 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 To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!

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@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 Sent: Monday, December 23, 2024 5:22 PM To: Ben Kaufman bkaufman@bcmone.com Cc: Kamailio (SER) - Users Mailing List 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.

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@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@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@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@192.168.86.250} tm [t_lookup.c:998]: t_lookup_request(): transaction found (T=0x7f05d8e425a0) 14(16) DEBUG: {1 1 ACK 1-43346@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@192.168.86.250} tm [t_reply.c:1782]: cleanup_uac_timers(): RETR/FR timers reset 14(16) DEBUG: {1 1 ACK 1-43346@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@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@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@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@192.168.86.250} <core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil) 14(16) DEBUG: {1 1 ACK 1-43346@192.168.86.250} <core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil) 14(16) DEBUG: {1 1 ACK 1-43346@192.168.86.250} <core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil) 14(16) DEBUG: {1 1 ACK 1-43346@192.168.86.250} <core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil) 14(16) DEBUG: {1 1 ACK 1-43346@192.168.86.250} <core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil) 14(16) DEBUG: {1 1 ACK 1-43346@192.168.86.250} <core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil) 14(16) DEBUG: {1 1 ACK 1-43346@192.168.86.250} <core> [core/xavp.c:630]: xavp_destroy_list(): destroying xavp list (nil) 14(16) DEBUG: {1 1 ACK 1-43346@192.168.86.250} <core> [core/xavp.c:630]: xavp_destroy_list(): destroying xavp list (nil) 14(16) DEBUG: {1 1 ACK 1-43346@192.168.86.250} <core> [core/xavp.c:630]: xavp_destroy_list(): destroying xavp list (nil) 14(16) DEBUG: {1 1 ACK 1-43346@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@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.commailto: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.orgmailto:sr-users@lists.kamailio.org> Sent: Monday, December 23, 2024 4:55 PM To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> Cc: Alexis Fidalgo <alzrck@gmail.commailto: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.orgmailto: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

...

On Dec 23, 2024, at 5:14 pm, Alexis Fidalgo via sr-users <sr-users@lists.kamailio.orgmailto: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:8080http://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.250mailto: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.250mailto: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.250mailto: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.250mailto: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>

...

On 23 Dec 2024, at 6:44 PM, Ben Kaufman <bkaufman@bcmone.commailto: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.commailto: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.orgmailto:sr-users@lists.kamailio.org> Sent: Monday, December 23, 2024 3:19 PM To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> Cc: Alexis Fidalgo <alzrck@gmail.commailto: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:8080http://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.orgmailto:sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.orgmailto: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.orgmailto:sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.orgmailto: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%2Fevaristesy...https://evaristesys.com/ Tel: +1-706-510-6800

---

Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.orgmailto: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.orgmailto:sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.orgmailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!

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@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@lists.kamailio.org Sent: Monday, December 23, 2024 4:33 PM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Alex Balashov abalashov@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@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@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 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 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 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@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

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 Sent: Monday, December 23, 2024 3:19 PM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Alexis Fidalgo 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 To unsubscribe send an email to 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 To unsubscribe send an email to 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%2Fevaristesy...https://evaristesys.com/ Tel: +1-706-510-6800

__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!

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_expe...

Kaufman Senior Voice Engineer

E: 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: Sergio Charrua sergio.charrua@voip.pt Sent: Monday, December 23, 2024 4:14 PM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Alexis Fidalgo alzrck@gmail.com; Ben Kaufman bkaufman@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:5060http://10.20.0.1:5060/ 10.20.20.1:5060http://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:5060http://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:5060http://sip:sipp@10.20.0.1:5060/>;tag=1 To: <sip:1@10.20.20.1:5060http://sip:1@10.20.20.1:5060/> Call-ID: 1-3147164@10.20.0.1mailto: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:5060http://sip:sipp@10.20.0.1:5060/>;tag=1 To: <sip:1@10.20.20.1:5060http://sip:1@10.20.20.1:5060/> Call-ID: 1-3147164@10.20.0.1mailto: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:5060http://sip:sipp@10.20.0.1:5060/>;tag=1 To: <sip:1@10.20.20.1:5060http://sip:1@10.20.20.1:5060/>;tag=d360f2f6fe5d9cd3912155e609771cc6-f406b8d3 Call-ID: 1-3147164@10.20.0.1mailto: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%3Ehttp://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:5060http://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:5060http://sip:sipp@10.20.0.1:5060/>;tag=1 To: <sip:1@10.20.20.1:5060http://sip:1@10.20.20.1:5060/>;tag=d360f2f6fe5d9cd3912155e609771cc6-f406b8d3 Contact: <sip:sipp@10.20.0.1:5060http://sip:sipp@10.20.0.1:5060/> Call-ID: 1-3147164@10.20.0.1mailto: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.orgmailto: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.commailto:bkaufman@bcmone.com

SIP.UShttp://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.orgmailto:sr-users@lists.kamailio.org> Sent: Monday, December 23, 2024 3:19 PM To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> Cc: Alexis Fidalgo <alzrck@gmail.commailto: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.orgmailto:sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.orgmailto: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.orgmailto:sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.orgmailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!

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@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@lists.kamailio.org Sent: Tuesday, December 24, 2024 11:02 AM To: sr-users@lists.kamailio.org sr-users@lists.kamailio.org Cc: Alex Balashov abalashov@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@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_expe...

Kaufman Senior Voice Engineer

E: 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: Sergio Charrua sergio.charrua@voip.pt Sent: Monday, December 23, 2024 4:14 PM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Alexis Fidalgo alzrck@gmail.com; Ben Kaufman bkaufman@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:5060http://10.20.0.1:5060/ 10.20.20.1:5060http://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:5060http://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:5060http://sip:sipp@10.20.0.1:5060/>;tag=1 To: <sip:1@10.20.20.1:5060http://sip:1@10.20.20.1:5060/> Call-ID: 1-3147164@10.20.0.1mailto: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:5060http://sip:sipp@10.20.0.1:5060/>;tag=1 To: <sip:1@10.20.20.1:5060http://sip:1@10.20.20.1:5060/> Call-ID: 1-3147164@10.20.0.1mailto: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:5060http://sip:sipp@10.20.0.1:5060/>;tag=1 To: <sip:1@10.20.20.1:5060http://sip:1@10.20.20.1:5060/>;tag=d360f2f6fe5d9cd3912155e609771cc6-f406b8d3 Call-ID: 1-3147164@10.20.0.1mailto: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%3Ehttp://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:5060http://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:5060http://sip:sipp@10.20.0.1:5060/>;tag=1 To: <sip:1@10.20.20.1:5060http://sip:1@10.20.20.1:5060/>;tag=d360f2f6fe5d9cd3912155e609771cc6-f406b8d3 Contact: <sip:sipp@10.20.0.1:5060http://sip:sipp@10.20.0.1:5060/> Call-ID: 1-3147164@10.20.0.1mailto: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.orgmailto: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.commailto:bkaufman@bcmone.com

SIP.UShttp://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.orgmailto:sr-users@lists.kamailio.org> Sent: Monday, December 23, 2024 3:19 PM To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> Cc: Alexis Fidalgo <alzrck@gmail.commailto: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.orgmailto:sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.orgmailto: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.orgmailto:sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.orgmailto: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 To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!

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 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@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 To unsubscribe send an email to 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://evaristesys.com Tel: +1-706-510-6800

---

Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!

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] - 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} <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} <core> [core/receive.c:474]: receive_msg(): preparing to run routing scripts... 10(12) DEBUG: {1 1 ACK 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} *** 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} *** 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} *** 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} *** 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} *** 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} 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} 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} 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} tm [t_lookup.c:981]: t_lookup_request(): no transaction found 10(12) DEBUG: {1 1 ACK 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} *** 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} <script>: >>>>>>> NOT MATCHED 10(12) exec: {1 1 ACK 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} <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} <core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil) 10(12) DEBUG: {1 1 ACK 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} <core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil) 10(12) DEBUG: {1 1 ACK 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} <core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil) 10(12) DEBUG: {1 1 ACK 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} <core> [core/xavp.c:630]: xavp_destroy_list(): destroying xavp list (nil) 10(12) DEBUG: {1 1 ACK 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} <core> [core/xavp.c:630]: xavp_destroy_list(): destroying xavp list (nil) 10(12) DEBUG: {1 1 ACK 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_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 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 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 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 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 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 https://www.sip.us/ https://www.siptrunk.com/ 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.com... 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@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%2Fevaristesy... https://evaristesys.com/ 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!

---

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!

and “exit;” if enough to finish it (if matched) ?

On 23 Dec 2024, at 7:52 PM, Ben Kaufman bkaufman@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 https://www.sip.us/ https://www.siptrunk.com/ 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 https://www.sip.us/ https://www.siptrunk.com/ 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.com... 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@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%2Fevaristesy... https://evaristesys.com/ 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!

---

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!

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@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@voip.pt Sent: Monday, December 23, 2024 5:04 PM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Alexis Fidalgo alzrck@gmail.com; Ben Kaufman bkaufman@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:5060http://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:5060http://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.1mailto: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.1mailto: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.1mailto: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.1mailto: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.1mailto: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.1mailto: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.1mailto: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.1mailto: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.1mailto: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.1mailto: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.1mailto: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.1mailto: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.1mailto: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.1mailto: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.orgmailto: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.commailto:bkaufman@bcmone.com

SIP.UShttp://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.orgmailto:sr-users@lists.kamailio.org> Sent: Monday, December 23, 2024 4:16 PM To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> Cc: Alexis Fidalgo <alzrck@gmail.commailto: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.orgmailto: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.com...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@lists.kamailio.orgmailto: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.orgmailto:sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.orgmailto: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%2Fevaristesy...https://evaristesys.com/ Tel: +1-706-510-6800

---

Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.orgmailto: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.orgmailto:sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.orgmailto: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.orgmailto:sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.orgmailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!

Also, I still wonder if your ACK URI matches the contact from your failure response.

Kaufman Senior Voice Engineer

E: 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: Sergio Charrua sergio.charrua@voip.pt Sent: Monday, December 23, 2024 5:04 PM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Alexis Fidalgo alzrck@gmail.com; Ben Kaufman bkaufman@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:5060http://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:5060http://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.1mailto: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.1mailto: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.1mailto: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.1mailto: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.1mailto: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.1mailto: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.1mailto: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.1mailto: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.1mailto: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.1mailto: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.1mailto: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.1mailto: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.1mailto: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.1mailto: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.orgmailto: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.commailto:bkaufman@bcmone.com

SIP.UShttp://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.orgmailto:sr-users@lists.kamailio.org> Sent: Monday, December 23, 2024 4:16 PM To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> Cc: Alexis Fidalgo <alzrck@gmail.commailto: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.orgmailto: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.com...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@lists.kamailio.orgmailto: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.orgmailto:sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.orgmailto: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%2Fevaristesy...https://evaristesys.com/ Tel: +1-706-510-6800

---

Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.orgmailto: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.orgmailto:sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.orgmailto: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.orgmailto:sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.orgmailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!