Cisco ASA Services Module CLI Configuration Guide, 8.5
Configuring Inspection of Voice and Video Protocols
Downloads: This chapterpdf (PDF - 367.0KB) The complete bookPDF (PDF - 12.85MB) | Feedback

Configuring Inspection for Voice and Video Protocols

Table Of Contents

Configuring Inspection for Voice and Video Protocols

CTIQBE Inspection

CTIQBE Inspection Overview

Limitations and Restrictions

Verifying and Monitoring CTIQBE Inspection

H.323 Inspection

H.323 Inspection Overview

How H.323 Works

H.239 Support in H.245 Messages

Limitations and Restrictions

Configuring an H.323 Inspection Policy Map for Additional Inspection Control

Configuring H.323 and H.225 Timeout Values

Verifying and Monitoring H.323 Inspection

Monitoring H.225 Sessions

Monitoring H.245 Sessions

Monitoring H.323 RAS Sessions

MGCP Inspection

MGCP Inspection Overview

Configuring an MGCP Inspection Policy Map for Additional Inspection Control

Configuring MGCP Timeout Values

Verifying and Monitoring MGCP Inspection

RTSP Inspection

RTSP Inspection Overview

Using RealPlayer

Restrictions and Limitations

Configuring an RTSP Inspection Policy Map for Additional Inspection Control

SIP Inspection

SIP Inspection Overview

SIP Instant Messaging

Configuring a SIP Inspection Policy Map for Additional Inspection Control

Configuring SIP Timeout Values

Verifying and Monitoring SIP Inspection

Skinny (SCCP) Inspection

SCCP Inspection Overview

Supporting Cisco IP Phones

Restrictions and Limitations

Configuring a Skinny (SCCP) Inspection Policy Map for Additional Inspection Control

Verifying and Monitoring SCCP Inspection


Configuring Inspection for Voice and Video Protocols


This chapter describes how to configure application layer protocol inspection. Inspection engines are required for services that embed IP addressing information in the user data packet or that open secondary channels on dynamically assigned ports. These protocols require the ASASM to do a deep packet inspection instead of passing the packet through the fast path. As a result, inspection engines can affect overall throughput.

Several common inspection engines are enabled on the ASASM by default, but you might need to enable others depending on your network.

This chapter includes the following sections:

CTIQBE Inspection

H.323 Inspection

MGCP Inspection

RTSP Inspection

SIP Inspection

Skinny (SCCP) Inspection

CTIQBE Inspection

This section describes CTIQBE application inspection. This section includes the following topics:

CTIQBE Inspection Overview

Limitations and Restrictions

Verifying and Monitoring CTIQBE Inspection

CTIQBE Inspection Overview

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 ASASM.

TAPI and JTAPI are used by many Cisco VoIP applications. CTIQBE is used by Cisco TSP to communicate with Cisco CallManager.

Limitations and Restrictions

The following summarizes limitations that apply when using CTIQBE application inspection:

CTIQBE application inspection does not support configurations with the alias command.

Stateful failover of CTIQBE calls is not supported.

Entering the debug ctiqbe command may delay message transmission, which may have a performance impact in a real-time environment. When you enable this debugging or logging and Cisco IP SoftPhone seems unable to complete call setup through the ASASM, increase the timeout values in the Cisco TSP settings on the system running Cisco IP SoftPhone.

The following summarizes special considerations when using CTIQBE application inspection in specific scenarios:

If two Cisco IP SoftPhones are registered with different Cisco CallManagers, which are connected to different interfaces of the ASASM, calls between these two phones fails.

When Cisco CallManager is located on the higher security interface compared to Cisco IP SoftPhones, if NAT or outside NAT is required for the Cisco CallManager IP address, the mapping must be static as Cisco IP SoftPhone requires the Cisco CallManager IP address to be specified explicitly in its Cisco TSP configuration on the PC.

When using PAT or Outside PAT, if the Cisco CallManager IP address is to be translated, its TCP port 2748 must be statically mapped to the same port of the PAT (interface) address for Cisco IP SoftPhone registrations to succeed. The CTIQBE listening port (TCP 2748) is fixed and is not user-configurable on Cisco CallManager, Cisco IP SoftPhone, or Cisco TSP.

Verifying and Monitoring CTIQBE Inspection

The show ctiqbe command displays information regarding the CTIQBE sessions established across the ASASM. 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 ASASM. 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.

hostname# # show ctiqbe
 
   
Total: 1
        LOCAL           FOREIGN         STATE   HEARTBEAT
---------------------------------------------------------------
1       10.0.0.99/1117  172.29.1.77/2748        1       120
        ----------------------------------------------
        RTP/RTCP: PAT xlates: mapped to 172.29.1.99(1028 - 1029)
        ----------------------------------------------
        MEDIA: Device ID 27     Call ID 0
               Foreign 172.29.1.99      (1028 - 1029)
               Local   172.29.1.88      (26822 - 26823)
        ----------------------------------------------
 
   

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 ASASM 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:

hostname# show xlate debug
3 in use, 3 most used
Flags:  D - DNS, d - dump, I - identity, i - inside, n - no random,
        r - portmap, s - static
TCP PAT from inside:10.0.0.99/1117 to outside:172.29.1.99/1025 flags ri idle 0:00:22 
timeout 0:00:30
UDP PAT from inside:10.0.0.99/16908 to outside:172.29.1.99/1028 flags ri idle 0:00:00 
timeout 0:04:10
UDP PAT from inside:10.0.0.99/16909 to outside:172.29.1.99/1029 flags ri idle 0:00:23 
timeout 0:04:10
 
   

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:

hostname# show conn state ctiqbe
1 in use, 10 most used
hostname# show conn state ctiqbe detail
1 in use, 10 most used
Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,
       B - initial SYN from outside, C - CTIQBE media, D - DNS, d - dump,
       E - outside back connection, F - outside FIN, f - inside FIN,
       G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,
       i - incomplete, J - GTP, j - GTP data, k - Skinny media,
       M - SMTP data, m - SIP media, O - outbound data, P - inside back connection,
       q - SQL*Net data, R - outside acknowledged FIN,
       R - UDP RPC, r - inside acknowledged FIN, S - awaiting inside SYN,
       s - awaiting outside SYN, T - SIP, t - SIP transient, U - up

H.323 Inspection

This section describes the H.323 application inspection. This section includes the following topics:

H.323 Inspection Overview

How H.323 Works

H.239 Support in H.245 Messages

Limitations and Restrictions

Configuring an H.323 Inspection Policy Map for Additional Inspection Control

Configuring H.323 and H.225 Timeout Values

Verifying and Monitoring H.323 Inspection

H.323 Inspection Overview

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 ASASM supports H.323 through Version 6, including H.323 v3 feature Multiple Calls on One Call Signaling Channel.

With H.323 inspection enabled, the ASASM 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 ASASM.

The two major functions of H.323 inspection are as follows:

NAT the necessary embedded IPv4 addresses in the H.225 and H.245 messages. Because H.323 messages are encoded in PER encoding format, the ASASM uses an ASN.1 decoder to decode the H.323 messages.

Dynamically allocate the negotiated H.245 and RTP/RTCP connections.

How H.323 Works

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 ASASM 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.

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 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 ASASM opens an H.225 connection based on inspection of the ACF and RCF nmessages.

After inspecting the H.225 messages, the ASASM opens the H.245 channel and then inspects traffic sent over the H.245 channel as well. All H.245 messages passing through the ASASM 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 ASASM must remember the TPKT length to process and decode the messages properly. For each connection, the ASASM keeps a record that contains the TPKT length for the next expected message.

If the ASASM 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 ASASM proxy ACKs that TPKT and appends a new TPKT to the H.245 message with the new length.


Note The ASASM 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 ASASM 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 ASASM 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 Configuring an H.323 Inspection Policy Map for Additional Inspection Control.


H.239 Support in H.245 Messages

The ASASM 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 ASASM ensure successful H.239 negotiation between the endpoints.

H.239 is a standar 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 ASASM 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 of the telepresentation session is enabled by default. H.239 encoding and decoding is preformed by ASN.1 coder.

Limitations and Restrictions

The following are some of the known issues and limitations when using H.323 application inspection:

Static PAT may not properly translate IP addresses embedded in optional fields within H.323 messages. If you experience this kind of problem, do not use static PAT with H.323.

H.323 application inspection is not supported with NAT between same-security-level interfaces.

When a NetMeeting client registers with an H.323 gatekeeper and tries to call an H.323 gateway that is also registered with the H.323 gatekeeper, the connection is established but no voice is heard in either direction. This problem is unrelated to the ASASM.

If you configure a network static address where the network static address is the same as a third-party netmask and address, then any outbound H.323 connection fails.

Configuring both H.323 inspection and communication in and out of the same interface (using the same-security-traffic permit intra-interface command) on the ASASM is not supported. When you configure both these features, the ASASM cannot correctly establish NetMeeting calls because it modifies the H.225 setup message incorrectly by changing the destCallSignalAddress field to point to itself rather than the NetMeeting destination endpoint.

To workaround this limitation, perform one of the following actions:

Configure the ASASM so that either H.323 inspection or communication in and out of the same interface, but not both, is set up on the device.

To disable communication on the same interface, remove the same-security-traffic permit intra-interface command.

To disable H.323 inspection, enter the no inspect h323 h225 command under the global policy.

Configure inside to inside traffic to use NAT 0:

access-list id permit ip src_ip mask dest_ip mask 
 
   

Where src_ip mask and dest_ip mask are both the inside network.

Configuring an H.323 Inspection Policy Map for Additional Inspection Control

To specify actions when a message violates a parameter, create an H.323 inspection policy map. You can then apply the inspection policy map when you enable H.323 inspection.

To create an H.323 inspection policy map, perform the following steps:


Step 1 (Optional) Add one or more regular expressions for use in traffic matching commands according to the "Creating a Regular Expression" section. See the types of text you can match in the match commands described in Step 3.

Step 2 (Optional) Create one or more regular expression class maps to group regular expressions according to the "Creating a Regular Expression Class Map" section.s

Step 3 (Optional) Create an H.323 inspection class map by performing the following steps.

A class map groups multiple traffic matches. Traffic must match all of the match commands to match the class map. 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 can specify actions such as drop-connection, reset, and/or log the connection 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:

hostname(config)# class-map type inspect h323 [match-all | match-any] class_map_name
hostname(config-cmap)# 
 
   

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 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:

hostname(config-cmap)# description string
 
   

Where string is the description of the class map (up to 200 characters).

c. (Optional) To match a called party, enter the following command:

hostname(config-cmap)# match [not] called-party regex {class class_name | regex_name}
 
   

Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.

d. (Optional) To match a media type, enter the following command:

hostname(config-cmap)# match [not] media-type {audio | data | video}
 
   

Step 4 Create an H.323 inspection policy map, enter the following command:

hostname(config)# policy-map type inspect h323 policy_map_name
hostname(config-pmap)# 
 
   

Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.

Step 5 (Optional) To add a description to the policy map, enter the following command:

hostname(config-pmap)# description string
 
   

Step 6 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:

Specify the H.323 class map that you created in Step 3 by entering the following command:

hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)# 
 
   

Specify traffic directly in the policy map using one of the match commands described in Step 3. 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 you want to perform on the matching traffic by entering the following command:

hostname(config-pmap-c)# {[drop [send-protocol-error] | 
drop-connection [send-protocol-error]| mask | reset] [log] | rate-limit message_rate}
 
   

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 send-protocol-error keyword sends a protocol error message.

The drop-connection keyword drops the packet and closes the connection.

The mask keyword masks out the matching portion of the packet.

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.

You can specify multiple class or match commands in the policy map. For information about the order of class and match commands, see the "Defining Actions in an Inspection Policy Map" section.

Step 7 To configure parameters that affect the inspection engine, perform the following steps:

a. To enter parameters configuration mode, enter the following command:

hostname(config-pmap)# parameters
hostname(config-pmap-p)# 
 
   

b. To enable call setup betweeen H.323 Endpoings, enter the following command:

hostname(config)# ras-rcf-pinholes enable
 
   

You can enable call setup between H.323 endpoints when the Gatekeeper is inside the network. The ASASM 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 ASASM opens a pinhole through source IP address/port 0/0. By default, this option is disabled.

c. To define the H.323 call duration limit, enter the following command:

hostname(config-pmap-p)# call-duration-limit time
 
   

Where time is the call duration limit in seconds. Range is from 0:0:0 ti 1163:0;0. A value of 0 means never timeout.

d. To enforce call party number used in call setup, enter the following command:

hostname(config-pmap-p)# call-party-number
 
   

e. To enforce H.245 tunnel blocking, enter the following command:

hostname(config-pmap-p)# h245-tunnel-block action {drop-connection | log}
 
   

f. To define an hsi group and enter hsi group configuration mode, enter the following command:

hostname(config-pmap-p)# hsi-group id
 
   

Where id is the hsi group ID. Range is from 0 to 2147483647.

To add an hsi to the hsi group, enter the following command in hsi group configuration mode:

hostname(config-h225-map-hsi-grp)# hsi ip_address
 
   

Where ip_address is the host to add. A maximum of five hosts per hsi group are allowed.

To add an endpoint to the hsi group, enter the following command in hsi group configuration mode:

hostname(config-h225-map-hsi-grp)# endpoint ip_address if_name
 
   

Where ip_address is the endpoint to add and if_name is the interface through which the endpoint is connected to the security appliance. A maximum of ten endpoints per hsi group are allowed.

g. To check RTP packets flowing on the pinholes for protocol conformance, enter the following command:

hostname(config-pmap-p)# rtp-conformance [enforce-payloadtype]
 
   

Where the enforce-payloadtype keyword enforces the payload type to be audio or video based on the signaling exchange.

h. To enable state checking validation, enter the following command:

hostname(config-pmap-p)# state-checking {h225 | ras}
 
   

The following example shows how to configure phone number filtering:

hostname(config)# regex caller 1 "5551234567"
hostname(config)# regex caller 2 "5552345678"
hostname(config)# regex caller 3 "5553456789"
 
   
hostname(config)# class-map type inspect h323 match-all h323_traffic
hostname(config-pmap-c)# match called-party regex caller1
hostname(config-pmap-c)# match calling-party regex caller2
 
   
hostname(config)# policy-map type inspect h323 h323_map
hostname(config-pmap)# parameters
hostname(config-pmap-p)# class h323_traffic
hostname(config-pmap-c)# drop
 
   

Configuring H.323 and H.225 Timeout Values

To configure the idle time after which an H.225 signalling 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.

Verifying and Monitoring H.323 Inspection

This section describes how to display information about H.323 sessions. This section includes the following topics:

Monitoring H.225 Sessions

Monitoring H.245 Sessions

Monitoring H.323 RAS Sessions

Monitoring H.225 Sessions

The show h225 command displays information for H.225 sessions established across the ASASM. 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.

Before entering the show h225, show h245, or show h323-ras commands, we recommend that you configure the pager command. If there are a lot of session records and the pager command is not configured, it may take a while for the show command output to reach its end. 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:

hostname# show h225
Total H.323 Calls: 1
1 Concurrent Call(s) for
    Local:   10.130.56.3/1040   Foreign: 172.30.254.203/1720
    1. CRV 9861
    Local:   10.130.56.3/1040   Foreign: 172.30.254.203/1720
0 Concurrent Call(s) for
    Local:   10.130.56.4/1050   Foreign: 172.30.254.205/1720
 
   

This output indicates that there is currently 1 active H.323 call going through the ASASM 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.

Monitoring H.245 Sessions

The show h245 command displays information for H.245 sessions established across the ASASM 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.) Along with the debug h323 h245 event, debug h323 h225 event, and show local-host commands, this command is used for troubleshooting H.323 inspection engine issues.

The following is sample output from the show h245 command:

hostname# show h245
Total: 1
        LOCAL           TPKT    FOREIGN         TPKT
1       10.130.56.3/1041        0       172.30.254.203/1245    0
        MEDIA: LCN 258 Foreign 172.30.254.203 RTP 49608 RTCP 49609
                      Local   10.130.56.3 RTP 49608 RTCP 49609
        MEDIA: LCN 259 Foreign 172.30.254.203 RTP 49606 RTCP 49607
                      Local   10.130.56.3 RTP 49606 RTCP 49607
 
   

There is currently one H.245 control session active across the ASASM. 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.

Monitoring H.323 RAS Sessions

The show h323-ras command displays information for H.323 RAS sessions established across the ASASM 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 show h323-ras command displays connection information for troubleshooting H.323 inspection engine issues. The following is sample output from the show h323-ras command:

hostname# show h323-ras
Total: 1
        GK                      Caller
        172.30.254.214 10.130.56.14
 
   

This output shows that there is one active registration between the gatekeeper 172.30.254.214 and its client 10.130.56.14.

MGCP Inspection

This section describes MGCP application inspection. This section includes the following topics:

MGCP Inspection Overview

Configuring an MGCP Inspection Policy Map for Additional Inspection Control

Configuring MGCP Timeout Values

Verifying and Monitoring MGCP Inspection

MGCP Inspection Overview

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:

Trunking gateways, that interface between the telephone network and a Voice over IP network. Such gateways typically manage a large number of digital circuits.

Residential gateways, that provide a traditional analog (RJ11) interface to a Voice over IP network. Examples of residential gateways include cable modem/cable set-top boxes, xDSL devices, broad-band wireless devices.

Business gateways, that provide a traditional digital PBX interface or an integrated soft PBX interface to a Voice over IP network.


Note To avoid policy failure when upgrading from ASA version 7.1, all layer 7 and layer 3 policies must have distinct names. For instance, a previously configured policy map with the same name as a previously configured MGCP map must be changed before the upgrade.


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. Figure 41-1 illustrates how NAT can be used with MGCP.

Figure 41-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.

MGCP transactions are composed of a command and a mandatory response. There are eight types of commands:

CreateConnection

ModifyConnection

DeleteConnection

NotificationRequest

Notify

AuditEndpoint

AuditConnection

RestartInProgress

The first four commands are sent by the call agent to the gateway. The Notify command is sent by the gateway to the call agent. The gateway may also send a DeleteConnection. The registration of the MGCP gateway with the call agent is achieved by the RestartInProgress command. The AuditEndpoint and the AuditConnection commands are sent by the call agent to the gateway.

All commands are composed of a Command header, optionally followed by a session description. All responses are composed of a Response header, optionally followed by a session description.

The port on which the gateway receives commands from the call agent. Gateways usually listen to UDP port 2427.

The port on which the call agent receives commands from the gateway. Call agents usually listen to UDP port 2727.


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 ASASM requires the RTP data to come from the same address as MGCP signalling.


Configuring an MGCP Inspection Policy Map for Additional Inspection Control

If the network has multiple call agents and gateways for which the ASASM has to open pinholes, create an MGCP map. You can then apply the MGCP map when you enable MGCP inspection.

To create an MGCP map, perform the following steps:


Step 1 To create an MGCP inspection policy map, enter the following command:

hostname(config)# policy-map type inspect mgcp map_name
hostname(config-pmap)#
 
   

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:

hostname(config-pmap)# description string
 
   

Step 3 To configure parameters that affect the inspection engine, perform the following steps:

a. To enter parameters configuration mode, enter the following command:

hostname(config-pmap)# parameters
hostname(config-pmap-p)# 
 
   

b. To configure the call agents, enter the following command for each call agent:

hostname(config-pmap-p)# call-agent ip_address group_id
 
   

Use the call-agent command to specify a group of call agents that can manage one or more gateways. The call agent group information is used to open connections for the call agents in the group (other than the one a gateway sends a command to) so that any of the call agents can send the response. call agents with the same group_id belong to the same group. A call agent may belong to more than one group. The group_id option is a number from 0 to 4294967295. The ip_address option specifies the IP address of the call agent.


Note MGCP call agents send AUEP messages to determine if MGCP end points are present. This establishes a flow through the ASASM and allows MGCP end points to register with the call agent.


c. To configure the gateways, enter the following command for each gateway:

hostname(config-pmap-p)# gateway ip_address group_id
 
   

Use the gateway command to specify which group of call agents are managing a particular gateway. The IP address of the gateway is specified with the ip_address option. The group_id option is a number from 0 to 4294967295 that must correspond with the group_id of the call agents that are managing the gateway. A gateway may only belong to one group.

d. If you want to change the maximum number of commands allowed in the MGCP command queue, enter the following command:

hostname(config-pmap-p)# command-queue command_limit
 
   

The following example shows how to define an MGCP map:

hostname(config)# policy-map type inspect mgcp sample_map
hostname(config-pmap)# parameters
hostname(config-pmap-p)# call-agent 10.10.11.5 101
hostname(config-pmap-p)# call-agent 10.10.11.6 101
hostname(config-pmap-p)# call-agent 10.10.11.7 102
hostname(config-pmap-p)# call-agent 10.10.11.8 102
hostname(config-pmap-p)# gateway 10.10.10.115 101
hostname(config-pmap-p)# gateway 10.10.10.116 102
hostname(config-pmap-p)# gateway 10.10.10.117 102
hostname(config-pmap-p)# command-queue 150
 
   

Configuring MGCP Timeout Values

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.

Verifying and Monitoring MGCP Inspection

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:

hostname# show mgcp commands
1 in use, 1 most used, 200 maximum allowed
CRCX, gateway IP: host-pc-2, transaction ID: 2052, idle: 0:00:07
 
   

The following is sample output from the show mgcp detail command.

hostname# show mgcp commands detail
1 in use, 1 most used, 200 maximum allowed
CRCX, idle: 0:00:10
Gateway IP      host-pc-2
Transaction ID  2052
Endpoint name   aaln/1
Call ID         9876543210abcdef
Connection ID   
Media IP        192.168.5.7
Media port      6058
 
   

The following is sample output from the show mgcp sessions command.

hostname# show mgcp sessions
1 in use, 1 most used
Gateway IP host-pc-2, connection ID 6789af54c9, active 0:00:11
 
   

The following is sample output from the show mgcp sessions detail command.

hostname# show mgcp sessions detail
1 in use, 1 most used
Session active 0:00:14
Gateway IP      host-pc-2
Call ID         9876543210abcdef
Connection ID   6789af54c9
Endpoint name   aaln/1
Media lcl port  6166
Media rmt IP    192.168.5.7
Media rmt port  6058
 
   

RTSP Inspection

This section describes RTSP application inspection. This section includes the following topics:

RTSP Inspection Overview

Using RealPlayer

Restrictions and Limitations

Configuring an RTSP Inspection Policy Map for Additional Inspection Control

RTSP Inspection Overview

The RTSP inspection engine lets the ASASM 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 port 554 and TCP 8554.


RTSP applications use the well-known port 554 with TCP (rarely UDP) as a control channel. The ASASM only supports TCP, in conformity with RFC 2326. This TCP control channel is used to negotiate the data channels that is 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 ASASM parses Setup response messages with a status code of 200. If the response message is travelling inbound, the server is outside relative to the ASASM and dynamic channels need to be opened for connections coming inbound from the server. If the response message is outbound, then the ASASM 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 ASASM 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 supports PAT or dual-NAT. The ASA provides TCP fragment reassembly support, a scalable parsing routine on RTSP, and security enhancements that protect RTSP traffic.

Using RealPlayer

When using RealPlayer, it is important to properly configure transport mode. For the ASASM, 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 ASASM, 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 ASASM, add an inspect rtsp port command.

Restrictions and Limitations

The following restrictions apply to the RSTP inspection.

The ASASM does not support multicast RTSP or RTSP messages over UDP.

The ASASM does not have the ability to recognize HTTP cloaking where RTSP messages are hidden in the HTTP messages.

With Cisco IP/TV, the number of translates the ASASM performs on the SDP part of the message is proportional to the number of program listings in the Content Manager (each program listing can have at least six embedded IP addresses).

You can configure NAT for Apple QuickTime 4 or RealPlayer. Cisco IP/TV only works with NAT if the Viewer and Content Manager are on the outside network and the server is on the inside network.

Configuring an RTSP Inspection Policy Map for Additional Inspection Control

To specify actions when a message violates a parameter, create an RTSP inspection policy map. You can then apply the inspection policy map when you enable RTSP inspection.

To create an RTSP inspection policy map, perform the following steps:


Step 1 (Optional) Add one or more regular expressions for use in traffic matching commands according to the "Configuring Regular Expressions" section. See the types of text you can match in the match commands described in Step 3.

Step 2 (Optional) Create one or more regular expression class maps to group regular expressions according to the "Creating a Regular Expression Class Map" section.

Step 3 (Optional) Create an RTSP inspection class map by performing the following steps.

A class map groups multiple traffic matches. Traffic must match all of the match commands to match the class map. 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 can specify actions such as drop-connection and/or log the connection 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:

hostname(config)# class-map type inspect rtsp [match-all | match-any] class_map_name
hostname(config-cmap)# 
 
   

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:

hostname(config-cmap)# description string
 
   

c. (Optional) To match an RTSP request method, enter the following command:

hostname(config-cmap)# match [not] request-method method
 
   

Where method is the type of method to match (announce, describe, get_parameter, options, pause, play, record, redirect, setup, set_parameter, teardown).

d. (Optional) To match URL filtering, enter the following command:

hostname(config-cmap)# match [not] url-filter regex {class class_name | regex_name}
 
   

Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.

Step 4 To create an RTSP inspection policy map, enter the following command:

hostname(config)# policy-map type inspect rtsp policy_map_name
hostname(config-pmap)# 
 
   

Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.

Step 5 (Optional) To add a description to the policy map, enter the following command:

hostname(config-pmap)# description string
 
   

Step 6 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:

Specify the RTSP class map that you created in Step 3 by entering the following command:

hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)# 
 
   

Specify traffic directly in the policy map using one of the match commands described in Step 3. 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 you want to perform on the matching traffic by entering the following command:

hostname(config-pmap-c)# {[drop [send-protocol-error] | 
drop-connection [send-protocol-error]| mask | reset] [log] | rate-limit message_rate}
 
   

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 send-protocol-error keyword sends a protocol error message.

The drop-connection keyword drops the packet and closes the connection.

The mask keyword masks out the matching portion of the packet.

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.

You can specify multiple class or match commands in the policy map. For information about the order of class and match commands, see the "Defining Actions in an Inspection Policy Map" section.

Step 7 To configure parameters that affect the inspection engine, perform the following steps:

a. To enter parameters configuration mode, enter the following command:

hostname(config-pmap)# parameters
hostname(config-pmap-p)# 
 
   

b. To restrict usage on reserve port for media negotiation, enter the following command:

hostname(config-pmap-p)# reserve-port-protect
 
   

c. To set the limit on the URL length allowed in the message, enter the following command:

hostname(config-pmap-p)# url-length-limit length
 
   

Where the length argument specifies the URL length in bytes (0 to 6000).


The following example shows a how to define an RTSP inspection policy map.

hostname(config)# regex badurl1 www.url1.com/rtsp.avi
hostname(config)# regex badurl2 www.url2.com/rtsp.rm
hostname(config)# regex badurl3 www.url3.com/rtsp.asp
 
   
hostname(config)# class-map type regex match-any badurl-list
hostname(config-cmap)# match regex badurl1
hostname(config-cmap)# match regex badurl2
hostname(config-cmap)# match regex badurl3
 
   
hostname(config)# policy-map type inspect rtsp rtsp-filter-map
hostname(config-pmap)# match url-filter regex class badurl-list
hostname(config-pmap-p)# drop-connection
 
   
hostname(config)# class-map rtsp-traffic-class
hostname(config-cmap)# match default-inspection-traffic
 
   
hostname(config)# policy-map rtsp-traffic-policy
hostname(config-pmap)# class rtsp-traffic-class
hostname(config-pmap-c)# inspect rtsp rtsp-filter-map
 
   
hostname(config)# service-policy rtsp-traffic-policy global
 
   

SIP Inspection

This section describes SIP application inspection. This section includes the following topics:

SIP Inspection Overview

SIP Instant Messaging

Configuring a SIP Inspection Policy Map for Additional Inspection Control

Configuring SIP Timeout Values

Verifying and Monitoring SIP Inspection

SIP Inspection Overview

SIP, as defined by the IETF, enables call handling sessions, particularly two-party audio conferences, or "calls." SIP works with SDP for call signalling. SDP specifies the ports for the media stream. Using SIP, the ASASM can support any SIP VoIP gateways and VoIP proxy servers. SIP and SDP are defined in the following RFCs:

SIP: Session Initiation Protocol, RFC 3261

SDP: Session Description Protocol, RFC 2327

To support SIP calls through the ASASM, 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. SIP inspection applies NAT for these embedded IP addresses.

The following limitations and restrictions apply when using PAT with SIP:

If a remote endpoint tries to register with a SIP proxy on a network protected by the ASASM, the registration fails under very specific conditions, as follows:

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.

If a SIP device transmits a packet in which the SDP portion has an IP address in the owner/creator field (o=) that is different than the IP address in the connection field (c=), the IP address in the o= field may not be properly translated. This is due to a limitation in the SIP protocol, which does not provide a port value in the o= field.

SIP Instant Messaging

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:

Session Initiation Protocol (SIP)-Specific Event Notification, RFC 3265

Session Initiation Protocol (SIP) Extension for Instant Messaging, RFC 3428

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 currently 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 ASASM 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 ASASM, unless the ASASM configuration specifically allows it.

Configuring a SIP Inspection Policy Map for Additional Inspection Control

To specify actions when a message violates a parameter, create a SIP inspection policy map. You can then apply the inspection policy map when you enable SIP inspection.

To create a SIP inspection policy map, perform the following steps:


Step 1 (Optional) Add one or more regular expressions for use in traffic matching commands according to the "Configuring Regular Expressions" section. See the types of text you can match in the match commands described in Step 3.

Step 2 (Optional) Create one or more regular expression class maps to group regular expressions according to the "Creating a Regular Expression Class Map" section.s

Step 3 (Optional) Create a SIP inspection class map by performing the following steps.

A class map groups multiple traffic matches. Traffic must match all of the match commands to match the class map. 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 can specify actions such as drop-connection, reset, and/or log the connection 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:

hostname(config)# class-map type inspect sip [match-all | match-any] class_map_name
hostname(config-cmap)# 
 
   

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 leX ( 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:

hostname(config-cmap)# description string
 
   

Where string is the description of the class map (up to 200 characters).

c. (Optional) To match a called party, as specified in the To header, enter the following command:

hostname(config-cmap)# match [not] called-party regex {class class_name | regex_name}
 
   

Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.

d. (Optional) To match a calling party, as specified in the From header, enter the following command:

hostname(config-cmap)# match [not] calling-party regex {class class_name | regex_name}
 
   

Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.

e. (Optional) To match a content length in the SIP header, enter the following command:

hostname(config-cmap)# match [not] content length gt length
 
   

Where length is the number of bytes the content length is greater than. 0 to 65536.

f. (Optional) To match an SDP content type or regular expression, enter the following command:

hostname(config-cmap)# match [not] content type {sdp | regex {class class_name | 
regex_name}}
 
   

Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.

g. (Optional) To match a SIP IM subscriber, enter the following command:

hostname(config-cmap)# match [not] im-subscriber regex {class class_name | regex_name}
 
   

Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.

h. (Optional) To match a SIP via header, enter the following command:

hostname(config-cmap)# match [not] message-path regex {class class_name | regex_name}
 
   

Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.

i. (Optional) To match a SIP request method, enter the following command:

hostname(config-cmap)# match [not] request-method method
 
   

Where method is the type of method to match (ack, bye, cancel, info, invite, message, notify, options, prack, refer, register, subscribe, unknown, update).

j. (Optional) To match the requester of a third-party registration, enter the following command:

hostname(config-cmap)# match [not] third-party-registration regex {class class_name | 
regex_name}
 
   

Where the regex regex_name argument is the regular expression you created in Step 1. The class regex_class_name is the regular expression class map you created in Step 2.

k. (Optional) To match an URI in the SIP headers, enter the following command:

hostname(config-cmap)# match [not] uri {sip | tel} length gt length
 
   
Where length is the number of bytes the URI is greater than. 0 to 65536. 

Step 4 Create a SIP inspection policy map, enter the following command:

hostname(config)# policy-map type inspect sip policy_map_name
hostname(config-pmap)# 
 
   

Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.

Step 5 (Optional) To add a description to the policy map, enter the following command:

hostname(config-pmap)# description string
 
   

Step 6 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:

Specify the SIP class map that you created in Step 3 by entering the following command:

hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)# 
 
   

Specify traffic directly in the policy map using one of the match commands described in Step 3. 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 you want to perform on the matching traffic by entering the following command:

hostname(config-pmap-c)# {[drop [send-protocol-error] | 
drop-connection [send-protocol-error]| mask | reset] [log] | rate-limit message_rate}
 
   

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 send-protocol-error keyword sends a protocol error message.

The drop-connection keyword drops the packet and closes the connection.

The mask keyword masks out the matching portion of the packet.

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.

You can specify multiple class or match commands in the policy map. For information about the order of class and match commands, see the "Defining Actions in an Inspection Policy Map" section.

Step 7 To configure parameters that affect the inspection engine, perform the following steps:

a. To enter parameters configuration mode, enter the following command:

hostname(config-pmap)# parameters
hostname(config-pmap-p)# 
 
   

b. To enable or disable instant messaging, enter the following command:

hostname(config-pmap-p)# im
 
   

c. To enable or disable IP address privacy, enter the following command:

hostname(config-pmap-p)# ip-address-privacy
 
   

d. To enable check on Max-forwards header field being 0 (which cannot be 0 before reaching the destination), enter the following command:

hostname(config-pmap-p)# max-forwards-validation action {drop | drop-connection | 
reset | log} [log]
 
   

e. To enable check on RTP packets flowing on the pinholes for protocol conformance, enter the following command:

hostname(config-pmap-p)# rtp-conformance [enforce-payloadtype]
 
   

Where the enforce-payloadtype keyword enforces the payload type to be audio or video based on the signaling exchange.

f. To identify the Server and User-Agent header fields, which expose the software version of either a server or an endpoint, enter the following command:

hostname(config-pmap-p)# software-version action {mask | log} [log]
 
   

Where the mask keyword masks the software version in the SIP messages.

g. To enable state checking validation, enter the following command:

hostname(config-pmap-p)# state-checking action {drop | drop-connection | reset | log} 
[log]
 
   

h. To enable strict verification of the header fields in the SIP messages according to RFC 3261, enter the following command:

hostname(config-pmap-p)# strict-header-validation action {drop | drop-connection | 
reset | log} [log]
 
   

i. To allow non SIP traffic using the well-known SIP signaling port, enter the following command:

hostname(config-pmap-p)# traffic-non-sip 
 
   

j. To identify the non-SIP URIs present in the Alert-Info and Call-Info header fields, enter the following command:

hostname(config-pmap-p)# uri-non-sip action {mask | log} [log]
 
   

The following example shows how to disable instant messaging over SIP:

hostname(config)# policy-map type inspect sip mymap
hostname(config-pmap)# parameters
hostname(config-pmap-p)# no im
 
   
hostname(config)# policy-map global_policy
hostname(config-pmap)# class inspection_default
hostname(config-pmap-c)# inspect sip mymap
 
   
hostname(config)# service-policy global_policy global
 
   

Configuring SIP Timeout Values

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. To configure the timeout for the SIP control connection, enter the following command:

hostname(config)# timeout sip hh:mm:ss 
 
   

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:

hostname(config)# timeout sip_media hh:mm:ss 
 
   

This command configures the idle timeout after which a SIP media connection is closed.

Verifying and Monitoring SIP Inspection

The show sip command assists in troubleshooting SIP inspection engine issues and is described with the inspect protocol sip udp 5060 command. The show timeout sip command displays the timeout value of the designated protocol.

The show sip command displays information for SIP sessions established across the ASASM. Along with the debug sip and show local-host commands, this command is used for troubleshooting SIP inspection engine issues.


Note We recommend that you configure the pager command before entering the show sip command. If there are a lot of SIP session records and the pager command is not configured, it takes a while for the show sip command output to reach its end.


The following is sample output from the show sip command:

hostname# show sip
Total: 2
call-id c3943000-960ca-2e43-228f@10.130.56.44
    state Call init, idle 0:00:01
call-id c3943000-860ca-7e1f-11f7@10.130.56.45
    state Active, idle 0:00:06
 
   

This sample shows two active SIP sessions on the ASASM (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.

Skinny (SCCP) Inspection

This section describes SCCP application inspection. This section includes the following topics:

SCCP Inspection Overview

Supporting Cisco IP Phones

Restrictions and Limitations

Configuring a Skinny (SCCP) Inspection Policy Map for Additional Inspection Control

Verifying and Monitoring SIP Inspection

SCCP Inspection Overview

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 ASASM 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 signalling and media packets can traverse the ASASM.

Normal traffic between Cisco CallManager and Cisco IP Phones uses SCCP and is handled by SCCP inspection without any special configuration. The ASASM 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. For more information, see the "Using Cisco IP Phones with a DHCP Server" section.


Note The ASASM supports inspection of traffic from Cisco IP Phones running SCCP protocol version 19 and earlier.


Supporting Cisco IP Phones

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 access list 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 access list or static entry is required to allow the Cisco IP Phones to initiate the connection.

Restrictions and Limitations

The following are some of the known issues and limitations when using SCCP application inspection:

PAT does not work with configurations containing the alias command.

Outside NAT or PAT is not supported.

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 ASASM currently does not support NAT or PAT for the file content transferred over TFTP.

Although the ASASM supports NAT of TFTP messages and opens a pinhole for the TFTP file, the ASASM 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.

The ASASM supports stateful failover of SCCP calls except for calls that are in the middle of call setup.

When the ASASM is running in transparent firewall mode, it blocks SCCP voice traffic because pinholes are not opened for the connection. Displaying debugging messages for SCCP inspection indicate that RTP and RTCP channels are not open. This limication affects communication between IP Phones and the Unified Communications Manager.

To workaround this limitation, perform one of the following actions to open secondary connections:

(Preferred) Install static route entries for IP Phones or convert to routed mode.

Configure static ARP entries for IP Phones

Example:

UC Manager---IP Phone 1---Inside ASA (Transparent)---Outside ASA---IP Phone 2
 
   

In this example, configure a static ARP entry for IP Phone 1 on the ASASM to send RTP and RTCP traffic from IP Phone 2 to IP Phone 1.

Configuring a Skinny (SCCP) Inspection Policy Map for Additional Inspection Control

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.

To create an SCCP inspection policy map, perform the following steps:


Step 1 (Optional) Add one or more regular expressions for use in traffic matching commands according to the "Configuring Regular Expressions" section. See the types of text you can match in the match commands described in Step 3.

Step 2 (Optional) Create one or more regular expression class maps to group regular expressions according to the "Creating a Regular Expression Class Map" section.

Step 3 Create an SCCP inspection policy map, enter the following command:

hostname(config)# policy-map type inspect skinny policy_map_name
hostname(config-pmap)# 
 
   

Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.

Step 4 (Optional) To add a description to the policy map, enter the following command:

hostname(config-pmap)# description string
 
   

Step 5 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:

Specify the SCCP class map that you created in Step 3 by entering the following command:

hostname(config-pmap)# class class_map_name
hostname(config-pmap-c)# 
 
   

Specify traffic directly in the policy map using one of the match commands described in Step 3. 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 you want to perform on the matching traffic by entering the following command:

hostname(config-pmap-c)# {[drop [send-protocol-error] | 
drop-connection [send-protocol-error]| mask | reset] [log] | rate-limit message_rate}
 
   

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 send-protocol-error keyword sends a protocol error message.

The drop-connection keyword drops the packet and closes the connection.

The mask keyword masks out the matching portion of the packet.

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.

Step 6 You can specify multiple class or match commands in the policy map. For information about the order of class and match commands, see the "Defining Actions in an Inspection Policy Map" section.To configure parameters that affect the inspection engine, perform the following steps:

a. To enter parameters configuration mode, enter the following command:

hostname(config-pmap)# parameters
hostname(config-pmap-p)# 
 
   

b. To enforce registration before calls can be placed, enter the following command:

hostname(config-pmap-p)# enforce-registration
 
   

c. To set the maximum SCCP station message ID allowed, enter the following command:

hostname(config-pmap-p)# message-ID max hex_value
 
   

Where the hex_value argument is the station message ID in hex.

d. To check RTP packets flowing on the pinholes for protocol conformance, enter the following command:

hostname(config-pmap-p)# rtp-conformance [enforce-payloadtype]
 
   

Where the enforce-payloadtype keyword enforces the payload type to be audio or video based on the signaling exchange.

e. To set the maximum and minimum SCCP prefix length value allowed, enter the following command:

hostname(config-pmap-p)# sccp-prefix-len {max | min} value_length
 
   

Where the value_length argument is a maximum or minimum value.

f. To configure the timeout value for signaling and media connections, enter the following command:

hostname(config-pmap-p)# timeout
 
   

The following example shows how to define an SCCP inspection policy map.

hostname(config)# policy-map type inspect skinny skinny-map
hostname(config-pmap)# parameters 
hostname(config-pmap-p)# enforce-registration
hostname(config-pmap-p)# match message-id range 200 300
hostname(config-pmap-p)# drop log
hostname(config)# class-map inspection_default
hostname(config-cmap)# match default-inspection-traffic
hostname(config)# policy-map global_policy
hostname(config-pmap)# class inspection_default
hostname(config-pmap-c)# inspect skinny skinny-map
hostname(config)# service-policy global_policy global
 
   

Verifying and Monitoring SCCP Inspection

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 ASASM. 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.

hostname# show skinny
        LOCAL                   FOREIGN                 STATE
---------------------------------------------------------------
1       10.0.0.11/52238         172.18.1.33/2000                1
  MEDIA 10.0.0.11/22948         172.18.1.22/20798
2       10.0.0.22/52232         172.18.1.33/2000                1
  MEDIA 10.0.0.22/20798         172.18.1.11/22948
 
   

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:

hostname# show xlate debug
2 in use, 2 most used
Flags:  D - DNS, d - dump, I - identity, i - inside, n - no random,
        r - portmap, s - static
NAT from inside:10.0.0.11 to outside:172.18.1.11 flags si idle 0:00:16 timeout 0:05:00
NAT from inside:10.0.0.22 to outside:172.18.1.22 flags si idle 0:00:14 timeout 0:05:00