ON THIS PAGE
Next Gen Services Application Layer Gateways
This topic describes the Application Layer Gateways (ALGs) supported by Junos OS for Next Gen Services. ALG support includes managing pinholes and parent-child relationships for the supported ALGs.
RTSP
The Real-Time Streaming Protocol (RTSP) controls the delivery of data with real-time properties such as audio and video. The streams controlled by RTSP can use RTP, but it is not required. Media can be transmitted on the same RTSP control stream. This is an HTTP-like text-based protocol, but client and server maintain session information. A session is established using the SETUP message and terminated using the TEARDOWN message. The transport (the media protocol, address, and port numbers) is negotiated in the setup and the setup-response.
Support for stateful firewall and NAT services requires that you configure the RTSP ALG for TCP port 554.
The ALG monitors the control connection, opens flows dynamically for media (RTP/RTSP) streams, and performs NAT address and port rewrites.
SIP
The Session Initiation Protocol (SIP) is an application layer protocol that can establish, maintain, and terminate media sessions. It is a widely used voice over IP (VoIP) signaling protocol. The SIP ALG monitors SIP traffic and dynamically creates and manages pinholes on the signaling and media paths. The ALG only allows packets with the correct permissions. The SIP ALG also performs the following functions:
Manages parent-child session relationships.
Enforces security policies.
Manages pinholes for VoIP traffic.
The SIP ALG supports the following features:
Stateful firewall
Static source NAT
Dynamic address only source NAT
Network Address Port Translation (NAPT)
SIP sessions are limited to 12 hours (720 minutes) for NAT processing on the MS-MIC and MS-MPC interface cards. SIP sessions on the MS-DPC have no time limit.
Configuring SIP
The Session Initiation Protocol (SIP) is a generalized protocol for communication between endpoints involved in Internet services such as telephony, fax, video conferencing, instant messaging, and file exchange.
The Junos OS provides ALG services in accordance with the standard described in RFC 3261, SIP: Session Initiation Protocol. SIP flows under the Junos OS are as described in RFC 3665, Session Initiation Protocol (SIP) Basic Call Flow Examples.
Before implementing the Junos OS SIP ALG, you should be familiar with certain limitations, discussed in Junos OS SIP ALG Limitations
The use of NAT in conjunction with the SIP ALG results in changes in SIP header fields due to address translation. For an explanation of these translations, refer to SIP ALG Interaction with Network Address Translation.
To implement SIP on adaptive services interfaces, you configure
the application-protocol
statement at the [edit applications
application application-name]
hierarchy
level with the value sip
. In addition, there are two other statements you can configure
to modify how SIP is implemented:
You can enable the router to accept any incoming SIP calls for the endpoint devices that are behind the NAT firewall. When a device behind the firewall registers with the proxy that is outside the firewall, the AS or Multiservices PIC maintains the registration state. When the
learn-sip-register
statement is enabled, the router can use this information to accept inbound calls. If this statement is not configured, no inbound calls are accepted; only the devices behind the firewall can call devices outside the firewall.To configure SIP registration, include the
learn-sip-register
statement at the[edit applications application application-name]
hierarchy level:[edit applications application application-name] learn-sip-register;
Note:The
learn-sip-register
statement is not applicable to the Next Gen Services MX-SPC3.You can also manually inspect the SIP register by issuing the
show services stateful-firewall sip-register
command; for more information, see the Junos OS System Basics and Services Command Reference. Theshow services stateful-firewall sip-register
command is not supported for Next Gen Services.You can specify a timeout period for the duration of SIP calls that are placed on hold. When a call is put on hold, there is no activity and flows might time out after the configured
inactivity-timeout
period expires, resulting in call state teardown. To avoid this, when a call is put on hold, the flow timer is reset to thesip-call-hold-timeout
cycle to preserve the call state and flows for longer than theinactivity-timeout
period.Note:The
sip-call-hold-timeout
statement is not applicable to the Next Gen Services MX-SPC3.To configure a timeout period, include the
sip-call-hold-timeout
statement at the[edit applications application application-name]
hierarchy level:[edit applications application application-name] sip-call-hold-timeout seconds;
The default value is 7200 seconds and the range is from 0 through 36,000 seconds (10 hours).
SIP ALG Interaction with Network Address Translation
The Network Address Translation (NAT) protocol enables multiple hosts in a private subnet to share a single public IP address to access the Internet. For outgoing traffic, NAT replaces the private IP address of the host in the private subnet with the public IP address. For incoming traffic, the public IP address is converted back into the private address, and the message is routed to the appropriate host in the private subnet.
Using NAT with the Session Initiation Protocol (SIP) service is more complicated because SIP messages contain IP addresses in the SIP headers as well as in the SIP body. When using NAT with the SIP service, the SIP headers contain information about the caller and the receiver, and the device translates this information to hide it from the outside network. The SIP body contains the Session Description Protocol (SDP) information, which includes IP addresses and port numbers for transmission of the media. The device translates SDP information for allocating resources to send and receive the media.
How IP addresses and port numbers in SIP messages are replaced depends on the direction of the message. For an outgoing message, the private IP address and port number of the client are replaced with the public IP address and port number of the Juniper Networks firewall. For an incoming message, the public address of the firewall is replaced with the private address of the client.
When an INVITE message is sent out across the firewall, the SIP Application Layer Gateway (ALG) collects information from the message header into a call table, which it uses to forward subsequent messages to the correct endpoint. When a new message arrives, for example an ACK or 200 OK, the ALG compares the “From:, To:, and Call-ID:” fields against the call table to identify the call context of the message. If a new INVITE message arrives that matches the existing call, the ALG processes it as a REINVITE.
When a message containing SDP information arrives, the ALG allocates ports and creates a NAT mapping between them and the ports in the SDP. Because the SDP requires sequential ports for the Real-Time Transport Protocol (RTP) and Real-Time Control Protocol (RTCP) channels, the ALG provides consecutive even-odd ports. If it is unable to find a pair of ports, it discards the SIP message.
This topic contains the following sections:
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 five 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 one or more media sessions are removed from a call, pinholes are closed and bindings released just as with a BYE message.
Call Session Timers
The SIP ALG uses the Session-Expires value to time out a session if a Re-INVITE or UPDATE message is not received. The ALG gets the Session-Expires value, if present, from the 200 OK response to the INVITE and uses this value for signaling timeout. If the ALG receives another INVITE before the session times out, it resets all timeout values to this new INVITE or to default values, and the process is repeated.
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 five seconds to allow time for the final 200 OK to pass through. The call is terminated when the five 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.
INVITE bob@10.150.20.5
SIP/2.0 Via: SIP/2.0/UDP10.150.20.3
:5434 From: alice@10.150.20.3
To: bob@10.150.20.5
Call-ID: a12abcde@10.150.20.3
Contact: alice@10.150.20.3
:5434 Route: <sip:netscreen@10.150.20.3
:5060> Record-Route: <sip:netscreen@10.150.20.3
:5060>
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.
Inbound Request (from public to private) |
To: |
Replace domain with local address |
From: |
None |
|
Call-ID: |
None |
|
Via: |
None |
|
Request-URI: |
Replace ALG address with local address |
|
Contact: |
None |
|
Record-Route: |
None |
|
Route: |
None |
|
Outbound Response (from private to public) |
To: |
Replace ALG address with local address |
From: |
None |
|
Call-ID: |
None |
|
Via: |
None |
|
Request-URI: |
N/A |
|
Contact: |
Replace local address with ALG address |
|
Record-Route: |
Replace local address with ALG address |
|
Route: |
None |
|
Outbound Request (from private to public) |
To: |
None |
From: |
Replace local address with ALG address |
|
Call-ID: |
None |
|
Via: |
Replace local address with ALG address |
|
Request-URI: |
None |
|
Contact: |
Replace local address with ALG address |
|
Record-Route: |
Replace local address with ALG address |
|
Route: |
Replace ALG address with local address |
|
Outbound Response (from public to private) |
To: |
None |
From: |
Replace ALG address with local address |
|
Call-ID: |
None |
|
Via: |
Replace ALG address with local address |
|
Request-URI: |
N/A |
|
Contact: |
None |
|
Record-Route: |
Replace ALG address with local address |
|
Route: |
Replace ALG address with local address |
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.
o=user 2344234 55234434 IN IP410.150.20.3
c=IN IP410.150.20.3
m=audio43249
RTP/AVP 0
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:
c=IN IP410.123.33.4
m=audio33445
RTP/AVP 0 c=IN IP410.123.33.4
m=audio33447
RTP/AVP 0 c=IN IP410.123.33.4
m=audio33449
RTP/AVP 0
Junos OS supports up to 6 SDP channels negotiated for each direction, for a total of 12 channels per call.
Junos OS SIP ALG Limitations
The following limitations apply to configuration of the SIP ALG:
Only the methods described in RFC 3261 are supported.
Only SIP version 2 is supported.
TCP is not supported as a transport mechanism for signaling messages for MS-MPCs but is supported for Next Gen Services.
Do not configure the SIP ALG when using STUN. if clients use STUN/TURN to detect the firewall or NAT devices between the caller and responder or proxy, the client attempts to best-guess the NAT device behavior and act accordingly to place the call.
On MS-MPCs, do not use the endpoint-independent mapping NAT pool option in conjunction with the SIP ALG. Errors will result. This does not apply to Next Gen Services.
IPv6 signaling data is not supported for MS-MPCs but is supported for Next Gen Services.
Authentication is not supported.
Encrypted messages are not supported.
SIP fragmentation is not supported for MS-MPCs but is supported for Next Gen Services.
The maximum UDP packet size containing a SIP message is assumed to be 9 KB. SIP messages larger than this are not supported.
The maximum number of media channels in a SIP message is assumed to be six.
Fully qualified domain names (FQDNs) are not supported in critical fields.
QoS is not supported. SIP supports DSCP rewrites.
High availability is not supported, except for warm standby.
A timeout setting of never is not supported on SIP or NAT.
Multicast (forking proxy) is not supported.