Hello Brett,
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 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:
<scenario name="Basic UAS responder"> <!-- By adding rrs="true" (Record Route
Sets), the route sets --> <!-- are saved and used for following
messages sent. Useful to test --> <!-- against stateful SIP proxies/B2BUAs.
--> <recv request="INVITE" crlf="true"> </recv>
<!-- The '[last_*]' keyword is replaced automatically by the -->
<!-- specified header if it was present in the last message received --> <!--
(except if it was a retransmission). If the header was not --> <!--
present or if no message has been received, the '[last_*]' --> <!--
keyword is discarded, and all bytes until the end of the line --> <!-- are
also discarded. --> <!--
--> <!-- If the
specified header was present several times in the --> <!-- message,
all occurences are concatenated (CRLF seperated) --> <!-- to be used in
place of the '[last_*]' keyword. -->
<send> <![CDATA[
SIP/2.0 180 Ringing [last_Via:] [last_From:]
[last_To:];tag=[call_number] [last_Call-ID:] [last_CSeq:]
Contact: <sip:[local_ip]:[local_port];transport=[transport]>
Content-Length: 0
]]> </send>
<send retrans="500"> <![CDATA[
SIP/2.0 200 OK [last_Via:] [last_From:]
[last_To:];tag=[call_number] [last_Call-ID:] [last_CSeq:]
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] [media_ip] t=0 0 m=audio [media_port]
RTP/AVP 0 a=rtpmap:0 PCMU/8000
]]> </send>
<recv request="ACK" optional="true" rtd="true"
crlf="true"> </recv>
<recv request="BYE"> </recv>
<send> <![CDATA[
SIP/2.0 200 OK [last_Via:] [last_From:] [last_To:]
[last_Call-ID:] [last_CSeq:] Contact:
<sip:[local_ip]:[local_port];transport=[transport]> Content-Length: 0
]]> </send>
Luis Morales.
> Date: Mon, 12 Sep 2011 21:58:00 -0500
> From: [email protected]
> To: [email protected]
> Subject: Re: [OpenSIPS-Users] OpenSIPs Stress test problem
>
> Luis,
> Your scenario isn't setup to properly handle the call flow. The error
> message clearly shows that 200 was expected but 180 was received.
>
> -Brett
> On Monday, September 12, 2011, Luis Morales
> <[email protected]> wrote:
> >
> >
> >
> >
> >
> > 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:
> >
> >
> > ####### Global Parameters #########
> > debug=0log_stderror=no
> > fork=yeschildren=12
> > /* uncomment the next line to disable TCP (default on) */disable_tcp=yes
> > #listen=udp:10.0.0.1:5060port=5060
> >
> >
> > ####### Modules Section ########
> > #set module pathmpath="/usr/lib/opensips/modules/"
> > loadmodule "sl.so"loadmodule "tm.so"
> > modparam("tm", "wt_timer", 2)modparam("tm", "restart_fr_on_each_reply", 0)#
> > ----------------- setting module-specific parameters ---------------
> >
> > ####### Routing Logic ########
> >
> > # main request routing logic
> > route{ forward();}
> >
> > The errors I'm receiving in sipp are like the following:
> > 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
> > <sip:sipp@[::1]:5062>;tag=8326SIPpTag00188To: sut
> > <sip:[email protected]:5061>;tag=188Call-ID: 188-8326@::1CSeq: 1
> > INVITEContact: <sip:[::1]:5061;transport=UDP>Content-Length: 0
> > Thanks,
> > Luis Morales.
> >
> > From: [email protected]
> > Date: Mon, 12 Sep 2011 21:19:22 -0500
> > To: [email protected]
> > Subject: Re: [OpenSIPS-Users] OpenSIPs Stress test problem
> >
> > Can't really tell without seeing what the errors are and what your script
> > is doing. Are you doing any database lookups??
> >
> > -Brett
> > On Sep 12, 2011, at 9:18 PM, Luis Morales <[email protected]>
> > wrote:
> >
> >
> > Hello Brett,
> > 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.?
> >
> >
> >
> > Thanks,
> > Luis Morales.
> >
> > From: <[email protected]>[email protected]
> > Date: Mon, 12 Sep 2011 10:56:13 -0500
> > To: <[email protected]>[email protected]
> > Subject: Re: [OpenSIPS-Users] OpenSIPs Stress test problem
> >
> >
> >
> > On Mon, Sep 12, 2011 at 9:15 AM, Luis Alfredo Morales Lora <
> > <[email protected]>[email protected]> wrote:
> >
> >
> >
> >
> >
> >
> > 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 in sending each response, but
> > what I don't understand is why with such a small call rate I'm having this
> > problem.
> >
> >
> >
> >
> > Luis,
> > 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.
> >
> > This is pretty well documented and has been reported in the past. That may
> > be your issue.
> > -Brett
> >
> >
> >
> >
> > _______________________________________________
> > Users mailing list
> > [email protected]
> >
> > <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
> >
> > _______________________________________________
> > Users mailing list
> > [email protected]
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
> >
> > _______________________________________________
> > Users mailing list
> > [email protected]
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
> >
>
> _______________________________________________
> Users mailing list
> [email protected]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
