I have a scenario file attached -- but the gist of which is that it does
a basic invite:
<send> ... invite </send>
<recv response="100" optional="global"/>
<recv response="180" optional="global"./>
<recv response="200"> <action which saves a variable $6 from the contact
header></recv>
<send>
ACK sip:[EMAIL PROTECTED]:[remote_port];transport=[transport];[$6] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:[EMAIL
PROTECTED]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: sut <sip:[EMAIL PROTECTED]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: [cseq] ACK
[routes]
Contact: sip:[EMAIL PROTECTED]:[local_port]
Max-Forwards: 70
Subject: InviteProxy Performance Test
Content-Length: 0
</send>
This all works fine, except that sometimes, sipp sends out an ACK formatted
like this:
ACK sip:[EMAIL PROTECTED]:5045 SIP/2.0
Via: SIP/2.0/TCP 10.5.8.146:5035;branch=z9hG4bK-17387-130--1
From: ...
To: ...
Call-ID: ....
CSeq: 1 ACK
Max-Forwards: 70
Contact: ....
Content-Length: 0
There are at least three things wrong here: the ACK doesn't have the
transport correct (nor the variable), the branch is malformed (not a
typo; it does have --1 at the end), and the headers after the CSeq are
out of order and don't include the route.
I've been unable to track this down -- I believe it may be a combination
of two things: first is that we could receive the 180 following the 200
(which is why the 180 is marked optional), and second we could be very
congested. I suspect (but haven't been able to tell) that it is a
combination of things: a simple test where the 180 is deliberately sent
after the 200 doesn't cause the corrupted ACK message to be sent, but
the higher load we run, the more it seems to happen. [Also, if I have my
UAS never send a 180, the ACK is never corrupted either.]
Under normal circumstances, when sipp processes the 200 OK, the ACK is
immediately sent (before sipp processes the 180). Is it possible somehow
that if the socket is congested, the 180 will be processed before the
ACK is forrmatted and put on the pending messages list? That could mess
up the route (though I wouldn't think it would mess up the branch), and
in fact if I short-circuit the processing of the optional message
(immediately returning from call:process_incoming when the global
message is found), I never see the corrupted ACK either.
Is there something wrong with my understanding of the global optional
flag, or is there some bug I still need to track down (and if so, any
suggestions would be welcome!). I'm using the stable 3.0 build (I've
tried the latest code in the trunk, but it had some performance
regressions for me, so I didn't spend a lot of time with it).
-Scott
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<!--
sipp file used for InviteProxy UAC test. Designed only for TCP (no
retransmission enabled for UDP). Scenario of this test:
UAC PROXY UAC
INVITE
--------------- >
100
<--------------
INVITE
-------------------- >
180 Ringing
<--------------------
200 OK
<--------------------
180 Ringing
<--------------
200 OK
<--------------
ACK
--------------- >
BYE
--------------- >
ACK
-------------------- >
BYE
-------------------- >
200 OK
<--------------------
200 OK
<--------------
The rtd timer is set to measure only the time from invote to first 200
OK response.
Note that because the 100/180/200 responses can be received in any order,
the 100/180 are marked as optional=global -- that way, they can occur at
any time without affecting the scenario.
-->
<scenario name="InviteProxy UAC">
<send retrans="500">
<![CDATA[
INVITE sip:[EMAIL PROTECTED]:[remote_port];transport=[transport] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:[EMAIL PROTECTED]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: sut <sip:[EMAIL PROTECTED]:[remote_port]>
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: <sip:[EMAIL PROTECTED]:[local_port];transport=[transport]>
Max-Forwards: 70
Subject: InviteProxy Performance Test
Test-Type: uas
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="global"/>
<recv response="180" optional="global"/>
<recv response="200" rtd="true" rrs="true" optional="false">
<action>
<ereg regexp="fid=[-a-zA-Z0-9_]*" search_in="hdr" header="Contact:" check_it="true" assign_to="6" />
</action>
</recv>
<send>
<![CDATA[
ACK sip:[EMAIL PROTECTED]:[remote_port];transport=[transport];[$6] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:[EMAIL PROTECTED]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: sut <sip:[EMAIL PROTECTED]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
[routes]
Contact: sip:[EMAIL PROTECTED]:[local_port]
Max-Forwards: 70
Subject: InviteProxy Performance Test
Content-Length: 0
]]>
</send>
<pause/>
<send retrans="500">
<![CDATA[
BYE sip:[EMAIL PROTECTED]:[remote_port];transport=[transport];[$6] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:[EMAIL PROTECTED]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: sut <sip:[EMAIL PROTECTED]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
[routes]
CSeq: 2 BYE
Contact: sip:[EMAIL PROTECTED]:[local_port]
Max-Forwards: 70
Subject: InviteProxy Performance Test
Content-Length: 0
]]>
</send>
<recv response="200" crlf="true"/>
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Sipp-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sipp-users
