10.3. SIP ALG

Home Prev	cOS Stream 4.00.03 Administration Guide	Next

Overview

Session Initiation Protocol (SIP) is an ASCII (UTF-8) text based signaling protocol used to establish sessions between clients in an IP network. It is a request-response protocol that resembles HTTP and SMTP. The session which SIP sets up might consist of a Voice-Over-IP (VoIP) telephone call or it could be a collaborative multi-media conference. Using SIP with VoIP means that telephony can become another IP application which can integrate into other services.

SIP does not know about the details of a session's content and is only responsible for initiating, terminating and modifying sessions. Sessions set up by SIP are typically used for the streaming of audio and video over the Internet using the RTP/RTCP protocol (which is based on UDP) but they might also involve traffic based on the TCP protocol. A RTP/RTCP based sessions might also involve TCP or TLS based traffic in the same session.

SIP is defined by IETF RFC 3261 and is considered an important standard for VoIP communication. It is comparable to H.323 but a design goal with SIP was to make it more scalable than H.323.

SIP ALG processing is set up by creating a SIPAlgProfile object and associating it with the SIPAlgProfile property of an IPRule object. The IPRule object must also have a ServiceTCPUDP object assigned to it which has its AppProto property set to SIP.

	Note: Traffic shaping does not function with SIP profiles
	Any traffic connections that trigger an IP rule that references a SIPAlgProfile object cannot be also subject to traffic shaping.

SIP Media-related Protocols

A SIP session makes use of a number of protocols. These are:

SDP: Session Description Protocol (RFC4566) is used for media session initialization.
RTP: Real-time Transport Protocol (RFC3550) is used as the underlying packet format for delivering audio and video streaming via IP using the UDP protocol.
RTCP: Real-time Control Protocol (RFC3550) is used in conjunction with RTP to provide out-of-band control flow management.

SIP Components

The following components are the logical building blocks for SIP communication:

User Agents

These are the endpoints or clients that are involved in the client-to-client communication. These would typically be the workstation or device used in an IP telephony conversation. The term client will be used throughout this section to describe a user agent.

Proxy Servers

These act as routers in the SIP protocol, performing both as client and server when receiving client requests. They forward requests to a client's current location as well as authenticating and authorizing access to services. They also implement provider call-routing policies.

The proxy is often located on the external, unprotected side of the Clavister NetShield Firewall but can have other locations. All of these scenarios are supported by cOS Stream.

Registrars

A server that handles SIP REGISTER requests is given the special name of Registrar. The Registrar server has the task of locating the host through which the other client is reachable.

The Registrar and Proxy Server are logical entities and may, in fact, reside on the same physical server.

SIP Setup Steps

When configuring cOS Stream to handle SIP sessions the following steps are needed:

A ServiceTCPUDP object for SIP is required. If no custom values are required, the predefined ServiceTCPUDP object called sip-udp can be used.

If custom values are required, a new ServiceTCPUDP object should be created. The AppProto property of the service must be set to a value of SIP.
A SIPAlgProfile object is required. If no custom values are required, the predefined SIPAlgProfile object called sip can be used.

If custom values are required, a new SIPAlgProfile object should be created.
Define the appropriate IP rules for SIP communications and associate the ServiceTCPUDP object and SIPAlgProfile object with them.

SIP Profile Properties

The following properties can be configured for a SIPAlgProfile object:

MaxSessionsPerID: The maximum number of simultaneous sessions that a single client can be involved with is restricted by this value. The default number is 5.
MaxSessions: The maximum number of sessions that can be handled by a single instance of this object. The default number is 1000.
MaxRegistrationTime: The maximum time for registration with a SIP Registrar. The default value is 3600 seconds.
SIPSignalTimeout: The maximum time allowed for SIP sessions. The default value is 14400 seconds.

The SIP Proxy Record-Route Option

To understand how to set up SIP scenarios with cOS Stream, it is important to first understand the SIP proxy Record-Route option. SIP proxies have the Record-Route option either enabled or disabled. When it is switched on, a proxy is known as a Stateful proxy. When Record-Route is enabled, a proxy is saying it will be the intermediary for all SIP signalling that takes place between two clients.

When a SIP session is being set up, the calling client sends an INVITE message to its outbound SIP proxy server. The SIP proxy relays this message to the remote proxy server responsible for the called, remote client's contact information. The remote proxy then relays the INVITE message to the called client. Once the two clients have learnt of each other's IP addresses, they can communicate directly with each other and remaining SIP messages can bypass the proxies. This facilitates scaling since proxies are used only for the initial SIP message exchange.

The disadvantage of removing proxies from the session is that IP rules must be set up to allow all SIP messages through the Clavister NetShield Firewall, and if the source network of the messages is not known then a large number of potentially dangerous connections must be allowed by the main IP rule set. This problem does not occur if the local proxy is set up with the Record-Route option enabled. In this mode, all SIP messages will only come from the proxy.

The different rules required when the Record-Route option is enabled and disabled can be seen in the two different sets of IP rules listed below in the detailed description of SIP setup.

IP Rules for Media Data

When discussing SIP data flows there are two distinct types of exchanges involved:

The SIP session which sets up communication between two clients prior to the exchange of media data.
The exchange of the media data itself, for example the coded voice data which constitute a VoIP phone call.

In the SIP setups described below, IP rules need only be explicitly defined to deal with the first of the above, the SIP exchanges needed for establishing client-to-client communications. No IP rules or other objects need to be defined to handle the second of the above, the exchange of media data. The SIP ALG automatically and invisibly takes care of creating the connections required (sometimes described as SIP pinholes) for allowing the media data traffic to flow through the Clavister NetShield Firewall.

	Tip
	Make sure there are no preceding rules already in the IP rule which disallow or allow the targeted traffic.

SIP Usage Scenarios

Currently, cOS Stream only provides support for a single SIP scenario and that is protecting local clients with SIP proxy located on the Internet

In this scenario, the SIP session is between a client on the local, protected side of the Clavister NetShield Firewall and a client which is on the external, unprotected side. The SIP proxy is located on the external, unprotected side of the Clavister NetShield Firewall. Communication typically takes place across the public Internet with clients on the internal, protected side registering with a proxy on the public, unprotected side. This scenario also deals with the situation where two clients in a session reside on the same network.

For example, assume that there is an office with VoIP users on a private internal network where the network's topology will be hidden using NAT. This is illustrated below.

Figure 10.1. SIP ALG Usage

The proxy should be configured with the Record-Route feature enabled to insure all SIP traffic to and from the office clients will be sent through the SIP Proxy. This is recommended since the attack surface is minimized by allowing only SIP signaling from the SIP Proxy to enter the local network.

This scenario can be implemented in two ways:

Using NAT to hide the network topology. Note that NAT pools could also be used for this and is discussed later in this section.
Without NAT so the network topology is exposed.

	Note: NAT traversal should not be configured
	SIP User Agents and SIP Proxies should not be configured to employ NAT Traversal in any setup. For instance the Simple Traversal of UDP through NATs (STUN) technique should not be used. The SIP ALG will take care of all NAT traversal issues in a SIP scenario.

The detailed setup steps for this scenario are as follows:

Define a SIPAlgProfile object. This step is not needed if the predefined sip object is used.
Define a Service object for SIP. The service should have the following configured:
- Destination Port set to 5060 (the default SIP signaling port).
- Type set to TCP/UDP.
- AppProto set to SIP.
Note that the predefined Service called sip-udp can be used instead of creating a new custom object.
Define two rules in the main IP rule set:
1. A NAT rule for outbound traffic from clients on the internal network to the SIP Proxy Server located externally. The SIP ALG will take care of all address translation needed by the NAT rule. This translation will occur both on the IP level and the application level. Neither the clients or the proxies need to be aware that the local users are being NATed.
2. An Allow rule for inbound SIP traffic from the SIP proxy to the IP of the Clavister NetShield Firewall. This rule will use core (in other words, cOS Stream itself) as the destination interface. The reason for this is due to the NAT rule above. When an incoming call is received, cOS Stream will automatically locate the local receiver, perform address translation and forward SIP messages to the receiver. This will be executed based on the ALGs internal state.
A SAT rule for translating incoming SIP messages is not needed since the ALG will automatically redirect incoming SIP requests to the correct internal user. When a SIP client behind a NATing Clavister NetShield Firewall registers with an external SIP proxy, cOS Stream sends its own IP address as contact information to the SIP proxy. cOS Stream registers the client's local contact information and uses this to redirect incoming requests to the user. The ALG takes care of the address translations needed.
Ensure the clients are correctly configured. The SIP Proxy Server plays a key role in locating the current location of the other client for the session. The proxy's IP address is not specified directly in the SIP profile. Instead, its location is either entered directly into the client software used by the client or in some cases the client will have a way of retrieving the proxy's IP address automatically such as through DHCP.

The IP rules with the Record-Route option enabled would be as shown below, the changes that apply when NAT is used are shown in parentheses "(..)".

Action	Src Interface	Src Network	Dest Interface	Dest Network
Allow (or NAT)	if1	if1_net	wan	ip_proxy
Allow	wan	ip_proxy	if1 (or core)	if1_net (or wan_ip)

Without the Record-Route option enabled the IP rules would be as shown below, the changes that apply when NAT is used are again shown in parentheses "(..)".

Action	Src Interface	Src Network	Dest Interface	Dest Network
Allow (or NAT)	if1	if1_net	wan	<All possible IPs>
Allow	wan	<All possible IPs>	if1 (or core)	if1_net (or wan_ip)

The advantage of using Record-Route is clear since now the destination network for outgoing traffic and the source network for incoming traffic have to include all IP addresses that are possible.

	The Service object for IP rules
	In this section, tables which list IP rules like those above, will omit the Service object associated with the rule. However, the same Service object could be used for all SIP scenarios and that could be the predefined object called sip.

Example 10.3. SIP with Local Clients, Proxy on Internet

The client is assumed to be on the network if1_net connected to the interface if1. The SIP proxy is assumed to have the IPv4 address proxy_ip. The interface if3 is connected to the Internet and has the public IPv4 address if3_ip.

This example will use the predefined ServiceTCPUDP object called sip-udp and the predefined SIPAlgProfile object called sip. Custom objects will not be created.

Command-Line Interface

A. Set up the IPv4 address objects if this has not been done already:

The protected if1 network which has the clients:

System:/> set Address IPAddress if1_net Address=192.168.1.0/24

The public IP address of the if3 interface:

System:/> set Address IPAddress if3_ip Address=203.0.113.1

The external SIP proxy IP:

System:/> add Address IPAddress proxy_ip Address=203.0.113.10

B. Define the outgoing SIP traffic IP rule using NAT:

System:/> cc RuleSet IPRuleSet main

Now, create the IP rule:

System:/IPRuleSet/main> add IPRule
			SourceInterface=if1
			SourceNetwork=if1_net
			DestinationInterface=if3
			DestinationNetwork=proxy_ip
			Service=sip-udp
			Action=Allow
			SourceTranslation=NAT
			SetSourceAddress=InterfaceAddress
			Name=sip_nat
			SIPALGProfile=sip

C. Define the incoming SIP traffic IP rule:

System:/IPRuleSet/main> add IPRule
			SourceInterface=if3
			SourceNetwork=proxy_ip
			DestinationInterface=core
			DestinationNetwork=if3_ip
			Service=sip-udp
			Action=Allow
			Name=sip_allow
			SIPALGProfile=sip

D. Return to the default CLI context:

System:/IPRuleSet/main> cc
System:/>

Using NAT Pools with the SIP ALG

As mentioned previously in this section, when using NAT with SIP to hide the network behind the firewall, a NATPool object could be used to allocate the public IP address on the external interface. These pools are described at length in Section 9.3, NAT Pools. A pool with its Type property set to Stateless cannot be used for this purpose.

The recommendation is to use a NATPool object with its Type property set to either Fixed or Deterministic.

The Type property can be set to Stateful but if this done then the rules listed below should be followed to avoid problems:

SIP clients must send periodic keep-alive messages to maintain the connection.
SIP clients must periodically re-register with the registrar.
In the NATPool object, the StateKeepAlive property must be set to a value which is at least twice the re-register period described in the previous requirement.

Below is an example of using a deterministic NATPool object with the SIP ALG. Note that a Route object needs to be created that routes the NAT pool's addresses on the core interface and which also proxy ARPs those addresses on the interface connected to the Internet.

Example 10.4. Setting Up SIP with NAT Pools

This example implements SIP with local clients and an external proxy on the Internet. The local network topology is hidden using NAT. The proxy server lies on the external, unprotected side of the Clavister NetShield Firewall. The example is based on Example 10.3, “SIP with Local Clients, Proxy on Internet” but uses a deterministic NATPool object to allocate the public IP addresses.

The protected clients are on the network connected to the interface if1 and the public Internet is connected to the interface if3.

Command-Line Interface

A. Create an address book object that specifies the public IP range for the pool:

System:/> add Address IPAddress nat_pool_range
			Address=203.0.113.2-203.0.113.5

B. Create a deterministic NATPool object:

System:/> add NATPool my_sip_natpool
			Type=Deterministic
			ExternalIPPool=nat_pool_range
			InternalNetwork=if1_net
			DynPoolRatio=10
			DynBlockAllocLimit=2

C. Set up the IPv4 address objects:

The protected network on the interface if1 which has the clients:

System:/> set Address IPAddress if1_net Address=192.168.1.0/24

The public IP address of the if3 interface:

System:/> set Address IPAddress if3_ip Address=203.0.113.1

The IP address of the external SIP proxy:

System:/> add Address IPAddress proxy_ip Address=203.0.113.10

D. Create the outgoing SIP traffic IP rule using the NAT pool:

Change the CLI context to be the main IP rule set:

System:/> cc RuleSet IPRuleSet main

Add the IP rule:

System:/IPRuleSet/main> add IPRule
			SourceInterface=if1
			SourceNetwork=if1_net
			DestinationInterface=if3
			DestinationNetwork=proxy_ip
			Service=sip-udp
			Action=Allow
			SourceTranslation=NAT
			SetSourceAddress=NATPool
			NATPool=my_sip_natpool
			Name=sip_nat
			SIPALGProfile=sip

E. Define the incoming SIP traffic IP rule:

System:/IPRuleSet/main> add IPRule
			SourceInterface=if3
			SourceNetwork=proxy_ip
			DestinationInterface=core
			DestinationNetwork=nat_pool_range
			Service=sip-udp
			Action=Allow
			Name=sip_allow
			SIPALGProfile=sip

F. Return to the default CLI context:

System:/IPRuleSet/main> cc
System:/>

G. Create a core route for the addresses in the NAT pool:

Change the context to be the main routing table:

System:/> cc RoutingTable main

Add the core route and specify proxy ARP:

System:/RoutingTable/main> add Route
			Interface=core
			Network=nat_pool_range
			ProxyArpInterfaces=if3

Return to the default CLI context:

System:/RoutingTable/main> cc

HA Synchronization with the SIP ALG

When the SIP ALG is being used in a high availability cluster, some aspects of SIP are synchronized and preserved after an HA failover occurs and some other aspects will be lost.

The fully synchronized parts of SIP are the following:

Most SIP signaling traffic flows, except those set up by cOS Stream itself. Such flows can be reviewed with the CLI command flow.
Registered SIP clients. Registered clients can be listed with the CLI command sipalg -registration.
Established SIP call sessions. Established calls can be listed with the CLI command sipalg -session and will have the state field set to CONFIRMED.
IP rules set up for RTP/RTCP flows. These can be listed using the CLI command ruledb -show sipalg.

The elements of SIP that will be lost after an HA failover are the following:

Flows for RTP/RTCP traffic. The CLI command flow would list these before a failover occurs. However, after a failover occurs these will be recreated by the media traffic using the dynamic rules since the rules are synchronized.
SIP sessions which have not yet reached the CONFIRMED state. The CLI command sipalg -session would list these before a failover and they would not have the Call State field set to CONFIRMED.

As a result of the above losses after a failover, a mismatch can occur between the cluster nodes for statistical values related to SIP. For example, the statistical values regarding total SIP sessions might not be the same on both cluster nodes after a failover. However, the statistics for active registrations and call sessions will always match.

For troubleshooting purposes, it is useful to note that the statistical value for the total number of SIP objects for an HA node:

		/system/ha/modules/sipalg/objects

Should normally equal the following sum of statistics for that node:

		/alg/sip/global/active_call_sessions
				plus
		/alg/sip/global/active_registrations