support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: May 18 2007 at 9:05am | IP Logged
|
|
|
To: All VOIP Media Engine customers.
Subject: Deploying large line media engines (Memory/Threads)
Purpose:
For all customers who are deploying “large lined” VOIP Media Engines in their products, we wanted to post additional information here that will help you get the most out of your media engine product.
This post will offer additional information you may need in order to effectively use all of the supported phone lines in your particular version of the media engine.
Depending on how you develop your VOIP application (that uses the VOIP Media Engine), you may not be able to use all of the configured media engine phone lines at the same time. The primary reason is the 2Gig memory limit on the 32 bit process address space. Fear not, this limitation can be managed so that you can use all of your phone lines concurrently. The solution is to make well informed design decisions regarding how you develop your VOIP application in addition to using only those media engine capabilities that are required for your application. With this knowledge in hand, you will be able to “tune” your voip application to achieve your results.
Definition: Large lined Media Engine:
This is any media engine supporting 128 lines or greater. Each logical VOIP phone line in the media engine can be used for receiving incoming calls or for initiating outgoing calls. All phone lines can be used at the same time to carry individual voice data (and in the upcoming future H.264 video data).
The Problem:
Not being able to use all of your media engine phone lines concurrently.
The primary reason for this is memory, memory and memory. Each 32 bit process (i.e. your VOIP application) has at most 2 Gigabytes of memory. When all of your process memory is used, that’s it. Your application will not be able to create additional data areas, instantiate new objects or start new threads of execution. If your application starts to have memory related problems, the media engine will either return the following values as API return values or send them to you application as events: SipMemoryError, SipThreadCreationError. For complete detail associated with these two error codes, see the VOIP Media Engine Developer’s Reference.
Windows 32bit process space, memory and threads:
Currently Windows 32 bit operating systems allow each running process to have up to 2 gigabytes of memory space. This memory space is used to load your application program code and data. It is also used to load the code and data areas of all dynamic link libraries (DLLs) your application uses.
In addition to that stated above, if you develop your VOIP application using managed code (using .NET languages like C#, VB etc), the Common Language Runtime support will also be loaded into your process address space therefore reducing your total usable process memory accordingly.
Reducing your process memory footprint:
There are three primary options you can employ to reduce the process memory that is consumed by the VOIP Media Engine and your application. You can use all of the suggestions below to reduce your process memory requirements or select only those that will not impact or limit your VOIP application.
Item1 – Disable conferencing capability:
This is the “big one”. Disabling conferencing capability greatly reduces the process memory burden on your VOIP application. The primary reason this is true is because conferencing support requires all sorts of internal “cross wiring” of logical phone lines. This cross wiring of signal paths internally also introduces additional audio signal paths, audio sample block buffering and digital mixing of audio data. All of these operations consume additional memory. If you cannot disable conferencing support, see item 2 below.
Conference support is enabled or disabled by setting the Boolean “CallConferenceEnabled” media engine start-up parameter.
Item2 – Reduce internal signal path buffering size:
The VOIP Media Engine internally is complex. It must route and manage audio data that is transmitted and received on each phone line. It must digitally mix various audio data streams in “real time”. It must playback and record from the host’s multimedia hardware. It must also manage all the logical signal paths that are possible when conferencing capabilities are enabled. It manages local audio playback and full transmit and receive IVR interfaces for each phone line. In short, the media engine has a lot of work to do and always has a certain amount of audio data buffered at any one time.
By default, the media engine will configure itself using internal signal paths consisting of about 1.28 seconds of digital audio (64-20Ms block buffers per internal signal path). This internal signal path buffering for most applications can be greatly reduced.
Internal signal path buffering is specified by the “MaxMixerLinebuffers” media engine start-up parameter. Here is an excerpt from the VOIP Media Engine Developer’s Reference:
MaxMixerLinebuffers
Specifies the max signal buffering that occurs internally in the media engine. Each mixer line buffer represents 20Ms of audio sample data. The internal default value for this parameter is 64. If you do not want to change the default value when the media engine is initialized, then specify a value of zero.
This parameter affects the max buffering depth for all internally handled audio sample blocks during digital mixing operations. Reducing this value will save memory but at the cost of possible interrupted or "choppy" audio. This value also has the effect of capping the maximum received voice delay that a phone line will experience.
If you really want to lower the process memory that is used for internal signal buffering, try setting this startup value to 16 (16-20Ms sample blocks is 320Ms total buffering per internal signal path). If you notice any broken or “choppy” audio as the result of the platform you are running on, increase this value until audio is acceptable.
Item3 – Set your default application stack size to less than 1 megabyte:
This is something you do when your build your application. Normally, most applications have a default stack size of 1 megabyte. For each thread your application (and the VOIP Media Engine) creates, 1 megabyte of memory is basically reserved as a stack for that thread.
If the total number of threads in your app is high, then a lot of memory may be consumed needlessly. When we develop VOIP applications at LanScape that are based on the VOIP Media Engine (either for our own use or for customers who have contracted with us to do the devlopment), we usually set our default stack size to 0x7a120 bytes (1/2 of 1mg or 500,000 bytes per thread). This cuts in half the thread stack memory required per thread in your application.
However, be careful though when reducing the default stack size. Reducing it too far will eventually cause stack overflows and program crashing. The VOIP Media Engine does not rely heavily on thread stacks so the limiting factor here will probably be the stack requirements of some other library or DLL that your application uses. Experimenting and fully testing your VOIP app when aggressively reducing the default stack size is the best way to tune your memory requirements when using this technique.
Benchmark Figures (Process memory, threads and handle counts):
For testing purposes, we have a various number of test applications we use in our lab when performing evaluation of the VOIP Media Engine. One such test app is a simple GUI utility called CallTester.exe.
CallTester.exe is a simple dialog based MFC app developed in C++. Its main purpose is to allow us to enable and disable specific capabilities in the media engine and test memory and thread consumption in addition to basic VOIP Media Engine call and process behavior.
Using this test app, we configured and started the latest version of the VOIP Media Engine as follows:
Max number of phone lines: 768
Max internal signal path length: 16 (320Ms)
Call conferencing: disabled
Default stack size: 500,000 bytes.
After Instantiating the media engine and letting it sit idle (no call processing), here are the process parameters:
Memory usage: 216,624K
Handles: 18,540
Threads: 2,311
The CallTester.exe utility also has the ability to initiate and receive phone calls. We then configured it to call itself. It uses phone lines 0-383 to make outgoing calls and uses phone lines 384-768 to answer the incoming calls.
We started the call test and allowed all 768 phone lines to be in the “In call” state. When phone lines are in this state, we refer to them as being “active”. After all phone calls are connected, the utility then waits for us to tell it to terminate the calls. At the time all 768 phone lines were active, these are the process parameters:
Memory usage: 325,416K
Handles: 34,361
Threads: 3,080
Then after terminating all the calls (thus terminating all the calls on all 768 phone lines), process parameters returned to the pre-call states.
Note:
If you have specific questions or comments regarding this forum post and its contents, please start a new thread and reference this forum thread in your new post. Please do not post to the end of this thread. Thanks.
Support
|
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: Deploying large line media engines (Memory/Threads)
