3.3. A Typical SBC Configuration Example

Many SBC deployments, especially in smaller networks, follow a simple schema which is given through the network structure. In this typical network, the SBC bridges between an internal network, where the home proxies, PBXs and other servers like conference and application servers are located, and the public network, where the user agents reside. Typically, in such a network the main motivations for deploying an SBC are

  • network separation for security reasons
  • foolproof and always-working NAT handling
  • protection of the core network from high registration load
  • protection against fraud by enforcing call limits
  • possibility for monitoring and tracing for troubleshooting

This chapter presents step by step how to address these network aspects using the ABC SBC. The configuration presented here also corresponds to the sample configuration pre-configured in the virtual machine version of the ABC SBC.  It assumes an SBC “sitting” between two networks, a public one with user telephones and a private protected one with operator’s infrastructure.

3.3.1. Identifying Network topology

Simple as it is in this case, the network topology is shown in Sample network Topology.


Figure 1: Sample network Topology

What administrator needs to do in this step is configuration of the physical network interfaces and of the SBC-level interfaces.

The ABC SBC has two physical interfaces, one public connecting to the public networks, here with IP address, and one private connecting to the private network, here with IP address The physical interfaces are configured using procedures described in Section Physical and System Interfaces.

User agents are located in the public network and have IP addresses from any network, and they are configured to use the public interface of the SBC with the address as proxy (in a real world deployment, this address would not be a private RFC1918 address, but a public one).

A proxy (or PBX) and a conference (or other application) server are located in the internal network. The ABC SBC can communicate with the entities in the internal network through its interface in the private network which has the IP address

The detailed procedure for setting up SBC interfaces is described in Section SBC Interfaces. It links media processing, signaling and administration with physical interfaces, IP addresses and port ranges.

3.3.2. Describing ABC SBC Realms and Call Agents

The network topology is described in the ABC SBC configuration by Realms and Call Agents. Call Agents are typically consumer or operator SIP devices identified by their IP addresses or DNS names. They are grouped in networks called Realms whose processing rules they share.

In our example two Realms are created in the SBC: public and internal_network.


Figure 2: Creation of Realm


Figure 3: Public and private Realms

In the Realm public, the call agent public_users is created with IP address, which means that public_users can have any IP address, or: requests received from any IP address on the public interface will be identified as coming from the Call Agent public_users.  The address list can include multiple addresses that are used for routing (See section Determination of the IP destination and Next-hop Load-Balancing). Also a backup call agent can be defined here which can be used as alternate destination if forwarding to the primary destination fails. The CA definition further specifies interfaces used for sending and receiving signaling and media and availability management information – see Section IP Blacklisting: Adaptive Availability Management for more information.


Figure 4: Create public-users Call Agent

As we have neither defined a specific IP:port for the Call Agent nor a hostname, requests can be routed to that Call Agent only by Request URI, or by setting the destination IP explicitly in the routing rule.


Figure 5: Public Call Agents list

For the internal realm, the call agents proxy and conference are created with IP addresses and respectively.


Figure 6: Internal Call Agents list

3.3.3. Configuring Registration Cache and Throttling

REGISTER processing accomodates several goals: off-loading servers behind the SBC, enforcing frequent re-registration load to keep NAT bindings alive and dealing with REGISTER avallanches caused by different sorts of outages.

For REGISTER requests coming from the “public side”, the ABC SBC is configured to cache the registrations using the Enable REGISTER caching action. The cache works as follows:

  • For every new registration, it creates an alias, a special unique one-time identifier.
  • It saves the original contact along with the alias in the local registrar cache.
  • To facilitate NAT traversal, it also saves the IP address, port and transport with which the REGISTER was received.
  • It may re-adjust re-registration period so that it is frequent towards client for NAT keep-alives and less frequent downstream for better performance.
  • It replaces the Contact in the REGISTER with a combination of the alias and the SBCs IP address: alias@SBC_IP:SBC_PORT.

This way, the “aliased” contact propagated downstream hides details of NAT-related address translation performed at the SBC and manipulates re-registration period as needed. The cache entry becomes effective once the REGISTER request is positively confirmed by the downstream SIP element.

Thus, when the REGISTER request is then routed to the registrar (the home proxy, here Call Agent proxy), the alias@SBC_IP:SBC_PORT is saved as he registered contact address of the user at the registrar.

We define this rule in the A rules of the public Realm, so that it is executed for REGISTER requests coming from any user agent defined under the Realm.


Figure 7: Rule A Definition for caching REGISTERs coming from public realm

In order to protect the home proxy from the bulk of the registration load, the action REGISTER throttling is enabled with a Minimum registrar expiration, i.e., the re-register interval used upstream to the home proxy, set to the default of 3600 (one hour), while the Maximum UA expiration, i.e., the re-register period for the user agents, is set to 30 seconds.

3.3.4. SIP Routing

The SIP routing tables (B tables) define to which Call Agent a call is forwarded. In our example, there are two cases: calls from the UAs towards the proxy server and calls from the internal network towards the UAs.

Calls from the User Agents are routed towards the proxy with a simple rule. Here we route all calls from the public realm to the proxy - we might also set a filter on Source Call Agent, which would be equivalent in our case. We route by setting the next_hop (the destination IP address) directly.


Figure 8: Rule B Definition for the sample network

The next rule specifies routing of all calls from the internal network towards the registered UAs. If the home proxy wants to send a call to a user, it finds in its registrar database the alias@SBC_IP:SBC_PORT as contact for the user, thus it sends the call to the SBC with the alias in the request URI like this: INVITE sip:alias@SBC_IP:SBC_PORT.

In the SBC, we use the action Retarget R-URI from cache (alias) to look up the UAs IP and port values and set the request-URI to it. We also use the Enable NAT handling  and Enable sticky transport options to handle NATs properly. Using these options the SBC will send the request to the IP and port where the REGISTER request was received from and using the same transport protocol it was received on.


Figure 9: Rule A Definition for internal CAs

We can then use the R-URI to determine request’s destination. For simplicity, in this example we define a catch-all routing rule for the complete internal network, which includes all call agents defined there. (We may also define special routing rules for the different call agents in the internal network if they would have to be treated separately, e.g. if some calls need to be sent to a peering partner.)


Figure 10: Rule B Definition for internal-network Realm

3.3.5. Configuring NAT Handling and Media Anchoring

We have already used the NAT option in the Retarget R-URI from cache (alias) action above. In order to route in-dialog requests to the caller properly even if the UA is behind NAT, we use the Enable dialog NAT handling action. This will make the SBC remember the source address of the caller for the dialog and use that to send in-dialog requests.


Figure 11: Rule A Definition for NAT handling

For the RTP to flow properly through different NATed users - and also from the internal network to the public network for calls to conference bridge server - we Enable RTP anchoring with the Force symmetric RTP for UAC option enabled. To anchor the RTP of all calls at the SBC, we leave the Enable intelligent relay option unchecked; if we want to reduce bandwidth consumption and latency (total mouth-to-ear delay), we can also enable the intelligent relay option if we are sure that no users are behind double NATs.


Figure 12: RTP Anchoring Rule Definition (A)

We enable this for calls in both directions - from and to the UAs.


Figure 13: RTP Anchoring Rule Definition (C)

3.3.6. Configuring transparent dialog IDs

If we want to enable call transfers through the SBC, and to simplify troubleshooting, we can Enable transparent dialog IDs.


Figure 14: Transparent Dialog Rule Definition (A)

3.3.7. Setting up tracing

In the testing phase, we can enable tracing for calls with the Log received traffic action.


Figure 15: Tracing Rule Definition (A)

In production use we should not forget to disable or remove this rule to protect the privacy of the users and to reduce processing power and disk space requirements at the SBC host.

3.3.8. Summary of rules

The rules we have created so far can be seen in the Overview screen. The rules implement so far routing from the external to the private network and vice versa, recording traffic in PCAP files, NAT handling and registration caching and throttling.


Figure 16: Rule list for sample network

3.3.9. Setting Call Limits

In order to reduce the risks of fraud, we can set some limits on traffic coming from the external network as shown in Figure Limiting calls and traffic:

  • a parallel call limit of 10 for calls coming to the realm from the same source IP address ($si)
  • a limit of 5 calls coming to the realm from the same user ($fU)
  • a limit of call attempts per second (CAPS) of 10 for the calls coming to the realm from the same source IP address ($si)
  • and a limit of 120 kbit/s for every single call coming to the realm - sufficient bandwidth for audio calls only. For video calls you might want to use a higher value.

For the limits per source IP address, it has to be noted that the limits may apply to a group of users if they are behind the same NAT. If for example there are enterprise users, we may group them into a separate Realm with a different, higher limit and/or group by a combination of IP address and domain name.

We set these limits in calls from the external realm.


Figure 17: Limiting calls and traffic

3.3.10. Blacklisting specific IPs and User Agents

We can use a rule to block calls from a specific IP address.


Figure 18: Blacklisting IP adresses

And also specific User Agent types, for example SIP scans from sipvicious which works if the User Agent header string is unchanged.


Figure 19: Rejecting calls from certain user agents

3.3.11. Handling P-Asserted-Identity

The P-Asserted-Identity header is usually used within a network to signal the caller, if the identity is asserted, e.g. if it is signalled from a trusted source.

The P-Asserted-Identity header should usually only be trusted if it was set by some element in the internal network, e.g. by the home proxy after authentication. Hence, for requests coming from an external network it is recommended to remove the P-Asserted-Identity header*.


Figure 20: Remove P-Asserted-Identity header from untrusted requests

3.3.12. Where to go from here

This section described a typical initial configuration for a simple use case and a simple network topology.

Going further from here, various use cases that are solved with the ABC SBC are explained in various sections of this document: