Managing SIP traffic with Zeus Traffic Manager

(1)

Managing SIP traffic

with Zeus Traffic

Manager

(2)

High-Availability and Scalable Voice-over-IP Services

Voice-over-IP (VoIP) services are converging on SIP and RTP for signaling and real-time media delivery respectively. This paper will introduce the key elements of a SIP network, and describe the scalability and high-availability services provided by Zeus’ Application Delivery Controller, Zeus Traffic Manager.

Although SIP is an IETF standard, many implementations and extensions exist and mutual compatibility between different user agents cannot always be assured. Furthermore, organizations who wish to deploy advanced, differentiated SIP services need deep visibility and management of SIP traffic. Zeus Traffic Manager’s full application-level inspection, driven by the TrafficScriptTM_{programming language, makes it possible to compensate for} any differences in behavior between applications and to rapidly prototype and deploy differentiated SIP services.

What is SIP?

SIP (Session Initiation Protocol) is a signaling protocol used to support VoIP and other rich media services. It provides several capabilities:

User Registration: When a user device such as a smart phone is activated or moves,

it communicates with a SIP proxy to register its location and capabilities.

User Availability: When a remote device wishes to communicate with a local user, it

locates and communicates with the local SIP proxy to check the availability of the user.

User Capabilities: A remote device may use SIP to query the capabilities of the local

user, for example, to determine if the user is able to take video calls, or use a shared whiteboard resource.

Session Setup: The SIP protocol is used to set up a rich media session between two

endpoints (a remote and local user).

Session Management: Once a session is established, media data is exchanged using

a protocol such as RTP, but the SIP connection is maintained and used to control the various media sessions. SIP allows for session transfer from one device to another, creation of new media sessions on-the-fly and the ultimate termination of media sessions.

SIP is an HTTP-like protocol, but it runs over either UDP or TCP. SIP sessions are typically much more long-lived than HTTP.

(4)

Architecture of a SIP-based Service

A SIP-based service will contain several components that work together to ensure successful delivery of the service:

SIP User Agents: A SIP User Agent is the connection endpoint that initiates or

receives a SIP connection. User agents include SIP-enabled VoIP telephones, client software (a ‘softphone’) and other end user devices.

SIP Proxy Servers: SIP Proxy Servers route SIP messages from endpoint to endpoint

and manage core services such as user registration. For example, the widely used OpenSER SIP Proxy Server(www.openser.org) provides registration services (accepting SIP REGISTER requests), location services (managing and forwarding INVITE requests), request proxying (to forward SIP messages or tunnel through local firewalls) and redirect services (directing a user agent to an alternate location).

SIP proxy servers may also route and proxy the RTP media data, or a separate RTP proxy application may be used.

PBX Gateways: A gateway may be used to interface a VoIP network with other

telephony systems such as PSTN (Public Switched Telephone Network). For example, a VoIP deployment may use the Asterix (www.asterix.org) server for this purpose.

Sample SIP deployment: Telephony Provider and Customer

SIP services – registration, location, SIP traffic management - are commonly provided by an external telephony provider. End user organizations manage the user agent devices, minimizing their capital investment and cost of management.

Successful provision of a SIP service requires very high availability, scalability as the client base and call volumes grow, and the ability to create differentiated services for client groups.

Organizations typically use a SIP-aware Application Delivery Controller such as Zeus Traffic Manager to achieve this.

PSTN/Internet gateway

SIP Proxy server

Location Server

RTP Proxy

SIP traffic

RTP traffic

Telephony Provider Customer

PSTN Internet

gateway

PSTN gateway

SIP User Agent

(5)

High Availability SIP Services

The Zeus Traffic Manager Application Delivery Controller fully understands SIP traffic, including the requirement to maintain and update the Via field in the SIP traffic before load-balancing the message to a proxy.

Zeus Traffic Manager is used in SIP traffic management mode to load-balance SIP requests across a cluster of redundant SIP proxy servers for high availability:

SIP deployment with Application Delivery Controller

Load Balancing

Load balancing, based on ‘least connections’ effectively distributes new SIP connections to the least utilized SIP proxy servers and ensures even distribution of connections across the cluster.

Session Persistence

Although SIP is a stateful, connection-based protocol, it is based on UDP which does not provide connection semantics. Zeus Traffic Manager automatically applies session persistence, honoring the Call-ID field and routing SIP messages in the same session to the same proxy server to ensure that SIP sessions are handled as efficiently as possible and to facilitate logging and diagnostics. Session persistence is necessary for session continuity when handling SIP message retransmits.

Nevertheless, the SIP protocol is robust, and if an individual SIP server were to fail, Zeus Traffic Manager’s health checking and routing would ensure that the failover would occur without interruption.

Health Monitoring

Built-in health monitors regularly probe each SIP Proxy Server to verify correct operation and apply failover when required.

SIP traffic

Telephony Provider Customer

PSTN Internet

gateway

PSTN gateway

SIP User Agent

SIP User Agent SIP Proxy servers

(6)

Gatewaying between SIP networks

As organizations roll out IPv6 infrastructures, communications between disparate IPv4 and IPv6 networks require special management. IPv4 clients will be unable to contact IPv6 proxies and clients directly, so an intermediate gateway that can translate addresses and locations is required.

Using Zeus Traffic Manager to gateway between internal IPv6 network and external IPv4 network

Without a SIP-aware IPv4/IPv6 gateway like Zeus Traffic Manager, IPv4 SIP clients would be unable to communicate with IPv6 SIP proxies.

Internal SIP networks

Zeus Traffic Manager’s built-in RTP proxy can be used to manage and make fault-tolerant both the SIP and RTP traffic in an environment where all clients are local:

Using Zeus Traffic Manager’s built-in RTP proxy when all clients are local In more complex environments, a specialized RTP proxy is required.

INVITE mary@example.com

SIP Proxy servers @example.com

joe@example.com

mary@example.com REGISTER joe@example.com

fred@somewhere.else INVITE joe@example.com

example.com IPv6 network

IPv4 / IPv6 gateway

Public IPv4 network

VPN gateway

PSTN gateway

SIP User Agent SIP Proxy servers

PSTN

(7)

SIP Service - Capacity Scaling

SIP Proxies can be added to a SIP cluster as required, without incurring any downtime or significant reconfiguration. This way, service capacity can be easily scaled.

Removing SIP proxies

When a SIP proxy needs to be removed, for maintenance purposes for example, Zeus Traffic Manager can be instructed to ‘drain’ the proxy, ensuring that no new connections or sessions are routed to that proxy.

Once existing sessions time out and inactivity is verified with the visualization tools in Zeus Traffic Manager itself, it is safe to remove the SIP proxy server without interrupting any user sessions.

Differentiated Services and SIP Solutions

Zeus Traffic Manager’s powerful TrafficScriptTM_{-based inspection engine can be used to} inspect, modify and route SIP traffic. This allows the telephony provider to rapidly create differentiated services for their customers.

Request Inspection

A TrafficScript rule can discriminate between different types of SIP requests, and can inspect data within each request:

if( sip.getMethod() == "REGISTER" ) {

log.info( "Client " . request.getRemoteIP().

" calling from " . sip.getRequestHeader( "From" ). " to " . sip.getRequestHeader( "To" ).

" using " . sip.getRequestHeader( "User‐Agent" ) ); }

Request Routing

A telephony provider may wish to operate a single shared SIP proxy service for customers with smaller call volumes, and one or more dedicated proxy services for larger customers with many SIP clients who would otherwise dominate a shared service.

TrafficScript can be used to distinguish between users based on the domain part of SIP addresses, and route traffic accordingly to different clusters of SIP proxy servers:

$user = sip.getRequestURI();

if( string.EndsWith( $user, "@example.com" ) ) { pool.use( "Example.com SIP Servers" );

(8)

Issuing Redirects

SIP calls can be explicitly redirected based on logic in TrafficScript rules: $user = sip.getRequestURI();

# Customer service team are not available outside 9am to 5pm, or on weekends if( string.EndsWith( $user, "@custservice.example.com" ) ) {

if( sys.time.hour() < 9 || sys.time.hour() >= 17 ||

sys.time.weekday() == 1 || sys.time.weekday() == 7 ) { sip.redirect( "voicemail@example.com" );

} }

Rectifying Application Errors

When an intermediate device such as a proxy or firewall processes, forwards or NATs SIP traffic, the device is required to update the Via field in the SIP message so that return messages are correctly routed.

During extensive testing, engineers determined that a particular family of firewall applications did not correctly update SIP traffic; when proxying and NAT-ing traffic, they would prepend incorrectly formatted ‘Via’ lines to SIP messages. Strict user agents and proxies subsequently rejected the message.

Zeus Traffic Manager was configured using TrafficScript to correct the formatting of the Via line and resolve the problem:

$via = sip.getRequestHeader( "Via" );

$via = string.replaceAll( $via, ";,", "," ); sip.setRequestHeader( "Via", $via );

Adding Information to SIP Calls

Various SIP user agents can recognize and act on additional information in a SIP call. For example, icons and caller information can be provided using the ‘Call-Info’ header in a SIP message:

# Add a reference to an information page about # a known company when a call is received from # them, and an icon to help identify them.

if( sip.getRequestHeader( "Organization" ) == "Zeus" ) { sip.setRequestHeader( "Call-Info",

"<http://www.zeus.com/assets/img/logo.gif> ;purpose=icon,". "<http://www.zeus.com/about/> ;purpose=info" );

(9)

‘REGISTER’ Storms

SIP user agents send frequent ‘REGISTER’ messages to their local SIP proxy in order to keep firewall tunnels open and prevent them from timing out. However, proxies do not require such frequent updates, and storms of REGISTER messages can overwhelm a proxy. Zeus Traffic Manager can be configured to inspect and filter the REGISTER messages, only sending a small number through to the proxies and responding directly to the large majority in order to maintain the firewall tunnels.

Request rule:

# Process SIP requests $interval = 600;

if( sip.getMethod() == "REGISTER" ) { $user = sip.getRequestHeader( "To" ); $contact = sip.getRequestHeader( "Contact" ); $key = $user.$contact;

$data = data.get( $key );

if( $data && sys.time() < $data + $interval ) {

# We've seen the user less than $interval seconds ago. Respond directly sip.sendResponse( "200", "OK" );

}

# Otherwise, update our timing and pass the message through to the proxy data.set( $key, sys.time() );

sip.setRequestHeader( "Expires", "0" ); }

Response rule:

The Response rule needs to cater for the possibility that the registration failed, returned an ‘Authorization Required’ response, or any other situation that requires the SIP User Agent to repeat the registration action:

# Process SIP responses

if( sip.getMethod() == "REGISTER" ) { if( sip.getResponseCode() != "200" ) { $user = sip.getRequestHeader( "To" ); $contact = sip.getRequestHeader ( "Contact" ); $key = $user.$contact;

data.set( $key, 0 ); }

(10)

Rewriting SIP Data

Zeus Traffic Manager provides full read and write access to all SIP data, through specialized helper functions and through functions that return or set the raw message data.

For example, Zeus Traffic Manager can transparently rewrite usernames to avoid callers receiving an ‘unknown user’ error in the case that a user’s SIP address has changed:

if( sip.getRequestURI() == "sip:jane.doe@example.com" ) { # Jane got married last month – congratulations! sip.setRequestURI( "sip:jane.jones@example.com" ); }

Conclusion

Zeus Traffic Manager is a sophisticated, proven application delivery controller that provides for high availability, improved service performance and faster service creation. Zeus Traffic Manager’s native understanding of the SIP protocol (as opposed to less intelligent IP sprayer solutions), coupled with full transaction inspection and management using TrafficScriptTM_{makes Zeus Traffic Manager a powerful tool for the creation of} highly-available, standards-compliant and innovative SIP services.

(11)

Appendix: SIP processing functions in TrafficScript

TM

sip.addRequestHeader( name, value, at_top )

sip.addRequestHeader() modifies the current SIP request, adding a SIP header with the supplied value. If the header already exists, then this value will be appended to the existing value. If at_top is set then the value will be prepended to the header. The header name is automatically translated to the correct case before it is added.

sip.addResponseHeader( name, value, at_top )

sip.addResponseHeader() adds a header to the SIP response that will be sent back to the client. If the header already exists in the response, then this value will be appended to the existing value. If at_top is set then the value will be prepended to the existing value. The header name is automatically translated to the correct case before it is added.

sip.getMethod()

sip.getMethod() returns the SIP method that was used to make the request, such as INVITE or REGISTER.

sip.getRequest()

sip.getRequest() returns the full SIP request and headers, but does not include any body data.

sip.getRequestBody()

sip.getRequestBody() returns the data contained in the body of the request.

sip.getRequestHeader( name )

sip.getRequestHeader() returns the value of a named SIP header in the SIP request, or the empty string if the header does not exist or has an empty value. The header name is automatically translated into the proper case for the lookup.

sip.getRequestHeaderNames()

sip.getRequestHeaderNames() returns a list of all the headers that are present in the request. The headers are returned as a single string, separated by spaces.

sip.getRequestURI()

sip.getRequestURI() returns the target of the SIP request.

sip.getResponse()

sip.getRequest() returns the full SIP response and headers, but does not include any body data.

sip.getResponseBody()

sip.getResponseBody() returns the session description of the SIP response.

sip.getResponseCode()

(12)

sip.getResponseHeader( name )

sip.getResponseHeader() returns the value of a named SIP header in the SIP response, or the empty string if the header does not exist or has an empty value. The header name is automatically translated into the proper case for the lookup.

sip.getResponseHeaderNames()

sip.getResponseHeaderNames() returns a list of all the headers that are present in the response. The headers are returned as a single string, separated by spaces.

sip.getVersion()

sip.getVersion() returns the version of the SIP protocol being used. It returns the version string in the SIP/version specifier in the first line of the SIP request, such as 'SIP/2.0'.

sip.redirect( contact )

sip.redirect( contact ) sends back a 302 Moved Temporarily response. This response instructs the client to retry the request at the new address(es) given in the 'contact' parameter. This is equivalent to sip.sendResponse( "302", "Moved Temporarily", "Contact: " . $uri, "" );

sip.removeRequestHeader( name )

sip.removeRequestHeader() removes a named header if it exists in the request. The header name is automatically translated to the correct case.

sip.removeResponseHeader( name )

sip.removeResponseHeader() removes the named SIP header from the SIP response. The header name is automatically translated to the correct case.

sip.requestHeaderExists( name )

sip.requestHeaderExists() determines if a named header exists or not. It is similar to sip.getRequestHeader(), but makes it possible to distinguish between a header not being present and a header having no value.

The header name is automatically translated into the proper case for the lookup. It returns 1 if the header exists, and 0 if it does not.

sip.responseHeaderExists( name )

sip.responseHeaderExists() determines if a named header exists in the SIP response. It is similar to sip.getResponseHeader(), but makes it possible to distinguish between a header not being present and a header having no value.

The header name is automatically translated into the proper case for the lookup. It returns 1 if the header exists, and 0 if it does not.

sip.sendResponse( code, reason, [headers], [body] )

sip.sendresponse() sends back a SIP response to the client instead of balancing the request via a pool onto a node. The Statue-Line of the response has the form: SIP/2.0 code reason Via, Record-Route, From, To, CSeq, Call-ID and Content-Length headers are automatically added to the response. Any headers supplied in the headers parameter will also be added to the response. Multiple headers must be separated by \r\n. Any body data specified is appended to the response.

(13)

sip.setMethod( method )

sip.setMethod() sets the SIP method to use when forwarding the request via a pool to a node.

sip.setRequestBody( body )

sip.setRequestBody() sets the request body for this SIP request to the supplied string, replacing any request body already present.

This also updates the 'Content-Length' header in the request to the length of the new body data.

sip.setRequestHeader( name, value )

sip.setRequestHeader() sets the value of the named SIP header, replacing any existing value if the header already exists.

sip.setRequestURI( uri )

sip.setRequestURI() sets the target of the SIP request.

sip.setResponseBody( body )

sip.setResponseBody() sets the response body for this SIP response to the supplied string, replacing any response body already present.

This also updates the 'Content-Length' header in the response to the length of the new body data. If the server is still sending the original response body when this function is called, the connection to the server will be harmlessly dropped.

The optional transfer-encoding parameter indicates the encoding of the body data (for example, 'chunked').

sip.setResponseCode( code, message )

sip.setResponseCode() sets the status code and message in the first line of the SIP response.

sip.setResponseHeader( name, value )

sip.setResponseHeader() sets a header in the SIP response that will be sent back to the client. If the header already exists in the response, then it will be replaced with this new value.

(14)

For further information, please email: info@zeus.com or visit www.zeus.com Stay in touch with Zeus by following: blog.zeus.com or twitter.com/ZeusTechnology

Try before you buy.

Simply visit our website: www.zeus.com/downloads Technical support is also available during your evaluation.

Zeus Technology Limited (UK) Sales: +44 (0)1223 568555 Zeus Technology, Inc. (U.S.) Phone: 1-888-ZEUS-INC The Jeffreys Building Main: +44 (0)1223 525000 1875 South Grant Street Fax: 1-866-628-7884 Cowley Road Fax: +44 (0)1223 525100 Suite 720 Email: info@zeus.com Cambridge CB4 0WS Email: info@zeus.com San Mateo, California 94402 Web: www.zeus.com United Kingdom Web: www.zeus.com United States of America.

Managing SIP traffic with Zeus Traffic Manager