sipp icon indicating copy to clipboard operation
sipp copied to clipboard

Auto-Answer in UAS mode consider the first OPTIONS message to be a valid call-id

Open jimbojd72 opened this issue 7 years ago • 9 comments

The problem come from using the -aa option in sipp. The test I was using was a simple UAS that expect an INVITE from a remote side. I'm using the -aa option because sometimes, the remote side is sending unexpected OPTIONS that may make my test failed. Using option -aa prevent the error when receiving the OPTIONS in the middle of the call, but it doesn't prevent the error when it is the first message received. Since the OPTIONS is sometimes the first message received in the UAS scenario, it consider the call-id of the OPTIONS message to be the call-id for the subsequent INVITE, which is not really consistent, causing the test to fail with a timeout for the INVITE message.

I would have expect sipp to just answer with 200 OK to the OPTIONS message and completely ignore the call-id even if it is the first message received when -aa option is passed. After that, the INVITE would have been considered the valid call-id.

I am only doing one call with sipp so using <recv optional="true" label="end_of_scenario"/> is not really an option since I don't the test to pass when receiving a simple OPTIONS.

Thanks for you insight

Sipp version: SIPp v3.5.1-TLS-SCTP-PCAP-RTPSTREAM built Mar 27 2017, 09:59:05

Options messages: `OPTIONS sip:54.241.157.158:58730 SIP/2.0 Via: SIP/2.0/UDP 199.87.121.228:5060;branch=z9hG4bK2939754 From: sip:[email protected];tag=aa8626f3 To: sip:54.241.157.158:58730 Call-ID: [email protected] CSeq: 1 OPTIONS Max-Forwards: 70 Content-Length: 0

SIP/2.0 200 OK Via: SIP/2.0/UDP 199.87.121.228:5060;branch=z9hG4bK2939754 From: sip:[email protected];tag=aa8626f3 To: sip:54.241.157.158:58730 Call-ID: [email protected] CSeq: 1 OPTIONS Contact: sip:172.20.0.2:58730;transport=UDP Content-Length: 0 `

Sipp output 07:39:30 b"Resolving remote host '199.87.121.228'... Done.\n2018-01-24\t14:39:12.558960\t1516804752.558960: Call-Id: [email protected], receive timeout on message UAS:0 without label to jump to (ontimeout attribute): aborting call.\nsipp: There were more errors, enable -trace_err to log them.\n" 07:39:30 07:39:30 2018-01-24 14:39:12,573 - report - WARNING: 'screen_file' contents for 'uas_ua1' @ ('172.20.0.2', 58730): 07:39:30 ------------------------------ Scenario Screen -------- [1-9]: Change Screen -- 07:39:30 Timestamp: Wed Jan 24 14:39:12 2018 07:39:30 07:39:30 Port Total-time Total-calls Transport 07:39:30 58730 32.09 s 1 UDP 07:39:30 07:39:30 Call limit reached (-m 1), 0.000 s period 0 ms scheduler resolution 07:39:30 0 calls Peak was 1 calls, after 0 s 07:39:30 0 Running, 2 Paused, 0 Woken up 07:39:30 0 dead call msg (discarded) 07:39:30 1 open sockets 07:39:30 07:39:30 Messages Retrans Timeout Unexpected-Msg 07:39:30 ----------> INVITE 0 0 1 0 07:39:30 07:39:30 <---------- 100 0 0 07:39:30 <---------- 180 0 0 07:39:30 [ 200ms] Pause 0 0 07:39:30 <---------- 200 0 0 07:39:30 ----------> ACK E-RTD1 0 0 0 0 07:39:30 07:39:30 ----------> BYE 0 0 0 0 07:39:30 <---------- 200 0 0 07:39:30 ------- Waiting for active calls to end. Press [q] again to force exit. -------

Sipp command: '/usr/bin/sipp' '199.87.121.228':'5060' -i '172.20.0.2' -p '49311' -s '8000' -sf 'uac_ua0.xml' -recv_timeout '32000' -timeout '30' -cid_str '7b926cd8-3c42-4f00-bad1-b04f7f73ffe2-%u-%p@%s' -ap 'password' -au 'username' -r '40' -l '1' -m '1' -key local_number '7000' -key ua2_number '8001' -key user_agent 'Dockersipp' -key auth_username 'username' -key auth_password 'password' -key ua1_number '8000' -log_file '/tmp/uac_ua0_log_file' -screen_file '/tmp/uac_ua0_screen_file' -aa -trace_logs -trace_screen

UAS scenario `

<recv request="INVITE" crlf="true"/>

<send>
    <![CDATA[
  SIP/2.0 100 Trying
  [last_Via:]
  [last_From:]
  [last_To:];tag=[call_number]
  [last_Call-ID:]
  [last_CSeq:]
  User-Agent: [user_agent]
  Contact: <sip:[local_ip]:[local_port];transport=[transport]>
  Content-Length: [len]
]]>
</send>

<send>
    <![CDATA[
  SIP/2.0 180 Ringing
  [last_Via:]
  [last_From:]
  [last_To:];tag=[call_number]
  [last_Call-ID:]
  [last_CSeq:]
  User-Agent: [user_agent]
  Contact: <sip:[local_ip]:[local_port];transport=[transport]>
  Content-Length: [len]
]]>
</send>


<pause milliseconds="200"/>
<send>
    <![CDATA[
  SIP/2.0 200 OK
  [last_Via:]
  [last_From:]
  [last_To:];tag=[call_number]
  [last_Call-ID:]
  [last_CSeq:]
  User-Agent: [user_agent]
  Contact: <sip:[local_ip]:[local_port];transport=[transport]>
  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] [local_ip]
  t=0 0
  m=audio [media_port] RTP/AVP 8 0
]]>
</send>

<recv request="ACK" rtd="true" crlf="true">
</recv>

<recv request="BYE"/>

<label id="5"/>
<send>
    <![CDATA[
  SIP/2.0 200 OK
  [last_Via:]
  [last_From:]
  [last_To:]
  [last_Call-ID:]
  [last_CSeq:]
  User-Agent: [user_agent]
  Contact: <sip:[local_ip]:[local_port];transport=[transport]>
  Content-Length: [len]
]]>
</send>

`

jimbojd72 avatar Jan 24 '18 15:01 jimbojd72

I am also facing this issue. Anybody has any solution?

splivo avatar Aug 30 '18 06:08 splivo

Check the sipp command, if it has -m 1, then remove it and run again. It has worked for me.

splivo avatar Aug 30 '18 07:08 splivo

@jimbojd72 did you find any workaround for this?

I have a similar case and want to keep my -m 1

fnurglewitz avatar Aug 31 '18 14:08 fnurglewitz

Not really. I was doing two scenarios in a row on the same uac (REGISTER and then an INVITE tests), so I added a long pause and the end of the REGISTER scenario to have a chance to answer to my OPTION but it is far from perfect.

jimbojd72 avatar Sep 10 '18 15:09 jimbojd72

Hi there, is there any update on this ? I'm facing the same issue.
I need to keep the -m 1 since I need to terminate the SIP UAS after the call.

stadelmannj avatar May 21 '19 12:05 stadelmannj

No updates from me.

I understand your request, but I'm not sure off-hand how to fix this easily without resorting to horrible new options and code duplication.

And.. does auto-answer even work?

In the code I see this:

        } else if (creationMode == MODE_SERVER) {
            if (quitting >= 1) {
                CStat::globalStat(CStat::E_OUT_OF_CALL_MSGS);
                TRACE_MSG("Discarded message for new calls while quitting\n");
                return;
            }

            // Adding a new INCOMING call !
            main_scenario->stats->computeStat(CStat::E_CREATE_INCOMING_CALL);

I suspect you're not hitting the auto_answer code at all when in UAS mode.

Probably you'll want this bit before the MODE_SERVER?

            } else if (auto_answer &&
                       ((strstr(msg, "INFO") == msg) ||
                        (strstr(msg, "NOTIFY") == msg) ||
                        (strstr(msg, "OPTIONS") == msg) ||
                        (strstr(msg, "UPDATE") == msg))) {

wdoekes avatar May 21 '19 15:05 wdoekes

Removing -m 1 from SIPp command is worked for me

chandresh1-Plivo avatar Sep 22 '20 09:09 chandresh1-Plivo

Hello everyone, Is there any update on this ? I'm facing the same issue. Is there any workaround ? I would like that UAS responds to the OPTIONS (keepalive) without considering it as a valid call and I would like to stop my UAS after 1 INVITE processed. Thanks you for your help :-)

othomas-dev avatar Sep 27 '23 08:09 othomas-dev

Hi, I have the same issue here. If someone has another solution besides remove the '-m' option, please tell us.

Thanks for your help ;)

Drevix1 avatar Jul 22 '24 12:07 Drevix1