Handling many simultaneous calls

Revision as of 13:36, 5 October 2012

Handling many simultaneous calls

The ability of handling a large number of calls is not only a matter of Yate configuration but also of system setup. Hardware devices and VoIP protocols also have specific demands on the system that place different limits on how many simultaneous calls can be handled and how fast can they be established.

System resources

Handling many calls will place a large demand on system resources. Here are some guidelines:

• CPU speed - Nice to be high but not critical unless you perform transcoding (codecs) or encryption.
• CPU number (or cores) - The more you have the best Yate will behave. Hyperthreading also helps but less.
• CPU instruction set - A 32 bit CPU is just fine, 64 bit won't bring better performance. Better get more cores.
• Installed Memory - Most protocols do not demand a lot of memory but try to have at least 1GB.
• Virtual Memory - Configure the system to allow plenty of virtual memory (ulimit -v) for Yate.
• Maximum file handles - There should be at least two file handles per call leg, more on some protocols. By default Yate configures 8192 handles at compile time which you should also allow at runtime (ulimit -n).
• Maximum threads - Allow for at least one per call leg, more (or many more) on some protocols. Do not use old (pre-NPTL) Linux kernels as the performance is poor and they eat one extra file handle per thread.
• Network card - Quality of drivers is more important than manufacturer declared performance.

TDM cards

To handle large number of calls try to use Sangoma cards with the BITSTREAM API as it offers an efficient way to move the data from and to the kernel space. The Zaptel API requires one file handle and one thread per timeslot therefore spending more time in user-to-kernel transitions.

Expect to handle in the order of hundreds of call legs with Wanpipe drivers.

H.323 specific

NOTE!!!! Please if you use Linux to setup ulimit -n 8096. This will setup the number of open files (file handlers) Yate is allowed to use.

This is a very demanding VoIP protocol because of its complexity and also some implementation issues. You will need plenty of virtual memory, file handles and threads to handle many calls. Depending on configuration of both endpoints there can be as many as 7 file handles and 5 threads per call leg.

It is highly recommended to use the Yate RTP implementation as it gets far better performance than OpenH323's builtin RTP support.

Please see this excellent document that describes common H.323 performance issues and specific PWLib and OpenH323 problems and solutions: Increasing the Maximum Call Density of OpenH323 and OPAL

Expect to handle in the order of hundreds of call legs with H.245 tunneling and Yate's RTP.

SIP specific

This protocol allows for the maximum call density supported by Yate. Signalling over UDP sockets is quite efficient. Just for signaling (no RTP) there can be thousands of simultaneous calls. If voice data passes through Yate please see the RTP specific issues.

IAX specific

The IAX protocol could potentially deliver the largest number of simultaneous calls but unfortunately is plagued by bad design decisions and typical operating system handling of network sockets.

We do not recommend IAX for handling large number of calls because of these design problems.

If you still want to use it note that the major bottleneck is that just one socket queue is used by all signaling and voice packets. The kernel performance (in network and scheduling) must be fine tuned to properly handle large number of calls.

RTP specific

As it's used by most VoIP protocols for moving around the voice data, RTP configuration is one of the factors that influences most the maximum number of calls.

As a rule you will need 2 file handles (1 if RTCP is disabled) and one thread per simultaneous call leg.

RTP deals with many small packets. The kernel and network card performance and a high number of CPUs will help handling many simultaneous calls.

Since timing of packets arriving on network is not predictable a good kernel scheduler performance is desired. Please use a recent (2.6+) Linux kernel.

If RTCP is not required you can disable it - this will save one file handle per call leg and around 5% of the CPU usage of RTP.

Secure RTP (SRTP) is a performance killer. Even if encryption is disabled (authentication only) expect around 5 times less call legs on SRTP compared with plain RTP