The Performance Reality of Session Border Controllers

sonusnetworks.com

The Performance Reality of Session Border ControllersHow to Effectively Define, Evaluate and Measure IP Session Control Requirements

A Sonus Networks White Paper sonusnetworks.com

sonusnetworks.com

The Performance Reality of Session Border Controllers

sonusnetworks.com

Table of ContentsIntroduction 2

Session Control: Measuring for Success 2

Real-World Performance Factors 3

Number of Subscribers 3

Number of Concurrent Calls 3

Call Attempts Per Second (CAPS) 3

Codec and Sample Rates 4

Performance Under Attack 5

Performance Under Load 5

Transcoding 6

Signaling Manipulation 6

The Performance Impact of NAT Traversal 6

The Performance Impact of Presence 8

Encryption 9

SIP Call Flows 9

High Availability 9

Centralized vs. Distributed Routing 9

Use Case Scenarios 10

Residential Broadband VoIP 10

SIP Trunking 11

Carrier-to-Carrier Peering 12

Scalability in the Real World 12

Conclusion 13

IntroductionSession Border Controllers (SBCs) will play a vital role in the next generation of IP network architectures.

That’s the consensus from global service providers polled in a recent survey by Infonetics Research

(“SBC Deployment Strategies,” October 2009). The survey found that capacity, scalability, and

performance were the #1 considerations of service providers when selecting a session border solution.

And they’ll have plenty to consider, as IP traffic is expected to double over the next four years.

While network operators know that IP voice and multimedia traffic will grow for the foreseeable future,

planning a session border strategy around that growth has proven problematic. SBC vendors have

historically underestimated the complexity of IP session control when publishing their performance and

capacity numbers, often basing those figures on simplistic SIP call flows, erroneous bandwidth figures,

and a limited subset of factors. As a result, network operators may find it necessary to deploy more

boxes than anticipated, thereby increasing deployment complexity and cost despite their best efforts to

predict capacity and bandwidth.

At Sonus Networks, we believe that the typical approach to evaluating SBC capacity based on number

of subscribers, concurrent sessions, and Call Attempts Per Second (CAPS) is a good beginning, but it’s

only a beginning. Network operators need to look beyond these basic metrics to weigh other key factors

such as the network application, media transcoding, Network Address Translation (NAT) traversal, and

encryption—factors that can heavily influence SBC performance.

This white paper seeks to explore SBC capacity and performance measurements by sharing the lessons

learned from Sonus Networks’ decade-plus leadership in VoIP and IP session control. In particular, we’ll

highlight performance factors that every network operator should consider, how those factors change in

various application settings, and the SBC features/functions that separate the true performers from the

underperformers.

Session Control: Measuring for SuccessWhen SBCs were first introduced, Voice over IP (VoIP) was the exception in a world still ruled by digital-

switched networks. SBC performance was rarely challenged because early IP-to-IP connections served

a minority of subscribers/sessions. The primary business driver for an SBC was security; capacity and

performance were secondary concerns that, conventional wisdom went, could always be “solved” by

adding more boxes to the network (a practice that still prevails today).

As session-based traffic explodes—and the promise of data, video, and voice convergence on an

IP infrastructure is realized—network operators require more from their SBCs than simply security;

multimedia support, network intelligence, and transcoding capabilities must be tightly integrated as

well. For their part, many SBC vendors have responded by adding new functionality like call routing

and transcoding into their products. However, performance in a multimedia environment still remains

an Achilles heel for many SBCs, resulting in an ever-growing number of network elements that are

becoming increasingly difficult to manage.

sonusnetworks.com

The Performance Reality of Session Border Controllers

sonusnetworks.com

Traditionally, SBC vendors measure capacity and performance using basic metrics such as number

of subscribers, maximum concurrent sessions, and CAPS. Capacity planning then follows the simple

logic of aligning box capacity with network requirements. If an SBC claims to support X number of

concurrent sessions, the logic goes, then two boxes should support a network with a maximum of 2X

concurrent sessions. This approach is flawed in its presumption of a very simplified SIP session with

no concessions for the network environment or additional features like transcoding and encryption.

Planning a VoIP network based on an idealized expectation of IP session requirements can have dire

consequences including overloads, outages, lost transactions, and compromised network integrity.

Real-World Performance FactorsEffectively measuring session border requirements demands a holistic perspective that looks at

the reality of SIP sessions and considers the bandwidth/performance factors beyond the superficial

characteristics of subscriber and session numbers. Each of the following real-world performance

factors should be carefully weighed and explored when evaluating SBC solutions.

Number of Subscribers

For access network environments, an obvious metric for capacity is the maximum number of

subscribers that can be supported by an SBC. But be careful: this number often fails to take into

consideration factors like NAT traversal or quality assurance measures, which can boost SIP session

complexity considerably and dramatically reduce the number of subscribers that can be supported.

Maximum Concurrent Sessions

This is a theoretical maximum number of media sessions that can be handled by the SBC at one

time. In today’s network environments, the maximum number of concurrent sessions is becoming an

increasingly irrelevant metric. Network operators are often facing other “choke points” in the network

that determine capacity before the number of sessions over a Gigabit Ethernet (GigE) interface are

reached. In a peering environment, this might include the number of Virtual LANs (VLANs) that can be

supported or, in an access environment, the impact of control plane policing on the traffic flow where a

1:1 subscriber/flow control policing ratio is required.

Call Attempts Per Second

CAPS represent the number of call attempts per second. SBC vendors offer quote CAPS under ideal

conditions, such as a peering or trunking topology with a very simple SIP call flow (e.g., seven SIP

messages) and without any additional features or functions enabled (transcoding, etc.). This inflates

performance numbers and does not give a true indication of an SBC’s call handling capabilities under

real-world conditions. In addition, the CAPS numbers presented by SBC vendors are often based on

UDP transport and not Real-Time Transport Control Protocol (RTCP). This is an important distinction

because RTCP requires an extra pinhole for the RTCP stream, which can reduce the maximum number

of concurrent calls supported by up to 50%.

Codecs and Sample Rates

SBCs typically connect to the network via GigE interfaces—one for the trusted network and a matching

interface for the untrusted (peer) network—with each session passing through both interfaces. The

media handling capacity of an SBC using a GigE interface varies greatly depending on the media

codec; G.711, for example, has an approximate capacity of 10,000 sessions over a GigE interface.

Even the same codec at the same sample rate can have different bandwidth numbers depending on

the calculations used. For example, G.711 sampled at a 20-millisecond rate has a listed bandwidth of

between 87.2 kpbs and 95.2 kbps. Why the difference? Because the lower figure omits the portion

of the Media Access Control (MAC) Ethernet frame that goes undetected by “sniffing” tools—the MAC

frame/preamble, start-of-frame delimiter, and inter-frame gap—even though it still consumes 20 bytes

of bandwidth per frame. This consideration pushes the G.711 - 20 ms bandwidth to 95.2 kpbs, and

reflects a much more accurate picture of bandwidth requirements.

Below is a list of popular voice codecs, their payload sizes, and payload delivery expressed as Packets

Per Second (PPS). The estimated bandwidth for each is calculated using the following formula:

[Voice Payload + 58 bytes (IP/UDP/RTP and Ethernet L2 headers)] x PPS

The actual bandwidth is calculated as follows:

[Voice Payload + 58 bytes (headers) + 20 bytes (other MAC frame elements)] x PPS

The final number in both calculations is then multiplied by eight, as bandwidth is expressed in bits

(one byte = eight bits).

Codec Voice payload PPS Est. bandwidthActual

bandwidth

G.711 160 bytes 50 87.2 kbps 95.2 kbps

G.722 160 bytes 50 87.2 kbps 95.2 kbps

G.723.1 20 bytes 33.3 20.8 kbps 26.1 kbps

G.726 60 bytes 50 47.2 kbps 55.2 kbps

G.728 60 bytes 33.3 31.5 kbps 36.8 kbps

G.729 20 bytes 50 31.2 kbps 39.2 kbps

iLBC 38 bytes 33.3 28.8 kbps 30.9 kbps

Using the estimated bandwidth figure for G.711 (20 ms sample rate) would give us a session capacity

of 11,467 sessions over GigE. However, using the actual bandwidth as shown above (95.2 kbps),

that number drops to 10,504 sessions. From there, we need to calculate the link utilization rate. A

100% utilization rate would produce intolerable packet queues and poor performance. If we modify

the capacity measurement by taking into account a more sustainable link utilization rate of 90%, we

arrive at a figure of 9,454 maximum concurrent sessions – more than 2,000 sessions less than our

initial capacity formula indicated. Calculating CAPS then becomes a matter of multiplying the actual

concurrent sessions figure by the ACHT.

sonusnetworks.com

The Performance Reality of Session Border Controllers

sonusnetworks.com

Voice codecs also have different sample rates, which can affect the total bandwidth. G.711, for

example, has a base sample rate of 10 ms and can be delivered in voice payloads of 10x multiples

(e.g., 20 ms, 40 ms) in a single packet, which reduces packet header sizes per payload and thus

overall bandwidth. Of course, longer sample rates also introduce potential issues in regard to latency

and packet loss, so network operators need to weigh all considerations carefully when choosing an

ideal sample rate. The chart below illustrates the actual bandwidth differences between G.711 in

10-40 ms samples.

Codec Sample rate PPS PayloadActual

bandwidth

G.711 10 ms 100 80 bytes 126.4 kbps

G.711 20 ms 50 160 bytes 95.2 kbps

G.711 40 ms 25 320 bytes 79.6 kbps

Finally, network operators need to consider the transport protocol for the media. Transport Control

Protocol (TCP) or RTCP, for example, require more processing than UDP. If this processing is done on

the main SBC processor, call processing performance will logically degrade. It may be only a small

degradation in and of itself, but compounded by other processing requirements (IPsec encryption,

media transcoding, signal interworking, CDR collection, etc.) the impact on SBC performance can

be quite significant.

Performance Under Attack

Like many IP-based applications, VoIP networks are exposed to a variety of security risks that threaten

quality and stability. By design, SBCs are on the first line of defense against malicious Denial of

Service (DoS) and Distributed Denial of Service (DDoS) attacks. SBCs therefore must identify and

subdue these attacks quickly and recover gracefully without impacting the main call processor’s

performance. This requires an orchestrated approach that combines embedded security at the

hardware processor level with software-based security (blacklisting, etc.).

Performance Under Load

Non-malicious overloads such as those caused by high-traffic network events (e.g., a cable cut or

power outage in the network) can similarly affect SBC performance. Again, the key characteristic that

network operators should look for is a combination of hardware- and software-based mechanisms

that address overload scenarios while preserving session quality/performance. When evaluating

SBCs, ensure that the system’s ability to continue to process established sessions and complete new

calls is maintained–even during severe traffic conditions. This can significantly impact a subscriber’s

perceived Quality of Service as SBCs under load conditions may no longer complete calls, thus

propagating the outage and extending its duration.

Transcoding

VoIP sessions passing through an SBC often require some level of transcoding. However, not all SBCs

deal with transcoding the same way; some, for example, hand off transcoding functionality to an

external device. While this device may be dedicated to the SBC, it remains a distinct element that is

managed separately in the network, requires additional rack space, and adds one more “hop” in the

session media path. Other SBCs perform transcoding as a software function of the main processor.

This reduces the available processing (and thus the performance) for primary SBC functions like

session handling and security, and can have a significant impact on performance and call quality.

The method that Sonus has embraced for audio/media transcoding in an SBC is a dedicated Digital

Signal Processor (DSP) embedded with the SBC hardware itself. This provides committed transcoding

resources without affecting the performance of other SBC functions or burdening the operations teams

with the cost of deploying, managing, and maintaining separate transcoding elements.

Signaling Manipulation

VoIP networks employ a variety of signaling protocols including H.323, SIP, and SIP-ISUP (SIP-I). In

order to enable calls and maintain call features between H.323 and SIP endpoints, for example, the

SBC is expected to provide signaling interworking between both endpoints. Considerable signaling

manipulation also takes place between SIP endpoints and the VoIP network for call control. These

tasks can be processing intensive and significantly impact the media/session handling capabilities of

the SBC. Many SBC vendors assume simple SIP-to-SIP interworking when quoting performance rather

than the more processing-intensive SIP-to-H.323 scenario, so network operators would be wise to

question signaling protocol interworking when measuring SBC performance.

The Performance Impact of NAT Traversal

Network Address Translation, a necessity for topology hiding, introduces a new set of complexities into

the IP session border control landscape. Specifically, NAT traversal requires increased signaling traffic

in the form of frequent SIP REGISTER messages in order to keep the session alive through the NAT-

enabled firewall. SIP registration through the NAT firewall can dramatically effect the number of SIP

signaling messages, increasing them by more than 400%. While others suggest that you can address

this problem by reducing the SIP registration refresh rate, this would first require a crystal ball. Simply

put, you need to know the precise number of NAT-enabled endpoints before you can calculate SIP

registration requirements.

To illustrate the impact of NAT traversal on a SIP session, let’s examine two network environments:

both with 250,000 subscribers, one with NAT traversal and one without. Both environments will

share the same contention ratio (10:1), yielding a call handling requirement of 25,000 concurrent

sessions. In addition, both will presume an Average Call Hold Time (ACHT) of 100 seconds, resulting

in 250 CAPS. If we assume an average of 10 SIP messages per call flow, we arrive at a call handling

requirement of 2,500 messages per second.

In our non-NAT environment, we would add an additional contingency for our 250,000 subscribers to

send a SIP REGISTER message every 60 minutes (the typical default refresh time), or 140 messages

per second. Our new call handling capacity then becomes 2,640 SIP message per second:

sonusnetworks.com

The Performance Reality of Session Border Controllers

sonusnetworks.com

SIP Session Requirements in a Non-NAT Environment

SIP Centrex subscribers 250,000

Contention Ratio 10:1

Maximum number of concurrent calls 25,000

Average Call Hold Time 100 seconds

CAPS 250

SIP messages per call flow 10

SIP messages per second 2,500

SIP signaling messages per second 140

Total SIP call/signaling messages per second 2,640

Now let’s look at an environment where NAT traversal is a requirement for 200,000 subscribers

(and where 50,000 subscribers will not need NAT traversal). In order to keep a SIP session open

through a NAT firewall, a “pinhole” will have to be created by sending frequent SIP REGISTER

messages. The message frequency is determined by the time it typically takes a NAT firewall to close

a session after the last message is sent; in our example, 50 seconds. This would add an additional

8,000 messages per second for registration handling (REGISTER and 200 OK messages) for our

200,000 NAT-enabled subscribers, plus a relatively inconsequential 28 messages per second for the

remaining 50,000 non-NAT subscribers (as in our previous example, presuming one SIP REGISTER

message every 60 minutes). This calculation now gives us a dramatically different number for

session requirements than before:

SIP Session Requirements in a NAT-Enabled Environment

Subscribers requiring NAT traversal 200,000

Subscribers not requiring NAT traversal 50,000

Maximum number of concurrent calls 25,000

Contention Ratio 10:1

Average Call Hold Time 100 seconds

CAPS 250

SIP message per call flow 10

SIP messages per second (call media) 2,500

NAT SIP signaling messages per second 8,000

Total SIP call/signaling messages per second 10,528

Clearly, the introduction of NAT traversal in the network environment has a dramatic effect on the

number of SIP call/signaling messages: from 2,640 per second to 10,528 per second. This is a good

illustration of why network operators need to look beyond CAPS, subscribers, and concurrent calls

when determining SBC capacity. In the case where an allowance for NAT traversal had not been

made, the network operator would be forced to reduce the number of subscribers and calls in order to

accommodate the bandwidth demands for frequent SIP registration and re-registration.

The Performance Impact of Presence

Another critical SBC scaling problem relates to presence or IM services based on SIP/SIMPLE

protocols. The message flow in a presence environment is impacted by three key factors: the number

of subscribers, the number of contacts or “buddies” that each is connected with, and the timeframe

between status changes. As each of these grows, the number of messages will multiply. For example,

in the first case below, with only a small percentage of subscribers using presence with relatively modest

“buddy lists,” the number of SIP messages generated is fairly manageable.

SIP Messages in a LOW Usage Presence Environment

Subscribers 25,000

Number of subscribers using presence 2500

Average number of buddies per subscriber 10

Average time between status changes per sub. 60 min

Status changes 7 msg / sec

Now, let’s explore the impact of implementing a full Unified Communications environment. In this case,

subscriber usage is likely ubiquitous with each user possessing a much larger list of contacts, and

statuses will update more frequently due to the inclusion of “in a meeting,” “on the phone,” etc.

SIP Messages in a LOW usage Presence Environment

Subscribers 25,000

Number of subscribers using presence 25,000

Average number of buddies per subscriber 100

Average time between status changes per sub. 15 min

Status changes 2,778 msg / sec

As you can see, the messages related to presence can quickly explode–with nearly a 400x increase

seen in this example. If you are using session border control in the midst of this communication, the

scalability requirements to support presence can rapidly eclipse that of voice and must be factored into

any network design decisions.

sonusnetworks.com

The Performance Reality of Session Border Controllers

sonusnetworks.com

Encryption

As a security function, SBCs are expected to encrypt network connections, IP packets, and specific

media via Transport Layer Security (TLS), Internet Protocol Security (IPsec), Secure Real-Time Transport

Protocol (SRTP), and other security protocols. Encryption can be a processing-intensive step, however,

and degrade SBC performance if it is performed as a software function by the SBC’s main processor.

In order to provide optimal call handling capacity during encryption, this function is better handled by

dedicated hardware such as a separate but embedded network processor.

SIP Call Flows

The complexity of SIP call flows can vary greatly depending on factors such as NAT traversal, proxy

servers, and Centrex services like call transfers. Often, SBC product performance numbers are based

on a simple, seven-message SIP call flow when measuring concurrent session capacity and CAPS.

This can be short-sighted and misleading, as simply enabling PRACK can result in a ten-message SIP

call flow, while a dual proxy scenario can boost the call flow to beyond twenty messages. Network

operators should therefore look beyond posted performance numbers to see how SBC vendors arrived

at those numbers, or run the risk of basing their border capacity on bad math.

High Availability

As critical network components, SBCs are expected to deliver high availability, even during adverse

conditions such as DoS/DDoS attacks, overloads, and systems failure. Most SBCs have a redundancy

scheme in place, yet not all SBCs handle this transition in a seamless and elegant manner. In the

contingency of a system failure, for example, call states will be passed between the in-service and

redundant pair of SBCs, which can significantly impact SBC processing. How well an SBC handles

these contingencies should be considered when estimating and evaluating SBC performance.

Centralized vs. Distributed Routing

Historically, SBCs have been “dumb” devices that left network intelligence such as call routing and

policy management to third-party devices in the network core. While some SBCs still follow this

model, many SBC vendors have recently begun to develop call routing technology and co-locate it

in their products, a feature sometimes referred to as localized or distributed routing. These vendors

suggest that localized routing helps to reduce latency in the network, which is true, although whether

this is faster or more efficient than centralized call routing depends on the implementation and other

architectural considerations. Sonus Networks, for example, offers a mixture of distributed call routing

servers with centralized routing intelligence and management. This approach greatly simplifies call

routing database updates and policy management for the network through the use of a “master”

routing/policy database where information is automatically propagated to distributed “replica” routing/

policy servers co-located with the SBC. The centralized management of distributed intelligence solves

the dual problem of consistent intelligence across the network with localized intelligence for reduced

latency and is unique to the Sonus solution.

Use Case ScenariosIn addition to the individual factors listed above is an overarching factor that greatly influences

SBC performance and capacity: the network application itself. For the purpose of this white paper,

we’ll examine three common user scenarios: residential broadband VoIP, SIP trunking, and carrier-

to-carrier peering.

Residential Broadband VoIP

The SBC in this case would be deployed in an access role, which means it would reside between the

service provider’s core network and the subscribers accessing services over a residential broadband

connection. The most important considerations for SBC performance and capacity in this scenario

would be: number of subscribers, NAT traversal, SIP-to-SIP interworking, high availability, SIP call

flow, security, and DoS/DDoS protection. CAPS would be determined by dividing the total number of

subscribers by the contention ratio (i.e., the percentage of subscribers using the network at any one

time), and dividing the resulting number (i.e., concurrent calls) with the Average Call Hold Time (ACHT).

Generally, as the number of NAT-enabled subscribers increase, the capacity of the SBC drops. As seen

in the NAT traversal calculations, most SBCs will need to reduce the number of subscribers and calls

that each box can handle in order to accommodate the heightened messaging demands of frequent SIP

registration/re-registration. The solution often proposed by SBC vendors is to add more boxes, which in

turn raises the cost of the solution and the complexity of managing additional devices in the network.

By contrast, the Sonus Network Border Switch and NBS5200™ can support a high number of

NAT-enabled sessions. Fewer boxes are required and, because Sonus uses real-world performance

measurements rather than fair-weather conditions, fewer surprises occur.

FIGURE 1. Residential broadband VoIP network architecture

sonusnetworks.com

The Performance Reality of Session Border Controllers

sonusnetworks.com

SIP Trunking

A second access scenario with different session characteristics is SIP trunking between a service

provider and an enterprise customer. Here, the SBC would provide a secure access entrypoint and

session border between the service provider’s core network and the enterprise’s PBX. Because of

the greater need for security at the enterprise level and the likelihood of legacy PBX systems, there

are different considerations to take into account when measuring SBC performance and capacity for

SIP trunking, including: CAPS, SIP-to-H.323 interworking, encryption (e.g., TLS, SRTP), DoS/DDoS

protection, high availability, and SIP call flows.

When measuring SBC performance in this environment, network operators need to take a close look

at the device’s support for SIP-to-H.323 interworking. Encryption is also important, specifically where

the SBC performs the encryption—in the main processor or a separate processor—as this can

negatively impact call handling performance. Finally, it’s important that the SBCs perform stateful call

handling during DoS/DDoS attacks, which again depends largely on where the security functions of

the SBC reside.

Because the Sonus NBS performs transcoding and encryption in a dedicated, embedded DSP, call

handling performance in the main processor is not impacted, even during DoS/DDoS attacks.

FIGURE 2. SIP trunking network architecture

Carrier-to-Carrier Peering

In the case of carrier-to-carrier peering, the SBC resides between two service provider (or “peer”)

networks and handles the IP sessions between them. Key SBC considerations in a peering application

are the number of trunks and concurrent calls, SIP-to-SIP interworking (including SIP-I), encryption,

SIP call flows, security, high availability, and media transcoding. The absence of directly connected

subscribers means that CAPS is now generated by simply dividing the maximum number of concurrent

sessions with the ACHT. Here, the focus of the SBC’s performance shifts from serving subscribers to

maximizing bandwidth utilization.

Protocol interworking and transcoding are again important factors in a peering environment. Where

SBCs lack these as embedded functions or perform them as a software function from the main

processor, call handling performance will be negatively impacted. The Sonus NBS addresses peering

requirements in a more efficient manner by embedding a dedicated DSP to perform these roles

independent of the call handling processor.

Scalability in the Real WorldSome SBC vendors would have you believe that increasing session capacity is as simple as adding

more SBC boxes to the network. Yet this kind of “boxed-in” thinking can actually have the unintended

effect of scaling deficiencies. We’ve already discussed how many SBCs have substantial gaps in terms

of features and functionality. What happens to these gaps as more SBCs are added to the network?

They grow wider, requiring network operators to plug them with additional network elements for media

transcoding, hardware resources to manage the SBCs, etc.

In addition to rising costs, network operators may see decreased performance as SBCs scale. This

is especially true in the case of SBCs that delegate media transcoding and encryption to their main

processor rather than a dedicated DSP. Sonus Networks offers two session border solutions; one that

migrates elegantly from TDM switching to IP session control (the Sonus NBS9000™), and another

FIGURE 3. Carrier-to-carrier peering network architecture

Sonus Networks, Inc. 7 Technology Park Drive Westford, MA 01886 978.614.8100

The content in this document is for informational purposes only and is subject to change by Sonus Networks without notice. While reasonable efforts have been made in the preparation of this publication to assure its accuracy, Sonus Networks assumes no liability resulting from technical or editorial errors or omissions, or for any damages resulting from the use of this information. Unless specifically included in a written agreement with Sonus Networks, Sonus Networks has no obligation to develop or deliver any future release or upgrade or any feature, enhancement or function.

Copyright © 2010 Sonus Networks, Inc. All rights reserved. Sonus is a registered trademark and NBS9000 and NBS5200 are trademarks of Sonus Networks, Inc. All other trademarks, service marks, registered trademarks or registered service marks may be the property of their respective owners.

Printed in the USA 08/10

A Sonus Networks White Paper

that scales elegantly in an all-IP environment (the Sonus NBS5200). Both feature embedded DSPs

that preserve call handling capacity even as media manipulation demands such as transcoding

and security increase.

ConclusionWhen comparing session border solutions, network operators need to take a hard look at the

numbers and the underlying architecture to avoid making a faulty “apples vs. oranges” comparison.

Specifically, when evaluating a session border solution, potential buyers should ask for numbers

derived from use cases that reflect:

> More than just featureless “vanilla” SIP sessions

> Different peering and access configurations

> Performance under attack

> Security-enabled SIP transactions

> NAT traversal

> Heterogeneous networks (legacy gateways, multivendor PBXs)

> Media transcoding

> Complex call routing

Capacity measurements based on fair-weather assumptions or select functionality don’t offer a true

measure of performance, and only serve to “box” network operators into an SBC strategy that will

ultimately be costly to manage and maintain as IP traffic grows. Session border solutions should

be evaluated from a holistic viewpoint that includes call handling, call routing, security, and media

transcoding. Only when network operators look at SBC performance under real-world conditions will

they be able to accurately assess and implement a scalable, reliable border solution for the all-IP

world of tomorrow.

To learn more, call your Sonus sales representative or visit us online at sonusnetworks.com.

WP-1100 Rev. A