Inspection for Voice and Video Protocols

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

Limitations for CTIQBE Inspection

Stateful failover of CTIQBE calls is not supported.

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 ASA, calls between these two phones fail.

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

H.323 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.

The following sections describe the H.323 application inspection.

H.323 Inspection Overview

H.323 inspection provides support for H.323 compliant applications such as Cisco CallManager. 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:

  • 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 ASA uses an ASN.1 decoder to decode the H.323 messages.

  • Dynamically allocate the negotiated H.245 and RTP/RTCP connections. The H.225 connection can also be dynamically allocated when using RAS.

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 ASA dynamically allocates the H.245 connection based on the inspection of the H.225 messages. 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 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.

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 in the Configuration > Firewall > Advanced > Global Timeouts pane.


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.

H.239 Support in H.245 Messages

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.

Limitations for H.323 Inspection

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:

  • PAT is supported except for extended PAT or per-session PAT.

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

  • Not supported with NAT between same-security-level interfaces.

  • Not supported with NAT64.

  • NAT with H.323 inspection is not compatible with NAT when done directly on the endpoints. If you perform NAT on the endpoints, disable H.323 inspection.

Configure H.323 Inspection Policy Map

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.

You can optionally create a H.323 inspection class map to define the traffic class for H.323 inspection. The other option is to define the traffic classes directly in the H.323 inspection policy map. The difference between creating a class map and defining the traffic match directly in the inspection map is that you can create more complex match criteria and you can reuse class maps. Although this procedure explains inspection maps, the matching criteria used in class maps are the same as those explained in the step relating to the Inspection tab. You can configure H.323 class maps by selecting Configuration > Firewall > Objects > Class Maps > H.323, or by creating them while configuring the inspection map.


Tip

You can configure inspection maps while creating service policies, in addition to the procedure explained below. The contents of the map are the same regardless of how you create it.

Before you begin

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.

Procedure

Step 1

Choose Configuration > Firewall > Objects > Inspect Maps > H.323.

Step 2

Do one of the following:

  • Click Add to add a new map.

  • Select a map to view its contents. You can change the security level directly, or click Customize to edit the map. The remainder of the procedure assumes you are customizing or adding a map.

Step 3

For new maps, enter a name (up to 40 characters) and description. When editing a map, you can change the description only.

Step 4

In the Security Level view of the H.323 Inspect Map dialog box, select the level that best matches your desired configuration. The default level is Low.

If one of the preset levels matches your requirements, you are now done. Just click OK, skip the rest of this procedure, and use the map in a service policy rule for H.323 inspection.

Tip

 

The Phone Number Filtering button is a shortcut to configure called or calling party inspection, which is explained later in this procedure.

Step 5

If you need to customize the settings further, click Details, and do the following:

  1. Click the State Checking tab and choose whether to enable state transition checking of RAS and H.225 messages.

    You can also check RCF messages and open pinholes for call signal addresses present in RRQ messages, which enables call setup between H.323 endpoints when the Gatekeeper is inside the network. Use this option 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.

  2. Click the Call Attributes tab and choose whether to enforce a call duration limit (maximum is 1193 hours) or to enforce the presence of calling and called party numbers during call setup.

    You an also allow H.225 FACILITY messages to arrive before H.225 SETUP messages in accordance to H.460.18. If you encounter call setup issues, where connections are being closed before being completed when using H.323/H.225, select this option to allow early messages. Also, ensure that you enable inspection for both H.323 RAS and H.225 (they are both enabled by default).

  3. Click the Tunneling and Protocol Conformance tab and choose whether check for H.245 tunneling; you can either drop the connection or log it.

    You can also choose whether to check RTP packets that are flowing on the pinholes for protocol conformance. If you check for conformance, you can also choose whether to limit the payload to audio or video, based on the signaling exchange.

Step 6

If necessary, click the HSI Group Parameters tab and define the HSI groups.

  1. Do any of the following:

    • Click Add to add a new group.

    • Select an existing group and click Edit.

  2. Specify the group ID (from 0 to 2147483647) and the IP address of the HSI.

  3. To add an endpoint to the HSI group, enter the IP address, select the interface through which the endpoint is connected to the ASA, and click Add>>. Remove any endpoints that are no longer needed. You can have up to 10 endpoints per group.

  4. Click OK to add the group. Repeat the process as needed.

Step 7

Click the Inspections tab and define the specific inspections you want to implement based on traffic characteristics.

You can define traffic matching criteria based on H.323 class maps, by configuring matches directly in the inspection map, or both.

  1. Do any of the following:

    • Click Add to add a new criterion.

    • Select an existing criterion and click Edit.

  2. Choose Single Match to define the criterion directly, or Multiple Match, in which case you select the H.323 class map that defines the criteria.

  3. If you are defining the criterion here, choose the match type for the criteria: Match (traffic must match the criterion) or No Match (traffic must not match the criterion). Then, configure the criterion as follows:

    • Called Party—Match the H.323 called party against the selected regular expression or regular expression class.

    • Calling Party—Match the H.323 calling party against the selected regular expression or regular expression class.

    • Media Type—Match the media type: audio, video, or data.

  4. Choose the action to take for matching traffic. For calling or called party matching, you can drop the packet, drop the connection, or reset the connection. For media type matching, the action is always to drop the packet; you can enable logging for this action.

  5. Click OK to add the inspection. Repeat the process as needed.

Step 8

Click OK in the H.323 Inspect Map dialog box.

You can now use the inspection map in an H.323 inspection service policy.

What to do next

You can now configure an inspection policy to use the map. See Configure Application Layer Protocol Inspection.

MGCP Inspection

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.

The following sections describe MGCP application inspection.

MGCP Inspection Overview

MGCP is 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.

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

  • Gateways usually listen to UDP port 2427 to receive commands from the call agent.

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


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.

Configure an MGCP Inspection Policy Map

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.

Procedure

Step 1

Choose Configuration > Firewall > Objects > Inspect Maps > MGCP.

Step 2

Do one of the following:

  • Click Add to add a new map.

  • Select a map and click Edit.

Step 3

For new maps, enter a name (up to 40 characters) and description. When editing a map, you can change the description only.

Step 4

(Optional) Click the Command Queue tab and specify the maximum number of commands allowed in the MGCP command queue. The default is 200, the allowed range is 1 to 2147483647.

Step 5

Click the Gateways and Call Agents tab and configure the groups of gateways and call agents for the map.

  1. Click Add to create a new group, or select a group and click Edit.

  2. Enter the Group ID of the call agent group. A call agent group associates one or more call agents with one or more MGCP media gateways. The valid range is from 0 to 2147483647.

  3. Add the IP addresses of the media gateways that are controlled by the associated call agents to the group by entering them in Gateway to Be Added and clicking Add>>. Delete any gateways that are no longer used.

    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. Normally, a gateway sends commands to the default MGCP port for call agents, UDP 2727.

  4. Add the IP addresses of the call agents that control the MGCP media gateways by entering them in Call Agent to Be Added and clicking Add>>. Delete any agents that are no longer needed.

    Normally, a call agent sends commands to the default MGCP port for gateways, UDP 2427.

  5. Click OK in the MGCP Group dialog box. Repeat the process to add other groups as needed.

Step 6

Click OK in the MGCP Inspect Map dialog box.

You can now use the inspection map in an MGCP inspection service policy.

What to do next

You can now configure an inspection policy to use the map. See Configure Application Layer Protocol Inspection.

RTSP Inspection

RTSP inspection is enabled by default. You need to configure it only if you want non-default processing. The following sections describe RTSP application inspection.

RTSP Inspection Overview

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.

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.

RealPlayer Configuration Requirements

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

Limitations for RSTP Inspection

The following restrictions apply to the RSTP inspection.

  • The ASA does not support multicast RTSP or RTSP messages over UDP.

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

  • The ASA cannot perform NAT on RTSP messages because the embedded IP addresses are contained in the SDP files as part of HTTP or RTSP messages. Packets could be fragmented and the ASA cannot perform NAT on fragmented packets.

  • With Cisco IP/TV, the number of translates the ASA 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.

Configure RTSP Inspection Policy Map

You can create an RTSP inspection policy map to customize RTSP inspection actions if the default inspection behavior is not sufficient for your network.

You can optionally create a RTSP inspection class map to define the traffic class for RTSP inspection. The other option is to define the traffic classes directly in the RTSP inspection policy map. The difference between creating a class map and defining the traffic match directly in the inspection map is that you can create more complex match criteria and you can reuse class maps. Although this procedure explains inspection maps, the matching criteria used in class maps are the same as those explained in the step relating to the Inspection tab. You can configure RTSP class maps by selecting Configuration > Firewall > Objects > Class Maps > RTSP, or by creating them while configuring the inspection map.


Tip

You can configure inspection maps while creating service policies, in addition to the procedure explained below. The contents of the map are the same regardless of how you create it.

Before you begin

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.

Procedure

Step 1

Choose Configuration > Firewall > Objects > Inspect Maps > RTSP.

Step 2

Do one of the following:

  • Click Add to add a new map.

  • Select a map to and click Edit.

Step 3

For new maps, enter a name (up to 40 characters) and description. When editing a map, you can change the description only.

Step 4

Click the Parameters tab and configure the desired options:

  • Enforce Reserve Port Protection—Whether to restrict the use of reserved ports during media port negotiation.

  • Maximum URL Length—The maximum length of the URL allowed in the message, 0 to 6000.

Step 5

Click the Inspections tab and define the specific inspections you want to implement based on traffic characteristics.

You can define traffic matching criteria based on RTSP class maps, by configuring matches directly in the inspection map, or both.

  1. Do any of the following:

    • Click Add to add a new criterion.

    • Select an existing criterion and click Edit.

  2. Choose Single Match to define the criterion directly, or Multiple Match, in which case you select the RTSP class map that defines the criteria.

  3. If you are defining the criterion here, choose the match type for the criteria: Match (traffic must match the criterion) or No Match (traffic must not match the criterion). For example, if No Match is selected on the string “example.com,” then any traffic that contains “example.com” is excluded from the class map. Then, configure the criterion as follows:

    • URL Filter—Match the URL against the selected regular expression or regular expression class.

    • Request Method—Match the request method: announce, describe, get_parameter, options, pause, play, record, redirect, setup, set_parameters, teardown.

  4. Choose the action to take for matching traffic. For URL matching, you can drop the connection or log it, and you can enable logging of dropped connections. For Request Method matches, you can apply a rate limit in packets per second.

  5. Click OK to add the inspection. Repeat the process as needed.

Step 6

Click OK in the RTSP Inspect Map dialog box.

You can now use the inspection map in an RTSP inspection service policy.

What to do next

You can now configure an inspection policy to use the map. See Configure Application Layer Protocol Inspection.

SIP Inspection

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

  • SIP: Session Initiation Protocol, RFC 3261

  • SDP: Session Description Protocol, RFC 2327

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.

Instant Messaging (IM) applications also use SIP extensions (defined in RFC 3428) and SIP-specific event notifications (RFC 3265). After users initiate a chat session (registration/subscription), the IM applications use the MESSAGE/INFO methods and 202 Accept responses when users chat with each other. 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

SIP inspection supports the Chat feature only. Whiteboard, File Transfer, and Application Sharing are not supported. RTC Client 5.0 is not supported.

Limitations for SIP Inspection

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.

If you find that SIP phones are not connecting to the call manager, you can try increasing the maximum number of unprocessed TCP segments in the CLI using the following command: sysopt connection tcp-max-unprocessed-seg 6-24 . The default is 6, so try a higher number.

SIP inspection does not support the T.38 MIME Internet Facsimile Protocol(IFP). SIP inspection drops SIP invitations that use the T.38 MIME audio sub-type. If you need to allow this type, disable SIP inspection and write an access control rule that allows the RTP streams.

NAT Limitations for SIP Inspection

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.

Do not configure NAT or PAT for interfaces with the same, or lower (source) to higher (destination), security levels. This configuration is not supported.

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 ASA, 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. Because PAT needs a port to translate, the translation fails.

  • When using PAT, any SIP header field which contains an internal IP address without a port might not be translated and hence the internal IP address will be leaked outside. If you want to avoid this leakage, configure NAT instead of PAT.

  • If you configure SIP inspection for a targeted traffic class (that is, not the inspection_default traffic class), ensure that you use a bi-directional ACL and that you specify the 5060 destination port only. Otherwise, you might have NAT problems where the IP address in the SIP header is not translated even though the IP packet is correctly translated.

Default SIP Inspection

SIP inspection is enabled by default using the default inspection map, which includes the following:

  • SIP instant messaging (IM) extensions: Enabled.

  • Non-SIP traffic on SIP port: Dropped.

  • Hide server’s and endpoint’s IP addresses: Disabled.

  • Mask software version and non-SIP URIs: Disabled.

  • Ensure that the number of hops to destination is greater than 0: Enabled.

  • RTP conformance: Not enforced.

  • SIP conformance: Do not perform state checking and header validation.

Also note that inspection of encrypted traffic is not enabled. You must configure a TLS proxy to inspect encrypted traffic.

Configure SIP Inspection Policy Map

You can create a SIP inspection policy map to customize SIP inspection actions if the default inspection behavior is not sufficient for your network.

You can optionally create a SIP inspection class map to define the traffic class for SIP inspection. The other option is to define the traffic classes directly in the SIP inspection policy map. The difference between creating a class map and defining the traffic match directly in the inspection map is that you can create more complex match criteria and you can reuse class maps. Although this procedure explains inspection maps, the matching criteria used in class maps are the same as those explained in the step relating to the Inspection tab. You can configure SIP class maps by selecting Configuration > Firewall > Objects > Class Maps > SIP, or by creating them while configuring the inspection map.


Tip

You can configure inspection maps while creating service policies, in addition to the procedure explained below. The contents of the map are the same regardless of how you create it.

Before you begin

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.

Procedure

Step 1

Choose Configuration > Firewall > Objects > Inspect Maps > SIP.

Step 2

Do one of the following:

  • Click Add to add a new map.

  • Select a map to view its contents. You can change the security level directly, or click Customize to edit the map. The remainder of the procedure assumes you are customizing or adding a map.

Step 3

For new maps, enter a name (up to 40 characters) and description. When editing a map, you can change the description only.

Step 4

In the Security Level view of the SIP Inspect Map dialog box, select the level that best matches your desired configuration. The default level is Low.

If one of the preset levels matches your requirements, you are now done. Just click OK, skip the rest of this procedure, and use the map in a service policy rule for SIP inspection.

Step 5

If you need to customize the settings further, click Details, and do the following:

  1. Click the Filtering tab and choose whether to enable SIP instant messaging (IM) extensions or to permit non-SIP traffic on the SIP port.

  2. Click the IP Address Privacy tab and choose whether to hide the server and endpoint IP addresses.

  3. Click the Hop Count tab and choose whether to ensure that the number of hops to the destination is greater than 0. This checks the value of the Max-Forwards header, which cannot be zero before reaching the destination. You must also choose the action to take for non-conforming traffic (drop packet, drop connection, reset, or log) and whether to enable or disable logging.

  4. Click the RTP Conformance tab and choose whether to check RTP packets that are flowing on the pinholes for protocol conformance. If you check for conformance, you can also choose whether to limit the payload to audio or video, based on the signaling exchange.

  5. Click the SIP Conformance tab and choose whether to enable state transition checking and strict validation of header fields. For each option you choose, select the action to take for non-conforming traffic (drop packet, drop connection, reset, or log) and whether to enable or disable logging.

  6. Click the Field Masking tab and choose whether to inspect non-SIP URIs in Alert-Info and Call-Info headers and to inspect the server’s and endpoint’s software version in the User-Agent and Server headers. For each option you choose, select the action to take (mask or log) and whether to enable or disable logging.

  7. Click the TVS Server tab and identify the Trust Verification Services servers, which enable Cisco Unified IP Phones to authenticate application servers during HTTPS establishment. You can identify up to four servers; enter their IP addresses separated by commas. SIP inspection opens pinholes to each server for each registered phone, and the phone decides which to use.

    Configure the Trust Verification Services server on the CUCM server. If the configuration uses a non-default port, enter the port number (in the range 1026 to 32768). The default port is 2445.

Step 6

Click the Inspections tab and define the specific inspections you want to implement based on traffic characteristics.

You can define traffic matching criteria based on SIP class maps, by configuring matches directly in the inspection map, or both.

  1. Do any of the following:

    • Click Add to add a new criterion.

    • Select an existing criterion and click Edit.

  2. Choose Single Match to define the criterion directly, or Multiple Match, in which case you select the SIP class map that defines the criteria.

  3. If you are defining the criterion here, choose the match type for the criteria: Match (traffic must match the criterion) or No Match (traffic must not match the criterion). For example, if No Match is selected on the string “example.com,” then any traffic that contains “example.com” is excluded from the class map. Then, configure the criterion as follows:

    • Called Party—Match the called party, as specified in the To header, against the selected regular expression or regular expression class.

    • Calling Party—Match the calling party, as specified in the From header, against the selected regular expression or regular expression class.

    • Content Length—Match a SIP content header of a length greater than specified, between 0 and 65536 bytes.

    • Content Type—Match the Content Type header, either the SDP type or a type that matches the selected regular expression or regular expression class.

    • IM Subscriber—Match the SIP IM subscriber against the selected regular expression or regular expression class.

    • Message Path—Match the SIP Via header against the selected regular expression or regular expression class.

    • Request Method—Match the SIP request method: ack, bye, cancel, info, invite, message, notify, options, prack, refer, register, subscribe, unknown, update.

    • Third-Party Registration—Match the requester of a third-party registration against the selected regular expression or regular expression class.

    • URI Length—Match a URI in the SIP headers of the selected type (SIP or TEL) that is greater than the length specified, between 0 and 65536 bytes.

  4. Choose the action to take for matching traffic (drop packet, drop connection, reset, log) and whether to enable or disable logging. For Request Method matches to “invite” and “register,” you can also apply a rate limit in packets per second.

  5. Click OK to add the inspection. Repeat the process as needed.

Step 7

Click OK in the SIP Inspect Map dialog box.

You can now use the inspection map in a SIP inspection service policy.

What to do next

You can now configure an inspection policy to use the map. See Configure Application Layer Protocol Inspection.

Skinny (SCCP) Inspection

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.

The following sections describe SCCP application 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 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.

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

Limitations for SCCP Inspection

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

Default SCCP Inspection

SCCP inspection is enabled by default using these defaults:

  • Registration: Not enforced.

  • Maximum message ID: 0x181.

  • Minimum prefix length: 4

  • Media timeout: 00:05:00

  • Signaling timeout: 01:00:00.

  • RTP conformance: Not enforced.

Configure a Skinny (SCCP) Inspection Policy Map

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.

Procedure

Step 1

Choose Configuration > Firewall > Objects > Inspect Maps > SCCP (Skinny).

Step 2

Do one of the following:

  • Click Add to add a new map.

  • Select a map to view its contents. You can change the security level directly, or click Customize to edit the map. The remainder of the procedure assumes you are customizing or adding a map.

Step 3

For new maps, enter a name (up to 40 characters) and description. When editing a map, you can change the description only.

Step 4

In the Security Level view of the SCCP (Skinny) Inspect Map dialog box, select the level that best matches your desired configuration. The default level is Low.

If one of the preset levels matches your requirements, you are now done. Just click OK, skip the rest of this procedure, and use the map in a service policy rule for SCCP inspection.

Step 5

If you need to customize the settings further, click Details, and do the following:

  1. Click the Parameters tab and choose among the following options:

    • Enforce endpoint registration—Whether Skinny endpoints must register before placing or receiving calls.

    • Maximum Message ID—The maximum SCCP station message ID allowed. The default maximum is 0x181. The hex number can be 0x0 to 0xffff.

    • SCCP Prefix Length—The maximum and minimum SCCP prefix length. The default minimum is 4; there is no default maximum.

    • Timeouts—Whether to set timeouts for media and signaling connections, and the value of those timeouts. The defaults are 5 minutes for media, 1 hour for signaling.

  2. Click the RTP Conformance tab and choose whether to check RTP packets that are flowing on the pinholes for protocol conformance. If you check for conformance, you can also choose whether to limit the payload to audio or video, based on the signaling exchange.

Step 6

(Optional) Click the Message ID Filtering tab to identify traffic to drop based on the station message ID field in SCCP messages.

  1. Do any of the following:

    • Click Add to add a new criterion.

    • Select an existing criterion and click Edit.

  2. Choose the match type for the criteria: Match (traffic must match the criterion) or No Match (traffic must not match the criterion).

  3. In the Value fields, identify the traffic based on the station message ID value in hexadecimal, from 0x0 to 0xffff. Either enter the value for a single message ID, or enter the beginning and ending value for a range of IDs.

  4. Choose whether to enable or disable logging. The action is always to drop the packet.

  5. Click OK to add the filter. Repeat the process as needed.

Step 7

Click OK in the SCCP (Skinny) Inspect Map dialog box.

You can now use the inspection map in an SCCP inspection service policy.

What to do next

You can now configure an inspection policy to use the map. See Configure Application Layer Protocol Inspection.

STUN Inspection

Session Traversal Utilities for NAT (STUN), defined in RFC 5389, is used by WebRTC clients for browser-based real-time communications so that plug-ins are not necessary. WebRTC clients often use cloud STUN servers to learn their public IP addresses and ports. WebRTC uses Interactive Connectivity Establishment (ICE, RFC 5245) to verify connectivity between clients. These clients typically use UDP, although they can also use TCP or other protocols.

Because firewalls often block outgoing UDP traffic, WebRTC products such as Cisco Spark can have problems completing connections. STUN inspection opens pinholes for STUN endpoints, and enforces basic STUN and ICE compliance, to allow communications for clients if the connectivity check is acknowledged by both sides. Thus, you can avoid opening new ports in your access rules to enable these applications.

When you enable STUN inspection on the default inspection class, TCP/UDP port 3478 is watched for STUN traffic. The inspection supports IPv4 addresses and TCP/UDP only.

There are some NAT limitations for STUN inspection. For WebRTC traffic, static NAT/PAT44 are supported. Cisco Spark can support additional types of NAT, because Spark does not require pinholes. You can also use NAT/PAT64, including dynamic NAT/PAT, with Cisco Spark.

STUN inspection is supported in failover and cluster modes, as pinholes are replicated. However, the transaction ID is not replicated among nodes. In the case where a node fails after receiving a STUN Request and another node received the STUN Response, the STUN Response will be dropped.


Note

STUN inspection uses transaction IDs to match requests and responses. If you use debug to troubleshoot connection drops, note that the system changes the format (endianness) of the IDs for the debug output, so they do not compare directly to those you might see in a pcap.

For information on enabling STUN inspection, see Configure Application Layer Protocol Inspection.

History for Voice and Video Protocol Inspection

Feature Name

Releases

Feature Information

SIP, SCCP, and TLS Proxy support for IPv6

9.3(1)

You can now inspect IPv6 traffic when using SIP, SCCP, and TLS Proxy (using SIP or SCCP).

We did not modify any ASDM screens.

SIP support for Trust Verification Services, NAT66, CUCM 10.5, and model 8831 phones.

9.3(2)

You can now configure Trust Verification Services servers in SIP inspection. You can also use NAT66. SIP inspection has been tested with CUCM 10.5.

We added Trust Verification Services Server support to the SIP inspection policy map.

Improved SIP inspection performance on multiple core ASA.

9.4(1)

If you have multiple SIP signaling flows going through an ASA with multiple cores, SIP inspection performance has been improved. However, you will not see improved performance if you are using a TLS, phone, or IME proxy.

We did not modify any ASDM screens.

SIP inspection support in ASA clustering

9.4(1)

You can now configure SIP inspection on the ASA cluster. A control flow can be created on any unit (due to load balancing), but its child data flows must reside on the same unit. TLS Proxy configuration is not supported.

We did not modify any screens.

SIP inspection support for Phone Proxy and UC-IME Proxy was removed.

9.4(1)

You can no longer use Phone Proxy or UC-IME Proxy when configuring SIP inspection. Use TLS Proxy to inspect encrypted traffic.

We removed Phone Proxy and UC-IME Proxy from the Select SIP Inspect Map service policy dialog box.

H.323 inspection support for the H.255 FACILITY message coming before the H.225 SETUP message for H.460.18 compatibility.

9.6(1)

You can now configure an H.323 inspection policy map to allow for H.225 FACILITY messages to come before the H.225 SETUP message, which can happen when endpoints comply with H.460.18.

We added an option to the Call Attributes tab in the H.323 inspection policy map.

Session Traversal Utilities for NAT (STUN) inspection.

9.6(2)

You can now inspect STUN traffic for WebRTC applications including Cisco Spark. Inspection opens pinholes required for return traffic.

We added an option to the Rule Actions > Protocol Inspection tab of the Add/Edit Service Policy dialog box.

Support for TLSv1.2 in TLS proxy and Cisco Unified Communications Manager 10.5.2.

9.7(1)

You can now use TLSv1.2 with TLS proxy for encrypted SIP or SCCP inspection with the Cisco Unified Communications Manager 10.5.2. The TLS proxy supports the additional TLSv1.2 cipher suites added as part of the client cipher-suite command.

We did not modify any screens.

TLS proxy deprecated for SCCP (Skinny) inspection.

9.13(1)

The tls-proxy keyword, and support for SCCP/Skinny encrypted inspection, was deprecated. The keyword will be removed from the inspect skinny command in a future release.

TLS proxy support eliminated for SCCP (Skinny) inspection.

9.14(1)

The tls-proxy keyword, and support for SCCP/Skinny encrypted inspection, was removed.

The default SIP inspection policy map drops non-SIP traffic.

9.16(1)

For SIP-inspected traffic, the default is now to drop non-SIP traffic. The previous default was to allow non-SIP traffic on ports inspected for SIP.

We changed the default SIP policy map to include the no traffic-non-sip command.