I wish I had seen these SIPp threads sooner: (a) (TCP is an issue for callees): https://www.mail-archive.com/sipp-users@xxxxxxxxxxxxxxxxxxxxx/msg06118.html and (b) https://sourceforge.net/p/sipp/mailman/sipp-users/thread/CAH1RVig_qj5OSnaKfRkAJ0pY8bOw8idFi3wo9DUZ2H6OAC0NMQ@xxxxxxxxxxxxxx/
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@xxxxxxxxxxxxx> wrote:
On Sun, Mar 20, 2016 at 8:39 PM, Tickling Contest <tickling.contest@xxxxxxxxx> 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-RTPSTREAMOn Sun, Mar 20, 2016 at 9:12 PM, George Joseph <george.joseph@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> wrote:On Sun, Mar 20, 2016 at 5:29 PM, Tickling Contest <tickling.contest@xxxxxxxxx> 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/a0754549a88dc748f52dIdeally, 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...registerpause 1 secinvitepause 1 secbyepause 1 secunregisterTo 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:SEQUENTIALcallerID1;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@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
_______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
