To be a bit more specific, the issue would appear to be that Kamailio is not 
correlating the ACK with the transaction.   Compare the ACK sent by Asterisk to 
the ACK sent by SIPp to see what is wrong with the SIPp ACK.


From: Sergio Charrua <[email protected]>
Sent: Monday, May 6, 2024 10:39 AM
To: Ben Kaufman <[email protected]>
Cc: Kamailio (SER) - Users Mailing List <[email protected]>
Subject: Re: [SR-Users] Retransmission behaviour after 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.

Thanks Ben1

that did not make it!
Just to be clear, there is no UAS scenario for SIPp running. The call is 
generated by SIPp scenario, in "UAC mode", to Kamailio and Kamailio will reply 
back to the originating SIPp instance with a 300 Multiple Choices message. 
Setting the "rrs" attribute in the "recv" element doesn't work.
As for next_url, it did not help either....


Sérgio Charrua

On Mon, May 6, 2024 at 3:46 PM Ben Kaufman 
<[email protected]<mailto:[email protected]>> wrote:
SIPp’s syntax for handling record route and setting ACK request lines correctly 
kinda sucks.


Try setting `rrs` in your `recv` element 
(https://sipp.readthedocs.io/en/latest/scenarios/ownscenarios.html?highlight=rrs#list-of-commands-with-their-attributes),
 and then use `next_url` as the contact in your ACK:  
(https://sipp.readthedocs.io/en/latest/scenarios/keywords.html#next-url)


Kaufman


From: Sergio Charrua via sr-users 
<[email protected]<mailto:[email protected]>>
Sent: Monday, May 6, 2024 6:57 AM
To: Kamailio (SER) - Users Mailing List 
<[email protected]<mailto:[email protected]>>
Cc: Sergio Charrua <[email protected]<mailto:[email protected]>>
Subject: [SR-Users] Retransmission behaviour after 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 all!

I'm testing some redirect scenarios with Kamailio 5.7.4 and using Astterisk 13 
and SIPp for unit testing.

The kamailio's script is simple and uses TM, HTTP_ASYNC_MODULE, JSONRPC, 
JANSSON, RTJSON and XLog modules.

Request route is simple:
request_route {

  route(HANDLE_OPTIONS);
  route(HANDLE_RETRANS);
  route(HANDLE_CANCEL);
  route(REQINIT);
  route(HANDLE_INVITE);

}

where HANDLE_RETRANS is:

route[HANDLE_RETRANS]{
        # handle retransmissions
        xlog("L_INFO","HANDLE_RETRANS - message type is $mt for method $rm");
        if (!is_method("ACK")) {
                if(t_precheck_trans()) {
                        xlog("L_INFO","HANDLE_RETRANS - Precheck Trans");
                        t_check_trans();
                        xlog("L_INFO", "HANDLE_RETRANS - Exiting after 
Retransmission check - method $rm");
                        exit;
                }
                xlog("L_INFO","HANDLE_RETRANS - Check Trans");
                t_check_trans();
        }
}


and HANDLE INVITE is:

route[HANDLE_INVITE]{
        if (is_method("INVITE"))
        {
                xlog("L_INFO","MAIN - calling TO_CARRIER");
                setflag(FLT_ACC);
                route(TO_CARRIER);
                exit;
        }
}

The HTTP requests call a REST API returning a JSON object, that is iterated and 
produces a CONTACT header containing multiple choices using the append_branch() 
command.
The RELAY route is :

route[RELAY] {
  # Sends a 300 Multiple Choices back to the proxy that requested the routing 
lookup
  xlog("L_INFO","REPLY_302 - send reply");
  send_reply("300", "Multiple Choices");
  xlog("L_INFO","REPLY_302 - exit");
  exit;
}

Which returns indeed a Contact header with multiple contact choices.

When using Asterisk to originate a call to Kamailio, the SIP call flow is as 
follows and terminates (SNGrep and TCPDump do not detect anything else):

SRC                                         DST
        INVITE (SDP)
 ──────────────────────────>
  100 trying -- your call is
 <──────────────────────────
    300 Multiple Choices
 <──────────────────────────
             ACK
 ──────────────────────────>

However when using SIPp I get some retransmissions after the final ACK.
SRC                                         DST
        INVITE (SDP)
 ──────────────────────────>
  100 trying -- your call is
 <──────────────────────────
    300 Multiple Choices
 <──────────────────────────
             ACK
 ──────────────────────────>
    300 Multiple Choices
 <<<────────────────────────
    300 Multiple Choices
 <<<────────────────────────
    300 Multiple Choices
 <<<────────────────────────

SIPp scenario is :
<?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" start_rtd="true" rrs="true">
<![CDATA[
INVITE sip:[call_number]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
Max-Forwards: 70
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[call_number]
To: <sip:[call_number]@[remote_ip]:[remote_port]>
Contact: sip:sipp@[local_ip]:[local_port];transport=[transport]>
Call-ID: [call_id]
CSeq: 102 INVITE
User-Agent: SIPp
Supported: replaces, timer
Content-Type: application/sdp
Subject: Performance Test
Session-Expires: 3600;refresher=uas
Content-Length: [len]

v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=SIPp
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" rss="true"> </recv>

<recv response="300" rtd="true" rss="true">
    <action>
      <ereg regexp="\&lt;([a-zA-Z0-9@.=;]+)[^&gt;]+"
            search_in="hdr"
            header="Contact: "
            assign_to="1"/>
      <log message="INFO: 300 Contact Header: [$1]" />
      <exec command="echo [$1] >> ./300_ContactHeader.txt" />
    </action>
    <action>
      <ereg 
regexp="sip:.*@([0-9A-Za-z\.]+):([0-9]+);transport=([A-Z]+)<sip:.*@([0-9A-Za-z\.%5d+):(%5b0-9%5d+);transport=(%5bA-Z%5d+)>"
 search_in="hdr" header="Contact:" check_it="true" 
assign_to="dummy,host,port,transport" />
    </action>
</recv>

<!-- Reference variables="dummy" /-->

  <!-- Send ACK for 180 Ringing
  ACK sip:[service]@[remote_ip]:[remote_port] SIP/2.0 -->
<send rrs="true">
<![CDATA[
ACK sip:[call_number]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
Max-Forwards: 70
From: <sip:sipp@[local_ip]:[local_port]>;tag=[call_number]
To: <sip:[call_number]@[remote_ip]:[remote_port]>[peer_tag_param]
Contact: <sip:sipp@[local_ip]:[local_port]>
Call-ID: [call_id]
CSeq: 102 ACK
User-Agent: SIPp
Content-Length: 0
]]>
</send>

<!--  definition of the response time repartition table (unit is ms)    -->
<!-- ResponseTimeRepartition value="10, 50, 100, 150, 200, 500, 1000"/ -->
</scenario>



The question is : is there anything wrong with my kamailio script? or with SIPp 
scenario? why does kamailio have different behaviours between Asterisk and SIPp?
Any option to disable retransmissions on Kamailio ? (using UDP)

Thanks in advance,


Sérgio Charrua


__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

Reply via email to