> For the complete documentation index, see [llms.txt](https://prosbcdocs.telcobridges.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://prosbcdocs.telcobridges.com/telecom-references/transmission-and-lines/performance-metrics.md). # 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](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/transmission/tdm/README.md) or [VoIP](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/sip-voip/voip/README.md) 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](https://telcobridges.com/learning/sip-trunking/what-is-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. ![Call duration](https://docs.telcobridges.com/w/images/c/cb/Call-duration.png) 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](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/voice-media/ringback-tones/README.md) 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](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/protocols/isdn/README.md) or [SS7](https://telcobridges.com/media-gateways/solutions/signaling/migrating-ss7-sigtran/) * [IVR](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/concepts/ivr/README.md) 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](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/protocols/nap/README.md) * 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](https://github.com/telcobridges-main/tmedia-wiki/tree/main/tmedia/configuration/web-portal/README.md) (Warning: this feature is available for 2-5-94 or later). * For the [NAP](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/protocols/nap/README.md), go to the Nap menu page. ![NAP Call Rate Limit](https://docs.telcobridges.com/w/images/0/03/NAP_Call_Rate_Limit.png) * For the Tmedia unit, go to the Hardware menu page. ![Hardware Call Rate Limit](https://docs.telcobridges.com/w/images/0/0f/Hardware_Call_Rate_Limit.png) #### 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](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/protocols/nap/README.md) limit. Maximum simultaneous calls limit is generally used to protect a [NAP](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/protocols/nap/README.md) 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](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/protocols/isdn/README.md), [CAS](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/protocols/cas/README.md) or [SS7](https://telcobridges.com/media-gateways/solutions/signaling/migrating-ss7-sigtran/) as the number of CICs in the [NAP](https://github.com/telcobridges-main/tmedia-wiki/tree/main/reference/protocols/nap/README.md) already provides a limit to the number of simultaneous calls. ### References * [TMG7800 Toolpack performance tests](https://forums.telcobridges.com/viewtopic.php?f=13\&t=123\&p=505#p505) (registration required) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://prosbcdocs.telcobridges.com/telecom-references/transmission-and-lines/performance-metrics.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.