Overview

AG Projects RTC Platforms (Routing Guides)

This document describes the routing mechanisms.

Intro

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

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).

Primitives

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:

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/:

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.

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.

AAA

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

Authentication

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

Sessions

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.

Register

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.

Presence

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:

http://openxcap.org/features

Authorization

Sessions

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

Presence

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

1. XCAP pres-rules document
2. Trusted peers

Accounting

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

Next Steps

Continue by:

• learning about Routes: End-Point; or
• learning about Routes: MSRP media; or
• learning about Routes: PBX or Trunk; or
• learning about Routes: Presence; or
• learning about Routes: PSTN; or
• learning about Routes: Special.