Usage scenarios for OpenSIPS

The huge set of features provided by the modules combined with the powerful routing script makes OpenSIPS the best candidate for almost any SIP-related scenario.

From simple traffic switching to complex residential or trunking scenarios, from the ingress to egress of your network, OpenSIPS is able to cope with the requirements in an efficient and scalable way.

This chapter does not aim to list all the possible usage scenarios for OpenSIPS but just to scratch the surface, show the most popular usage scenarios, and give some reference points when it comes to what you can do with OpenSIPS. Let's take the classical SIP network as a case study, which typically consists of an ingress, a core, and an egress. We will inspect each of these sides in order to see what OpenSIPS can do for them.

The ingress side

In a SIP network, the ingress component sits between the SIP endpoints (registering SIP phones, SIP PBX, and SIP trunks) and the SIP core platform.

Due to its location, the ingress component must address two important issues:

• Scalability: The ingress SIP servers concentrate a huge volume of traffic from the endpoints
• Security: The SIP servers are in direct contact with the endpoints and so the ingress component is more exposed to attacks, floods, or other security issues

Usually, an ingress component is also called Session Border Controller (SBC). Despite the common understanding that an SBC is responsible only for security and NAT traversal, the term of SBC is something very generic—it is a component sitting on the edge of the network and controlling the traffic crossing in and out of your network. The following figure shows OpenSIPS working as a SIP router:

Acting as an SBC (or ingress component), OpenSIPS can address multiple requirements at the same time.

Starting from the lowest level, the network level, OpenSIPS is able to provide the most complex operations:

• Network bridging: As it is able to listen on multiple interfaces in different networks, OpenSIPS can route the traffic between different isolated networks (to perform bridging). The interface used to send out the traffic can be controlled manually from a script or automatically detected by OpenSIPS. The bridging is also available between the IPv4 and IPv6 networks.
• NAT traversal: With NAT autodetection functions, OpenSIPS is able to discover the traffic coming from behind NAT and translate all the SIP traffic into public IP addresses. The built-in STUN server is also available in OpenSIPS; even better, the STUN server is able to listen on the same listeners as the SIP traffic (mixing SIP and STUN on the same UDP listeners). The NAT traversal logic may be combined with media relaying by using OpenSIPS to control such external media relays.
• Protocol conversion: As OpenSIPS implements various transport protocols for SIP, it can take incoming traffic over TLS (towards the endpoints) and convert it to UDP (towards the core components).The OpenSIPS script gives a maximum of flexibility to detect the need of protocol conversion and also to implement it.
• Flood detection: By monitoring all the source IPs for the incoming traffic, OpenSIPS can detect potential sources of flood (attacks or unintended) in an efficient way. All the received packets, SIP-valid or not, over different protocols are counted in the flood detection process.
• IP Filtering: IPs or ranges of IPs can be configured to be discarded as sources of traffic.

Moving up on the stack, on the SIP level, OpenSIPS addresses multiple important issues for an SBC:

• SIP validation: The incoming SIP packets are subject to validation from a SIP perspective. It checks both the syntax and message contents to make sure that all the mandatory headers are present. If body is present, it checks the Content-Length and Content-Type headers. Depending on the nature of the packets (and its methods), specific consistency checks are performed.
• Call aware: OpenSIPS can be (optionally) call stateful, which means that it will be call aware. If configured, OpenSIPS monitors all the ongoing calls and checks the validity and health of all the SIP messages in the call. Such checks are mainly looking for broken in-call routing (for sequential requests), requests injection (attacks based on sequential requests), or hanged calls (so-called zombie calls, which were terminated only by one end).
• Topology hiding: On a call basis, OpenSIPS can perform IP and/or SIP topology hiding.
• Traffic filtering: Using regular expression patterns, OpenSIPS can filter out the SIP traffic by inspecting various fields in the SIP requests—Request URI, User-Agent, or From/To headers.
• Media handling: Codec filtering and reordering can be performed in combination with media pinning, transcoding, or call recording (using external media servers).
• SIP tracing: OpenSIPS can be instructed to selectively trace (and store) certain SIP traffic on a SIP user, source IP, or destination criteria.
• Data replication: OpenSIPS implements an internal data replication mechanism, which is a must in building High Availability (HA) solutions with hot backups (active backup) or even Active-Active solutions. Transparency and 0% losses are mandatory requirements for the SBC HA solutions.

On the top level, at the routing level, endpoints and traffic can be handled in almost any custom combination by OpenSIPS SBC, which acts as a frontend for the core components:

• Endpoint authentication: IP-based and Digest-based authentication can be performed against the traffic received from the endpoints.
• Traffic shaping: The traffic received from the endpoints may be subject to limitations based on the number of concurrent calls or the calling rate.
• Dialplan: For the incoming traffic, OpenSIPS can offer a simple dialplan. This provides you with the ability to perform inspection and changes over the dialled or dialling numbers (or SIP URIs).
• Dispatching/Load-balancing: As a frontend for the core components, OpenSIPS can provide the function of distributing the incoming traffic across multiple back servers (such as application or media servers); the distribution is also combined with a failover mechanism. OpenSIPS monitors and detects when one of the core servers is down and reroutes the traffic to the remaining back servers.
• Custom routing: The selection of the core servers may be done via different custom logics, such as inspecting the SIP domain, source IP, dial number, or any other part of the incoming SIP traffic.

A frontend (or SBC) OpenSIPS may be part of a SIP network design from day zero or it may be added later in order to solve problems such as scaling and distribution of the existing SIP platform.

There is a large set of deployments based on PBX-oriented SIP servers, such as FreeSwitch, Asterisk, or Yate. Such deployments are focused on delivering rich services to the end users (usually enterprises), but later face the problem of scalability. Such PBX-based services are quite limited in terms of users or active calls. The natural solution to scale them is to add more similar servers, but in order to manage the resulting pool/cluster of core servers, it is a must to add a frontend server to take care of distributing the traffic.

The ability of OpenSIPS to perform the frontending task makes it one of the best solutions when it comes to scaling or geographically distributing the existing SIP platforms.

The core side

The core component of a SIP platform is usually called an application, telephony, media, or feature server. It is basically responsible for implementing the actual service in the way that it is seen by the end users.

There are several classes of services such as residential (end user-oriented), hosted PBX, or enterprise (company-oriented), trunking (traffic exchange), or origination/termination (inbound or outbound gateways).

OpenSIPS is the perfect platform to build core services such as Residential and Hosted PBX services also known as end user-oriented services. Such services are more demanding as they combine the need for a rich set of advanced features (addressing the needs of the end users) with the carrier-level scaling in terms of traffic and location presence.

OpenSIPS offers a rich feature set and an ability to mix everything together via a flexible routing script. It also offers the following end user-oriented features:

• Endpoints management
• DID management
• Advanced call routing (forward, filter, DND, and star codes)
• Presence and messaging
• Class 5 calling (virtual PBX)
• Call center (call queuing)
• CDRs and pre/postpaid billing

Such features are the building blocks of the end user-oriented services. However, OpenSIPS offers basic (or simple) features that you can use, reuse, and combine via the routing script. Mastering the routing script gives you the ability to create new and custom rich features.

Tip

Not all the features are built-in modules; most of them result from pure scripting (combining several basic abilities of OpenSIPS).

Even more, the end user-oriented services offer both SIP-oriented features and non-SIP features. This leads to integration issues; for such purposes, OpenSIPS offers several mechanisms or interfaces to integrate with the external entities:

• A management interface to execute commands in OpenSIPS
• An event interface for OpenSIPS to deliver events to external parties
• An HTTP/REST interface
• An external script/apps execution

The Trunking services demand a high throughput, reliability, failure detection, handling of large amounts of data, precise CDRs, and billing. All these requirements are met by OpenSIPS, thanks to its scalability and flexibility.

Modules such as permissions, ratelimit, and dialog allow OpenSIPS to route, partition, and limit the SIP traffic to more than 10,000 SIP trunks on a single instance.

Even if OpenSIPS does not offer built-in billing engines, it generates accurate and real-time CDRs that can be pushed to external rating engines. Based on its ability to control the calls (to be dialog stateful), OpenSIPS can implement prepaid scenarios and precisely terminate ongoing calls on demand.

When dealing with multiple trunks, each having its particularities, there is a need of a complex dialplan to check and unify (as a format) all the dialled calls. OpenSIPS offers both built-in and scripting capabilities of achieving such operations.

In all the cases, whatever the service is, the access to the database(s) is a strong requirement. OpenSIPS offers a variety of backend to different kinds of databases listed as follows:

• SQL
• NoSQL
• Radius and Diameter AAA
• LDAP

OpenSIPS allows you to combine the usage of all these DB types in your routing logic and connect to different types of servers at the same time (using MySQL and Postgre at the same time or MongoDB and Redis).

The DB access can be transparent (hidden by modules offering encapsulated functionalities) or explicit from the routing script level.

The egress side

The egress side of a SIP platform is typically responsible for interfacing the platform with third-party SIP services such as termination providers (PSTN and IP gateway). Nevertheless, the egress side may also interface with the end users when it comes to delivering PSTN calls to the users. In relation with the termination providers (or carriers), OpenSIPS egress is responsible for doing the so-called PSTN prefix-based routing, which means selecting the proper carrier/gateway to terminate the call based on the dialled number.

In OpenSIPS, the PSTN routing logic has two logical parts:

• Based on the longest matched prefix (from the dialled number), OpenSIPS selects a set of gateways offering termination to this destination number.
• One gateway is chosen from the selected set—which one? It depends on the order in which the gateways are provisioned in OpenSIPS. If the order reflects cost, it means that you have to do Least Cost Routing (LCR). If the order reflects quality, you get quality-based routing.

The mechanism to select the destination gateway is combined with a failover mechanism (so-called gateway failover or gateway redundancy). If the chosen gateway is found as failed (not answering or generating server errors), OpenSIPS can retake the call to the next gateway from the set selected for the destination prefix.

In terms of gateway failover, OpenSIPS can actively monitor the gateways (as availability), enable and disable them on the fly, and adjust the gateway routing only to the available gateways. The following figure shows OpenSIPS working as a SIP router:

The dynamic routing engine in OpenSIPS provides extensions for advanced routing, such as quality-based routing. Based on the routed calls, OpenSIPS dynamically learns the quality of each gateway and adapts the routing to primarily send calls to the gateways providing better quality. The quality of a gateway can be given by statistics such as the following:

• Answer Seizure Ratio (ASR)
• Average Call Duration (ACD)
• Post Dial Delay (PDD)

The peering with the carriers can be subject to traffic limitation—certain carriers/gateways may accept a maximum calling rate or maximum number of parallel calls. OpenSIPS has the ability of calculating these values in real time in a per gateway manner and automatically rerouting the calls to a different gateway when the limits are reached.

The egress OpenSIPS may also be responsible for interacting with other third-party service providers for services such as LNP (number portability) or CNAME (Caller ID).

The interaction with such services can be done either at SIP level (using the SIP redirect mechanism) or via REST APIs. For SIP interfacing, you just need the OpenSIPS basic scripting, while for REST interfacing, OpenSIPS provides a REST client module to perform custom queries.

Similar to the ingress side, the egress side controls the IP and SIP layers of traffic, such as performing network bridging, SIP protocol conversion, NAT traversal, or media handling (pinning, transcoding, and recording).