Re: [Sipp-users] while expecting '400' (index 1), received 'SIP/2.0 400 Bad Request

[Michelle K. <she...@ho...>]

Thanks for explaining this, yes this is what I need to test
to ensure that the receiving party sends the correct response. I am
implementing torture test as per rfc 4475.


M


Date: Tue, 11 Oct 2011 00:01:19 +0900
Subject: Re: [Sipp-users] while expecting '400' (index 1), received 'SIP/2.0 400 Bad Request
From: may...@gm...
To: she...@ho...
CC: sip...@li...


On Mon, Oct 10, 2011 at 11:24 PM, Michelle Kearney <she...@ho...> wrote:






Hi Takeshi,

Thanks for your quick response.
I am running SIPp3.2.

The full scenario is:
<?xml version="1.0" encoding="ISO-8859-1" ?>

<!-- Start Line and CSeq Method Mismatch   -->


<scenario name="CALLCDNSM_ver1">

  <send retrans="500">
        <![CDATA[
                OPTIONS sip:us...@ex... SIP/2.0

                To: sip:j....@ex...
                From: sip:ca...@ex...;tag=34525

                Max-Forwards: 6
                Call-ID: mismatch01.dj0234sxdfl3///[call_id]
                CSeq: 8 INVITE
                Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
                l: 0

        ]]>
  </send>

  
  <!-- Recveive Response 400 Bad Request -->
  <recv response="400">
        <action>
                <log message="[timestamp] -  Call-ID [call_id]:  - 400 Bad Request"/>

        </action>
  </recv>

</scenario>



In then send command there is a deliberate mismatch between
the OPTIONS and the INVITE so the receiving element will respond with a 400 bad
request.
I was able to recreate the problem using your scenario:

2011-10-10      23:53:43:384    1318258423.384310: Aborting call on unexpected message for Call-Id '1-26291@192.168.2.129': while expecting '400' (index 1), received 'SIP/2.0 400 Bad Request

Via: SIP/2.0/UDP 192.168.2.129:5050;branch=z9hG4bK-26291-1-0
From: sip:ca...@ex...;tag=34525
To: sip:j....@ex...;tag=26259SIPpTag013

Call-ID: mismatch01.dj0234sxdfl3///1-26291@192.168.2.129
CSeq: 8 INVITE
Contact: <sip:192.168.2.129:6060;transport=UDP>
Content-Length: 0

I understand this is because when sipp sent the message, it memorized that an OPTION request was sent, so it entered waiting phase for a reply to OPTIONS.

But since the message you sent has CSeq for an INVITE, the scenario fails because a reply for an INVITE was received instead.

                OPTIONS sip:us...@ex... SIP/2.0

                ...
                CSeq: 8 INVITE

Is this really what you want to test? 
I think it is not possible to test this (unless by modifying sipp code).