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 [email protected]} 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 [email protected]} tm [t_lookup.c:781]:
t_lookup_request(): start searching: hash=31760, isACK=1
14(16) DEBUG: {1 1 ACK [email protected]} tm [t_lookup.c:483]:
matching_3261(): RFC3261 transaction matched, tid=-43346-1-0
14(16) DEBUG: {1 1 ACK [email protected]} tm [t_lookup.c:998]:
t_lookup_request(): transaction found (T=0x7f05d8e425a0)
14(16) DEBUG: {1 1 ACK [email protected]} 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 [email protected]} tm [t_reply.c:1782]:
cleanup_uac_timers(): RETR/FR timers reset
14(16) DEBUG: {1 1 ACK [email protected]} tm [t_funcs.c:133]:
put_on_wait(): put T [0x7f05d8e425a0] on wait
14(16) DEBUG: {1 1 ACK [email protected]} <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 [email protected]} tm [t_funcs.c:156]:
put_on_wait(): transaction 0x7f05d8e425a0 already on wait
14(16) DEBUG: {1 1 ACK [email protected]} <core> [core/receive.c:531]:
receive_msg(): request-route executed in: 94 usec
14(16) DEBUG: {1 1 ACK [email protected]} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
14(16) DEBUG: {1 1 ACK [email protected]} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
14(16) DEBUG: {1 1 ACK [email protected]} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
14(16) DEBUG: {1 1 ACK [email protected]} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
14(16) DEBUG: {1 1 ACK [email protected]} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
14(16) DEBUG: {1 1 ACK [email protected]} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
14(16) DEBUG: {1 1 ACK [email protected]} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
14(16) DEBUG: {1 1 ACK [email protected]} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
14(16) DEBUG: {1 1 ACK [email protected]} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
14(16) DEBUG: {1 1 ACK [email protected]} <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 <[email protected]> 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: [email protected] <mailto:[email protected]>
>
>
>
>
>
> 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 <[email protected]
> <mailto:[email protected]>>
> Sent: Monday, December 23, 2024 4:55 PM
> To: Kamailio (SER) - Users Mailing List <[email protected]
> <mailto:[email protected]>>
> Cc: Alexis Fidalgo <[email protected] <mailto:[email protected]>>
> 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
> > <[email protected] <mailto:[email protected]>> 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:[email protected]: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:[email protected]: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
> >> <[email protected] <mailto:[email protected]>> 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:[email protected]: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:[email protected]: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:[email protected]: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:[email protected]:5060 SIP/2.0
> >> Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
> >> From: sipp <sip:[email protected]:5060>;tag=35646SIPpTag001
> >> To: 123456 <sip:[email protected]:5060>
> >> Call-ID: [email protected] <mailto:[email protected]>
> >> CSeq: 1 INVITE
> >> Contact: sip:[email protected]: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:[email protected]:5060>;tag=35646SIPpTag001
> >> To: 123456 <sip:[email protected]:5060>
> >> Call-ID: [email protected] <mailto:[email protected]>
> >> 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:[email protected]:5060>;tag=35646SIPpTag001
> >> To: 123456
> >> <sip:[email protected]:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e0f89f75
> >> Call-ID: [email protected] <mailto:[email protected]>
> >> CSeq: 1 INVITE
> >> Contact: <sip:[email protected]:5060>, <sip:[email protected]: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:[email protected]:5060 SIP/2.0
> >> Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-3
> >> From: sipp <sip:[email protected]:5060>;tag=35646SIPpTag001
> >> To: 123456
> >> <sip:[email protected]:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e0f89f75
> >> Call-ID: [email protected] <mailto:[email protected]>
> >> 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 <[email protected]
> >>> <mailto:[email protected]>> wrote:
> >>>
> >>> Does your 3xx message have a Contact, and does that Contact URI match the
> >>> RURI in your ACK?
> >>>
> >>> Kaufman
> >>> Senior Voice Engineer
> >>>
> >>>
> >>>
> >>> E: [email protected] <mailto:[email protected]>
> >>>
> >>>
> >>>
> >>>
> >>> 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 <[email protected]
> >>> <mailto:[email protected]>>
> >>> Sent: Monday, December 23, 2024 3:19 PM
> >>> To: Kamailio (SER) - Users Mailing List <[email protected]
> >>> <mailto:[email protected]>>
> >>> Cc: Alexis Fidalgo <[email protected] <mailto:[email protected]>>
> >>> 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 --
> >>> [email protected] <mailto:[email protected]>
> >>> To unsubscribe send an email to [email protected]
> >>> <mailto:[email protected]>
> >>> Important: keep the mailing list in the recipients, do not reply only to
> >>> the sender!
> >>
> >>
> >> __________________________________________________________
> >> Kamailio - Users Mailing List - Non Commercial Discussions --
> >> [email protected] <mailto:[email protected]>
> >> To unsubscribe send an email to [email protected]
> >> <mailto:[email protected]>
> >> 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%2Fevaristesys.com%2F&data=05%7C02%7Cbkaufman%40bcmone.com%7Cb702534980f4447fc1db08dd23a577a6%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C638705915794412561%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=azba6Wb1qcph%2BuhwfOuwEEwcLp4vNxwIWFznR16zBsE%3D&reserved=0
> > <https://evaristesys.com/>
> > Tel: +1-706-510-6800
> >
> > __________________________________________________________
> > Kamailio - Users Mailing List - Non Commercial Discussions --
> > [email protected] <mailto:[email protected]>
> > To unsubscribe send an email to [email protected]
> > <mailto:[email protected]>
> > Important: keep the mailing list in the recipients, do not reply only to
> > the sender!
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions --
> [email protected] <mailto:[email protected]>
> To unsubscribe send an email to [email protected]
> <mailto:[email protected]>
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
[email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the
sender!
