The following topics explain application inspection for voice and video protocols. For basic information on why you need to use inspection for certain protocols, and the overall methods for applying inspection, see Getting Started with Application Layer Protocol Inspection.
CTIQBE protocol inspection supports NAT, PAT, and bidirectional NAT. This enables Cisco IP SoftPhone and other Cisco TAPI/JTAPI applications to work successfully with Cisco CallManager for call setup across the ASA.
TAPI and JTAPI are used by many Cisco VoIP applications. CTIQBE is used by Cisco TSP to communicate with Cisco CallManager.
For information on enabling CTIQBE inspection, see Configure Application Layer Protocol Inspection.
The following summarizes limitations that apply when using CTIQBE application inspection:
The following summarizes special considerations when using CTIQBE application inspection in specific scenarios:
The show ctiqbe command displays information regarding the CTIQBE sessions established across the ASA. It shows information about the media connections allocated by the CTIQBE inspection engine.
The following is sample output from the show ctiqbe command under the following conditions. There is only one active CTIQBE session setup across the ASA. It is established between an internal CTI device (for example, a Cisco IP SoftPhone) at local address 10.0.0.99 and an external Cisco CallManager at 172.29.1.77, where TCP port 2748 is the Cisco CallManager. The heartbeat interval for the session is 120 seconds.
The CTI device has already registered with the CallManager. The device internal address and RTP listening port is PATed to 172.29.1.99 UDP port 1028. Its RTCP listening port is PATed to UDP 1029.
The line beginning with RTP/RTCP: PAT xlates:
appears only if an internal CTI device has registered with an external CallManager and the CTI device address and ports are PATed to that external interface. This line does not appear if the CallManager is located on an internal interface, or if the internal CTI device address and ports are translated to the same external interface that is used by the CallManager.
The output indicates a call has been established between this CTI device and another phone at 172.29.1.88. The RTP and RTCP listening ports of the other phone are UDP 26822 and 26823. The other phone locates on the same interface as the CallManager because the ASA does not maintain a CTIQBE session record associated with the second phone and CallManager. The active call leg on the CTI device side can be identified with Device ID 27 and Call ID 0.
The following is sample output from the show xlate debug command for these CTIBQE connections:
The show conn state ctiqbe command displays the status of CTIQBE connections. In the output, the media connections allocated by the CTIQBE inspection engine are denoted by a ‘C’ flag. The following is sample output from the show conn state ctiqbe command:
The following sections describe the H.323 application inspection.
H.323 inspection provides support for H.323 compliant applications such as Cisco CallManager and VocalTec Gatekeeper. H.323 is a suite of protocols defined by the International Telecommunication Union for multimedia conferences over LANs. The ASA supports H.323 through Version 6, including H.323 v3 feature Multiple Calls on One Call Signaling Channel.
With H.323 inspection enabled, the ASA supports multiple calls on the same call signaling channel, a feature introduced with H.323 Version 3. This feature reduces call setup time and reduces the use of ports on the ASA.
The two major functions of H.323 inspection are as follows:
The H.323 collection of protocols collectively may use up to two TCP connection and four to eight UDP connections. FastConnect uses only one TCP connection, and 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 are not using FastConnect, the ASA dynamically allocates the H.245 connection based on the inspection of the H.225 messages.
Note The H.225 connection can also be dynamically allocated when using RAS.
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 the following ports.
You must permit traffic for the well-known H.323 port 1719 for RAS signaling. Additionally, 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 ASA opens an H.225 connection based on inspection of the ACF and RCF messages.
After inspecting the H.225 messages, the ASA opens the H.245 channel and then inspects traffic sent over the H.245 channel as well. All H.245 messages passing through the ASA 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 TPKT header, defining 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 ASA must remember the TPKT length to process and decode the messages properly. For each connection, the ASA keeps a record that contains the TPKT length for the next expected message.
If the ASA 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 ASA proxy ACKs that TPKT and appends a new TPKT to the H.245 message with the new length.
Note The ASA does not support TCP options in the Proxy ACK for the TPKT.
Each UDP connection with a packet going through H.323 inspection is marked as an H.323 connection and times out with the H.323 timeout as configured with the timeout command.
Note You can enable call setup between H.323 endpoints when the Gatekeeper is inside the network. The ASA includes options to open pinholes for calls based on the RegistrationRequest/RegistrationConfirm (RRQ/RCF) messages. Because these RRQ/RCF messages are sent to and from the Gatekeeper, the calling endpoint's IP address is unknown and the ASA opens a pinhole through source IP address/port 0/0. By default, this option is disabled. To enable call setup between H.323 endpoint, enter the ras-rcf-pinholes enable command during parameter configuration mode while creating an H.323 Inspection policy map. See Configure H.323 Inspection Policy Map.
The ASA sits between two H.323 endpoints. When the two H.323 endpoints set up a telepresentation session so that the endpoints can send and receive a data presentation, such as spreadsheet data, the ASA ensure successful H.239 negotiation between the endpoints.
H.239 is a standard that provides the ability for H.300 series endpoints to open an additional video channel in a single call. In a call, an endpoint (such as a video phone), sends a channel for video and a channel for data presentation. The H.239 negotiation occurs on the H.245 channel.
The ASA opens pinholes for the additional media channel and the media control channel. The endpoints use open logical channel message (OLC) to signal a new channel creation. The message extension is part of H.245 version 13.
The decoding and encoding of the telepresentation session is enabled by default. H.239 encoding and decoding is preformed by ASN.1 coder.
H.323 inspection is tested and supported for Cisco Unified Communications Manager (CUCM) 7.0. It is not supported for CUCM 8.0 and higher. H.323 inspection might work with other releases and products.
The following are some of the known issues and limitations when using H.323 application inspection:
H.323 inspection supports RAS, H.225, and H.245, and its functionality translates all embedded IP addresses and ports. It performs state tracking and filtering and can do a cascade of inspect function activation. H.323 inspection supports phone number filtering, dynamic T.120 control, H.245 tunneling control, HSI groups, protocol state tracking, H.323 call duration enforcement, and audio/video control.
H.323 inspection is enabled by default. You need to configure it only if you want non-default processing. If you want to customize H.323 inspection, use the following process.
Step 1 Configure H.323 Inspection Policy Map
Step 2 Configure the H.323 Inspection Service Policy
You can create an H.323 inspection policy map to customize H.323 inspection actions if the default inspection behavior is not sufficient for your network.
When defining traffic matching criteria, you can either create a class map or include the match statements directly in the policy map. The following procedure explains both approaches.
Some traffic matching options use regular expressions for matching purposes. If you intend to use one of those techniques, first create the regular expression or regular expression class map.
Step 1 (Optional) Create an H.323 inspection class map by performing the following steps.
A class map groups multiple traffic matches.You can alternatively identify match commands directly in the policy map. The difference between creating a class map and defining the traffic match directly in the inspection policy map is that the class map lets you create more complex match criteria, and you can reuse class maps.
To specify traffic that should not match the class map, use the match not command. For example, if the match not command specifies the string “example.com,” then any traffic that includes “example.com” does not match the class map.
For the traffic that you identify in this class map, you specify actions to take on the traffic in the inspection policy map.
If you want to perform different actions for each match command, you should identify the traffic directly in the policy map.
a. Create the class map by entering the following command:
Where class_map_name is the name of the class map. The match-all keyword is the default, and specifies that traffic must match all criteria to match the class map. The match-any keyword specifies that the traffic matches the class map if it matches at least one of the criteria. The CLI enters class-map configuration mode, where you can enter one or more match commands.
b. (Optional) To add a description to the class map, enter the following command:
Where string is the description of the class map (up to 200 characters).
c. Specify the traffic on which you want to perform actions using one of the following match commands. If you use a match not command, then any traffic that does not match the criterion in the match not command has the action applied.
Step 2 Create an H.323 inspection policy map:
Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.
Step 3 (Optional) To add a description to the policy map, enter the following command:
Step 4 To apply actions to matching traffic, perform the following steps.
You can specify multiple class or match commands in the policy map. For information about the order of class and match commands, see Defining Actions in an Inspection Policy Map.
a. Specify the traffic on which you want to perform actions using one of the following methods:
b. Specify the action you want to perform on the matching traffic by entering the following command:
The drop keyword drops the packet. For media type matches, you can include the log keyword to send a system log message.
The drop-connection keyword drops the packet and closes the connection. This option is available for called or calling party matching.
The reset keyword drops the packet, closes the connection, and sends a TCP reset to the server and/or client. This option is available for called or calling party matching.
Step 5 To configure parameters that affect the inspection engine, perform the following steps:
a. To enter parameters configuration mode, enter the following command:
b. Set one or more parameters. You can set the following options; use the no form of the command to disable the option:
Step 6 While still in parameter configuration mode, you can configure HSI groups.
a. Define an HSI group and enter HSI group configuration mode.
Where id is the HSI group ID. Range is from 0 to 2147483647.
b. Add an HSI to the HSI group using the IP address. You can add a maximum of five hosts per HSI group.
c. Add an endpoint to the HSI group.
Where ip_address is the endpoint to add and if_name is the interface through which the endpoint is connected to the ASA. You can add a maximum of ten endpoints per HSI group.
The following example shows how to configure phone number filtering:
The default ASA configuration includes H.323 H.255 and RAS inspection on the default ports applied globally on all interfaces. A common method for customizing the inspection configuration is to customize the default global policy. You can alternatively create a new service policy as desired, for example, an interface-specific policy.
Step 1 If necessary, create an L3/L4 class map to identify the traffic for which you want to apply the inspection.
hostname(config-cmap)# match access-list h323
In the default global policy, the inspection_default class map is a special class map that includes default ports for all inspection types (match default-inspection-traffic). If you are using this class map in either the default policy or for a new service policy, you can skip this step.
For information on matching statements, see Identify Traffic (Layer 3/4 Class Maps).
Step 2 Add or edit a policy map that sets the actions to take with the class map traffic.
In the default configuration, the global_policy policy map is assigned globally to all interfaces. If you want to edit the global_policy, enter global_policy as the policy name.
Step 3 Identify the L3/L4 class map you are using for H.323 inspection.
To edit the default policy, or to use the special inspection_default class map in a new policy, specify inspection_default for the name. Otherwise, you are specifying the class you created earlier in this procedure.
Step 4 Configure H.323 inspection.
Where h323_policy_map is the optional H.323 inspection policy map. You need a map only if you want non-default inspection processing. For information on creating the H.323 inspection policy map, see Configure H.323 Inspection Policy Map.
Note If you are editing the default global policy (or any in-use policy) to use a different H.323 inspection policy map, you must remove the H.323 inspection with the no inspect h323 command, and then re-add it with the new H.323 inspection policy map name.
Step 5 If you are editing an existing service policy (such as the default global policy called global_policy), you are done. Otherwise, activate the policy map on one or more interfaces.
The global keyword applies the policy map to all interfaces, and interface applies the policy to one interface. Only one global policy is allowed. You can override the global policy on an interface by applying a service policy to that interface. You can only apply one policy map to each interface.
You can configure H.323/H.255 global timeout values on the Configuration > Firewall > Advanced > Global Timeouts page. You can set the interval for inactivity after which an H.255 signaling connection is closed (default is 1 hour) or an H.323 control connection is closed (default is 5 minutes).
To configure the idle time after which an H.225 signaling connection is closed, use the timeout h225 command. The default for H.225 timeout is one hour.
To configure the idle time after which an H.323 control connection is closed, use the timeout h323 command. The default is five minutes.
The following sections describe how to display information about H.323 sessions.
The show h225 command displays information for H.225 sessions established across the ASA. Along with the debug h323 h225 event, debug h323 h245 event, and show local-host commands, this command is used for troubleshooting H.323 inspection engine issues.
If there is an abnormally large number of connections, check that the sessions are timing out based on the default timeout values or the values set by you. If they are not, then there is a problem that needs to be investigated.
The following is sample output from the show h225 command:
This output indicates that there is currently 1 active H.323 call going through the ASA between the local endpoint 10.130.56.3 and foreign host 172.30.254.203, and for these particular endpoints, there is 1 concurrent call between them, with a CRV for that call of 9861.
For the local endpoint 10.130.56.4 and foreign host 172.30.254.205, there are 0 concurrent calls. This means that there is no active call between the endpoints even though the H.225 session still exists. This could happen if, at the time of the show h225 command, the call has already ended but the H.225 session has not yet been deleted. Alternately, it could mean that the two endpoints still have a TCP connection opened between them because they set “maintainConnection” to TRUE, so the session is kept open until they set it to FALSE again, or until the session times out based on the H.225 timeout value in your configuration.
The show h245 command displays information for H.245 sessions established across the ASA by endpoints using slow start. Slow start is when the two endpoints of a call open another TCP control channel for H.245. Fast start is where the H.245 messages are exchanged as part of the H.225 messages on the H.225 control channel.)
The following is sample output from the show h245 command:
There is currently one H.245 control session active across the ASA. The local endpoint is 10.130.56.3, and we are expecting the next packet from this endpoint to have a TPKT header because the TPKT value is 0. The TKTP header is a 4-byte header preceding each H.225/H.245 message. It gives the length of the message, including the 4-byte header. The foreign host endpoint is 172.30.254.203, and we are expecting the next packet from this endpoint to have a TPKT header because the TPKT value is 0.
The media negotiated between these endpoints have an LCN of 258 with the foreign RTP IP address/port pair of 172.30.254.203/49608 and an RTCP IP address/port of 172.30.254.203/49609 with a local RTP IP address/port pair of 10.130.56.3/49608 and an RTCP port of 49609.
The second LCN of 259 has a foreign RTP IP address/port pair of 172.30.254.203/49606 and an RTCP IP address/port pair of 172.30.254.203/49607 with a local RTP IP address/port pair of 10.130.56.3/49606 and RTCP port of 49607.
The show h323 ras command displays connection information for H.323 RAS sessions established across the ASA between a gatekeeper and its H.323 endpoint. Along with the debug h323 ras event and show local-host commands, this command is used for troubleshooting H.323 RAS inspection engine issues.
The following is sample output from the show h323 ras command:
This output shows that there is one active registration between the gatekeeper 172.30.254.214 and its client 10.130.56.14.
The following sections describe MGCP application inspection.
MGCP is a master/slave protocol used to control media gateways from external call control elements called media gateway controllers or call agents. A media gateway is typically a network element that provides conversion between the audio signals carried on telephone circuits and data packets carried over the Internet or over other packet networks. Using NAT and PAT with MGCP lets you support a large number of devices on an internal network with a limited set of external (global) addresses. Examples of media gateways are:
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 may not arrive from the same address as the command was sent to. This can happen when multiple call agents are being 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 following figure illustrates how you can use NAT with MGCP.
Figure 8-1 Using NAT with MGCP
MGCP endpoints are physical or virtual sources and destinations for data. Media gateways contain endpoints on which the call agent can create, modify and delete connections to establish and control media sessions with other multimedia endpoints. Also, the call agent can instruct the endpoints to detect certain events and generate signals. The endpoints automatically communicate changes in service state to the call agent.
Note MGCP inspection does not support the use of different IP addresses for MGCP signaling and RTP data. A common and recommended practice is to send RTP data from a resilient IP address, such as a loopback or virtual IP address; however, the ASA requires the RTP data to come from the same address as MGCP signaling.
Use the following process to enable MGCP inspection.
Step 1 Configuring an MGCP Inspection Policy Map for Additional Inspection Control.
Step 2 Configure the MGCP Inspection Service Policy.
If the network has multiple call agents and gateways for which the ASA has to open pinholes, create an MGCP map. You can then apply the MGCP map when you enable MGCP inspection.
Step 1 To create an MGCP inspection policy map, enter the following command:
Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.
Step 2 (Optional) To add a description to the policy map, enter the following command:
Step 3 Enter parameters configuration mode.
Step 4 Set one or more parameters. You can set the following options; use the no form of the command to disable the option.
Note MGCP call agents send AUEP messages to determine if MGCP end points are present. This establishes a flow through the ASA and allows MGCP end points to register with the call agent.
The following example shows how to define an MGCP map:
MGCP inspection is not enabled in the default inspection policy, so you must enable it if you need this inspection. However, the default inspect class does include the default MGCP ports, so you can simply edit the default global inspection policy to add MGCP inspection. You can alternatively create a new service policy as desired, for example, an interface-specific policy.
Step 1 If necessary, create an L3/L4 class map to identify the traffic for which you want to apply the inspection.
hostname(config-cmap)# match access-list mgcp
In the default global policy, the inspection_default class map is a special class map that includes default ports for all inspection types (match default-inspection-traffic). If you are using this class map in either the default policy or for a new service policy, you can skip this step.
For information on matching statements, see Identify Traffic (Layer 3/4 Class Maps).
Step 2 Add or edit a policy map that sets the actions to take with the class map traffic.
In the default configuration, the global_policy policy map is assigned globally to all interfaces. If you want to edit the global_policy, enter global_policy as the policy name.
Step 3 Identify the L3/L4 class map you are using for MGCP inspection.
To edit the default policy, or to use the special inspection_default class map in a new policy, specify inspection_default for the name. Otherwise, you are specifying the class you created earlier in this procedure.
Step 4 Configure MGCP inspection.
Where mgcp_policy_map is the optional MGCP inspection policy map. For information on creating the MGCP inspection policy map, see Configuring an MGCP Inspection Policy Map for Additional Inspection Control.
Note If you are editing the default global policy (or any in-use policy) to use a different MGCP inspection policy map, you must remove the MGCP inspection with the no inspect mgcp command, and then re-add it with the new MGCP inspection policy map name.
Step 5 If you are editing an existing service policy (such as the default global policy called global_policy), you are done. Otherwise, activate the policy map on one or more interfaces.
The global keyword applies the policy map to all interfaces, and interface applies the policy to one interface. Only one global policy is allowed. You can override the global policy on an interface by applying a service policy to that interface. You can only apply one policy map to each interface.
You can configure several MGCP global timeout values on the Configuration > Firewall > Advanced > Global Timeouts page. You can set the interval for inactivity after which an MGCP media connection is closed (default is 5 minutes). You can also set the timeout for PAT xlates (30 seconds).
The timeout mgcp command lets you set the interval for inactivity after which an MGCP media connection is closed. The default is 5 minutes.
The timeout mgcp-pat command lets you set the timeout for PAT xlates. Because MGCP does not have a keepalive mechanism, if you use non-Cisco MGCP gateways (call agents), the PAT xlates are torn down after the default timeout interval, which is 30 seconds.
The show mgcp commands command lists the number of MGCP commands in the command queue. The show mgcp sessions command lists the number of existing MGCP sessions. The detail option includes additional information about each command (or session) in the output. The following is sample output from the show mgcp commands command:
The following is sample output from the show mgcp detail command.
The following is sample output from the show mgcp sessions command.
The following is sample output from the show mgcp sessions detail command.
The following sections describe RTSP application inspection.
The RTSP inspection engine lets the ASA pass RTSP packets. RTSP is used by RealAudio, RealNetworks, Apple QuickTime 4, RealPlayer, and Cisco IP/TV connections.
Note For Cisco IP/TV, use RTSP TCP ports 554 and 8554.
RTSP applications use the well-known port 554 with TCP (rarely UDP) as a control channel. The ASA only supports TCP, in conformity with RFC 2326. This TCP control channel is used to negotiate the data channels that are used to transmit audio/video traffic, depending on the transport mode that is configured on the client.
The supported RDT transports are: rtp/avp, rtp/avp/udp, x-real-rdt, x-real-rdt/udp, and x-pn-tng/udp.
The ASA parses Setup response messages with a status code of 200. If the response message is traveling inbound, the server is outside relative to the ASA and dynamic channels need to be opened for connections coming inbound from the server. If the response message is outbound, then the ASA does not need to open dynamic channels.
Because RFC 2326 does not require that the client and server ports must be in the SETUP response message, the ASA keeps state and remembers the client ports in the SETUP message. QuickTime places the client ports in the SETUP message and then the server responds with only the server ports.
RTSP inspection does not support PAT or dual-NAT. Also, the ASA cannot recognize HTTP cloaking where RTSP messages are hidden in the HTTP messages.
When using RealPlayer, it is important to properly configure transport mode. For the ASA, add an access-list command from the server to the client or vice versa. For RealPlayer, change transport mode by clicking Options > Preferences > Transport > RTSP Settings.
If using TCP mode on the RealPlayer, select the Use TCP to Connect to Server and Attempt to use TCP for all content check boxes. On the ASA, there is no need to configure the inspection engine.
If using UDP mode on the RealPlayer, select the Use TCP to Connect to Server and Attempt to use UDP for static content check boxes, and for live content not available via multicast. On the ASA, add an inspect rtsp port command.
The following restrictions apply to the RSTP inspection.
RTSP inspection is enabled by default. You need to configure it only if you want non-default processing. If you want to customize RTSP inspection, use the following process.
Step 1 Configure RTSP Inspection Policy Map
Step 2 Configure the RTSP Inspection Service Policy
You can create an RTSP inspection policy map to customize RTSP inspection actions if the default inspection behavior is not sufficient for your network.
When defining traffic matching criteria, you can either create a class map or include the match statements directly in the policy map. The following procedure explains both approaches.
Some traffic matching options use regular expressions for matching purposes. If you intend to use one of those techniques, first create the regular expression or regular expression class map.
Step 1 (Optional) Create an RTSP inspection class map by performing the following steps.
A class map groups multiple traffic matches.You can alternatively identify match commands directly in the policy map. The difference between creating a class map and defining the traffic match directly in the inspection policy map is that the class map lets you create more complex match criteria, and you can reuse class maps.
To specify traffic that should not match the class map, use the match not command. For example, if the match not command specifies the string “example.com,” then any traffic that includes “example.com” does not match the class map.
For the traffic that you identify in this class map, you specify actions to take on the traffic in the inspection policy map.
If you want to perform different actions for each match command, you should identify the traffic directly in the policy map.
a. Create the class map by entering the following command:
Where class_map_name is the name of the class map. The match-all keyword is the default, and specifies that traffic must match all criteria to match the class map. The match-any keyword specifies that the traffic matches the class map if it matches at least one of the criteria. The CLI enters class-map configuration mode, where you can enter one or more match commands.
b. (Optional) To add a description to the class map, enter the following command:
c. Specify the traffic on which you want to perform actions using one of the following match commands. If you use a match not command, then any traffic that does not match the criterion in the match not command has the action applied.
Step 2 To create an RTSP inspection policy map, enter the following command:
Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.
Step 3 (Optional) To add a description to the policy map, enter the following command:
Step 4 To apply actions to matching traffic, perform the following steps.
a. Specify the traffic on which you want to perform actions using one of the following methods:
b. Specify the action you want to perform on the matching traffic by entering the following command:
The drop-connection keyword drops the packet and closes the connection. This option is available for URL matching.
The log keyword, which you can use alone or with drop-connection, sends a system log message.
The rate-limit message_rate argument limits the rate of messages per second. This option is available for request method matching.
You can specify multiple class or match commands in the policy map. For information about the order of class and match commands, see Defining Actions in an Inspection Policy Map.
Step 5 To configure parameters that affect the inspection engine, perform the following steps:
a. To enter parameters configuration mode, enter the following command:
b. Set one or more parameters. You can set the following options; use the no form of the command to disable the option:
The following example shows a how to define an RTSP inspection policy map.
The default ASA configuration includes RTSP inspection on the default port applied globally on all interfaces. A common method for customizing the inspection configuration is to customize the default global policy. You can alternatively create a new service policy as desired, for example, an interface-specific policy.
Step 1 If necessary, create an L3/L4 class map to identify the traffic for which you want to apply the inspection.
hostname(config-cmap)# match access-list rtsp
In the default global policy, the inspection_default class map is a special class map that includes default ports for all inspection types (match default-inspection-traffic). If you are using this class map in either the default policy or for a new service policy, you can skip this step.
For information on matching statements, see Identify Traffic (Layer 3/4 Class Maps).
Step 2 Add or edit a policy map that sets the actions to take with the class map traffic.
In the default configuration, the global_policy policy map is assigned globally to all interfaces. If you want to edit the global_policy, enter global_policy as the policy name.
Step 3 Identify the L3/L4 class map you are using for RTSP inspection.
To edit the default policy, or to use the special inspection_default class map in a new policy, specify inspection_default for the name. Otherwise, you are specifying the class you created earlier in this procedure.
Step 4 Configure RTSP inspection.
Where rtsp_policy_map is the optional RTSP inspection policy map. You need a map only if you want non-default inspection processing. For information on creating the RTSP inspection policy map, see Configure RTSP Inspection Policy Map.
Note If you are editing the default global policy (or any in-use policy) to use a different RTSP inspection policy map, you must remove the RTSP inspection with the no inspect rtsp command, and then re-add it with the new RTSP inspection policy map name.
Step 5 If you are editing an existing service policy (such as the default global policy called global_policy), you are done. Otherwise, activate the policy map on one or more interfaces.
The global keyword applies the policy map to all interfaces, and interface applies the policy to one interface. Only one global policy is allowed. You can override the global policy on an interface by applying a service policy to that interface. You can only apply one policy map to each interface.
SIP is a widely used protocol for Internet conferencing, telephony, presence, events notification, and instant messaging. Partially because of its text-based nature and partially because of its flexibility, SIP networks are subject to a large number of security threats.
SIP application inspection provides address translation in message header and body, dynamic opening of ports and basic sanity checks. It also supports application security and protocol conformance, which enforce the sanity of the SIP messages, as well as detect SIP-based attacks.
SIP inspection is enabled by default. You need to configure it only if you want non-default processing, or if you want to identify a TLS proxy to enable encrypted traffic inspection. The following topics explain SIP inspection in more detail.
SIP, as defined by the IETF, enables call handling sessions, particularly two-party audio conferences, or “calls.” SIP works with SDP for call signaling. SDP specifies the ports for the media stream. Using SIP, the ASA can support any SIP VoIP gateways and VoIP proxy servers. SIP and SDP are defined in the following RFCs:
To support SIP calls through the ASA, signaling messages for the media connection addresses, media ports, and embryonic connections for the media must be inspected, because while the signaling is sent over a well-known destination port (UDP/TCP 5060), the media streams are dynamically allocated. Also, SIP embeds IP addresses in the user-data portion of the IP packet. Note that the maximum length of the SIP Request URI that the ASA supports is 255.
SIP inspection is tested and supported for Cisco Unified Communications Manager (CUCM) 7.0, 8.0, 8.6, and 10.5. It is not supported for CUCM 8.5, or 9.x. SIP inspection might work with other releases and products.
SIP inspection applies NAT for embedded IP addresses. However, if you configure NAT to translate both source and destination addresses, the external address (“from” in the SIP header for the “trying” response message) is not rewritten. Thus, you should use object NAT when working with SIP traffic so that you avoid translating the destination address.
The following limitations and restrictions apply when using PAT with SIP:
– PAT is configured for the remote endpoint.
– The SIP registrar server is on the outside network.
– The port is missing in the contact field in the REGISTER message sent by the endpoint to the proxy server.
Instant Messaging refers to the transfer of messages between users in near real-time. SIP supports the Chat feature on Windows XP using Windows Messenger RTC Client version 4.7.0105 only. The MESSAGE/INFO methods and 202 Accept response are used to support IM as defined in the following RFCs:
MESSAGE/INFO requests can come in at any time after registration/subscription. For example, two users can be online at any time, but not chat for hours. Therefore, the SIP inspection engine opens pinholes that time out according to the configured SIP timeout value. This value must be configured at least five minutes longer than the subscription duration. The subscription duration is defined in the Contact Expires value and is typically 30 minutes.
Because MESSAGE/INFO requests are typically sent using a dynamically allocated port other than port 5060, they are required to go through the SIP inspection engine.
Note Only the Chat feature is supported. Whiteboard, File Transfer, and Application Sharing are not supported. RTC Client 5.0 is not supported.
SIP inspection translates 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. These indices identify the call, the source, and the destination. This database contains the media addresses and media ports found in the SDP media information fields and the media type. There can be multiple media addresses and ports for a session. The ASA opens RTP/RTCP connections 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 may 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 translated.
As a call is set up, the SIP session is in the “transient” state until the media address and media port is received from the called endpoint in a Response message indicating the RTP port the called endpoint listens on. 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 does not traverse the ASA, unless the ASA configuration specifically allows it.
SIP inspection is enabled by default using the default inspection map, which includes the following:
Also note that inspection of encrypted traffic is not enabled. You must configure a TLS proxy to inspect encrypted traffic.
SIP application inspection provides address translation in message header and body, dynamic opening of ports and basic sanity checks. It also supports application security and protocol conformance, which enforce the sanity of the SIP messages, as well as detect SIP-based attacks.
SIP inspection is enabled by default. You need to configure it only if you want non-default processing, or if you want to identify a TLS proxy to enable encrypted traffic inspection. If you want to customize SIP inspection, use the following process.
Step 1 Configure SIP Inspection Policy Map
Step 2 Configure the SIP Inspection Service Policy
You can create a SIP inspection policy map to customize SIP inspection actions if the default inspection behavior is not sufficient for your network.
When defining traffic matching criteria, you can either create a class map or include the match statements directly in the policy map. The following procedure explains both approaches.
Some traffic matching options use regular expressions for matching purposes. If you intend to use one of those techniques, first create the regular expression or regular expression class map.
Step 1 (Optional) Create a SIP inspection class map by performing the following steps.
A class map groups multiple traffic matches.You can alternatively identify match commands directly in the policy map. The difference between creating a class map and defining the traffic match directly in the inspection policy map is that the class map lets you create more complex match criteria, and you can reuse class maps.
To specify traffic that should not match the class map, use the match not command. For example, if the match not command specifies the string “example.com,” then any traffic that includes “example.com” does not match the class map.
For the traffic that you identify in this class map, you specify actions to take on the traffic in the inspection policy map.
If you want to perform different actions for each match command, you should identify the traffic directly in the policy map.
a. Create the class map by entering the following command:
Where the class_map_name is the name of the class map. The match-all keyword is the default, and specifies that traffic must match all criteria to match the class map. The match-any keyword specifies that the traffic matches the class map if it matches at least one match statement. The CLI enters class-map configuration mode, where you can enter one or more match commands.
b. (Optional) To add a description to the class map, enter the following command:
Where string is the description of the class map (up to 200 characters).
c. Specify the traffic on which you want to perform actions using one of the following match commands. If you use a match not command, then any traffic that does not match the criterion in the match not command has the action applied.
d. Enter exit to leave class map configuration mode.
Step 2 Create a SIP inspection policy map, enter the following command:
Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.
Step 3 (Optional) To add a description to the policy map, enter the following command:
Step 4 To apply actions to matching traffic, perform the following steps.
a. Specify the traffic on which you want to perform actions using one of the following methods:
b. Specify the action you want to perform on the matching traffic by entering the following command:
Not all options are available for each match or class command. See the CLI help or the command reference for the exact options available.
The drop keyword drops all packets that match.
The drop-connection keyword drops the packet and closes the connection.
The reset keyword drops the packet, closes the connection, and sends a TCP reset to the server and/or client.
The log keyword, which you can use alone or with one of the other keywords, sends a system log message.
The rate-limit message_rate argument limits the rate of messages. Rate limiting is available for request method matches to “invite” and “register” only.
You can specify multiple class or match commands in the policy map. For information about the order of class and match commands, see Defining Actions in an Inspection Policy Map.
Step 5 To configure parameters that affect the inspection engine, perform the following steps:
a. To enter parameters configuration mode, enter the following command:
b. Set one or more parameters. You can set the following options; use the no form of the command to disable the option:
The following example shows how to disable instant messaging over SIP:
The following example shows how to identify four Trust Verification Services servers.
The default ASA configuration includes SIP inspection on the default port applied globally on all interfaces. A common method for customizing the inspection configuration is to customize the default global policy. You can alternatively create a new service policy as desired, for example, an interface-specific policy.
Step 1 If necessary, create an L3/L4 class map to identify the traffic for which you want to apply the inspection.
hostname(config-cmap)# match access-list sip
In the default global policy, the inspection_default class map is a special class map that includes default ports for all inspection types (match default-inspection-traffic). If you are using this class map in either the default policy or for a new service policy, you can skip this step.
For information on matching statements, see Identify Traffic (Layer 3/4 Class Maps).
Step 2 Add or edit a policy map that sets the actions to take with the class map traffic.
In the default configuration, the global_policy policy map is assigned globally to all interfaces. If you want to edit the global_policy, enter global_policy as the policy name.
Step 3 Identify the L3/L4 class map you are using for SIP inspection.
To edit the default policy, or to use the special inspection_default class map in a new policy, specify inspection_default for the name. Otherwise, you are specifying the class you created earlier in this procedure.
Step 4 Configure SIP inspection.
Note If you are editing the default global policy (or any in-use policy) to use a different SIP inspection policy map, you must remove the SIP inspection with the no inspect sip command, and then re-add it with the new SIP inspection policy map name.
Step 5 If you are editing an existing service policy (such as the default global policy called global_policy), you are done. Otherwise, activate the policy map on one or more interfaces.
The global keyword applies the policy map to all interfaces, and interface applies the policy to one interface. Only one global policy is allowed. You can override the global policy on an interface by applying a service policy to that interface. You can only apply one policy map to each interface.
The media connections are torn down within two minutes after the connection becomes idle. This is, however, a configurable timeout and can be set for a shorter or longer period of time.
You can configure several SIP global timeout values on the Configuration > Firewall > Advanced > Global Timeouts page.
To configure the timeout for the SIP control connection, enter the following command:
This command configures the idle timeout after which a SIP control connection is closed.
To configure the timeout for the SIP media connection, enter the following command:
This command configures the idle timeout after which a SIP media connection is closed.
The show sip command displays information for SIP sessions established across the ASA. Along with the debug sip and show local-host commands, this command is used for troubleshooting SIP inspection engine issues.
The following is sample output from the show sip command:
This sample shows two active SIP sessions on the ASA (as shown in the Total field). Each call-id
represents a call.
The first session, with the call-id c3943000-960ca-2e43-228f@10.130.56.44, is in the state Call Init, which means the session is still in call setup. Call setup is not complete until a final response to the call has been received. For instance, the caller has already sent the INVITE, and maybe received a 100 Response, but has not yet seen the 200 OK, so the call setup is not complete yet. Any non-1xx response message is considered a final response. This session has been idle for 1 second.
The second session is in the state Active, in which call setup is complete and the endpoints are exchanging media. This session has been idle for 6 seconds.
The following sections describe SCCP application inspection.
Skinny (SCCP) is a simplified protocol used in VoIP networks. Cisco IP Phones using SCCP can coexist in an H.323 environment. When used with Cisco CallManager, the SCCP client can interoperate with H.323 compliant terminals.
The ASA supports PAT and NAT for SCCP. PAT is necessary if you have more IP phones than global IP addresses for the IP phones to use. By supporting NAT and PAT of SCCP Signaling packets, Skinny application inspection ensures that all SCCP signaling and media packets can traverse the ASA.
Normal traffic between Cisco CallManager and Cisco IP Phones uses SCCP and is handled by SCCP inspection without any special configuration. The ASA also supports DHCP options 150 and 66, which it accomplishes by sending the location of a TFTP server to Cisco IP Phones and other DHCP clients. Cisco IP Phones might also include DHCP option 3 in their requests, which sets the default route.
Note The ASA supports inspection of traffic from Cisco IP Phones running SCCP protocol version 22 and earlier.
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 static identity 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 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 ACL 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 using NAT, an identity static entry maps to the same IP address. When using PAT, 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 ACL or static entry is required to allow the Cisco IP Phones to initiate the connection.
SCCP inspection is tested and supported for Cisco Unified Communications Manager (CUCM) 7.0, 8.0, 8.6, and 10.5. It is not supported for CUCM 8.5, or 9.x. SCCP inspection might work with other releases and products.
If the address of an internal Cisco CallManager is configured for NAT or PAT to a different IP address or port, registrations for external Cisco IP Phones fail because the ASA currently does not support NAT or PAT for the file content transferred over TFTP. Although the ASA supports NAT of TFTP messages and opens a pinhole for the TFTP file, the ASA cannot translate the Cisco CallManager IP address and port embedded in the Cisco IP Phone configuration files that are transferred by TFTP during phone registration.
Note The ASA supports stateful failover of SCCP calls except for calls that are in the middle of call setup.
SCCP inspection is enabled by default using these defaults:
Also note that inspection of encrypted traffic is not enabled. You must configure a TLS proxy to inspect encrypted traffic.
SCCP (Skinny) application inspection performs translation of embedded IP address and port numbers within the packet data, and dynamic opening of pinholes. It also performs additional protocol conformance checks and basic state tracking.
SCCP inspection is enabled by default. You need to configure it only if you want non-default processing, or if you want to identify a TLS proxy to enable encrypted traffic inspection. If you want to customize SCCP inspection, use the following process.
Step 1 Configure a Skinny (SCCP) Inspection Policy Map for Additional Inspection Control.
Step 2 Configure the SCCP Inspection Service Policy.
To specify actions when a message violates a parameter, create an SCCP inspection policy map. You can then apply the inspection policy map when you enable SCCP inspection.
Step 1 Create an SCCP inspection policy map.
Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.
Step 2 (Optional) Add a description to the policy map.
Step 3 (Optional) Drop traffic based on the station message ID field in SCCP messages.
a. Identify the traffic based on the station message ID value in hexadecimal, from 0x0 to 0xffff. You can either specify a single ID, or a range of IDs, using the match [ not ] message-id command. If you use a match not command, then any traffic that does not match the criterion in the match not command has the action applied.
b. Specify the action to perform on matching packets. You can drop the packet and optionally log it.
c. Repeat the process until you identify all message IDs that you want to drop.
Step 4 Configure parameters that affect the inspection engine.
a. Enter parameters configuration mode.
b. Set one or more parameters. You can set the following options; use the no form of the command to disable the option:
The following example shows how to define an SCCP inspection policy map.
The default ASA configuration includes SCCP inspection on the default port applied globally on all interfaces. A common method for customizing the inspection configuration is to customize the default global policy. You can alternatively create a new service policy as desired, for example, an interface-specific policy.
Step 1 If necessary, create an L3/L4 class map to identify the traffic for which you want to apply the inspection.
hostname(config-cmap)# match access-list sccp
In the default global policy, the inspection_default class map is a special class map that includes default ports for all inspection types (match default-inspection-traffic). If you are using this class map in either the default policy or for a new service policy, you can skip this step.
For information on matching statements, see Identify Traffic (Layer 3/4 Class Maps).
Step 2 Add or edit a policy map that sets the actions to take with the class map traffic.
In the default configuration, the global_policy policy map is assigned globally to all interfaces. If you want to edit the global_policy, enter global_policy as the policy name.
Step 3 Identify the L3/L4 class map you are using for SCCP inspection.
To edit the default policy, or to use the special inspection_default class map in a new policy, specify inspection_default for the name. Otherwise, you are specifying the class you created earlier in this procedure.
Step 4 Configure SCCP inspection.
Note If you are editing the default global policy (or any in-use policy) to use a different SCCP inspection policy map, you must remove the SCCP inspection with the no inspect skinny command, and then re-add it with the new SCCP inspection policy map name.
Step 5 If you are editing an existing service policy (such as the default global policy called global_policy), you are done. Otherwise, activate the policy map on one or more interfaces.
The global keyword applies the policy map to all interfaces, and interface applies the policy to one interface. Only one global policy is allowed. You can override the global policy on an interface by applying a service policy to that interface. You can only apply one policy map to each interface.
The show skinny command assists in troubleshooting SCCP (Skinny) inspection engine issues. The following is sample output from the show skinny command under the following conditions. There are two active Skinny sessions set up across the ASA. The first one is established between an internal Cisco IP Phone at local address 10.0.0.11 and an external Cisco CallManager at 172.18.1.33. TCP port 2000 is the CallManager. The second one is established between another internal Cisco IP Phone at local address 10.0.0.22 and the same Cisco CallManager.
The output indicates that a call has been established between two internal Cisco IP Phones. The RTP listening ports of the first and second phones are UDP 22948 and 20798 respectively.
The following is sample output from the show xlate debug command for these Skinny connections: