23 Dec
2024
23 Dec
'24
6:22 p.m.
Yes and it worked now.
<send>
<![CDATA[
ACK [next_url] SIP/2.0
Via: SIP/2.0/[transport]
[local_ip]:[local_port];branch=z9hG4bK-[pid]-[call_number]-0
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
Contact: [next_url]
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
No more retransmission and
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} tm [t_lookup.c:1565]: t_check_msg(): msg
(0x7f05de39d4d0) id=3/16 global id=2/16 T start=0xffffffffffffffff
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} tm [t_lookup.c:781]: t_lookup_request():
start searching: hash=31760, isACK=1
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} tm [t_lookup.c:483]: matching_3261():
RFC3261 transaction matched, tid=-43346-1-0
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} tm [t_lookup.c:998]: t_lookup_request():
transaction found (T=0x7f05d8e425a0)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} tm [t_lookup.c:1637]: t_check_msg(): msg
(0x7f05de39d4d0) id=3/16 global id=3/16 T end=0x7f05d8e425a0
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} tm [t_reply.c:1782]: cleanup_uac_timers():
RETR/FR timers reset
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} tm [t_funcs.c:133]: put_on_wait(): put T
[0x7f05d8e425a0] on wait
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/timer.c:555]:
timer_add_safe(): timer_add called on an active timer 0x7f05d8e42658 (0x7f05d8bdcb60,
0x7f05d8bdcb60), flags 201
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} tm [t_funcs.c:156]: put_on_wait():
transaction 0x7f05d8e425a0 already on wait
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/receive.c:531]:
receive_msg(): request-route executed in: 94 usec
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/usr_avp.c:654]:
destroy_avp_list(): destroying list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/xavp.c:630]:
xavp_destroy_list(): destroying xavp list (nil)
14(16) DEBUG: {1 1 ACK 1-43346(a)192.168.86.250} <core> [core/receive.c:635]:
receive_msg(): cleaning up
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f05d8e425a0
(p:0x7f05d8cf5eb0/n:0x7f05d8cf5eb0)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f05d8e425a0
from timer.c:651
thanks!!!
now ill run the comparison between http and async_http to compare.
On 23 Dec 2024, at 8:09 PM, Ben Kaufman
<bkaufman(a)bcmone.com> wrote:
I don't think you'll find a really good reason why SIPp does that, aside from
"that's how it was originally written", and sudden changes in behavior would
probably cause more problems than keeping it and using their method for off-setting the
counter.
The documentation defines it as a, "value which is a concatenation of magic cookie
(z9hG4bK) + call number + message index in scenario. An offset (like [branch-N]) can be
appended if you need to have the same branch value as a previous message." I think
it's actually magic cookie + PID + call number + message index, so you could omit the
message index, and just make it like this in every request:
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[z9hG4bK]-[pid]-[call_number]-0
And then only increment the suffix if you're actually doing a fork of the request..
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com <mailto:bkaufman@bcmone.com>
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
<https://www.sip.us/>
<https://www.siptrunk.com/>
<https://www.flowroute.com/>
From: Alexis Fidalgo via sr-users <sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>>
Sent: Monday, December 23, 2024 4:55 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>>
Cc: Alexis Fidalgo <alzrck(a)gmail.com <mailto:alzrck@gmail.com>>
Subject: [SR-Users] Re: help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
you’re right
for the ack the branch is built with
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
looks like sipp is increasing the branch last digit for any reason (im reading now why
this happen)
On 23 Dec 2024, at 7:33 PM, Alex Balashov via
sr-users <sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>>
wrote:
Why is the Via branch on the ACK different to that of the INVITE or the response?
See RFC 3261 § 17.1.1.3 ("Construction of the ACK Request"):
"The ACK MUST contain a single Via header field, and
this MUST be equal to the top Via header field of the original
request."
You have:
INVITE sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
SIP/2.0 302 Redirect
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
ACK sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-3
So, it's not being matched.
-- Alex
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
On Dec 23, 2024, at 5:14 pm, Alexis Fidalgo via
sr-users <sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>>
wrote:
request_route:
if(is_method("ACK")){
if(!t_check_trans()){
xlog("L_INFO","AAAA: MATCHED TRANSACTION\n"); }
else {
xlog("L_INFO","BBBB: MATCHED TRANSACTION\n");
}
exit;
}
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080 <http://nuc:8080/>",
"HTTP_REPLY");
}
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
append_branch("sip:1111@otherdomain.com:5060");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
pcap list
15 173.459633617 192.168.86.250 → 192.168.86.128 SIP/SDP 588 Request: INVITE
sip:123456@192.168.86.128:5060 |
16 173.460549905 192.168.86.128 → 192.168.86.250 SIP 344 Status: 100 Trying |
17 173.762804083 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
18 173.789493070 192.168.86.250 → 192.168.86.128 SIP 415 Request: ACK
sip:123456@192.168.86.128:5060 |
19 174.213115954 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
20 175.213132963 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
21 177.213136064 192.168.86.128 → 192.168.86.250 SIP 467 Status: 302 Redirect |
sipp trace dump
----------------------------------------------- 2024-12-23 19:10:01.820622
UDP message sent (546 bytes):
INVITE sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456 <sip:123456@192.168.86.128:5060>
Call-ID: 1-35646(a)192.168.86.250 <mailto:1-35646@192.168.86.250>
CSeq: 1 INVITE
Contact: sip:sipp@192.168.86.250:5060
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: 139
v=0
o=user1 53655765 2353687637 IN IP4 192.168.86.250
s=-
c=IN IP4 192.168.86.250
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
----------------------------------------------- 2024-12-23 19:10:01.847444
UDP message received [302] bytes :
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456 <sip:123456@192.168.86.128:5060>
Call-ID: 1-35646(a)192.168.86.250 <mailto:1-35646@192.168.86.250>
CSeq: 1 INVITE
Server: kamailio (5.8.4 (x86_64/linux))
Content-Length: 0
----------------------------------------------- 2024-12-23 19:10:02.169378
UDP message received [425] bytes :
SIP/2.0 302 Redirect
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-0
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456
<sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e0f89f75
Call-ID: 1-35646(a)192.168.86.250 <mailto:1-35646@192.168.86.250>
CSeq: 1 INVITE
Contact: <sip:1111@otherdomain.com:5060>, <sip:1111@otherdomain.com:5060>
Server: kamailio (5.8.4 (x86_64/linux))
Content-Length: 0
----------------------------------------------- 2024-12-23 19:10:02.169921
UDP message sent (373 bytes):
ACK sip:123456@192.168.86.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-35646-1-3
From: sipp <sip:sipp@192.168.86.250:5060>;tag=35646SIPpTag001
To: 123456
<sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-e0f89f75
Call-ID: 1-35646(a)192.168.86.250 <mailto:1-35646@192.168.86.250>
CSeq: 1 ACK
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
sipp br.xml
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<scenario name="Basic Sipstone UAC">
<!-- In client mode (sipp placing calls), the Call-ID MUST be -->
<!-- generated by sipp. To do so, use [call_id] keyword. -->
<send retrans="500">
<![CDATA[
INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[media_ip_type] [media_ip]
t=0 0
m=audio [media_port] RTP/AVP 0
a=rtpmap:0 PCMU/8000
]]>
</send>
<recv response="100" optional="true"></recv>
<!-- By adding rrs="true" (Record Route Sets), the route sets
-->
<!-- are saved and used for following messages sent. Useful to test -->
<!-- against stateful SIP proxies/B2BUAs. -->
<recv response="302" rtd="true">
</recv>
<!-- Packet lost can be simulated in any send/recv message by -->
<!-- by adding the 'lost = "10"'. Value can be [1-100] percent.
-->
<send>
<![CDATA[
ACK sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: [service] <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<!-- definition of the response time repartition table (unit is ms) -->
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
<!-- definition of the call length repartition table (unit is ms) -->
<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristes…
<https://evaristesys.com/>
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
On 23 Dec 2024, at 6:44 PM, Ben Kaufman
<bkaufman(a)bcmone.com <mailto:bkaufman@bcmone.com>> wrote:
Does your 3xx message have a Contact, and does that Contact URI match the RURI in your
ACK?
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com <mailto:bkaufman@bcmone.com>
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
From: Alexis Fidalgo via sr-users <sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>>
Sent: Monday, December 23, 2024 3:19 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>>
Cc: Alexis Fidalgo <alzrck(a)gmail.com <mailto:alzrck@gmail.com>>
Subject: [SR-Users] help on how to get ACK
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Hello all, moving just a bit aside of the http and async_http.
After all the real useful and interesting thread on that topic what helped me, im facing
a problem i cant deal with and need a hint at least.
Scenario
INVITE -> Kamailio
on request_route
...
if(is_method("INVITE")){
t_newtran();
http_async_query("http://nuc:8080 <http://nuc:8080/>",
"HTTP_REPLY");
}
…
Kamailio -> 100 - Trying
then
route[HTTP_REPLY] {
if ($http_ok) {
xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");
xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n");
t_reply(302,"Redirect");
} else {
xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n");
}
}
Kamailio -> 302 Redirect
ACK -> Kamailio
This last ACK, how can i read it and use it to terminate the transaction? because
Kamailio keeps transmitting the 302 message 3 more times until the transaction is finished
by a timer
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted.
buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3
42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f4c3fcd35a0
(p:0x7f4c3fad85d0/n:0x7f4c3fad85d0)
42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f4c3fcd35a0
from timer.c:651
in request_route i have
if(is_method("ACK")){
if(!t_check_trans()){
t_release();
}
exit;
}
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!