Performance metrics

Performance is a popular and key component of the decision to adopt a particular brand or model of media gateway. While popular, the notion of performance for the purposes of comparison is often hard to nail down. This is due to both the underlying details of the hardware being compared as well as the applications and production environments that are unique to each service provider. There is not even a commonly accepted, universal, 'metric' for comparing performance across systems. The most frequently heard one, 'calls per second' can actually refer to many things. For our purposes, we will focus on bridged calls per second (BCPS).

Important note: This page provides information on the performance of TelcoBridges products. Performance of each TelcoBridges device described here is based on a specific testing scenario and system configuration. Please note that TelcoBridges makes no claims, promises or guarantees regarding the actual performance of its products in a real-world production environment.

System resource requirements

The TDM or VoIP resources required by a telephony system can be calculated using a simple equation:

 CPS X average call duration = amount of resources required

To better estimate the amount of TDM and/or VoIP resources required by an application, it is important to define the call duration.

Call Duration

A telephone call consist of 3 parts:

• The establish part of a call consists of the signaling to establish the call (i.e. INVITE, 180 Ringing, 200 OK for SIP). It also contains the allocation and the connection of TDM and/or VoIP resources
• The active part consist of the 'useful' part of the call (i.e. users can now talk). The call is established and the media is connected
• The tear down of the call consists of the signaling of the call (i.e. BYE for SIP). It also contains the dis-connection and the de-allocation of the media (TDM and/or VoIP) resources

These three concepts are displayed in the figure below.

The call duration is the sum of those 3 parts and the duration of each may vary greatly according to the type of application. For example, voice mail applications will most likely have a very short 'Establish' time, since the application will answer the call immediately because it will not let it ring for long. For fax applications, the average 'Active' time will be longer than other types of calls (because of fax negotiation requirements).

Performance variables

Different factors may influence the performance expressed in calls per second (CPS) and call duration.

Establish

Calls, whether answered or not, will reserve outgoing resources even they are not connected until the end user answers. An exception to this is the case of early media and ring/ringback tones, which require allocation and connection.

The Establish CPS performance will vary according to these factors:

• Signaling protocol used: SIP is the most CPU-intensive protocol, much more than ISDN or SS7
• IVR resources: if the application requires IVR, it will increase CPU usage on the device
• VoIP resources: if the application requires VOIP, it will increase CPU usage on the device, much more than TDM resources do
• Percentage of unanswered calls: calls that are never answered require less CPU, since resources are not allocated and connected
• Early media: this call option forces resources to be allocated and connected even if the call is not answered yet; it is as CPU-intensive as a regular call that is answered even if the early media call is not answered yet
• Ring tone/ringback tone: same as early media

The Establish length will vary mostly because of these factors:

• Signaling protocol used: SIP takes a little longer to process, longer than ISDN or SS7
• Answer time: if the Tmedia terminates the call, the Establish length will be a lot shorter since the call will be answered immediately
• Average unanswered ring time: even though the call is not answered, it still reserves resources for the time it is ringing

NOTE: A ring is 6 seconds long, that is 2 seconds on and 4 seconds off.

Active

An Active call is not 'expensive' in terms of CPU time when compared to the resources required for allocation and connection.

The Active length will vary according to the type of application. IVR applications average call lengths of 20 seconds, while fax applications can be 4-5 minutes.

Tear down

Answered calls will eventually require disconnecting and deallocating the resources used, therefore they can be quite CPU intensive. As for unanswered calls (except when using early media or ring back tone), they only use signaling and are nominally CPU-intensive.\\ The Tear down CPS performance will vary according to these factors:

• Signaling protocol use: SIP is the most CPU intensive protocol, more than ISDN or SS7.
• IVR resources: if the application requires IVR it will increase CPU usage on the Tmedia.
• VoIP resources: if the application requires VoIP it will increase CPU usage on the Tmedia, much more than TDM resources will.
• Percentage of unanswered calls: calls that are never answered requires less CPU since the resources are not allocated or connected.
• Early media, this call option force the resources to be allocated and connected even if the call is not answered yet, it is as CPU-intensive as a regular call that is answered even if the early media call is not answered yet.
• Ring tone / ring-back tone, same as early media.

The Tear down length will vary mostly because of these factors:

• Signaling protocol use, SIP takes a little longer to process, longer than ISDN or SS7.

Limiting the call rate

Available limits

The Toolpack system can regulate call rate:

• Per NAP
  • Maximum call legs per second (incoming, outgoing or total)
  • Maximum simultaneous incoming, outgoing and/or total calls
  • Maximum processing delay
  • Maximum TMedia Unit CPU usage
• Per TMedia unit
  • Maximum call legs per second (per protocol type or total)

Limiting the call rate can be configure through Web Portal (Warning: this feature is available for 2-5-94 or later).

• For the NAP, go to the Nap menu page.

• For the Tmedia unit, go to the Hardware menu page.

Algorithm used

The algorithm to limit the call rate is based on the 'leaky bucket' algorithm. Two values define the algorithm behavior:

• (A) Maximum calls per second
• (B) Maximum calls burst

Tokens are added to the bucket at a regular rate of (A) per second, until the bucket contains a maximum of 'B' tokens. When an incoming call is received, or outgoing call needs to be made, a token is taken from the bucket, or the call is refused if the bucked is empty.

This allows to absorb call bursts of up to (B) consecutive calls without dropping any calls, and also protects from an average call rate that's higher than (A) calls per second.

Typical usage

Call rate limiting is generally used to avoid overloading a system's CPU (local system or remote systems). Local system is generally protected using a per-adapter limit. Remote systems are generally protected using a per-NAP limit.

Maximum simultaneous calls limit is generally used to protect a NAP from being overloaded. It's frequently used for SIP NAPs to avoid RTP bandwidth to exceeds the capacity of the IP network. It's less frequently used for ISDN, CAS or SS7 as the number of CICs in the NAP already provides a limit to the number of simultaneous calls.

References

• TMG7800 Toolpack performance tests (registration required)