ETM System SIP Trunk Support Technical Discussion Release 6.0 A product brief from SecureLogix Corporation Rev C
SIP Trunk Support in the ETM System v6.0 Introduction Today s voice networks are rife with security and usage issues and management challenges. Most enterprise voice networks consist of a dispersed network of proprietary circuit-switched PBXs and increasingly, VoIP switches. Some enterprises have both TDM and SIP trunks from the carrier, while others may have TDM trunks at the edge but some mix of VoIP on the premises. A number of voice network security threats and usage issues are common to both circuitswitched and packet-switched voice networks. These issues include the risk of data leaks from unauthorized modems and poorly secured authorized administrative modems, toll fraud, abusive calling patterns (such as fax SPAM, harassing callers who spoof their caller ID, and phishing), misuse of corporate voice resources, and others. Management challenges include bandwidth management, monitoring trunk status and Quality of Service (QoS), call accounting, and Voice Over IP (VoIP) migration. The ETM System addresses each of these challenges, regardless of the mix of proprietary equipment and different circuit types on your voice network. The ETM System secures your voice network with remotely managed Communication Appliances that are deployed inline on enterprise voice trunks. These Appliances, which are controlled by remote Servers, support a number of security and management applications and allow expansion to support future applications. The ETM System is managed from a remote Client that can be used to manage multiple Servers and hundreds of Appliances. ETM Communication Appliances are switch/media independent devices that sit inline on voice trunks to allow monitoring of voice network access and enforcement of user-defined policies. Several types of ETM Appliances are available for various types of voice network circuits and call volumes. In v6.0, a new Appliance type is being introduced to monitor SIP trunks from the service provider. This new SIP trunk Appliance consists of a set of software modules that run on server-class platforms running a custom-tailored version of the Linux operating system.
Figure 1 illustrates how the ETM System is deployed on the voice network. Figure 1: ETM System Deployment For a detailed technical discussion of the overall ETM System, see the ETM (Enterprise Telephony Management) System Technical Overview. The remainder of this document describes the new inline, enterprise-level SIP trunk support in the ETM System v6.0. Technical Overview To secure and manage voice trunks, ETM System Appliances are installed inline on the voice network and integrated into the data network to enable remote management. In v6.0, ETM System Appliance functionality for SIP trunks is provided by a set of integrated, modular software components that run on server-class platforms running a tailored version of the Linux operating system. These modular components include: a highly reliable inline Signaling Proxy, a highly reliable inline Media Proxy, and a Call Processor. The Call Processor interfaces with the ETM Server for all of the components in the SIP application, tracks call state, executes policy, and logs call events and other events. The SIP Signaling Proxy interfaces with the SIP Trunk (signaling) and acts as a logical endpoint to both ends of the SIP Trunk to extract signaling information from the trunk, enable media processing, and enable call termination. If media processing is enabled, the Media Proxy interfaces with the media carried on the SIP trunk and enables codec-based call type determination and media tracking.
These modules can be combined onto a common platform or kept separate, depending on factors such as reliability, load, and cost. Although it is a collection of software components that may be running on multiple hardware platforms, the ETM SIP Appliance application is presented and managed as a single ETM Appliance in the ETM Client GUI. The illustration below shows configuration management GUIs for the SIP application. Figure 2: Configuration GUIs for the SIP Application The ETM SIP application supports the same ETM System functions as for any other circuit type, such as Firewall and IPS Policy enforcement, Health and Status reporting, call monitoring, call logging, and CDR reporting. The illustration below shows SIP calls being monitored by the ETM SIP application. Figure 3: SIP Calls in the ETM Call Monitor
Component Communication The Call Processor, Signaling Proxy nodes, and Media Proxy nodes communicate via socket connections to enable the choice of combined deployment on fewer hardware platforms or distributed deployment across more hardware platforms. The hardware platforms hosting the SIP application components are interconnected using a private network, with the option of using IPSec to encrypt communication between components. Call Load Capacity Call load capacity scales according to the capacity of the hardware platforms chosen for a given deployment. When configured with appropriate hardware, the SIP Appliance application can support an average call rate of 100 calls/second and a total of 2000 simultaneous calls. See the ETM SIP Appliance Technical Specification for a description of each of the projected hardware platforms. (Note: The larger Appliance platforms may accommodate higher call volumes than projected in this document, while the smallest platform may support fewer calls. Specific per-platform capacities will be provided at release.) Logically Inline Deployment The ETM SIP Appliance application is installed logically inline (by IP address) with the SIP trunk signaling and media. It has defined IP addresses and acts as a SIP trunk endpoint to the local enterprise proxy and the remote service provider proxies. These are configured to route all SIP traffic on the specified trunk through the ETM SIP Appliance application, which proxies messages between the SIP Trunk endpoints within the Enterprise and at the Service Provider. The primary benefit of being logically inline is that the SIP application need not sit physically inline on a chokepoint link. This enables the application to see all signaling and media traffic regardless of its physical location, reduces the scope of the traffic that must be processed, and enables clean and effective call termination. However, since the application is inline, it must be deployed in a redundant manner to prevent loss of service, with one or more backup Signaling/Media Proxies ready to seamlessly take control if the processing Signaling or Media Proxy becomes unavailable. High Availability and Reliability Because the SIP product is logically inline with the SIP trunk, it has been designed to be deployed in a highly available manner to prevent loss of voice service. To that end, the Signaling
and Media Proxies are deployed in a redundant fashion on two or more Appliance platforms running high-availability software that provides failure detection and failover to a hot backup. The redundant Signaling Proxies share one or more public addresses that external devices such as SIP Trunk endpoints address. The current processing (active) Signaling Proxy is configured to use these public addresses, but if a service or network connection fails, one of the redundant Signaling Proxies assumes the public address(es) and immediately performs the Signaling Proxy function as messages arrive. Failure of a service or network connection on the processing (active) Signaling Proxy is detected within 5 seconds. Additionally, failover can be manually initiated to accommodate potentially service-disrupting activities such as maintenance or software updates. In this case, the failover to the backup proxy is immediate. After a loss of network connectivity, restart, or reboot and the subsequent switchover of activity, the former processing (active) Signaling Proxy reconnects with the other redundant Signaling Proxies and performs any necessary synchronization to become an available node within the high availability cluster. Like the Signaling Proxy, the Media Proxy must be highly available to ensure continued operation of the SIP Trunk. If the Media Proxy were to completely fail, any calls established through the Media Proxy would lose all media capability. If a service or network connection fails on the processing (active) Media Proxy, a redundant Media Proxy assumes the Media Proxy function. The processing Media Proxy shares connection state information with the redundant Media Proxies to allow them to immediately begin processing media packets for existing calls in case of a switch of activity. As with the Signaling Proxy, failover can be manually initiated to accommodate potentially service-disrupting activities such as maintenance or software updates. After a loss of connectivity, restart, or reboot, a Media Proxy reconnects with the other cluster members and synchronizes its connection state information to facilitate subsequent activity switchovers. In addition to redundancy and failover mechanisms, the SIP product was designed with reliability in mind. Software is as simple as possible with complex or nonessential tasks removed or located in other parts of the system. The software is also structured to continue working in spite of errors or configuration changes, minimizing the need for restarts.
Latency The ETM SIP Appliance application introduces extremely minimal latency to packets it processes so as not to impair voice quality. Latency limits are as follows: Signaling packets: - Invite message: < 3 ms - Non-Invite message with SDP: < 1 ms - Non-Invite message without SDP: < 500 μs Media packets: No more than 100 μs. IPv6 Support Each SIP Appliance application component supports both IPv4 and IPv6 internet protocols simultaneously. For instance, the Signaling Proxy could use IPv4 to communicate with the Call Processor and Media Proxy, but use IPv6 for SIP Trunk signaling. System Integration The ETM Server and ETM Client GUI treat the SIP application like another Appliance type in the ETM System. ETM System management and security functions, such as policy processing, call logging, and reporting are carried out as normal for calls handled by the SIP application. New configuration and control mechanisms are used to address the unique attributes of the SIP product, such as multiple hardware platforms in a single appliance and Signaling/Media Proxy failover from one platform to another. Call Type Determination Call type determination and policy processing based on call type is an important function of the ETM System. The SIP application determines call type by assigning a call type value to each codec, finding all of the codecs used in a call (and their associated call types), and then using a priority order to determine the call type applied to the overall call. For instance, a call using both a Voice and a Video codec would have an overall call type of Video (because the ETM System deems the Video portion more important and Voice is generally assumed to be part of a Video call).
Call Termination On receipt of a command to terminate a call (or termination due to a reject rule), the Signaling Proxy statefully terminates the call by sending out call teardown messages to the SIP Trunk endpoints. Termination is performed in a stateful manner to facilitate proper call teardown and perform any necessary re-transmissions. In addition to terminating calls via SIP signaling, the Signaling Proxy also prompts media connections to be torn down in the Media Proxy, if media processing is active. Architecture Diagram The illustration below provides a high-level logical architecture of the components comprising the SIP trunk interface. Figure 4: Architecture Diagram
Technical Details of the SIP Appliance Application Components The sections below provide technical details about the components comprising the ETM SIP Appliance application, including supported specifications and transmission mechanisms. Call Processor The Call Processor performs the core functions of the ETM appliance, which include Server communication, configuration processing, software package processing, status reporting, call state processing, policy processing, and logging. The Call Processor is typically deployed on its own hardware platform separate from the SIP Signaling Proxy and Media Proxy. Important technical details about the Call Processor include the following: Server Communications The Call Processor connects to the ETM Server in the same fashion as other ETM Appliances. The Call Processor is the conduit for all communication between the Server and individual components within the SIP application. Interaction between the Call Processor and the ETM Server is the same as that of the other types of ETM Appliances, including configuration exchange, log uploading, status reporting, and software and file download. The Call Processor facilitates these interactions with the SIP Signaling Proxy and Media Proxy nodes. Configuration Processing The Call Processor receives configuration information from the Server regarding itself and the Signaling Proxy and Media Proxy nodes. The Call Processor passes appropriate configuration to the other nodes. Upon initial connection to the Server, the Call Processor uploads all known configuration information for itself and the other SIP application nodes in the same way that other ETM Appliances upload their configuration information. Software Package Processing When software updates are installed, the Call Processor receives software packages from the Server that pertain to all of the SIP application components. The Call Processor first updates itself and then allows the Signaling Proxy and Media Proxy nodes to be upgraded one at a time, thus preventing downtime and allowing fallback to previous versions if necessary. Status Reporting The Call Processor reports status information to the ETM Server for itself and the for the Signaling Proxy and Media Proxy nodes.
Call State Processing The Call Processor executes the Call State Machine using events from the SIP Signaling Proxy (call signaling) and the Media Proxy (call type and media statistics). These events drive the Call State Machine, which in turn leads to Call Logging and Policy Processing. Policy Processing The Call Processor executes Firewall and IPS Policies in the same manner as other ETM Appliances, including reject rules (call blocking). Call Recording is not supported in this version. In the event that policy processing results in call termination, the Call Processor commands the Signaling Proxy to terminate the call. Logging The Call Processor logs call events, policy events, and other error and informational events and sends them to the ETM Server. SIP Signaling Proxy The SIP Signaling Proxy is a highly available transaction stateless proxy that sits logically inline (by address) on a SIP Trunk. The Signaling Proxy tracks the state of each call, requests setup of media connections through the Media Proxy, forwards call event information to the Call Processor, and performs call termination (both blocking and mid-call termination) as tasked by the Call Processor. The SIP Signaling Proxy allows up to four SIP Trunks to be defined simultaneously. Important technical details of the SIP Signaling Proxy include the following: Logically Inline As described previously, the SIP Signaling Proxy sits logically inline on a SIP Trunk by being an addressable entity on the network and proxying messages between the SIP Trunk endpoints within the Enterprise and at the Service Provider. The Enterprise and Service Provider SIP Trunk endpoints must be configured to point at the Signaling Proxy address (or addresses). Being logically inline eliminates the need to sit physically inline at a network chokepoint. That in turn eliminates the need to support all potential network interface types (for example fiber optic) and eliminates the need to filter out SIP traffic while not degrading non- VoIP traffic passing through the choke point. Transaction Stateless The SIP Signaling Proxy is stateless in regard to SIP Transaction processing carried out over each SIP Trunk. This simplifies the functionality, increases the throughput, and reduces the memory usage of the Signaling Proxy, while also reducing the chance of introducing an error while processing SIP signaling.
Call State Tracking Although the SIP Signaling Proxy is transaction stateless in regard to messages sent over the SIP trunks, it actively maintains the state of each call internally. This facilitates the setup of media connections through the Media Proxy, allows the proper logging of call events to the Call Processor, and enables stateful termination of calls. Highly Available The SIP Signaling Proxy achieves high availability by using multiple instances of the Signaling Proxy running on multiple hardware platforms, referred to as nodes. At any given time, one Signaling Proxy node is the processing (active) node and the other redundant nodes are available for activity should the processing node fail. Redundancy/failover is facilitated through the use of a shared IP address between the Signaling Proxy nodes. Media Proxy Interaction If media processing is enabled, the SIP Signaling Proxy requests that media connections for a SIP call be established through the Media Proxy as the call is established. The Signaling Proxy only initiates media sessions for SIP messages containing the Real Time Protocol (RTP) audio/video profile within the Session Description Protocol (SDP). Other forms of media are not processed by the ETM SIP application and pass by unaffected. Call Processor Interaction The SIP Signaling Proxy forwards call events to the Call Processor for call tracking and policy processing. If policy indicates that a call should be terminated, the Call Processor sends a message to the Signaling Proxy commanding it to terminate the call. The Signaling Proxy also receives reject policies from the Call Processor which it uses to perform call blocking without waiting for call establishment. Call Termination On receipt of a command to terminate a call (or termination due to reject policy), the Signaling Proxy statefully terminates the call by sending out call teardown messages to the SIP Trunk endpoints. Termination is performed in a stateful manner to facilitate proper call teardown and perform any necessary re-transmissions. In addition to terminating calls via SIP signaling, the Signaling Proxy also prompts media connections to be torn down in the Media Processor if media processing is active. Message Transport The Signaling Proxy supports both UDP and TCP transmission mechanisms. In general, the Signaling Proxy forwards messages using the same transport mechanism with which the message was received.
Media Proxy The Media Proxy is a highly available proxy that creates and manages media connections between SIP User Agents involved in calls established through the SIP Signaling Proxy. In addition to forwarding media information between SIP UAs, the Media Proxy calculates and forwards media statistics for its managed media streams and resulting call type to the Call Processor. The Media Proxy only supports UDP packets containing RTP/RTCP media. Other media forms/transports are not supported. Important technical details of the Media Proxy include the following: Media Connection Creation and Management The Media Proxy creates and manages media connections at the request of the SIP Signaling Proxy. The Signaling Proxy assigns ports to be used in each connection from a list of ports that it manages. Each connection includes an even numbered port for RTP packets and the next higher port number for Real Time Control Protocol (RTCP) packets. Media connections are torn down by the Media Proxy based on messaging from the SIP Signaling Proxy indicating that the call has ended or been terminated, or that the media connection has been renegotiated to use a different connection. Media Forwarding The Media Proxy forwards media information between SIP UAs based on its defined media connections. Packets are forwarded without modifications other than changing the Source and Destination IP addresses and ports to match the given media connection. Other packet information, such as Quality of Service tagging, is retained. Highly Available The Media Proxy functions in a redundant fashion like the SIP Signaling Proxy in order to achieve high availability. Multiple Media Proxy instances are deployed on different hardware platforms. One of these nodes actively processes media and the other nodes are available to take over for the active node in the event of a failure. These nodes achieve redundancy/failover through the use of a shared IP address. Call Processor Interaction The Media Proxy collects and forwards statistics regarding managed media streams to the Call Processor. Statistics information includes the types of codecs used, the number of packets and bytes sent/received, and RTCP information such as jitter and packet loss. The Media Proxy also determines the call type associated with each codec in use on the call and then reports the highest priority call type to the Call Processor as the overall call type for the call.
ETM, TeleWatch Secure, TWSA, We See Your Voice, Unified Communications Policy Manager, SecureLogix, SecureLogix Corporation, as well as the ETM Emblem, SecureLogix Emblem and the SecureLogix Diamond Emblem are trademarks and/or service marks or registered trademarks and/or service marks of SecureLogix Corporation in the U.S.A. and other countries. All other trademarks mentioned herein are believed to be trademarks of their respective owners Copyright 2009 SecureLogix Corporation. All Rights Reserved. SecureLogix technologies are protected by one or more of the following patents: US 6,226,372 B1, US 6,249,575 B1, US 6,320,948 B1, US 6,687,353 B1, US 6,700,964 B1, US 6,718,024 B1, US 6,735,291 B1, US 6,760,420 B2, US 6,760,421 B2, US 6,879,671 B1, US 7,133,511 B2, US 7,231,027 B2, US 7,440,558 B2, and CA 2,354,149. U.S. and Foreign Patents Pending.