Author |
|
ajdiaz Junior
Joined: December 10 2007 Location: United States Posts: 76
|
Posted: March 12 2009 at 3:54pm | IP Logged
|
|
|
Support,
We are interested in working with your team to execute some load testing for our implementation of your media engine, and would like some advice on how to move forward with this type of testing. A summary of our thoughts and approach is below - please comment and advise.
We currently have a 512 line license of the engine (recent custom build for SONAS equipment) and are interested in testing it up to a range around 300 or so lines.
On a separate note - currently we are unable to get the engine to run in our implementation at more than around 300 lines (1500 threads) - without the engine starting up and immediately stopping - however we are willing to live with this limiation for now to get the 300 line capacity working 100%.
Currently, we have already completed our own internal testing at low volumes and have had good success, but in order to be sure we're ready to launch our product we need to be sure the system will perform at full capacity and maximum load.
Please note that we are already are confident in the media engine itself is able to work properly at this capacity. Our goal in this testing is to ensure that the actual tests are done using our implementation of the media engine, through our equipment and configuration and software implementation. This approach would fully test our system including all servers, firewalls, network pipes, and software components in our production environment through our VOIP provider.
Our application can already make calls and play back any WAV file we give it - however the piece we would like some help with is to confirm on the receiving end that the calls made through our application (and subsequently through our VOIP provider) terminate and have acceptable audio, etc on the far end termination point. In order to complete this our thought was to have our application call and playback test tones, DTMF, etc - into a LANSCAPE test application (as previoulsy mentioned by LANSCAPE) to confirm audio playback, audio quality, call control-DTMF, etc. Do you have such an application we can call into at 300+ line capacity which would serve this purpose and output appropriate metrics? Given that bandwidth might be a barrier it would be important to mention that we do have racks in multiple data centers with large (40mbps) internet connections in which to host both sides of this production-testing scenario as necessary.
Please advise on how to begin this process and the steps involved to do so.
Thank You,
AJDiaz
|
Back to Top |
|
|
support Administrator
Joined: January 26 2005 Location: United States Posts: 1666
|
Posted: March 13 2009 at 6:42pm | IP Logged
|
|
|
Hi Aj,
Good post. Very clear description of what you want to do.
I think we will want to get you copies of our “call tester” Win32 app. Its not a LanScape product that we sell – its simply something we developed for our own use. We use it here and in the filed all the time to perform various load testing and quality of service (Qos) testing.
We can use this call tester to initiate and receive calls, play live audio from wave files through the lines and send 600HZ or 700Hz pilot test tones across any of the VOIP phone lines. Calls can use G729/G729A, uLaw/aLaw, iLBC or any of the other PCM supported codecs. It also allows us to monitor any of the audio or test tones being received on any of the lines.
I think what we want to do is to have your media engine based VOIP app (the server) call through your SIP trunk service provider. You then will have to set things up at your end to make sure the outgoing calls from your server through the service provider route back to one or more “call tester” test machines in your lab. The “call tester” test machines will act to terminate the VOIP calls. You can set up a single target call test machine or many. It all depends on how fast your test machine hardware is.
Your server should then be set up to initiate calls through the service provider. For the purposes of testing call volume and when call quality finally drops off, your server should not transmit voice signals. Test tones are better (600 or 700 HZ tones) because they are continuous and allow you to actually hear when things start to fall apart.
You can also perform the same testing scenario described above without vectoring the calls through the Sip trunk provider. In this case, your media engine based VOIP server can call the “call tester” machines directly. This is good if you really have a fast local network and really want to see how far you can push your VOIP server.
The machine you use for the call testers can be any old hardware you have that is lying around. The only thing that matters is that each test machine be able to handle the number of test calls each will service. We do not want call testers to be the limiting component when evaluating call volume and quality of service (Qos).
Call testing usually starts out using say… 30 concurrent lines. Verify that this test scenario is OK and then go to 40 concurrent lines. Keep testing and increasing the total number of concurrent lines in your VOIP server until it can no longer keep up. It will become apparent when call audio hits the “toilet”. As you perform call testing, also monitor on your server machine network utilization and CPU loading. You can do this with ‘task manager” or “performance monitor”.
We can take this up again this Monday or Tuesday. We have to get a current build of the call tester for your use.
Thanks Aj,
Randal
|
Back to Top |
|
|
support Administrator
Joined: January 26 2005 Location: United States Posts: 1666
|
Posted: March 16 2009 at 11:07am | IP Logged
|
|
|
Hi Ajay,
We will work this week to get you the call tester app with some form of basic documentation. Unfortunately it won’t be today (Monday) however.
We will post again when a download is ready.
Thank you,
Randal
|
Back to Top |
|
|
support Administrator
Joined: January 26 2005 Location: United States Posts: 1666
|
Posted: March 17 2009 at 7:10pm | IP Logged
|
|
|
Hi Ajay,
There is a “call tester” download archive image in your support FTP account. See file “CallTester - Expires 12-31-09.zip”
This test software can be unzipped and placed into any directory of your choice.
If you want to run multiple instances on the same host machine, you can do this by using batch files or Windows shortcuts and specifying the –f command line switch such as:
CallTester.exe –f ConfigFile.ini
Each running instance needs its own INI file for configuration settings.
If you want to perform basic load testing of your media engine based IVR server to see how many concurrent calls are possible, here is one possible test scenario:
1)
Configure your IVR server to dial out calls directly to one or more call testers. Calls made by your IVR server can be sent directly to one or more call tester apps on one or more host machines.
2)
When calls connect, have your IVR server loop/continuously play pilot tones (600 or 700 Hz tone) out its phone lines instead of voice. The call tester has a few of these wave files if you need them. Make the call duration for each call a few minutes to give enough time to manually check the received tones using the call tester app.
3)
Start out by load testing approximately 32 concurrent calls made by your IVR server app.
4)
The call testers should be set up in receive mode only so that they answer all incoming calls.
5)
When all of your calls are connected between your IVR server and the call tester(s), use the “enable call tracing” function of the call tester so that you can monitor the audio (pilot tones) being receive from your IVR server. See the call tester docs for more info. Post to the support forum if you get stuck.
6)
If the audio on any one phone line is OK, it will be OK for all the other lines. In this case, terminate all the calls and repeat the call testing by increasing the total number of calls by 10. Repeat steps 1 through 6. Continue testing and increasing the total number of concurrent calls until the audio from your IVR server app starts to break up and fall apart. You will eventually hit the number of concurrent calls that will be possible with your IVR server implementation and the media engine.
Note:
Run your IVR server on a host machine all by itself. Run the call testers on their own machines too if possible.
You can also perform a similar test as described above but instead of having your IVR server dial the call testers directly, have your IVR server call out via your SIP service provider. The calls should be made to route back from your service provider back to the call testers in your lab. Testing like this will allow to see the limitation (if any) of your SIP trunk connectivity.
Randal
|
Back to Top |
|
|
|
|