Recommended Deployment Topologies

Session Border Controller

The SBC family products can be deployed following several generalized topology types; Peering (sometimes called Trunking), Access (also called Hosted IP Services), and Hybrid which combines the two models.

Peering - In a peering model the SBC is contacted by a SIP server to relay endpoint signaling information. The SIP server may be a PBX, registrar, proxy, SBC, or other device. The IP of the device is usually trusted and pre-provisioned in the SBC as an endpoint (session agent) that will be relaying calls. Since the remote endpoint is already known, Access Control Lists (ACL) and Call Admission Controls (CAC) can be pre-provisioned for the appropriate level of protection or service level assurance.
Access - In an access model the SBC is contacted by a SIP endpoint to relay endpoint signaling information. The IP address of the endpoint is usually not known, so trust should be established through behavior such as establishment of a successful registration. Once the endpoint becomes trusted, dynamic Access Control Lists (ACL) and Call Admission Controls (CAC) can be applied. Monitoring of potentially abusive behaviors provides a mechanism to “demote” or blacklist endpoints.
Hybrid - A hybrid model combines both Peering and Access topologies into a single configuration. This is a fairly common model, where remote users use a registrar server in the core network, but their calls are forwarded to a service provider on one of the peer connections.

Unified Session Manager

The Unified Session Manager (USM) provides edge security for an IMS network, and should be positioned at access borders to integrate "traditional" SBC functionality with the core IMS session control functions. It provides a user registrar, local subscriber tables and Call Session Control Function components such as Proxy CSCF, Interrogating CSCF, Session CSCF, IMS Access Gateway, Emergency CSCF and Breakout Gateway Control Function. Diagram of USM as providing edge security for IMS networks.

Core Session Manager

Session Router

The Core Session Manager, which should never be positioned at a network edge, is used as a core session controller between multiple network types. It supports SIP in IMS and non-IMS environments, application servers, media servers, gateways, etc. It can be deployed in a distributed, virtualized model on COTS server hardware. The CSM can be used for session routing, interoperability assurance, CAC, and subscriber database integration through HSS, ENUM, or local subscriber table databases. Diagram of CSM as a core network controller between multiple network types in an IMS networks.

The Session Router is a “pure” SIP session router that can be positioned in either a core network or at network borders. When installed at a border, the same SBC protections used in peering and access models can apply. In the network core, the emphasis is on routing and interoperability. Diagram of Session Router within a network passing only SIP signaling traffic.

Enterprise Communications Broker

The Enterprise Communications Broker (ECB) should only be deployed within an enterprise core network, and not on the edge. Instead of perimeter security, the ECB is oriented towards functions such as dial plan management, centralized session, routing, CAC, load balancing, and interworking. Network diagram of ECB providing call routing within an enterprise network.

Realm Design Considerations

As a general rule, separate realms are created for external untrusted traffic and internal trusted traffic. However, there are many deployment complications that prevent that simple model from being used. Examples of these might include:

A mix of user endpoints, gateways, or peer trunks on the untrusted network
Varying capabilities or incompatibilities of user agents
Impacts of blocking traffic to one group of users vs. another (i.e. trust low or medium)
Service level agreements (SLA) that require Call Admission Controls (CAC)

A few of the general rules for Realm design include:

Separate endpoints into realms based on trust level (high, medium, low) and that the response to detected abuse is appropriate for them (no action, demotion or blocking)
Create multiple realms for endpoints based on the type of device – a user endpoint, a gateway, or a peer - since they will have very different considerations for SIP Header Manipulation, trust, signaling thresholds, endpoints behind NAT, and CAC.
Consider increasing the deny-period from 30 seconds to something longer depending on how much abuse it is believed will be received from a public network and what type of delay users may tolerate.
Set restricted-latching to sdp so only media received from the IP and port negotiated in signaling will be allowed.
Pay close attention to the media management settings required for the endpoints and traffic flows (see the mm- parameters on the realm). If one way-audio is experienced this is one place to start investigating.