SIP inspection NATs the SIP text-based messages, recalculates the content length for the SDP portion of the message, and recalculates the packet length and checksum. It dynamically opens media connections for ports specified in the SDP portion of the SIP message as address/ports on which the endpoint should listen.
SIP inspection has a database with indices CALL_ID/FROM/TO from the SIP payload that identifies the call, as well as the source and destination. Contained within this database are the media addresses and media ports that were contained in the SDP media information fields and the media type. There can be multiple media addresses and ports for a session. RTP/RTCP connections are opened between the two endpoints using these media addresses/ports.
The well-known port 5060 must be used on the initial call setup (INVITE) message. However, subsequent messages might not have this port number. The SIP inspection engine opens signaling connection pinholes, and marks these connections as SIP connections. This is done for the messages to reach the SIP application and be NATed.
As a call is set up, the SIP session is considered in the transient state. This state remains until a Response message is received which indicates the RTP media address and port on which the destination endpoint listens. If there is a failure to receive the response messages within one minute, the signaling connection is torn down.
Once the final handshake is made, the call state is moved to active and the signaling connection remains until a BYE message is received.
If an inside endpoint initiates a call to an outside endpoint, a media hole is opened to the outside interface to allow RTP/RTCP UDP packets to flow to the inside endpoint media address and media port specified in the INVITE message from the inside endpoint. Unsolicited RTP/RTCP UDP packets to an inside interface will not traverse the security appliance, unless the security appliance configuration specifically allows it.
The media connections are torn down within two minutes after the connection becomes idle. This is a configurable timeout and can be set for a shorter or longer period of time.
In order to use MGCP, you usually need to configure at least two inspect commands: one for the port on which the gateway receives commands, and one for the port on which the call agent receives commands. Normally, a call agent sends commands to the default MGCP port for gateways, 2427, and a gateway sends commands to the default MGCP port for call agents, 2727.
MGCP messages are transmitted over UDP. A response is sent back to the source address (IP address and UDP port number) of the command, but the response might not arrive from the same address as the command was sent to. This can occur when multiple call agents are used in a failover configuration and the call agent that received the command has passed control to a backup call agent, which then sends the response.
The H.323 collection of protocols collectively can use up to two TCP connection and four to six UDP connections. FastConnect uses only one TCP connection, and Reliability, Availability, and Serviceability (RAS) uses a single UDP connection for registration, admissions, and status.
An H.323 client can initially establish a TCP connection to an H.323 server using TCP port 1720 to request Q.931 call setup. As part of the call setup process, the H.323 terminal supplies a port number to the client to use for an H.245 TCP connection. In environments where H.323 gatekeeper is in use, the initial packet is transmitted using UDP.
H.323 inspection monitors the Q.931 TCP connection to determine the H.245 port number. If the H.323 terminals do not use FastConnect, the security appliance dynamically allocates the H.245 connection based on the inspection of the H.225 messages.
Within each H.245 message, the H.323 endpoints exchange port numbers that are used for subsequent UDP data streams. H.323 inspection inspects the H.245 messages to identify these ports and dynamically creates connections for the media exchange. RTP uses the negotiated port number, while RTCP uses the next higher port number.
The H.323 control channel handles H.225 and H.245 and H.323 RAS. H.323 inspection uses these ports:
- 1718â€”Gate Keeper Discovery UDP port
- 1719â€”RAS UDP port
- 1720â€”TCP Control Port
You must permit traffic for the well-known H.323 port 1720 for the H.225 call signaling. However, the H.245 signaling ports are negotiated between the endpoints in the H.225 signaling. When an H.323 gatekeeper is used, the security appliance opens an H.225 connection based on inspection of the Admission Confirmation (ACF) message.
After the H.225 messages are inspected, the security appliance opens the H.245 channel and then inspects traffic sent over the H.245 channel. All H.245 messages that pass through the security appliance undergo H.245 application inspection, which translates embedded IP addresses and opens the media channels negotiated in H.245 messages.
The H.323 ITU standard requires that a Transport Protocol Data Unit Packet (TPKT) header, which defines the length of the message, precede the H.225 and H.245, before being passed on to the reliable connection. Because the TPKT header does not necessarily need to be sent in the same TCP packet as H.225 and H.245 messages, the security appliance must remember the TPKT length to process and decode the messages properly. For each connection, the security appliance keeps a record that contains the TPKT length for the next expected message.
If the security appliance needs to perform NAT on IP addresses in messages, it changes the checksum, the UUIE length, and the TPKT, if it is included in the TCP packet with the H.225 message. If the TPKT is sent in a separate TCP packet, the security appliance proxy acknowledgments (ACKs) that TPKT and appends a new TPKT to the H.245 message with the new length.
In topologies where Cisco CallManager is located on the higher security interface with respect to the Cisco IP Phones, if NAT is required for the Cisco CallManager IP address, the mapping must be static as a Cisco IP Phone requires the Cisco CallManager IP address to be specified explicitly in its configuration. An identity static entry allows the Cisco CallManager on the higher security interface to accept registrations from the Cisco IP Phones.
Cisco IP Phones require access to a TFTP server in order to download the configuration information they need to connect to the Cisco CallManager server.
When the Cisco IP Phones are on a lower security interface compared to the TFTP server, you must use an access list in order to connect to the protected TFTP server on UDP port 69. While you do need a static entry for the TFTP server, this does not have to be an identity static entry. When NAT is used, an identity static entry maps to the same IP address. When PAT is used, it maps to the same IP address and port.
When the Cisco IP Phones are on a higher security interface compared to the TFTP server and Cisco CallManager, no access list or static entry is required to allow the Cisco IP Phones to initiate the connection.