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.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:55 PM To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org> Cc: Alexis Fidalgo <alzrck@gmail.com mailto:alzrck@gmail.com> Subject: [SR-Users] Re: help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
you’re right
for the ack the branch is built with
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
looks like sipp is increasing the branch last digit for any reason (im reading now why this happen)
On 23 Dec 2024, at 7:33 PM, Alex Balashov via sr-users <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org> wrote:
Why is the Via branch on the ACK different to that of the INVITE or the response?
See RFC 3261 § 17.1.1.3 ("Construction of the ACK Request"):
"The ACK MUST contain a single Via header field, and this MUST be equal to the top Via header field of the original request."
You have:
INVITE sip:123456@192.168.86.128:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
SIP/2.0 302 Redirect Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
ACK sip:123456@192.168.86.128:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-3
So, it's not being matched.
-- Alex
On Dec 23, 2024, at 5:14 pm, Alexis Fidalgo via sr-users <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org> wrote:
request_route: if(is_method("ACK")){ if(!t_check_trans()){ xlog("L_INFO","AAAA: MATCHED TRANSACTION\n"); } else { xlog("L_INFO","BBBB: MATCHED TRANSACTION\n"); } exit; }
if(is_method("INVITE")){ t_newtran(); http_async_query("http://nuc:8080 http://nuc:8080/", "HTTP_REPLY"); }
route[HTTP_REPLY] { if ($http_ok) { xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n"); xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n"); append_branch("sip:1111@otherdomain.com:5060"); t_reply(302,"Redirect"); } else { xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n"); } }
pcap list
15 173.459633617 192.168.86.250 → 192.168.86.128 SIP/SDP 588 Request: INVITE sip:123456@192.168.86.128:5060 | 16 173.460549905 192.168.86.128 → 192.168.86.250 SIP 344 Status: 100 Trying | 17 173.762804083 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect | 18 173.789493070 192.168.86.250 → 192.168.86.128 SIP 415 Request: ACK sip:123456@192.168.86.128:5060 | 19 174.213115954 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect | 20 175.213132963 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect | 21 177.213136064 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
sipp trace dump
----------------------------------------------- 2024-12-23 19:10:01.820622 UDP message sent (546 bytes):
INVITE sip:123456@192.168.86.128:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0 From: sipp sip:sipp@192.168.86.250:5060;tag=35646SIPpTag001 To: 123456 sip:123456@192.168.86.128:5060 Call-ID: 1-35646@192.168.86.250 mailto:1-35646@192.168.86.250 CSeq: 1 INVITE Contact: sip:sipp@192.168.86.250:5060 Max-Forwards: 70 Subject: Performance Test Content-Type: application/sdp Content-Length: 139
v=0 o=user1 53655765 2353687637 IN IP4 192.168.86.250 s=- c=IN IP4 192.168.86.250 t=0 0 m=audio 6000 RTP/AVP 0 a=rtpmap:0 PCMU/8000
----------------------------------------------- 2024-12-23 19:10:01.847444 UDP message received [302] bytes :
SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0 From: sipp sip:sipp@192.168.86.250:5060;tag=35646SIPpTag001 To: 123456 sip:123456@192.168.86.128:5060 Call-ID: 1-35646@192.168.86.250 mailto:1-35646@192.168.86.250 CSeq: 1 INVITE Server: kamailio (5.8.4 (x86_64/linux)) Content-Length: 0
----------------------------------------------- 2024-12-23 19:10:02.169378 UDP message received [425] bytes :
SIP/2.0 302 Redirect Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0 From: sipp sip:sipp@192.168.86.250:5060;tag=35646SIPpTag001 To: 123456 sip:123456@192.168.86.128:5060;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e0f89f75 Call-ID: 1-35646@192.168.86.250 mailto:1-35646@192.168.86.250 CSeq: 1 INVITE Contact: sip:1111@otherdomain.com:5060, sip:1111@otherdomain.com:5060 Server: kamailio (5.8.4 (x86_64/linux)) Content-Length: 0
----------------------------------------------- 2024-12-23 19:10:02.169921 UDP message sent (373 bytes):
ACK sip:123456@192.168.86.128:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-3 From: sipp sip:sipp@192.168.86.250:5060;tag=35646SIPpTag001 To: 123456 sip:123456@192.168.86.128:5060;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e0f89f75 Call-ID: 1-35646@192.168.86.250 mailto:1-35646@192.168.86.250 CSeq: 1 ACK Max-Forwards: 70 Subject: Performance Test Content-Length: 0
sipp br.xml
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<scenario name="Basic Sipstone UAC"> <!-- In client mode (sipp placing calls), the Call-ID MUST be --> <!-- generated by sipp. To do so, use [call_id] keyword. --> <send retrans="500"> <![CDATA[
INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number] To: [service] <sip:[service]@[remote_ip]:[remote_port]> Call-ID: [call_id] CSeq: 1 INVITE Contact: sip:sipp@[local_ip]:[local_port] Max-Forwards: 70 Subject: Performance Test Content-Type: application/sdp Content-Length: [len] v=0 o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip] s=- c=IN IP[media_ip_type] [media_ip] t=0 0 m=audio [media_port] RTP/AVP 0 a=rtpmap:0 PCMU/8000]]>
</send>
<recv response="100" optional="true"></recv>
<!-- By adding rrs="true" (Record Route Sets), the route sets -->
<!-- are saved and used for following messages sent. Useful to test -->
<!-- against stateful SIP proxies/B2BUAs. -->
<recv response="302" rtd="true"> </recv>
<!-- Packet lost can be simulated in any send/recv message by -->
<!-- by adding the 'lost = "10"'. Value can be [1-100] percent. -->
<send> <![CDATA[
ACK sip:[service]@[remote_ip]:[remote_port] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number] To: [service] <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param] Call-ID: [call_id] CSeq: 1 ACK Max-Forwards: 70 Subject: Performance Test Content-Length: 0]]>
</send>
<!-- definition of the response time repartition table (unit is ms) -->
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
<!-- definition of the call length repartition table (unit is ms) -->
<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
On 23 Dec 2024, at 6:44 PM, Ben Kaufman <bkaufman@bcmone.com mailto:bkaufman@bcmone.com> wrote:
Does your 3xx message have a Contact, and does that Contact URI match the RURI in your ACK?
Kaufman Senior Voice Engineer
E: bkaufman@bcmone.com mailto:bkaufman@bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 | Flowroute Client Support: 855.356.9768
From: Alexis Fidalgo via sr-users <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org> Sent: Monday, December 23, 2024 3:19 PM To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org> Cc: Alexis Fidalgo <alzrck@gmail.com mailto:alzrck@gmail.com> Subject: [SR-Users] help on how to get ACK CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hello all, moving just a bit aside of the http and async_http.
After all the real useful and interesting thread on that topic what helped me, im facing a problem i cant deal with and need a hint at least.
Scenario
INVITE -> Kamailio
on request_route ... if(is_method("INVITE")){ t_newtran(); http_async_query("http://nuc:8080 http://nuc:8080/", "HTTP_REPLY"); } …
Kamailio -> 100 - Trying
then
route[HTTP_REPLY] { if ($http_ok) { xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n"); xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n"); t_reply(302,"Redirect"); } else { xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n"); } }
Kamailio -> 302 Redirect ACK -> Kamailio
This last ACK, how can i read it and use it to terminate the transaction? because Kamailio keeps transmitting the 302 message 3 more times until the transaction is finished by a timer
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted. buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3 42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted. buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3 42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted. buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3 42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f4c3fcd35a0 (p:0x7f4c3fad85d0/n:0x7f4c3fad85d0) 42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f4c3fcd35a0 from timer.c:651
in request_route i have
if(is_method("ACK")){ if(!t_check_trans()){ t_release(); } exit; }
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org mailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
-- 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!