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

Tickling Contest tickling.contest at gmail.com
Sun Mar 20 22:10:04 CDT 2016


Sean,

I think I understood your comment incorrectly, let me try this again. I did
try a PJSIP based testing framework a while ago. I could not get it to
work, and I have forgotten what it was.

Anyway, what I think you are saying is that if I have come this far, why
not write the entire testing framework using PJSIP (and Python, maybe) as
it can get quite simple if I use the high level PJSUA binding.

I have not tried that. And at this time, it is worth a look, especially
because I find SIPp very cumbersome.

So, thanks!

On Sun, Mar 20, 2016 at 10:47 PM, Sean Brady <sbrady at haikuengineering.com>
wrote:

> Works fine for me, and it compiles with PJSIP.
>
> On Mar 20, 2016, at 20:46, Tickling Contest <tickling.contest at gmail.com>
> wrote:
>
> Sorry, but I started with PJSUA and was told that the package is broken. I
> couldn't get it work. Thanks, though.
>
> On Sun, Mar 20, 2016 at 10:43 PM, Sean Brady <sbrady at haikuengineering.com>
> wrote:
>
>> You can also use pjsua if you're looking for something simpler. If you
>> know Python there are bindings for it as well. Freeswitch is incredibly
>> suited to what I believe is your use case.
>>
>> HTH
>>
>> On Mar 20, 2016, at 20:39, 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...
>>
>> 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.
>>
>> 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!
>>
>> 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
>>
>>
> _______________________________________________
> 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/20160320/25e40639/attachment-0001.html>


More information about the asterisk-app-dev mailing list