Dimensioning Asterisk: Best Practices for Performance Optimization and System Resource Allocation

Introduction

The successful implementation of an Asterisk system is marked by optimal performance, resource allocation, and scalability. Dimensioning Asterisk requires accurately assessing factors such as call volume, hardware requirements, network bandwidth, codec selection, redundancy, and growth potential, organizations can build a robust telephony infrastructure that meets their specific needs.

In this article, we delve into the key considerations for Dimensioning Asterisk and provide insights into each aspect. From hardware specifications to network bandwidth planning and the selection of codecs, we explore the crucial factors that impact system performance. Additionally, we discuss the importance of redundancy and failover mechanisms, as well as the significance of monitoring and performance optimization in maintaining a high-quality Asterisk deployment.

Factors to consider when dimensioning Asterisk

Regarding Dimensioning Asterisk, several factors need to be considered to ensure optimal performance and resource allocation. Here are some key aspects to consider when Dimensioning Asterisk:

Call Volume (Simultaneous Calls):

Estimate the expected call volume or concurrency level for your Asterisk system. This includes the number of simultaneous calls you anticipate, as well as the peak hours or periods of high call traffic. This information will help determine the required processing power and resources. The higher the number of simultaneous calls, the more it degrades.

Registered Devices

The number of registered devices can have an impact on the system’s performance and speed. Here are a few ways registered devices can affect Asterisk:

1. Resource Utilization: Each registered device consumes system resources, including CPU, memory, and network bandwidth. The more devices registered with Asterisk, the more resources are required to handle their signalling and media traffic. If the system is not adequately provisioned to handle the load, it can lead to performance degradation and slower response times.
2. Call Processing: When a call is made or received by a registered device, Asterisk needs to handle call setup, call routing, media negotiation, and other call processing tasks. The higher the number of registered devices, the more concurrent calls and call processing load Asterisk has to manage. If the system is overwhelmed with simultaneous calls from numerous registered devices, it can impact call quality and responsiveness.
3. System Scalability: Asterisk’s scalability can be influenced by the number of registered devices. As the number of registered devices increases, the system needs to handle a larger number of signalling and media streams. It’s essential to ensure that the Asterisk server and network infrastructure are designed and configured to accommodate the anticipated number of registered devices to maintain optimal performance.

To optimize Asterisk’s performance with a large number of registered devices, it’s important to assess the system’s resources, implement proper network design, and consider load balancing and clustering techniques, if necessary. Regular monitoring and capacity planning can help identify and address any performance bottlenecks before they impact the system’s speed and responsiveness.

Call Attempts Per Seconds (CAPS):

Calls Attempts Per Second or CAPS refers to how many telephone call initiation attempts can be handled in a second. Asterisk servers can support up to 50 – 100 CAPS (most of the time it’s closer to 20 depending on the configuration). For example, sending constant 150+ CAPS traffic to a particular Asterisk box can be problematic if the Configuration Architecture does not have a Proxy in it.

Codec Selection

Choose the appropriate codecs based on your requirements. Different codecs have varying resource demands and affect call quality.
For example, Some codecs, such as G.711, are less resource-intensive but consume more bandwidth, while others, like G.729, require fewer network resources but more processing power. One G.729 transcoding session takes 13 million instructions per second (MIPS) to encode and decode, so a hundred G.729 transcoding to G.711 may be very CPU intensive.
Codecs like Opus take about 30-70 MFLOPS (Mega floating point operations per second) depending on whether it is a narrow band or wide band.
The chosen codecs will impact the hardware requirements and network bandwidth.

Hardware Requirements:

Consider the hardware specifications necessary to handle the expected call volume. Factors such as CPU power, memory (RAM), and disk storage will impact the performance and capacity of your Asterisk system. Higher call volumes may require more powerful hardware, especially if you plan to use advanced features or codecs, Generate CDRs, etc.

For Example,
Disk I/O: SATA HD Supports only 75 IOPS (inputs outputs per second); so generating 100 CDRs may be problematic as each CDR Generates I/Os for Data and indexes in the database. Since SAS Disk is more optimal for use in servers and workstations because it has a more versatile array of connectors and is faster at reading and writing data in a continuous computer session. It is wise to use SAS over SATA. Do not exceed more than 200 IOPS on SAS 15K RPM

Which to use? Telephony Cards OR SIP Trunking?

Telephony cards, or Telephony Interface Cards (TICs), are physical hardware components that are installed in a computer or a server. These cards act as an interface between the computer and the traditional telephone network (PSTN).

They are typically used in legacy telephony systems that rely on physical phone lines, such as analogue or digital telephony systems, enabling the computer or server to connect to the telephone network and handle incoming and outgoing calls, converting analogue signals from the phone lines into digital data that the computer can process.

The Asterisk DAHDI package includes drivers for a number of traditional telephony interface cards, most notably the telephony cards manufactured by Sangoma, the creator of Asterisk. These cards are available for both Analogue and Digital configurations. On-board TICs are industrial-grade echo cancellation is available on mostly digital telephony cards, offering superior audio quality along with reduced CPU usage to ensure optimized system performance.

On the other hand, you may consider using SIP (Session Initiation Protocol) trunking, a method of delivering telephone and unified communications services over the Internet that uses the Internet Protocol (IP) to transmit voice, video, and other unified communications sessions instead of traditional phone lines, enabling organizations to connect their IP-based PBX systems directly to an Internet Telephony Service Provider (ITSP) or a SIP trunk provider. This eliminates the need for traditional phone lines and allows for more flexible and cost-effective communication options. SIP trunks can support multiple concurrent calls, and the number of channels can be easily adjusted to meet the organization’s requirements.

In summary, The choice between telephony cards and SIP trunking depends on the specific requirements, infrastructure, and preferences of an organization. However, considering the benefits of SIP trunking, it is highly recommended over Physical cards. Consult with a SIP trunk provider who can assist you with accurately dimensioning your trunk based on your specific requirements. They can provide guidance on bandwidth, and codec selection, and help you choose an appropriate plan.

Network Bandwidth

Assess your network bandwidth requirements, including the anticipated inbound and outbound call traffic. Ensure that your network infrastructure can handle the expected call volume without significant latency or packet loss.

Bandwidth Calculation:

To calculate the bandwidth required per call based on the selected voice codec, you need to understand that different codecs have varying bandwidth requirements. For example, G.711 requires approximately 64 Kbps, while G.729 requires around 8 Kbps. By multiplying the bandwidth per call by the estimated number of simultaneous calls during peak periods can be used to determine the total required bandwidth capacity.

For example:
If each call requires 100kbits/sec including overhead, then 1000 Calls will require a device that can handle a bandwidth of about 100Mbps, That is:

100kb/s bandwidth x 1000 calls = 100,000 kb/s or 100Mbits/s (Mbps) or 12.5Megabytes/sec (MBps).

This also means that a network speed greater than 100Mbits/s (Mbps) or 12.5Megabytes/sec (MBps) is required for smooth operations. You should have a High bandwidth connection with giga speed for such a setup!

Definition:
The speed at which data is transmitted or received is known as network speed, while the maximum capacity of a network to transmit data is called bandwidth. A network with higher bandwidth has the potential to support faster network speeds, but the actual speed experienced by users may be lower due to several factors, including network congestion and device limitations.

Table Showing Codecs Bandwidths and Overhead

Regular Audio Codecs	Name	Bandwidth (Excluding overhead)	Bandwidth (including overhead)	Bandwidth required for 5 concurrent calls	Quality
G.711 a/u-law	PCM	64.00 Kibps	80 – 90 kbit/s	512 kbit/s	ISDN
G.729	CS-CELP	8.00 Kibps	35.00 kbit/s	200 kbit/s	good
iLBC	iLBC	15.20 Kibps	32.00 kbit/s	200 kbit/s	good
G.722	G.722	56.00 Kibps	72.80 kbit/s	464 kbit/s	good
G.722 over ISDN	G.722	64.00 Kibps	80.00 kbit/s	512 kbit/s	ISDN good
G.723.1	MP-MLQ	1 – 6.10 Kibps	21.00 kbit/s	110 kbit/s	average
G.723	A-CELP	5.3kibps	15.00 kbit/s	80 kbit/s	average
GSM fullrate	GSM	13.00 Kibps	13.00 kbit/s	80 kbit/s	average
G.726	AD-PCM	32.00 Kibps	55.00 kbit/s	386 kbit/s	GSM
Opus	Opus	Variable Bandwidth from 6kbit/sec to 514kbit/sec depending on available Bandwidth	8.4 – 719.60 kbit/s	45 – 3600 kbit/s (3 Mbps)	Excellent
SpeeX	SpeeX	2 to 44 kibps	4 – 80 kbit/s	25 – 300 kbit/s	variable

Determining the size of your SIP Trunks

In the past, companies used ISDN circuits that needed to be physically installed on their premises. Now, instead of routing voice calls over copper lines in these circuits, SIP trunking sends them over data networks.

When it comes to SIP Trunk sizing, overprovisioning bandwidth will inevitably result in a high total cost of ownership that surpasses the necessary levels and removes the chances of a return on investment. Conversely, an insufficient allocation of bandwidth will give rise to blocked calls, thereby causing an upsurge in abandoned calls and reduced productivity among contact centre and help desk agents. it is imperative to avoid such undesirable scenarios altogether.

When Dimensioning Asterisk SIP trunk size it’s important to know your desired Grade of Service (GoS), which represents the probability or likelihood of a caller encountering a busy signal when placing a call to a call centre or Office or IVR systems. The outcomes of the Grade of Service (GoS) calculations consistently range between 0 and 1. A low probability, such as less than 0.05, indicates that the call center is efficient in managing incoming traffic. Conversely, a high GoS value, exceeding 0.1, suggests that the call center experiences a substantial number of frustrated and impatient callers.

Also when determining SIP trunking, consider whether or not unanswered calls are going to be dropped or queued in your dialplan setup.

Definition: What are Erlangs?
Telecommunications traffic is measured in dimensionless units called Erlangs. The number of Erlangs of traffic is equal to the average number of calls received per unit of time, multiplied by the average duration of a call.

Calculating SIP trunk for a system where unanswered calls are dropped

Although the Erlang B formula is used for calculating the GoS, the Erlang B formula it can also determine how many phone lines are needed to attain a desired Grade of Service, given a certain known or expected level of traffic.

The Erlang B Formula

The formula provides the GoS (Grade of Service) which is the probability P_b that a new call arriving to the resources group is rejected because all resources (servers, lines, circuits) are busy: B(E, m) where E is the total offered traffic in erlang, offered to m identical parallel resources (servers, communication channels, traffic lanes).

where:

• P_b is the probability of blocking
• m is the number of identical parallel resources such as servers, telephone lines, etc.
• E = Average number of calls/unit time x h (average call duration); offered traffic stated in Erlang – Where both parameters must share the same unit of measurement.

Example

If a call centre has 10 phone lines, receives 480 calls per day, and the average duration of a call is 15 minutes. Find the Grade of Service.

using the formula:

E = 5 ; (that is, 480 calls/day x 0.0104167 days). Since 15 minutes = 0.0104167 days (Computing Erlangs requires that call frequency and call duration be in the same units of time. You will get the same number no matter which units you use, Whether you convert days to minutes or minutes to days.)
m = 10; (that is, m is the number of identical parallel resources such as servers, telephone lines, etc.)

so, therefore using the first principles method:

m! = 10! = 10 x 9 x 8 x 7 x 6 x 5 x 4 x 3 x 2 x 1 = 3,628,800
E^m = 5¹⁰ = 5 x 5 x 5 x 5 x 5 x 5 x 5 x 5 x 5 x 5 = 9,765,625
E^m/m! = 9,765,625 / 3,628,800 = 2.691144456

the sum = ∑^m_n=0 Eⁿ/n! means, calculate the looped sum Eⁿ/n! from when n = 0 to when m = 10;

sum = (5⁰ / 0! ) + (5¹ / 1! ) + (5² / 2! ) + (5³ / 3! ) + (5⁴ / 4! ) + (5⁵ / 5! ) + (5⁶ / 6! ) + (5⁷ / 7! ) + (5⁸ / 8! ) + (5⁹ / 9! ) + (5¹⁰ / 10! ) = 143.689

Thus, the probability that a call is blocked is:

P_b , probability of blocking = 2.691144456 / 143.689 = 0.01873

This means about 1.87% of the calls get dropped. As M becomes large, calculating GoS by hand becomes unwieldy, thus Erlang calculators must be used.

Calculating SIP trunk size for a system where calls are Queued

If you know or have an estimated traffic level in Erlang and the number of trunks (e.g. phone lines or servers), then you can

Subsequently, the second Phase entails the calculation of the bandwidth required to accommodate the determined number of SIP trunk sessions as per the Erlang calculations. In this context, trunks refer to the number of lines or sessions required to facilitate the transmission of calls.

Applications

Applications play a crucial role in extending the functionality of Asterisk and enabling advanced features such as IVR, Conference Room(s), etc. However, they can also affect system performance depending on their complexity, resource usage, and how efficiently they are designed and implemented. Let’s explore how applications can impact Asterisk performance:

1. Application Complexity:
   • Complex applications with intricate logic and extensive feature sets can consume more system resources and processing power. This can potentially impact overall system performance.
   • Applications that require heavy database interactions, external API calls, or complex real-time data processing may introduce additional latency and resource usage, affecting call-handling capabilities.
2. Resource Utilization:
   • Applications that extensively use Asterisk’s internal resources, such as channels, bridges, and media streams, can strain the system. This includes applications like conferencing, call recording, and voicemail.
   • Applications that utilize CPU-intensive operations, such as speech recognition or transcription, can impact the overall processing capacity of the system, potentially leading to delays or dropped calls.
3. Call Routing and Dialplan Logic:
   • The design and complexity of the dialplan and call routing logic can impact performance. Poorly optimized dialplan configurations with complex conditions, loops, or excessive use of macros can introduce processing overhead and increase call setup time.
   • Inefficient call routing decisions or excessive call transfers can add unnecessary load to the system, affecting its ability to handle concurrent calls efficiently.
4. Third-Party Integrations:
   • Integrating third-party applications or services with Asterisk can introduce additional performance considerations. This includes CRM systems, database lookups, external APIs, or custom applications.
   • Poorly optimized integrations or inefficient data retrieval processes can introduce delays and impact call-handling capabilities.
5. Code Efficiency and Optimization:
   • Well-designed and optimized application code can significantly improve performance. Efficient use of variables, loops, and functions, as well as proper memory management, can minimize resource consumption.
   • Regular code reviews, performance profiling, and optimization efforts can identify and address bottlenecks, improving the overall efficiency and responsiveness of applications.

Scalability and Load Balancing:

As the number of concurrent calls and application usage increases, it becomes essential to consider scalability and load-balancing mechanisms. Distributing the load across multiple Asterisk servers, utilizing clustering or session border controllers, can ensure efficient utilization of resources and maintain high performance.

It’s important to note that the impact of applications on Asterisk performance can vary depending on the specific use case, complexity, and resource requirements of the applications. Regular performance testing, monitoring, and optimization efforts are crucial to ensure that the system can handle the desired call volume and application usage effectively while maintaining high-quality call-handling capabilities.

Redundancy and Failover

Consider whether you need redundancy and failover mechanisms in your Asterisk deployment. Redundancy ensures system availability and can be achieved through load balancing, clustering, or high-availability setups. Determine the level of redundancy required based on your business needs and the criticality of the telephony services.

Add-on Modules and Features

Identify any additional modules or features you plan to use with Asterisk. Some modules, like conferencing or call recording, may require additional resources. Account for these extra demands when dimensioning your system.

Performance Testing, Growth and Scalability:

Rigorous testing using tools like SIPp or Sippy Cup to simulate future growth and scalability. Consider how easily your Asterisk system can accommodate increased call volume or additional features. Assess whether the chosen hardware and architecture can be expanded or upgraded as needed.

Monitoring and Performance Optimization:
Implement monitoring tools to assess system performance and make necessary adjustments. Regularly analyze system logs and monitor resource usage to identify potential bottlenecks or areas for improvement.

It is important to note that Dimensioning Asterisk system can vary based on specific requirements, so it is advisable to consult Asterisk documentation, and resources, or engage with experienced Asterisk professionals for precise guidance tailored to your unique setup.