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: mayamatake...@gmail.com
To: shelly_kear...@hotmail.com
CC: sipp-users@lists.sourceforge.net
On Mon, Oct 10, 2011 at 11:24 PM, Michelle Kearney <shelly_kear...@hotmail.com>
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:u...@example.com SIP/2.0
To: sip:j.u...@example.com
From: sip:cal...@example.net;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:cal...@example.net;tag=34525
To: sip:j.u...@example.com;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:u...@example.com 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).
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
