<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'><div dir='ltr'>
<font class="Apple-style-span" face="Tahoma" size="2">Hello Brett,</font><div style="font-family: Tahoma; font-size: 10pt; "><br></div><div><font class="Apple-style-span" face="Tahoma" size="2">The SIPp scenarios are configured to handle the correct flow. If I run the SIPp UAC directly with the SIPp UAS I don't get the errors, it just happend when I use the OpenSIPs as a proxy. And that error doesn't&nbsp;</font><font class="Apple-style-span" face="Tahoma" size="2">occur on every call, is just in some. After I disabled the logging, I'm getting about 200 unexpected messages, out of about 25,000 calls (with a call rate of about 3000 calls per second). But i don' really know why this is happening. Here is the code I use in the UAS side of the scenario:&nbsp;</font></div><div><br></div><div><div>&lt;scenario name="Basic UAS responder"&gt;</div><div>&nbsp; &lt;!-- By adding rrs="true" (Record Route Sets), the route sets &nbsp; &nbsp; &nbsp; &nbsp; --&gt;</div><div>&nbsp; &lt;!-- are saved and used for following messages sent. Useful to test &nbsp; --&gt;</div><div>&nbsp; &lt;!-- against stateful SIP proxies/B2BUAs. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; --&gt;</div><div>&nbsp; &lt;recv request="INVITE" crlf="true"&gt;</div><div>&nbsp; &lt;/recv&gt;</div><div><br></div><div>&nbsp; &lt;!-- The '[last_*]' keyword is replaced automatically by the &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;--&gt;</div><div>&nbsp; &lt;!-- specified header if it was present in the last message received &nbsp;--&gt;</div><div>&nbsp; &lt;!-- (except if it was a retransmission). If the header was not &nbsp; &nbsp; &nbsp; --&gt;</div><div>&nbsp; &lt;!-- present or if no message has been received, the '[last_*]' &nbsp; &nbsp; &nbsp; --&gt;</div><div>&nbsp; &lt;!-- keyword is discarded, and all bytes until the end of the line &nbsp; &nbsp;--&gt;</div><div>&nbsp; &lt;!-- are also discarded. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;--&gt;</div><div>&nbsp; &lt;!-- &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;--&gt;</div><div>&nbsp; &lt;!-- If the specified header was present several times in the &nbsp; &nbsp; &nbsp; &nbsp; --&gt;</div><div>&nbsp; &lt;!-- message, all occurences are concatenated (CRLF seperated) &nbsp; &nbsp; &nbsp; &nbsp;--&gt;</div><div>&nbsp; &lt;!-- to be used in place of the '[last_*]' keyword. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; --&gt;</div><div><br></div><div>&nbsp; &lt;send&gt;</div><div>&nbsp; &nbsp; &lt;![CDATA[</div><div><br></div><div>&nbsp; &nbsp; &nbsp; SIP/2.0 180 Ringing</div><div>&nbsp; &nbsp; &nbsp; [last_Via:]</div><div>&nbsp; &nbsp; &nbsp; [last_From:]</div><div>&nbsp; &nbsp; &nbsp; [last_To:];tag=[call_number]</div><div>&nbsp; &nbsp; &nbsp; [last_Call-ID:]</div><div>&nbsp; &nbsp; &nbsp; [last_CSeq:]</div><div>&nbsp; &nbsp; &nbsp; Contact: &lt;sip:[local_ip]:[local_port];transport=[transport]&gt;</div><div>&nbsp; &nbsp; &nbsp; Content-Length: 0</div><div><br></div><div>&nbsp; &nbsp; ]]&gt;</div><div>&nbsp; &lt;/send&gt;</div><div><br></div><div>&nbsp; &lt;send retrans="500"&gt;</div><div>&nbsp; &nbsp; &lt;![CDATA[</div><div><br></div><div>&nbsp; &nbsp; &nbsp; SIP/2.0 200 OK</div><div>&nbsp; &nbsp; &nbsp; [last_Via:]</div><div>&nbsp; &nbsp; &nbsp; [last_From:]</div><div>&nbsp; &nbsp; &nbsp; [last_To:];tag=[call_number]</div><div>&nbsp; &nbsp; &nbsp; [last_Call-ID:]</div><div>&nbsp; &nbsp; &nbsp; [last_CSeq:]</div><div>&nbsp; &nbsp; &nbsp; Contact: &lt;sip:[local_ip]:[local_port];transport=[transport]&gt;</div><div>&nbsp; &nbsp; &nbsp; Content-Type: application/sdp</div><div>&nbsp; &nbsp; &nbsp; Content-Length: [len]</div><div><br></div><div>&nbsp; &nbsp; &nbsp; v=0</div><div>&nbsp; &nbsp; &nbsp; o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]</div><div>&nbsp; &nbsp; &nbsp; s=-</div><div>&nbsp; &nbsp; &nbsp; c=IN IP[media_ip_type] [media_ip]</div><div>&nbsp; &nbsp; &nbsp; t=0 0</div><div>&nbsp; &nbsp; &nbsp; m=audio [media_port] RTP/AVP 0</div><div>&nbsp; &nbsp; &nbsp; a=rtpmap:0 PCMU/8000</div><div><br></div><div>&nbsp; &nbsp; ]]&gt;</div><div>&nbsp; &lt;/send&gt;</div><div><br></div><div>&nbsp; &lt;recv request="ACK"</div><div>&nbsp; &nbsp; &nbsp; &nbsp; optional="true"</div><div>&nbsp; &nbsp; &nbsp; &nbsp; rtd="true"</div><div>&nbsp; &nbsp; &nbsp; &nbsp; crlf="true"&gt;</div><div>&nbsp; &lt;/recv&gt;</div><div><br></div><div>&nbsp; &lt;recv request="BYE"&gt;</div><div>&nbsp; &lt;/recv&gt;</div><div><br></div><div>&nbsp; &lt;send&gt;</div><div>&nbsp; &nbsp; &lt;![CDATA[</div><div><br></div><div>&nbsp; &nbsp; &nbsp; SIP/2.0 200 OK</div><div>&nbsp; &nbsp; &nbsp; [last_Via:]</div><div>&nbsp; &nbsp; &nbsp; [last_From:]</div><div>&nbsp; &nbsp; &nbsp; [last_To:]</div><div>&nbsp; &nbsp; &nbsp; [last_Call-ID:]</div><div>&nbsp; &nbsp; &nbsp; [last_CSeq:]</div><div>&nbsp; &nbsp; &nbsp; Contact: &lt;sip:[local_ip]:[local_port];transport=[transport]&gt;</div><div>&nbsp; &nbsp; &nbsp; Content-Length: 0</div><div><br></div><div>&nbsp; &nbsp; ]]&gt;</div><div>&nbsp; &lt;/send&gt;</div><br><div style="font-family: Tahoma; font-size: 10pt; ">Luis Morales.</div><br><br><div style="font-family: Tahoma; font-size: 10pt; ">&gt; Date: Mon, 12 Sep 2011 21:58:00 -0500<br>&gt; From: brett@nemeroff.com<br>&gt; To: users@lists.opensips.org<br>&gt; Subject: Re: [OpenSIPS-Users] OpenSIPs Stress test problem<br>&gt; <br>&gt; Luis,<br>&gt; Your scenario isn't setup to properly handle the call flow. The error<br>&gt; message clearly shows that 200 was expected but 180 was received.<br>&gt; <br>&gt; -Brett<br>&gt; On Monday, September 12, 2011, Luis Morales<br>&gt; &lt;luisalfredo_ml31@hotmail.com&gt; wrote:<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt; The script is simply forwarding requests and responses in a stateless manner. I've tried the simple stateful configuration in the opensips site, but I've like to try it with the stateless configuration. Here's the script I'm using:<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt; ####### Global Parameters #########<br>&gt; &gt; debug=0log_stderror=no<br>&gt; &gt; fork=yeschildren=12<br>&gt; &gt; /* uncomment the next line to disable TCP (default on) */disable_tcp=yes<br>&gt; &gt; #listen=udp:10.0.0.1:5060port=5060<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt; ####### Modules Section ########<br>&gt; &gt; #set module pathmpath="/usr/lib/opensips/modules/"<br>&gt; &gt; loadmodule "sl.so"loadmodule "tm.so"<br>&gt; &gt; modparam("tm", "wt_timer", 2)modparam("tm", "restart_fr_on_each_reply", 0)# ----------------- setting module-specific parameters ---------------<br>&gt; &gt;<br>&gt; &gt; ####### Routing Logic ########<br>&gt; &gt;<br>&gt; &gt; # main request routing logic<br>&gt; &gt; route{        forward();}<br>&gt; &gt;<br>&gt; &gt; The errors I'm receiving in sipp are like the following:<br>&gt; &gt; 2011-09-11        19:42:41:161        1315784561.161207: Aborting call on unexpected message for Call-Id '188-8326@::1': while expecting '200' (index 5), received 'SIP/2.0 180 RingingVia: SIP/2.0/UDP [::1]:5062;received=127.0.0.1;branch=z9hG4bK-8326-188-0From: sipp &lt;sip:sipp@[::1]:5062&gt;;tag=8326SIPpTag00188To: sut &lt;sip:service@127.0.0.1:5061&gt;;tag=188Call-ID: 188-8326@::1CSeq: 1 INVITEContact: &lt;sip:[::1]:5061;transport=UDP&gt;Content-Length: 0<br>&gt; &gt; Thanks,<br>&gt; &gt; Luis Morales.<br>&gt; &gt;<br>&gt; &gt; From: brett@nemeroff.com<br>&gt; &gt; Date: Mon, 12 Sep 2011 21:19:22 -0500<br>&gt; &gt; To: users@lists.opensips.org<br>&gt; &gt; Subject: Re: [OpenSIPS-Users] OpenSIPs Stress test problem<br>&gt; &gt;<br>&gt; &gt; Can't really tell without seeing what the errors are and what your script is doing. Are you doing any database lookups??<br>&gt; &gt;<br>&gt; &gt; -Brett<br>&gt; &gt; On Sep 12, 2011, at 9:18 PM, Luis Morales &lt;luisalfredo_ml31@hotmail.com&gt; wrote:<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt; Hello Brett,<br>&gt; &gt; You're right, I forgot to check the logging. I disabled it and it's working better. I'm still getting some unexpected messages error, but a lot less than I was getting before. Thanks for your help. Do you know if there's something else I could do so I could stop getting the errors.?<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt; Thanks,<br>&gt; &gt; Luis Morales.<br>&gt; &gt;<br>&gt; &gt; From: &nbsp;&lt;brett@nemeroff.com&gt;brett@nemeroff.com<br>&gt; &gt; Date: Mon, 12 Sep 2011 10:56:13 -0500<br>&gt; &gt; To: &nbsp;&lt;users@lists.opensips.org&gt;users@lists.opensips.org<br>&gt; &gt; Subject: Re: [OpenSIPS-Users] OpenSIPs Stress test problem<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt; On Mon, Sep 12, 2011 at 9:15 AM, Luis Alfredo Morales Lora &lt;&nbsp;&lt;luisalfredo_ml31@hotmail.com&gt;luisalfredo_ml31@hotmail.com&gt; wrote:<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt; I'm using version 3.1 and I've also tried version 3.2 and I have the same problem in both. I used the -trace_err to see what the errors where, and the problem is that while Sipp is expecting a particular response, it receives another, for example, while expecting and acknowledge it receives an OK. I used wireshark to see what was happening, and i saw that the Opensips server introduces a little delay &nbsp;in sending each response, but what I don't understand is why with such a small call rate I'm having this problem.<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt; Luis,<br>&gt; &gt; You didn't answer my logging questions. I've seen bad logging configurations totally disable an opensips server. Specifically a registration server that could handle ONE phone but not TWO. No kidding. Problem was 100% syslog setup. Disabled logging and back up to being able to handle thousands of phones.<br>&gt; &gt;<br>&gt; &gt; This is pretty well documented and has been reported in the past. That may be your issue.<br>&gt; &gt; -Brett<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt; _______________________________________________<br>&gt; &gt; Users mailing list<br>&gt; &gt; Users@lists.opensips.org<br>&gt; &gt; &nbsp;&lt;http://lists.opensips.org/cgi-bin/mailman/listinfo/users&gt;http://lists.opensips.org/cgi-bin/mailman/listinfo/users                                             <br>&gt; &gt;<br>&gt; &gt; _______________________________________________<br>&gt; &gt; Users mailing list<br>&gt; &gt; Users@lists.opensips.org<br>&gt; &gt; http://lists.opensips.org/cgi-bin/mailman/listinfo/users<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt; _______________________________________________<br>&gt; &gt; Users mailing list<br>&gt; &gt; Users@lists.opensips.org<br>&gt; &gt; http://lists.opensips.org/cgi-bin/mailman/listinfo/users                                             <br>&gt; &gt;<br>&gt; <br>&gt; _______________________________________________<br>&gt; Users mailing list<br>&gt; Users@lists.opensips.org<br>&gt; http://lists.opensips.org/cgi-bin/mailman/listinfo/users<br></div></div>                                               </div></body>
</html>