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]> 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:[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]
> 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]
> 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]
> 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]
> 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]> 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]
>>
>>
>>
>>
>> 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]>
>> Sent: Monday, December 23, 2024 3:19 PM
>> To: Kamailio (SER) - Users Mailing List <[email protected]>
>> Cc: Alexis Fidalgo <[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_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]
>> To unsubscribe send an email to [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!
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
__________________________________________________________
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!
