SIP ALG

SIP ALG Operation

There are two types of SIP traffic, the signaling and the media stream. SIP signaling traffic consists of request and response messages between client and server and uses transport protocols such as UDP or TCP. The media stream carries the data (audio data, for example) using transport protocols.

Starting in Junos OS Release 12.3X48-D25 and Junos OS Release 17.3R1, the SIP ALG supports TCP. TCP support over the SIP ALG reduces traffic to the server by eliminating the need to reregister or refresh the server frequently.

By default, Junos OS supports SIP signaling messages on port 5060. You can configure the port by creating a policy that permits SIP service, and the software filters SIP signaling traffic like any other type of traffic, permitting or denying it. The media stream, however, uses dynamically assigned port numbers that can change several times during the course of a call. Without fixed ports, it is insecure to create a static policy to control media traffic. In this case, the device invokes the SIP ALG. The device transport ports used for the media sessions are not known in advance; however, the ports used for the SIP negotiation are well-known (or predefined). The ALG registers interest in packets from the control session, which it can easily distinguish from the other packets, and inspects the negotiation for the transport information used for the media session (both IP addresses and ports).

The SIP ALG monitors SIP transactions and dynamically creates and manages pinholes based on the information it extracts from these transactions. The Juniper Networks SIP ALG supports all SIP methods and responses. You can allow SIP transactions to traverse the Juniper Networks firewall by creating a static policy that permits SIP service. If the policy is configured to inspect SIP traffic (or, more appropriately, if the policy sends some traffic to the SIP ALG for inspection), the allowed actions are to permit the traffic (in which case the appropriate pinholes are opened) or to deny the traffic.

The SIP ALG intercepts SIP messages that contain SDP and, using a parser, extracts the information it requires to create pinholes. The SIP ALG examines the SDP portion of the packet, and a parser extracts information such as IP addresses and port numbers, which the SIP ALG records in a pinhole table. The SIP ALG uses the IP addresses and port numbers recorded in the pinhole table to open pinholes and allow media streams to traverse the device.

NEC SIP products are conditionally supported.

SDP Session Descriptions

An SDP session description is a well-defined format for conveying sufficient information to discover and participate in a multimedia session. A session is described by a series of attribute/value pairs, one per line. The attribute names are single characters, followed by =, and a value. Optional values are specified with =*. Values are either an ASCII string, or a sequence of specific types separated by spaces. Attribute names are only unique within the associated syntactic construct, such as within the session, time, or media only.

Of the many fields in the SDP description, two are particularly useful to the SIP ALG because they contain Transport Layer information.

• c= for connection information

  This field can appear at the session or media level. It appears in this format:

  c=<network-type><address-type><connection-address>

  Junos OS supports only “IN” (for Internet) as the network type, “IPv4” as the address type, and a unicast IP address or domain name as the destination (connection) IP address. Starting in Junos OS Release 15.1X49-D40 and Junos OS Release 17.3R1, the “IPv6” address type is also supported.

  If the destination IP address is a unicast IP address, the SIP ALG creates pinholes using the IP address and port numbers specified in the media description field m=.

• m= for media announcement

  This field appears at the media level and contains the description of the media. It appears in this format:

  m=<media><port><transport><fmt list>

  Currently, Junos OS supports ”RTP” as the Application Layer transport protocol. The port number indicates the destination port of the media stream (the origin is allocated by the remote UA). The format list (fmt list) provides information on the Application Layer protocol that the media uses.

  The software opens ports only for RTP and Real-Time Control Protocol (RTCP). Every RTP session has a corresponding RTCP session. Therefore, whenever a media stream uses RTP, the SIP ALG must reserve ports (create pinholes) for both RTP and RTCP traffic. By default, the port number for RTCP is one higher than the RTP port number.

Pinhole Creation

Each pinhole (one for RTP traffic and the other for RTCP traffic) share the same destination IP address. The IP address comes from the c= field in the SDP session description. Because the c= field can appear in either the session-level or the media-level portion of the SDP session description, the parser determines the IP address based on the following rules (in accordance with SDP conventions):

• First, the SIP ALG parser looks for a c= field containing an IP address in the media level. If there is such a field, the parser extracts that IP address, and the SIP ALG uses that address to create a pinhole for the media.

• If there is no c= field in the media level, the SIP ALG parser extracts the IP address from the c= field in the session level, and the SIP ALG uses that IP address to create a pinhole for the media. If the session description does not contain a c= field in either level, this indicates an error in the protocol stack, and the device drops the packet and logs the event.

The SIP ALG also opens pinholes for signal traffic. These signal pinholes are useful after the previous signal session timeout, and they are also useful for the signal traffic sent to a third-party address that does not match with the previous signal session. The SIP ALG signal pinholes never age out, unlike RTP or RTCP pinholes, where only the destination IP and destination port are specified.

The SIP ALG opens signal pinholes for following headers, if needed:

• VIA

• CONTACT

• ROUTE

• RECORD-ROUTE

The SIP ALG needs the following information to create a pinhole. This information either comes from the SDP session description or from the SIP headers (as listed above).

• Protocol—UDP or TCP.

• Source IP—Unknown.

• Source port—Unknown.

• Destination IP—The parser extracts the destination IP address from the c= field at the media or session level.

• Destination port—The parser extracts the destination port number for RTP from the m= field in the media level and calculates the destination port number for RTCP using the following formula:

  RTP port number + one

• Lifetime—This value indicates the length of time (in seconds) during which a pinhole is open to allow a packet through. A packet must go through the pinhole before the lifetime expires. When the lifetime expires, the SIP ALG removes the pinhole.

  When a packet goes through the pinhole within the lifetime period, immediately afterwards the SIP ALG removes the pinhole for the direction from which the packet came.

  Figure 1 describes a call setup between two SIP clients and how the SIP ALG creates pinholes to allow RTP and RTCP traffic. The illustration assumes that the device has a policy that permits SIP, thus opening port 5060 for SIP signaling messages.

  Figure 1: SIP ALG Call Setup

• Understanding IPv6 Support for SIP ALG
• Understanding Scaling Busy Lamp Field Support for the UDP-Based SIP ALG
• Understanding SIP ALG Request Methods
• SIP ALG Configuration Overview
• Understanding SIP ALG DoS Attack Protection
• Understanding SIP ALG Unknown Message Types
• Understanding SIP ALG Call Duration and Timeouts

Retaining SIP ALG Hold Resources (CLI Procedure)

To accommodate proprietary SIP call flows:

Outgoing Calls

When a SIP call is initiated with a SIP request message from the internal to the external network, NAT replaces the IP addresses and port numbers in the SDP and binds the IP addresses and port numbers to the Juniper Networks firewall. Via, Contact, Route, and Record-Route SIP header fields, if present, are also bound to the firewall IP address. The ALG stores these mappings for use in retransmissions and for SIP response messages.

The SIP ALG then opens pinholes in the firewall to allow media through the device on the dynamically assigned ports negotiated based on information in the SDP and the Via, Contact, and Record-Route header fields. The pinholes also allow incoming packets to reach the Contact, Via, and Record-Route IP addresses and ports. When processing return traffic, the ALG inserts the original Contact, Via, Route, and Record-Route SIP fields back into packets.

Incoming Calls

Incoming calls are initiated from the public network to public static NAT addresses or to interface IP addresses on the device. Static NATs are statically configured IP addresses that point to internal hosts; interface IP addresses are dynamically recorded by the ALG as it monitors REGISTER messages sent by internal hosts to the SIP registrar. When the device receives an incoming SIP packet, it sets up a session and forwards the payload of the packet to the SIP ALG.

The ALG examines the SIP request message (initially an INVITE) and, based on information in the SDP, opens gates for outgoing media. When a 200 OK response message arrives, the SIP ALG performs NAT on the IP addresses and ports and opens pinholes in the outbound direction. (The opened gates have a short time-to-live, and they time out if a 200 OK response message is not received quickly.)

When a 200 OK response arrives, the SIP proxy examines the SDP information and reads the IP addresses and port numbers for each media session. The SIP ALG on the device performs NAT on the addresses and port numbers, opens pinholes for outbound traffic, and refreshes the timeout for gates in the inbound direction.

When the ACK arrives for the 200 OK, it also passes through the SIP ALG. If the message contains SDP information, the SIP ALG ensures that the IP addresses and port numbers are not changed from the previous INVITE—if they are, the ALG deletes old pinholes and creates new pinholes to allow media to pass through. The ALG also monitors the Via, Contact, and Record-Route SIP fields and opens new pinholes if it determines that these fields have changed.

Forwarded Calls

A forwarded call is when, for example, user A outside the network calls user B inside the network, and user B forwards the call to user C outside the network. The SIP ALG processes the INVITE from user A as a normal incoming call. But when the ALG examines the forwarded call from B to C outside the network and notices that B and C are reached using the same interface, it does not open pinholes in the firewall, because media will flow directly between user A and user C.

Call Termination

The BYE message terminates a call. When the device receives a BYE message, it translates the header fields just as it does for any other message. But because a BYE message must be acknowledged by the receiver with a 200 OK, the ALG delays call teardown for 5 seconds to allow time for transmission of the 200 OK.

Call Re-INVITE Messages

Re-INVITE messages add new media sessions to a call and remove existing media sessions. When new media sessions are added to a call, new pinholes are opened in the firewall and new address bindings are created. The process is identical to the original call setup. When all the media sessions or media pinholes are removed from a call, the call is removed when a BYE message is received.

Call Session Timers

As a precautionary measure, the SIP ALG uses hard timeout values to set the maximum amount of time a call can exist. This ensures that the device is protected should one of the following events occur:

• End systems crash during a call and a BYE message is not received.

• Malicious users never send a BYE in an attempt to attack a SIP ALG.

• Poor implementations of SIP proxy fail to process Record-Route and never send a BYE message.

• Network failures prevent a BYE message from being received.

Call Cancellation

Either party can cancel a call by sending a CANCEL message. Upon receiving a CANCEL message, the SIP ALG closes pinholes through the firewall—if any have been opened—and releases address bindings. Before releasing the resources, the ALG delays the control channel age-out for approximately 5 seconds to allow time for the final 200 OK to pass through. The call is terminated when the 5-second timeout expires, regardless of whether a 487 or non-200 response arrives.

Forking

Forking enables a SIP proxy to send a single INVITE message to multiple destinations simultaneously. When the multiple 200 OK response messages arrive for the single call, the SIP ALG parses but updates call information with the first 200 OK messages it receives.

SIP Messages

The SIP message format consists of a SIP header section and the SIP body. In request messages, the first line of the header section is the request line, which includes the method type, request-URI, and protocol version. In response messages, the first line is the status line, which contains a status code. SIP headers contain IP addresses and port numbers used for signaling. The SIP body, separated from the header section by a blank line, is reserved for session description information, which is optional. Junos OS currently supports the SDP only. The SIP body contains IP addresses and port numbers used to transport the media.

SIP Headers

In the following sample SIP request message, NAT replaces the IP addresses in the header fields to hide them from the outside network.

How IP address translation is performed depends on the type and direction of the message. A message can be any of the following:

• Inbound request

• Outbound response

• Outbound request

• Inbound response

Table 1 shows how NAT is performed in each of these cases. Note that for several of the header fields the ALG determine more than just whether the messages comes from inside or outside the network. It must also determine what client initiated the call, and whether the message is a request or response.

SIP Body

The SDP information in the SIP body includes IP addresses the ALG uses to create channels for the media stream. Translation of the SDP section also allocates resources, that is, port numbers to send and receive the media.

The following excerpt from a sample SDP section shows the fields that are translated for resource allocation.

SIP messages can contain more than one media stream. The concept is similar to attaching multiple files to an e-mail message. For example, an INVITE message sent from a SIP client to a SIP server might have the following fields:

Junos OS supports up to 6 SDP channels negotiated for each direction, for a total of 12 channels per call. For more information, see Understanding the SIP ALG.

SIP NAT Scenario

Figure 2 and Figure 3 show a SIP call INVITE and 200 OK. In Figure 2, ph1 sends a SIP INVITE message to ph2. Note how the IP addresses in the header fields—shown in bold font—are translated by the device.

The SDP section of the INVITE message indicates where the caller is willing to receive media. Note that the Media Pinhole contains two port numbers, 52002 and 52003, for RTCP and RTP. The Via/Contact Pinhole provides port number 5060 for SIP signaling.

Observe how, in the 200 OK response message in Figure 3, the translations performed in the INVITE message are reversed. The IP addresses in this message, being public, are not translated, but gates are opened to allow the media stream access to the private network.

Figure 2: SIP NAT Scenario 1

Figure 3: SIP NAT Scenario 2

Classes of SIP Responses

SIP responses provide status information about SIP transactions and include a response code and a reason phrase. SIP responses are grouped into the following classes:

• Informational (100 to 199)—Request received, continuing to process the request.

• Success (200 to 299)—Action successfully received, understood, and accepted.

• Redirection (300 to 399)—Further action required to complete the request.

• Client Error (400 to 499)—Request contains bad syntax or cannot be fulfilled at this server.

• Server Error (500 to 599)—Server failed to fulfill an apparently valid request.

• Global Failure (600 to 699)—Request cannot be fulfilled at any server.

Table 2 provides a complete list of current SIP responses.

NAT Mode in Pure IPv6 Mode (NAT66) for SIP IPv6 ALG

The SIP IPv6 ALG supports NAT66 just like NAT44. NAT66 (IPv6 NAT) provides source NAT and static NAT functions similar to NAT44 (IPv4 NAT).

NAT-PT

Network Address Translation Protocol Translation (NAT-PT) (RFC 2766) is a protocol translation mechanism that allows communication between IPv6-only and IPv4-only nodes through protocol-independent translation of IPv4 and IPv6 datagrams, requiring no state information for the session.

NAT-PT is implemented by normal NAT from IPv6 address to IPv4 address and vice versa. The SIP ALG processes those address translations in the payload just as the addresses are processed in normal NAT.

NAT-PT binds the addresses in the IPv6 network with addresses in the IPv4 network and vice versa to provide transparent routing for the datagrams traversing between address realms.

The main advantage of NAT-PT is that the end devices and networks can run either IPv4 addresses or IPv6 addresses and traffic can be started from any side.

NAT64

NAT64 is a mechanism to allow IPv6 hosts to communicate with IPv4 servers. NAT64 is required to keep the IPv6 to IPv4 address mapping. Such address mapping is either statically configured by the system administrator (stateless translation), or more frequently, created automatically when the first packet from the IPv6 network reaches NAT64 to be translated (stateful).

NAT64 is implemented on devices by using persistent NAT. When the first SIP request message (first packet should be only from IPv6) transverses the DUT, address binding is created and then the packets can flow in both directions.

The NAT64 mechanism translates IPv6 packets to IPv4 packets and vice versa, which allows IPv6 clients to contact to the IPv4 servers using unicast UDP, TCP, or ICMP. The NAT-PT and NAT64 behavior seems similar, but these mechanisms are implemented differently.

When NAT64 with persistent NAT is implemented, the SIP ALG with IPv6 support adds the NAT translation to the persistent NAT binding table if NAT is configured on the address of record. Because persistent NAT cannot duplicate the address configured, coexistence of NAT66 and NAT64 configured on the same address is not supported.

Only one binding is created for the same source IP address.

STUN and SIP ALG

Session Traversal Utilities for NAT (STUN) is a solution to make VoIP work through NAT and firewall.

Previously STUN worked without the SIP ALG. This means that the SIP ALG was not involved when persistent NAT was configured.

STUN can coexist with the SIP ALG and SIP ALG is involved when persistent NAT is configured.

Understanding Incoming SIP ALG Call Support Using the SIP Registrar and NAT

Session Initiation Protocol (SIP) registration provides a discovery capability by which SIP proxies and location servers can identify the location or locations where users want to be contacted. A user registers one or more contact locations by sending a REGISTER message to the registrar. The To and Contact fields in the REGISTER message contain the address-of-record Uniform Resource Identifier (URI) and one or more contact URIs, as shown in Figure 4. Registration creates bindings in a location service that associates the address-of-record with the contact address or addresses.

The device monitors outgoing REGISTER messages, performs Network Address Translation (NAT) on these addresses, and stores the information in an Incoming NAT table. Then, when an INVITE message is received from outside the network, the device uses the Incoming NAT table to identify which internal host to route the INVITE message to. You can take advantage of SIP proxy registration service to allow incoming calls by configuring interface source NAT or NAT pools on the egress interface of the device. Interface source NAT is adequate for handling incoming calls in a small office, whereas we recommend setting up source NAT pools for larger networks or an enterprise environment.

Note:

Incoming call support using interface source NAT or a source NAT pool is supported for SIP and H.323 services only. For incoming calls, Junos OS currently supports UDP and TCP only. Domain name resolution is also currently not supported; therefore, URIs must contain IP addresses, as shown in Figure 4.

Figure 4: Using the SIP Registrar