The Business Forum

"It is impossible for ideas to compete in the marketplace if no forum for
  their presentation is provided or available."           Thomas Mann, 1896

The Business Forum Journal

 

Managing SIP Traffic

 

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.

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.

 

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.

 

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.

 

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:

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:

Issuing Redirects

SIP calls can be explicitly redirected based on logic in TrafficScript rules:

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:

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:

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

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:

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:

 

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.

Appendix: SIP processing functions in TrafficScriptTM

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

sip.getResponseCode() returns the status code from the first line of the SIP response.

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.

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.

The header name is automatically translated to the correct case before it is added.

For further information, please email: info@zeus.com  or visit www.zeus.com

Jasper M. Rose is a Fellow of The Business Forum Institute and is the Vice President, Virtualization Business Unit for Zeus Technology, Inc. He has over 25 years of experience in the field of Information Technology.  During his career he has been a  Member of the Professional Telecommunications Workers of America and the Telecommunications Association and the American Society of Training Development. Jasper graduated from A. I. Prince Regional Technical School and is a Certified Network Telecommunications Engineer.  During his career he has held senior positions with Southern New England Telephone; Fujitsu America, Inc., and has been Director of Strategic Alliances and Business Development for Fujitsu Software Corporation; Director of Worldwide Accounts for Cylink Corporation; Director of Sales Western Region for Solsoft Corporation and Regional Director Federal and Strategic Accounts for Array Networks, Inc., prior to joining Zeus Technology.

Visit the Authors Web Site

http://knowledgehub.zeus.com

Return to


The Business Forum Journal
 

Search Our Site

Search the ENTIRE Business Forum site. Search includes the Business
Forum Library, The Business Forum Journal and the Calendar Pages.

Editorial Policy: Nothing you read in The Business Forum Journal should ever be construed to be the opinion of, statements condoned by, or advice from, The Business Forum, its staff, workers, officers, members, directors, sponsors or shareholders. We pass no opinion whatsoever on the content of what we publish, nor do we accept any responsibility for the claims, or any of the statements made, within anything published herein.  We merely aim to provide an academic forum and an information sourcing vehicle for the benefit of the business and the academic communities of the Pacific States of America and the World.  Therefore, readers must always determine for themselves where the statistics, comments, statements and advice that are published herein are gained from and act, or not act, upon such entirely and always at their own risk.  We accept absolutely no liability whatsoever, nor take any responsibility for what anyone does, or does not do, based upon what is published herein, or information gained through the use of links to other web sites included herein.                                                                                           Please refer to our: legal disclaimer
 


Home    Calendar    The Business Forum Journal    Features
Concept     History     Library    Formats    Guest Testimonials
 Client Testimonials      Search      News Wire     Why Sponsor
Tell-A-Friend     Join    Experts   Contact The Business Forum
 

 

The Business Forum


 Beverly Hills, California United States of America

Email:  john@bizforum.org

Graphics by DawsonDesign

Webmaster:  bruceclay.com
 

© Copyright The Business Forum Institute 1982 - 2010  All rights reserved.