Page MenuHomePhabricator

AG Projects RTC Platforms (Routing Guides)

This document describes the routing mechanisms.


MSP and SIP Thor platforms are based on a SIP Proxy/Registrar/Presence Agent design. Each SIP server node maintains transaction and dialog state for each session and is able to terminate each of them based on various criteria. The platform handles and controls the RTP and MSRP media planes and is able to take decisions related to authorization, authentication, accounting, NAT traversal and session termination based on the media flow behavior. The design eliminates the need of separate session border controller elements which just add costs, hurt scalability and add no end-user features.

The platform has rich telephony functions equivalent with traditional Class 4 switches (routing inter-carrier calls) and Class 5 switches (routing last-mile calls to end-users).

The platform can be equally used to perform SIP services that include and are not limited to Residential VoIP, Prepaid Cards, Video Calling, Presence and IM, Trunking, Least Cost Routing and ENUM Peering.

Logical Architecture

book-general-sip-platform-msp-interconnect (404×573 px, 76 KB)

IP addressing

The platform is designed to operate using IPv4 addresses using public IP space, this topology allows end-points to operate behind any type of NAT router. The end-points can use both private or private IPv4 addresses.

SIP Entities

This guide describes routing logic between several SIP entities defined as follows:

  1. SIP Proxy: the platform core that performs the logic described in this document
  2. End-Point: a SIP end-user device that is configured with the credentials of a SIP account for which the platform is responsable
  3. PBX: a SIP end-point or intermediary that is configured under a foreign SIP domain not handled by the platform
  4. PSTN gateway: a SIP end-point or intermediary that is handling the translation between IP (using SIP protocol) and PSTN networks

Supported Signaling

The platform supports SIP protocol over UDP/TCP/TLS transports. Additional, a gateway to and from XMPP remote domains can be configured.

Supported Media

The platform supports sessions containing the following media types:

  • Audio (RTP and sRTP)
  • Video (RTP and sRTP)
  • FAX (RTP and T.38)
  • Instant messaging (MSRP and its relay extension)
  • File transfer (MSRP and its relay extension)
  • Page mode messaging (SIP MESSAGE method)
  • Presence (RLS Subscriptions and Presence Agent)
  • XCAP contact lists (the OMA variant)

The platform is codec agnostic, the negotiation of the codecs depends entirely on the end-points. The MediaProxy component that relays the RTP media between the end-points, for NAT traversal and accounting purposes, relays all packets at IP layer 3 (UDP protocol that encapsulates the RTP/RTCP streams). The actual payload with the particular codecs used inside the RTP streams is transparently passed between end-points without interference from MediaProxy.

Other payloads are supported as long as they are embedded into a supported stream, for example any payload that is embedded within the RTP streams (zRTP, DTMF tones) or MSRP streams (file transfer, multy-party chat service, desktop sharing).


The routing of SIP sessions is governed by two main protocols:

  1. Domain based SIP routing based on RFC3261 and RFC3263
  2. ENUM lookups based on RFC3761

The routing logic of the platform can be configured by changing its database tables and configuration files. The primitives used for routing are:

Registrar databaseUsed to translate a SIP address into a SIP contact address
ENUMUsed to translate an E.164 telephone number into a SIP address
SIP aliasUsed for adding aliases to existing SIP accounts
Emergency numbersTranslation between 911 and 112 into closest emergency access points
Call diversionTranslate a SIP address into another based on signaling conditions or end-user preferences
DNS lookupsTranslate a SIP domain/hostname into an protocol:IP:port combination
LCRUsed for selection of outgoing PSTN gateway

Server Location

To locate the SIP Proxy/Registrar for a domain, SIP endpoints must perform DNS lookups based on RFC3263 that return the IP:port combination for which the server is configured.

Configuration Files

Index of SIP Proxy configuration files located in/etc/opensips/:

config/settings.m4Contains the settings that can customize the routing logic
config/opensips.m4Contains the proxy routing logic (should not be modified)
config/siteconfig/handle-incoming-pstn.m4Used to customize routing logic for incoming PSTN calls
config/siteconfig/handle-local-extensions.m4Used to define installation specific custom local extensions
config/siteconfig/handle-outgoing-peers.m4Used to customize routing for outgoing calls to non-local domains
config/siteconfig/postprocess-request.m4Used to customize outgoing requests before they leave the proxy
config/siteconfig/preprocess-pstn.m4Used to customize outgoing PSTN requests before applying LCR routing
config/siteconfig/preprocess-request.m4Used to apply custom pre-processing to a request before anything else
config/siteconfig/preprocess-uri.m4Used to apply custom pre-processing to the request URI before converting to E164

The settings.m4 file is used to customize the existing routing logic defined in opensips.m4 using the predefined routing options. The files under the siteconfig/ directory can contain installation specific routing logic, which will be included by opensips.m4 and will allow for the routing logic to be adapted to the specific requirements of a given installation. The opensips.m4 file will always be overwritten on upgrades, so it should never be modified, while the files under the siteconfig/ directory will never be overwritten and can be modified without restrictions.

NAT Traversal

NAT traversal methods encountered in the field and their properties:

  • SIP server based (Relay) - reliable server side technology that works with all SIP clients, this method is used by the platform
  • SIP client based (ICE) - client and server technology where client may negotiate media paths, is supported by the platform
  • Intermediates based:
    • NAT routers with SIP Application Level Gateway (SIP ALG) - located in customer premises network and the most *unreliable* technique
    • Sessions Border Controllers (SBC) - located in service provider network - reliable with high cost and high complexity

The most reliable way to solve NAT issues with SIP is server based, by relaying packets using servers visible by both end-points. A new methodology under development is ICE, which relies partially on the SIP clients. NAT traversal applied in intermediates only introduce problems and SBCs add costs without adding value to the SIP service.

Below is a display of all possible NAT traversal techinques used for SIP and related media.

book-general-sip-platform-nat-traversal-techniques (390×637 px, 51 KB)

The platform handles the NAT traversal for all its end-points by relaying all traffic, signaling and media through its servers that have public IP address and are visible for both end-points involved in a call flow.

Optional, ICE can be deployed when supported by the end-points. The media relay acts like a TURN candidate and the operator may choose on a per call basis when and how this relay is to be used. When using ICE, SIP sessions that do not have a BYE cannot be accounted for.

NAT traversal is not the same thing as Firewall traversal. A firewall has an administrative policy, which must be set to support SIP and associated media traffic.

Platform Ports

See the Firewall Setup section for a list of ports used by the platform software.

Make sure that NAT traversal functions related to SIP known as SIP ALG functionality in the NAT routers are disabled.


Authentication, Authorization and Accounting are performed depending on particular call flows as follows:


The trust relationship between SIP subscribers and SIP Proxy is based on DIGEST algorithm, both have a database with shared credentials.


Authentication for INVITE requests based on two methods:

  1. SIP credentials, when the From header contains a domain served by the platform. The From header presented by the device must match the credentials used for authentication.
  2. Trusted peer identified by IP address, used when the From header contains a remote domain and the request URI is not a local SIP address.

By default, incoming SIP sessions from remote domains to local SIP accounts served by the platform are not authenticated and always authorized.

For Instant Messaging and File transfers, MSRP relay reservations are authenticated using the same credentials for each SIP account.


Authentication for REGISTER methods is based on SIP credentials, this method can be used only by local SIP accounts and will not be relayed outside the platform. The From header presented by the SIP device must match the credentials used for authentication.


The platform provides a Presence Agent that handles PUBLISH, SUBSCRIBE and NOTIFY methods based on SIP SIMPLE standards. The following event packages are supported:

  • presence
  • presence.winfo
  • xcap-diff

Authentication for PUBLISH is based on SIP credentials, this methods can be used only by local SIP accounts and will not be relayed outside the platform. The From header presented by the SIP device must match the credentials used for authentication. Authentication for SUBSCRIBE requests are based on SIP credentials, when the From header contains a domain served by the SIP Proxy.

SUBSCRIBE requests from remote domains are allowed without authentication when the request URI is a local SIP address served by the platform.

SUBSCRIBE for the events message-summary and presence.winfo are allowed only for local users.

XCAP requests are authenticated using the same credentials for each SIP account.

The following XCAP documents are supported:



Authorization for outgoing SIP sessions can be performed for local SIP accounts based on:

  1. Access to PSTN
  2. Administrative blocking
  3. Monthly quota usage
  4. Prepaid balance
  5. Concurrent number of calls
  6. Call barring (user driven)
  7. Custom SIP Proxy logic

Authorization for incoming SIP sessions can be performed for local SIP accounts based on:

  1. Source IP address
  2. Administrative blocking
  3. Accept based on caller
  4. Accept based on time of day
  5. Reject based on caller id
  6. Custom SIP Proxy logic

Automatic session cut-off

SIP sessions can be terminated forcefully by the platform based on the following conditions:

  1. Prepaid balance exceeded (in real time)
  2. Monthly quota exceeded (on the next call)
  3. Maximum call duration exceeded
  4. RTP media timeout
  5. Signaling path lost


Authorization for SUBSCRIBE for the presence event can be performed for local SIP accounts based on:

  1. XCAP pres-rules document
  2. Trusted peers


All SIP and RTP sessions are accounted by using RADIUS requests. See the Accounting Guides for more information.

Next Steps

Continue by: