[asterisk-app-dev] Fwd: Problem when load testing Asterisk 13.7.2

Thu Mar 24 15:55:06 CDT 2016

I wish I had seen these SIPp threads sooner: (a) (TCP is an issue for
callees):
https://www.mail-archive.com/sipp-users@lists.sourceforge.net/msg06118.html
and (b)
https://sourceforge.net/p/sipp/mailman/sipp-users/thread/CAH1RVig_qj5OSnaKfRkAJ0pY8bOw8idFi3wo9DUZ2H6OAC0NMQ@mail.gmail.com/

I have whined plenty about SIPp here so it is only fair I mention this: I
want to re-iterate that I find SIPp very useful and have spent a
considerable amount of time trying to get it to work, but it is sorely
lacking in a number of ways that are quite important to me and every
attempt and mail from me on these threads is merely to make sure I have
left no stone unturned. I have already a lot of visibility into my
application's capability thanks solely to SIPp. That visibility was
possible due to SIPp being run as is in this gist:
https://gist.github.com/ticklingcontest/4762a57457b73db1a170 (ONE instance
of SIPp for each caller, callee, resulting in port madness at load testing
machine).

Rob Day, the person who came up with SIPp, says clearly that SIPp kinda
doesn't work very well for TCP. Especially when we have to match a callee's
REGISTER port and the subsequent CALLEE sipp instance's port (that's the
only way we can be assured that the INVITE is received). Note that we need
two instances of sipp for the callee as each instance of SIPp can only
handle an outbound or inbound dialog. Even then a whole manner of
script-fu-jujitsu is required, and is not straight forward.

Workarounds:
===========
One way around this is to use 3 sipp instances per real-world call (i.e.,
not SIPp call, which is something I cannot relate to at all), where the
(phone) caller ('s voip program) registers (to a SIP PBX) and calls (i.e.,
INVITEs the callee whish is a SIP endpoint attached to the SIP PBX) in one
sipp instance, but the callee (SIP) registers separately with one sipp
instance, and then accepts the call (recv request="INVITE" />) in another
sipp instance, but with the same port (-p parameter) as the callee's
registration. This only works when only one caller/callee is involved,
owing to the port business I mentioned earlier. This what I had managed
earlier (very similar to the gist I posted above, but since caller and
registration can be merged, that becomes ONE sipp instance per caller, and
not two instances per caller as the gist) , but it won't work beyond a
point (of simultaneous calls in one load testing desktop) as the ports get
clogged up (my OP).

For this SIPp + TCP related issue and out-of-call scenario + port madness,
there's a patch that is available (see
http://permalink.gmane.org/gmane.comp.telephony.sipp.user/5769), but I have
not tried it.

Last, but not the least, here's the error I received when I tried to fix
these issues using a OOCSF:

    Automatic calls (created by -aa, -oocsn or -oocsf) cannot use input
files!.

This information would have saved me so much heartache. I wish SIPp had
mentioned these issues surrounding SIP over TCP testing for caller->callee
REGISTER/INVITE scenarios front and center in their documentation.

But, I am just as perplexed that this business of actually making a
voice/video/message call (not SIPp call) using an intermediate controller
like a PBX (and load testing _that_) is not what SIPp is about.

On Mon, Mar 21, 2016 at 9:46 AM, George Joseph <george.joseph at fairview5.com>
wrote:

>
>
> On Sun, Mar 20, 2016 at 8:39 PM, Tickling Contest <
> tickling.contest at gmail.com> wrote:
>
>> Thanks George, I think I am very, very, very confused with sipp and how
>> it handles the coordination (I thought I knew this well, but the pause and
>> ti. There _HAS_ to be a simpler way. It is just way. Too. Complex. I just
>> surprised that there isn't a better tool for something that has a load  of
>> use. Maybe I should move to Asterisk based testing. Known beast...
>>
>
> As I said, this is what I do for more complex stuff.  You have more
> control.
>
> Having said that, I have used sipp to generate thousands of simultaneous
> TCP non-audio calls (REGISTER, OPTIONS, etc),
>
>
>>
>> I have already gotten it working for a single call; you will recall in my
>> OP I wasn't able to push it beyond about a 100 calls concurrently, and
>> that's when I decided to let sipp manage everything.
>>
>
> Yeah, sorry.  I forgot.
>
>
>>
>> The sipp software, I think is also quite buggy.
>>
>> For example, I know that -p flag is supposed to take the port over which
>> the peer registers. This port shows up when you do pjsip show endpoint
>> <peerExtension>. I know this (i.e., -p param)  works in my sipp because
>> that's how I controlled each peer in my earlier sipp load test scenario.
>>
>> Well, now, the local_port does not work when I pass it as a CSV file and
>> modify the [local_port] to [field0] etc, and as a result, the calls are not
>> going through.
>>
>> They also don't have the updated documentation for release 3.5.1 which is
>> what I am using. Sigh!
>>
>
> Is it possible that 3.5.1 just has too many issues?  Here's what I use...
> SIPp v3.4.1-TLS-PCAP-RTPSTREAM
>
>
>
>> On Sun, Mar 20, 2016 at 9:12 PM, George Joseph <
>> george.joseph at fairview5.com> wrote:
>>
>>>
>>> Oh, BTW...
>>>
>>> If sipp doesn't do it for you, there's another great tool you can use
>>> for load testing.  It's called Asterisk. :)
>>>
>>> For more complex scenarios, what I've done in the past is set up 3
>>> Asterisk instances, 1 as the call generator, 1 as the system under test,
>>> and 1 as the call receiver.
>>>
>>> On the generator instance, I have a script that keeps enough call files
>>> in /var/spool/asterisk/outgoing to simulate the number of calls I want.  On
>>> the call receiver, I can set up the dialplan to do anything I want with the
>>> calls.  Transfer, play something, echo, park.  Whatever.
>>>
>>>
>>> On Sun, Mar 20, 2016 at 6:37 PM, George Joseph <
>>> george.joseph at fairview5.com> wrote:
>>>
>>>>
>>>>
>>>> On Sun, Mar 20, 2016 at 5:29 PM, Tickling Contest <
>>>> tickling.contest at gmail.com> wrote:
>>>>
>>>>> OK. I did that, but now, all I do is get into an infinite loop with
>>>>> the registrations at the callee. Here's the gist:
>>>>> https://gist.github.com/ticklingcontest/a0754549a88dc748f52d
>>>>>
>>>>> Ideally, here's what I need:
>>>>>
>>>>> callee registers, and accepts an infinite number of calls.
>>>>> caller registers, and then sends INVITES an infinite number of times
>>>>> so as to keep the total number of calls per the (-l parameter).
>>>>>
>>>>> It is not clear to me how I would loop at the callee scenario or
>>>>> caller scenario.
>>>>>
>>>>
>>>> You don't loop anything.  sipp runs the scenarios itself repeatedly
>>>> until -m calls have been processed.
>>>>
>>>> I'd start without your script or the csv files and just get a simple 1
>>>> call scenario to work.
>>>>
>>>> If you want some good examples, look at the Asterisk testsuite
>>>> tests/channels/pjsip/basic_calls scenarios.
>>>>
>>>> Here's a caller file I used often...
>>>> https://gist.github.com/gtjoseph/ce5a719b11f307c7ec5e
>>>>
>>>> register
>>>> pause 1 sec
>>>> invite
>>>> pause 1 sec
>>>> bye
>>>> pause 1 sec
>>>> unregister
>>>>
>>>> To simulate a call from a phone with extension/endpoint name 1100, run
>>>> it like so...
>>>> # sipp -sf reg_and_call.xml -s 1100 -au 1100 -ap <password> -m 1
>>>> <server:ip>
>>>>
>>>> If you want it to resister/call/unregister 100 times with 10 parallel
>>>> calls over TCP, run
>>>>
>>>> # sipp -sf reg_and_call.xml -t tn -s 1100 -au 1100 -ap <password> -m
>>>> 100 -l 10  <server_ip:port>
>>>>
>>>> Once you get that working by itself to an existing extension,  set up
>>>> your callee the same way, then call it from a normal working extension and
>>>> make sure it responds correctly.
>>>>
>>>> Then have your caller call the callee, first as a single call, then try
>>>> multiple calls.
>>>>
>>>> Only when you have that working should you  introduce your injection
>>>> files.
>>>>
>>>>
>>>>> What is really confusing in the caller script apart from the real
>>>>> confusion I have with -m and -l parameters, is how the caller's INVITE goes
>>>>> out from the same port as the registered port especially when they are
>>>>> called as two separate processes. Does sipp write a  dot file somewhere
>>>>> where it gets its information from?
>>>>>
>>>>
>>>> Nope.
>>>>
>>>>
>>>>> BTW, In this model, I pass the CSV file that is pre-generated for the
>>>>> calls using a python script that looks like this:
>>>>>
>>>>> SEQUENTIAL
>>>>> callerID1;AsteriskIPAddress;[authentication username=silly
>>>>> password=sillier];calleeID1;callDuration1;
>>>>> callerID2;AsteriskIPAddress;[authentication username=silly
>>>>> password=sillier];calleeID2;callDuration2;
>>>>> ...
>>>>> callerIDn;AsteriskIPAddress;[authentication username=silly
>>>>> password=sillier];calleeIDn;callDurationn;
>>>>> etc.
>>>>>
>>>>> Again, any help is appreciated. I can see how this is turning into a
>>>>> sipp tutorial, so I understand if you have issues dealing with this here,
>>>>> but I can tell that SIPp help is very sparing online.
>>>>>
>>>>> Thanks!
>>>>>
>>>>
>>>> I'll say again...  If you want some good examples, look at the
>>>> Asterisk testsuite tests/channels/pjsip/basic_calls scenarios.  There are
>>>> both inbound and outbound scenarios, authed and unauthed.
>>>> 
>>>>
>>>>
>>> _______________________________________________
>>> asterisk-app-dev mailing list
>>> asterisk-app-dev at lists.digium.com
>>> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
>>>
>>>
>>
>> _______________________________________________
>> asterisk-app-dev mailing list
>> asterisk-app-dev at lists.digium.com
>> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
>>
>>
>
> _______________________________________________
> asterisk-app-dev mailing list
> asterisk-app-dev at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20160324/46dcd30c/attachment-0001.html>