3.1. Network Planning Guidelines

This section provides you with a list of steps every network administrator shall walk through carefully before deploying an SBC-powered network. Early planning helps to create robust network that well serves the needs of its users and make administrator’s life free of surprises.

Each planning step starts with a question about a particular network planning aspect. Administrators need to to ask themselves this question to determine their configuration needs. It is then followed by a short debate of the most important configuration options and trade-offs. Not all available options are included, yet those present are of major importance and shall be answered in the early planning phase.

The subsequent section includes a checklist that reiterates question raised in the section. We recommend going through it thoroughly before a deployment is commenced, and also completing the answers in the “Customer Site Survey” document available from our customer care.

The steps in this section are grouped as follows:

  • The Section Topology Model describes how an ABC SBC connects to the IP networks, how it models SIP devices and groups them administratively.
  • The Section SBC Logic describes the anticipated behaviour of the ABC SBC and what needs to be considered when configuring it: routing, media processing, NAT handling, and more.
  • The Section Security Policies summarises configuration steps needed to protect both the connected SIP networks and the SBC itself.
  • The Section Capacity planning provides guidelines for estimating the SBCs cluster dimensions.
  • Eventually the Section IT Integration discusses the configuration steps that need to be considered if the SBC connects to other network management elements.

3.1.1. Topology Model

The key function of the SBC is to securely connect various SIP elements and peering networks together. This is not trivial because the networks and devices may use different security policies, SIP protocol extensions, dialling plans, codecs, etc. To deal with this variety the SBC uses a network model in which the SIP devices are represented as abstract “Call Agents” that are  grouped in “Realms”. With Call Agents (CAs) and Realms there are rules associated that characterise how their traffic from and to them is treated.

The topology planning process includes the following steps:

3.1.1.1. IP layer topology

To which IP networks does the SBC connect?

The first step in defining your topology is located at the IP layer: you have to specify which IP networks connect with each other and how the SBC connects to them. This is captured in the specification of “interfaces”.

Interfaces describe in detail how an SBC connects to IP networks. In the simplest case all traffic can be routed through a single  Ethernet card using a single IP address and dedicated UDP port range.  Many deployments use multiple Ethernet cards or VLANs to connect two or more physical networks with different levels of security.

A widely used practice we recommend is use of three network cards for three networks: unprotected public, protected private, and highly-protected administrative. Then for example residential SIP phones and peering providers connect to the SBC over the public network, operator’s PSTN gateways are located in a private IP subnet, and administrators access the SBC over the administrative networks.

Note that using fewer cards makes a clean separation and security of traffic more difficult and also reduces total throughput.

More detailed discussion of interface configuration is described in Section Physical, System and SBC Interfaces.

3.1.1.2. IP layer security

Which firewall rules shall be used in firewalls and the SBC?

Once the IP connectivity is specified, you need to specify L3/L4 restrictions for your deployment. This consists of two parts: if you deploy additional L3/L4 firewalls in front of the SBCs you must make sure that they do not restrict legitimate traffic. You must allow SIP traffic (typically UDP/TCP port 5060), and if media anchoring is used also unprivileged UDP ports. On the SBC you may take the opposite approach and restrict critical ports, especially if no L3/L4 firewall is used. At least you shall make sure that traffic to privileged ports used for administration is permitted only from trusted IP addresses.

More can be found in the Section Manual IP-layer Blocking .

3.1.1.3. Call Agents (CAs)

What SIP Devices does the SBC talk to?

Identify CAs by IP address, IP address range or DNS  name. A CA may be physically a PSTN gateway, a whole “cloud” of identical IP phones located in a subnet, a peering party, just anything with unique identification and characteristics. Also specify if there is some specific treatment a CA shall obtain and that needs to be specified in SBC rules. These frequently include:

  • traffic limitations, i.e. will you impose one of these constraints on the traffic: RTP bandwidth, signalling rate, number of parallel calls?
  • mediation rules, i.e., do you to reconcile dialling plans, identity  (URI) usage, header usage? Note that some of these rules cannot be easily planned for ahead of time as they are used to fix protocol imperfections discovered after fact in operation.
  • NAT handling, i.e. does presence of NATs necessitate use of media relays, and shall the SBC handle traffic symmetrically? (normally the answer is yes to both these questions if there are NATs present).

More details about traffic limitations are described in the Section Traffic Limiting and Shaping, mediation is described further in Section SIP Mediation and media anchoring is described in more detail in the Sections NAT Traversal and Media Anchoring (RTP Relay).

3.1.1.4. Realms

What SIP Networks does the SBC talk to?

Most CAs belong to an administrative zone, whose traffic the SBC handles the same way. It would be impractical to define traffic rules for every single CA in such a zone. Therefore the SBC uses the concept of Realms that group all CAs sharing the same characteristics. For example a total bandwidth maximum restriction may be applied to a whole cluster of peering partner’s PSTN gateways modelled as a Realm. Also identical header-field manipulation and routing may be applied to all the machines in a Realm. Therefore the administrator needs to assign CAs to the Realms and associate the common rules with the Realm. The functionality of Realms’ rules is the same as for CAs.

3.1.2. SBC Logic

It is important to plan what the SBC will actually do for your network in precise terms because particular features have further impact on capacity planning, integration with other components, interoperability and administration.

3.1.2.1. Routing

What will be the routing criteria used in your network?

Routing is a mandatory part of every SBC configuration. Once the topology is established, you must define how traffic flows between the Realms and Call Agents. That is described in routing tables. The key decision to be made is what is the criteria used to determine the next hop for a new session. The most common examples of criteria include:

  • prefix-based routing. This is frequently used when you have a number of PSTN gateways serving different regions. Technically you match area codes against beginning of the user-part of the request URI.
  • source-based routing. This is frequently used when you connect multiple IP networks and want to make sure that all traffic from one network is forwarded to the other and vice versa. The criteria is then the source IP address, source Call Agent or Realm.
  • method-based routing. Sometimes specialised servers are used for processing specific traffic, like message stores for keeping messages for off-line recipients.
  • The SBC configuration options include even more criteria and these can be also  combined with each other.

Some functionality is only present in some deployments and whether to use it or not depends on used equipment, network characteristics and network policies. More information about administration of SIP routing may be found in the Section SIP Routing.

3.1.2.2. Media Anchoring

Do you need the SBC to anchor media so that all RTP traffic visits your site?

The ideal answer is no due to latency and bandwidth concerns, the most common answer is yes due to NAT traversal and controlling media. Relaying media costs considerable bandwidth and implies more SBC boxes. Yet if any of the following conditions applies, you will have to enable media relay:

  • There are SIP clients behind the NATs. That’s the common case in residential VoIP.
  • You wish to record calls. Obviously you can only record media that visits the SBC.
  • You want to implement topology hiding consequently and make sure that no party sees media coming from any other IP than that of the SBC.
  • The SBC connects two networks that are mutually unroutable.

More administrative details can be found in the Section Media Anchoring (RTP Relay).

3.1.2.3. Media Restrictions

Do media-restricting rules need to be placed?

The need for media restrictions arises mostly when bandwidth is scarce. This may be the case if media anchoring is used on a link from/to the SBC or on the SBC itself. It may be also the case on the link to the client, particularly if it is a mobile one.

The simplest solution is to restrict media negotiated by Call Agents by putting desirable codecs on a whitelist. All other codecs will be removed from codec negotiation.  It may happen though that the resulting codec subset is empty and the Call Agents would not be able to communicate with each other.

If there are no codecs left, you may extend the codec set by transcoding. The SBC then adds additional codecs to the negotiation process and if the Call Agents choose it,  the SBC will convert media to the chosen codec. The penalty that needs to be considered is degraded throughput of the SBC.

In addition to the codec-based proactive bandwidth saving approach, the SBC can also limit bandwidth retroactively and put bandwidth limits on CAs or Realms (or some portions of its traffic). This helps to stay on the bandwidth budget even if SIP devices exceed traffic signalled in SIP. However, it remains a reactive measure. That is, it does not prevent excessive traffic, it just drops it and impairs the affected media streams.

Codec handling is described in the Sections Media Type Filtering, CODEC Filtering, CODEC Preference and Transcoding, administration of media limits is described in Section Traffic Limiting and Shaping.

3.1.2.4. Registrar Cache

Does the SIP traffic include REGISTER messages?

If so, we recommend that you do enable registrar cache. The  cache is optimised to reduce the REGISTER traffic that is passed down to the registrar. This is particularly important if the clients are behind NATs. Then the cache must be configured to force SIP clients to re-register every minute to stay connected from behind NATs. Also the ability to track registration status of users allows the SBC logic to differentiate call processing for online and offline users. This can be used for example for voicemail routing.

Further administrative details are described in the Section Registration Caching and Handling.

3.1.2.5. NAT Handling

Are there some CAs behind NATs?

If so, you not only have to anchor media as described above, but also make sure that the signalling protocol traverses NATs successfully. Also registrar-cache must be used to force clients to refresh their connectivity using frequent re-registrations. Some deployments with STUN-capable SIP phones also set up a STUN server to assist these phones.

NAT configuration is described in further details in Sections NAT Traversal and Media Anchoring (RTP Relay).

3.1.2.6. SBC High Availability

Shall the SBC be operated in high-availability mode?

While this is normally the case, small enterprise deployments may prefer buying and administering fewer boxes. Introducing high-availability requires a standby spare machine for every active SBC and effectively doubles the number of machines.

It is recommended that in a high-available configuration setup an administrative network is used for internal inter-node communications and the availability protocol used between the machines in the active/standby pair.

More administrative details about HA mode are available in the Section High Available (HA) Pair Mode.

3.1.2.7. Downstream Failover and Load-Balancing

Shall the SBC seek alternative destinations when primary destinations become unavailable?

Handling downstream failover may or may not be needed. For example if the downstream telephones are single-user SIP telephones, there are usually no backup devices. Some high-density devices like PSTN gateways implement automated failover in a way which is invisible to the SBC and the SBC doesn’t need to handle it either. However if the primary destinations have spare backup machines without automated failover, the SBC can still detect a failure and try the alternate destinations.

If there are multiple alternate destinations, it may be also practical to spread the load among them.

There are several ways how to define a set of alternate destinations and their priorities: it can be defined in DNS maps or in the Call Agent specification. If the definition is managed in DNS, the SBC resolves DNS names automatically in compliance with RFC 3263. If using DNS is not practical, the same effect can be achieved by associating multiple IP addresses with a Call Agent. Additionaly, a backup Call Agent may be also associated with a Call Agent: in that case traffic to the backup destination will be processed by additional C-rules specific to the destination.

Procedures for determining the next hop are described in Section Determination of the IP destination and Next-hop Load-Balancing.

3.1.2.8. Dialing Plan Mediation

Do different CAs and Realms connect to the SBC use different dialling plans?

Often SBCs connecting different sites that use different numbering conventions: short-dials, regional dialling plans, special services numbers. To enable interconnection of such sites and avoid number overlaps, the SBC must bring all the numbers to a common denominator, mostly the E.164 numbering format.

More about mediation can be found in the Section SIP Mediation.

3.1.3. Security Policies

Generally, the SBC has two ways for protecting networks: putting various restrictions on traffic and concealing network internals. The latter is sometimes a double-edged sword as obfuscation of SIP traffic makes it hard to troubleshoot.

3.1.3.1. Restricting Traffic from Unwanted Sources

How do you identify and discard illegitimate traffic?

There are several ways the SBC recognises and drops undesirable traffic.

At the SIP-level you may set a variety of criteria which if it is met results in declining a session request. The conditions may include:

  • unusual message patterns such as User-Agents of a type known to offend other SIP devices, URIs to premium numbers or simply anything else that can be matched
  • unusual traffic patterns, such as call excessive call rate, number of parallel calls, or RTP bandwidth consumptions
  • The traffic patterns apply statically to a whole Realm or Call Agent. However they may be also tied dynamically to “traffic from any single IP coming from the Realm” or “traffic to any single phone number”. This way you could for example impose a Realm condition “maximum one parallel call from a single IP address to a 900 phone number”.

Additionally, if traffic from some specific IP address begins to take really excessive dimensions, you can drop it straight at the IP layer before it reaches the SBC logic.

More information about filtering unwanted traffic can be found in Section Police: Devising Security Rules in the ABC SBC.

3.1.3.2. Topology Hiding

Do you prefer SIP  transparency across networks or concealing network information?

This is indeed an operational dilemma. If you process SIP traffic “by standards”, the traffic will be passing the SBC with minimum changes. This approach will reveal lot of information about one network to the other: which IP addresses are being used, which port ranges, what type of equipment and potentially even more. This makes life easier for attackers seeking security holes in networks and therefore some operators chose to obfuscate this information.

The penalty for traffic obfuscation is significant however: operators’ administrators will find it similarly hard to find out what’s is going on in their own networks. That doesn’t make troubleshooting easier. Some complicated applications in which SIP messages tend to refer to each other (such as in call transfer) may also fail.

The choice to obfuscate or not is eventually to be taken by the operator. The ABC SBC has the following means of doing that:

  • Topology hiding rewrites known SIP header fields in which use of IP addresses is mandatory. The downside is that troubleshooting becomes more difficult.
  • Use of non-transparent mode will rewrite dialog-identifying information: from-tag, to-tag and callid which in some older implementations also includes IP addresses. The downside is some applications which refer in protocol to a call may fail.
  • Header whitelisting drops all header-fields that may potentially carry additional sensitive information, standardised (Warning, User-Agent for example) or proprietary (Remote-Party-ID for example). The downside is that sometimes “a baby can be thrown out with the bath water”, when the header-fields include potentially useful information.
  • Media anchoring can be used to obfuscate where media flows from and to. The downside is high bandwidth consumption and increased latency if media anchoring wouldn’t be used otherwise.

Additional information can be found in the Sections Topology Hiding, SIP Header Processing and Media Anchoring (RTP Relay).

3.1.4. Capacity planning

Capacity planning is a key part of the planning exercise. Failure to provision resources sufficiently can lead to network congestion and low quality of services. Overprovisioning way too far increases cost. The goal is to find the right measure of network size that serves the anticipated traffic. This section provides rules of thumb to estimate needed capacity and makes simplifying assumptions about state-of-the-art hardware, “normal” traffic patterns and no dependencies on external servers. A more detailed discussion of dimensioning can be found in the Section SBC Dimensioning and Performance Tuning.

3.1.4.1. Cluster Size

How many SBCs are required for a deployment?

There are two major factors that determine how many hosts you need to serve your traffic: anticipated performance bottleneck and organisation of clusters.

Which bottleneck is the most critical strongly varies with actual traffic patterns and services configured on the SBC. A rule of thumb for a rough estimate of the performance of the ABC SBC on PC with three-1GB-Ethernet and 12 GB of memory is this:

  • If transcoding is used, the bottleneck of a single box in terms of the maximum number of parallel calls which is about 1000. Otherwise...
  • ... if media-anchoring is used, the bottleneck in terms of the the maximum number of parallel calls which is about 5000. (Media overhead prevails even over heavy registration load.)
  • Otherwise the limit is a call rate of 480 calls per second.

We advice to add at least additional 35% of buffer capacity to deal with variances in hardware performance, increasing traffic patterns, too conservative traffic forecasts and DoS attacks.

Once you determined the per-box capacity, you need to take cluster organisation in account. There are the following three cases:

  • a single SBC deployment: no scaling, no high-availability.
  • high-available active/standby pair: the pair has still the total capacity of a single box, however it can survive scheduled and unscheduled outages without service impairment
  • high-available cluster: the number of boxes is determined by number of boxes needed to serve the target capacity, doubled to achieve high availability plus two more boxes for a highly-available load-balancer: cluster_capacity / box_capacity * 2 + 2.

3.1.4.2. Bandwidth

How much bandwidth needs to be allocated to serve the deployment?

To determine needed bandwidth you need to discriminate between two cases: using SBC with and without media anchoring. The more bandwidth-hungry case is that with media anchoring. With the most commonly used codec, G.711, a call consumes 197 kbps bandwidth in each direction.

To determine the maximum bandwidth needed calculate the product of maximum number of parallel calls by the bandwidth specific to the codec in use, 197 kbps if it is G.711.

3.1.4.3. Public IP Address Space

How many public IP addresses need to be allocated for an SBC Cluster?

The minimum number is one shared VIP address for every active/standby pair.

3.1.5. IT Integration

An SBC is rarely a standalone component. More often it integrates with other components for the sake of connecting to external policy logic, network monitoring, server naming and others. This section lists typical integration options you may need to consider for your deployment.

3.1.5.1. RESTful interface

Does the SBC need to consult an external server for its decision making?

If so, the ABC SBC built-in RESTful query allows to ask an external server how a session shall be handled. This query possibility allows to integrate external and complicated logic in the SBC which is customer-specific or for other reasons difficult to integrate with the SBC directly.

See more in the Section RESTful Interface.

3.1.5.2. Recording

For various reasons, audio recording may need to be configured. What needs to be integrated is access to the recorded files. The easiest way is none: the recorded files are stored on local storage and accessed through the events web-page. Uploading to HTTP may also be used. In either case, some deletion and retention policy must be created, otherwise the local storage will be soon full.

See more in the Section Audio Recording.

3.1.5.3. Monitoring

Do you need to see how the SBC is doing?

Of course you do. We suggest use of the optional ABC Monitor as described in Section ABC Monitor (Optional) as it provides ABC SBC administrators with full history of users and analytical tools to audit it.

You can also use SNMP at a third-party management console to inspect health of your ABC SBC and the networks. It is possible to define your own custom counters. See more in the Section Using SNMP for Measurements and Monitoring.

3.1.5.4. Mass Provisioning

Do you need to provision the SBC with lot of repetitive data such as thousands of Least-Cost-Routing Entries?

Then you certainly do not want to provision it rule by rule. Instead you devise one rule and fill it with data. The actual data can comes over a web interface or RPC.

See more in the Section Provisioned Tables.

3.1.5.5. Call Detail Record (CDR) Exports

Do you need to access CDRs for sake of charging and reconcilliation?

Then you must access the internally produced CDRs.

See the Section Call Data Records (CDRs) for more about CDR location, format and access.

3.1.5.6. DNS Naming

How do I make the SBCs known to their counter-parts?

While it is possibly to communicate with peer SIP-devices only using IP addresses we recommend that every single SBC has a DNS name which is communicated as the point-of-contact to its peers. If nothing else, it makes IP renumbering much easier should it occur.

DNS map entries for SIP servers follow the SRV DNS extension as described in RFC 3263.