Configuring Cisco Intercompany Media Engine Proxy

This chapter describes how to configure the ASA for Cisco Intercompany Media Engine Proxy.

This chapter includes the following sections:

Information About Cisco Intercompany Media Engine Proxy

This section includes the following topics:

Features of Cisco Intercompany Media Engine Proxy

Cisco Intercompany Media Engine enables companies to interconnect on-demand, over the Internet with advanced features made available by VoIP technologies. Cisco Intercompany Media Engine allows for business-to-business federation between Cisco Unified Communications Manager clusters in different enterprises by utilizing peer-to-peer, security, and SIP protocols to create dynamic SIP trunks between businesses. A collection of enterprises work together to end up looking like one large business with inter-cluster trunks between them.

The adaptive security appliance applies its existing TLS proxy, SIP Application Layer Gateway (ALG), and SIP verification features to the functioning of Cisco Intercompany Media Engine.

Cisco Intercompany Media Engine has the following key features:

  • Works with existing phone numbers: Cisco Intercompany Media Engine works with the phone numbers an enterprise currently has and does not require an enterprise to learn new numbers or change providers to use Cisco Intercompany Media Engine.
  • Works with existing IP phones: Cisco Intercompany Media Engine works with the existing IP phones within an enterprise. However, the feature set in business-to-business calls is limited to the capabilities of the IP phones.
  • Does not require purchasing new services: Cisco Intercompany Media Engine does not require any new services from any service providers. Customers continue to use the PSTN connectivity they have and the Internet connectivity they have today. Cisco Intercompany Media Engine gradually moves calls off the PSTN and onto the Internet.
  • Provides a full Cisco Unified Communications experience: Because Cisco Intercompany Media Engine creates inter-cluster SIP trunks between enterprises, any Unified Communication features that work over the SIP trunk and only require a SIP trunk work with the Cisco Intercompany Media Engine, thus providing a Unified Communication experience across enterprises.
  • Works on the Internet: Cisco Intercompany Media Engine was designed to work on the Internet. It can also work on managed extranets.
  • Provides worldwide reach: Cisco Intercompany Media Engine can connect to any enterprise anywhere in the world, as long as the enterprise is running Cisco Intercompany Media Engine technology. There are no regional limitations. This is because Cisco Intercompany Media Engine utilizes two networks that both have worldwide reach—the Internet and the PSTN.
  • Allows for unlimited scale: Cisco Intercompany Media Engine can work with any number of enterprises.
  • Is self-learning: The system is primarily self-learning. Customers do not have to enter information about other businesses: no phone prefixes, no IP address, no ports, no domain names, nor certificates. Customers need to configure information about their own networks, and provide policy information if they want to limit the scope of Cisco Intercompany Media Engine.
  • Is secure: Cisco Intercompany Media Engine is secure, utilizing a large number of different technologies to accomplish this security.
  • Includes anti-spam: Cisco Intercompany Media Engine prevents people from setting up software on the Internet that spams enterprises with phone calls. It provides an extremely high barrier to entry.
  • Provides for QoS management: Cisco Intercompany Media Engine provides features that help customers manage the QoS on the Internet, such as the ability to monitor QoS of the RTP traffic in real-time and fallback to PSTN automatically if problems arise.

How the UC-IME Works with the PSTN and the Internet

The Cisco Intercompany Media Engine utilizes two networks that both have worldwide reach—the Internet and the PSTN. Customers continue to use the PSTN connectivity they have. The Cisco Intercompany Media Engine gradually moves calls off the PSTN and onto the Internet. However, if QoS problems arise, the Cisco Intercompany Media Engine Proxy monitors QoS of the RTP traffic in real-time and fallbacks to PSTN automatically.

The Cisco Intercompany Media Engine uses information from PSTN calls to validate that the terminating side owns the number that the originated side had called. After the PSTN call terminates, the enterprises involved in the call send information about the call to their Cisco IME server. The Cisco IME server on the originating side validates the call.

On successful verification, the terminating side creates a ticket that grants permission to the call originator to make a Cisco IME call to a specific number. See Tickets and Passwords for information.

Tickets and Passwords

Cisco Intercompany Media Engine utilizes tickets and passwords to provide enterprise verification. Verification through the creation of tickets ensures an enterprise is not subject to denial-of-service (DOS) attacks from the Internet or endless VoIP spam calls. Ticket verification prevents spam and DOS attacks because it introduces a cost to the VoIP caller; namely, the cost of a PSTN call. A malicious user cannot set up just an open source asterisk PBX on the Internet and begin launching SIP calls into an enterprise running Cisco Intercompany Media Engine. Having the Cisco Intercompany Media Engine Proxy verify tickets allows incoming calls from a particular enterprise to a particular number only when that particular enterprise has previously called that phone number on the PSTN.

To send a spam VoIP call to every phone within an enterprise, an organization would have to purchase the Cisco Intercompany Media Engine and Cisco Unified Communications Manager and have called each phone number within the enterprise over the PSTN and completed each call successfully. Only then can it launch a VoIP call to each number.

The Cisco Intercompany Media Engine server creates tickets and the ASA validates them. The ASA and Cisco Intercompany Media Engine server share a password that is configured so that the ASA detects the ticket was created by a trusted Cisco Intercompany Media Engine server. The ticket contains information that indicates that the enterprise is authorized to call specific phone numbers at the target enterprise. See Figure 20-1 for the ticket verification process and how it operates between the originating and terminating-call enterprises.


Note Because the initial calls are over the PSTN, they are subject to any national regulations regarding telemarketing calling. For example, within the United States, they would be subject to the national do-not-call registry.


Figure 20-1 Ticket Verification Process with Cisco Intercompany Media Engine

 

As illustrated in Figure 20-1. Enterprise B makes a PSTN call to enterprise A. That call completes successfully. Later, Enterprise B Cisco Intercompany Media Engine server initiates validation procedures with Enterprise A. These validation procedures succeed. During the validation handshake, Enterprise B sends Enterprise A its domain name. Enterprise A verifies that this domain name is not on the blacklisted set of domains. Assuming it is not, Enterprise A creates a ticket.

Subsequently, someone in Enterprise B calls that number again. That call setup message from Enterprise B to Enterprise A includes the ticket in the X-Cisco-UC-IME-Ticket header field in the SIP INVITE message. This message arrives at the Enterprise A ASA. The ASA verifies the signature and computes several checks on the ticket to make sure it is valid. If the ticket is valid, the ASA forwards the request to Cisco UCM (including the ticket). Because the ASA drops requests that lack a valid ticket, unauthorized calls are never received by Cisco UCM.

The ticket password is a 128 bit random key, which can be thought of as a shared password between the adaptive security appliance and the Cisco Intercompany Media Engine server. This password is generated by the Cisco Intercompany Media Engine server and is used by a Cisco Intercompany Media Engine SIP trunk to generate a ticket to allow a call to be made between Cisco Intercompany Media Engine SIP trunks. A ticket is a signed object that contains a number of fields that grant permission to the calling domain to make a Cisco Intercompany Media Engine call to a specific number. The ticket is signed by the ticket password.

The Cisco Intercompany Media Engine also required that you configure an epoch for the password. The epoch contains an integer that updates each time that the password is changed. When the proxy is configured the first time and a password entered for the first time, enter 1 for the epoch integer. Each time you change the password, increment the epoch to indicate the new password. You must increment the epoch value each time your change the password.

Typically, you increment the epoch sequentially; however, the ASA allows you to choose any value when you update the epoch. If you change the epoch value, the tickets in use at remote enterprises become invalid. The incoming calls from the remote enterprises fallback to the PSTN until the terminating enterprise reissues tickets with the new epoch value and password.

The epoch and password that you configure on the ASA must match the epoch and password configured on the Cisco Intercompany Media Engine server. If you change the password or epoch on the ASA, you must update them on the Cisco Intercompany Media Engine server. See the Cisco Intercompany Media Engine server documentation for information.

Call Fallback to the PSTN

Cisco Intercompany Media Engine provides features that manage the QoS on the Internet, such as the ability to monitor QoS of the RTP traffic in real-time and fallback to PSTN automatically if problems arise. Call fallback from Internet VoIP calls to the public switched telephone network (PSTN) can occur for two reasons changes in connection quality and signal failure for the Cisco Intercompany Media Engine.

Internet connections can vary wildly in their quality and vary over time. Therefore, even if a call is sent over VoIP because the quality of the connection was good, the connection quality might worsen mid-call. To ensure an overall good experience for the end user, Cisco Intercompany Media Engine attempts to perform a mid-call fallback.

Performing a mid-call fallback requires the adaptive security appliance to monitor the RTP packets coming from the Internet and send information into an RTP Monitoring Algorithm (RMA) API, which will indicates to the adaptive security appliance whether fallback is required. If fallback is required, the adaptive security appliance sends a REFER message to Cisco UCM to tell it that it needs to fallback the call to PSTN.

The TLS signaling connections from the Cisco UCM are terminated on the adaptive security appliance and a TCP or TLS connection is initiated to the Cisco UCM. SRTP (media) sent from external IP phones to the internal network IP phone via the adaptive security appliance is converted to RTP. The adaptive security appliance inserts itself into the media path by modifying the SIP signaling messages that are sent over the SIP trunk between Cisco UCMs. TLS (signaling) and SRTP are always terminated on the adaptive security appliance.

If signaling problems occur, the call falls back to the PSTN; however, the Cisco UCM initiates the PSTN fall back and the adaptive security appliance does not send REFER message.

Architecture and Deployment Scenarios for Cisco Intercompany Media Engine

This section includes the following topics:

Architecture

Within the enterprise, Cisco Intercompany Media Engine is deployed with the following components for the following purposes:

  • The adaptive security appliance—Enabled with the Cisco Intercompany Media Engine Proxy, provides perimeter security functions and inspects SIP signaling between SIP trunks.
  • Cisco Intercompany Media Engine (UC-IME) server— Located in the DMZ, provides an automated provisioning service by learning new VoIP routes to particular phone numbers, and recording those routes in Cisco UCM. The Cisco Intercompany Media Engine server does not perform call control.
  • Cisco Unified Communications Manager (Cisco UCM)—Responsible for call control and processing. Cisco UCM connects to the Cisco Intercompany Media Engine server by using the Access Protocol to publish and exchange updates. The architecture can consist of a single Cisco UCM or a Cisco UCM cluster within the enterprise.
  • Cisco Intercompany Media Engine (UC-IME) Bootstrap server—Provides a certificate required admission onto the public peer-to-peer network for Cisco Intercompany Media Engine.

Figure 20-2 illustrates the components of the Cisco Intercompany Media Engine in a basic deployment.

Figure 20-2 Cisco Intercompany Media Engine Architecture in a Basic Deployment

 

Basic Deployment

In a basic deployment, the Cisco Intercompany Media Engine Proxy sits in-line with the Internet firewall such that all Internet traffic traverses the adaptive security appliance. In this deployment, a single Cisco UCM or a Cisco UCM cluster is centrally deployed within the enterprise, along with a Cisco Intercompany Media Engine server (and perhaps a backup).

As shown in Figure 20-3, the adaptive security appliance sits on the edge of the enterprise and inspects SIP signaling by creating dynamic SIP trunks between enterprises.

Figure 20-3 Basic Deployment Scenario

 

Off Path Deployment

In an off path deployment, inbound and outbound Cisco Intercompany Media Engine calls pass through an adaptive security appliance enabled with the Cisco Intercompany Media Engine Proxy. The adaptive security appliance is located in the DMZ and is configured to support only the Cisco Intercompany Media Engine traffic (SIP signaling and RTP traffic). Normal Internet facing traffic does not flow through this adaptive security appliance.

For all inbound calls, the signaling is directed to the adaptive security appliance because destined Cisco UCMs are configured with the global IP address on the adaptive security appliance. For outbound calls, the called party could be any IP address on the Internet; therefore, the adaptive security appliance is configured with a mapping service that dynamically provides an internal IP address on the adaptive security appliance for each global IP address of the called party on the Internet.

Cisco UCM sends all outbound calls directly to the mapped internal IP address on the adaptive security appliance instead of the global IP address of the called party on the Internet. The adaptive security appliance then forwards the calls to the global IP address of the called party.

Figure 20-4 illustrates the architecture of the Cisco Intercompany Media Engine in an off path deployment.

Figure 20-4 Off Path Deployment of the Adaptive Security Appliance

 

Licensing for Cisco Intercompany Media Engine

The Cisco Intercompany Media Engine feature supported by the ASA require a Unified Communications Proxy license.

The following table shows the details of the Unified Communications Proxy license:


Note This feature is not available on No Payload Encryption models.


 

Model
License Requirement

All models

Intercompany Media Engine license.

When you enable the Intercompany Media Engine (IME) license, you can use TLS proxy sessions up to the configured TLS proxy limit. If you also have a Unified Communications (UC) license installed that is higher than the default TLS proxy limit, then the ASA sets the limit to be the UC license limit plus an additional number of sessions depending on your model. You can manually configure the TLS proxy limit using the tls-proxy maximum-sessions command. To view the limits of your model, enter the tls-proxy maximum-sessions ? command. If you also install the UC license, then the TLS proxy sessions available for UC are also available for IME sessions. For example, if the configured limit is 1000 TLS proxy sessions, and you purchase a 750-session UC license, then the first 250 IME sessions do not affect the sessions available for UC. If you need more than 250 sessions for IME, then the remaining 750 sessions of the platform limit are used on a first-come, first-served basis by UC and IME.

  • For a license part number ending in “K8”, TLS proxy sessions are limited to 1000.
  • For a license part number ending in “K9”, the TLS proxy limit depends on your configuration and the platform model.

Note K8 and K9 refer to whether the license is restricted for export: K8 is unrestricted, and K9 is restricted.

You might also use SRTP encryption sessions for your connections:

  • For a K8 license, SRTP sessions are limited to 250.
  • For a K9 license, there is no limit.

Note Only calls that require encryption/decryption for media are counted toward the SRTP limit; if passthrough is set for the call, even if both legs are SRTP, they do not count toward the limit.

For more information about licensing, see “Managing Feature Licenses,” in the general operations configuration guide.

Guidelines and Limitations

Context Mode Guidelines

Supported in single context mode only.

Firewall Mode Guidelines

Supported in routed firewall mode only.

IPv6 Guidelines

Does not support IPv6 addresses.

Additional Guidelines and Limitations

Cisco Intercompany Media Engine has the following limitations:

  • Fax is not supported. Fax capability needs to be disabled on the SIP trunk.
  • Stateful failover of Cisco Unified Intercompany Media Engine is not supported. During failover, existing calls traversing the Cisco Intercompany Media Engine Proxy disconnect; however, new calls successfully traverse the proxy after the failover completes.
  • Having Cisco UCMs on more than one of the ASA interfaces is not supported with the Cisco Intercompany Media Engine Proxy. Having the Cisco UCMs on one trusted interface is especially necessary in an off path deployment because the ASA requires that you specify the listening interface for the mapping service and the Cisco UCMs must be connected on one trusted interface.
  • Multipart MIME is not supported.
  • Only existing SIP features and messages are supported.
  • H.264 is not supported.
  • RTCP is not supported. The ASA drops any RTCP traffic sent from the inside interface to the outside interface. The ASA does not convert RTCP traffic from the inside interface into SRTP traffic.
  • The Cisco Intercompany Media Engine Proxy configured on the ASA creates a dynamic SIP trunk for each connection to a remote enterprise. However, you cannot configure a unique subject name for each SIP trunk. The Cisco Intercompany Media Engine Proxy can have only one subject name configured for the proxy.

Additionally, the subject DN you configure for the Cisco Intercompany Media Engine Proxy match the domain name that has been set for the local Cisco UCM.

  • If a service policy rule for the Cisco Intercompany Media Engine Proxy is removed (by using the no service policy command) and reconfigured, the first call traversing the ASA will fail. The call fails over to the PSTN because the Cisco UCM does not know the connections are cleared and tries to use the recently cleared IME SIP trunk for the signaling.

To resolve this issue, you must additionally enter the clear connection all command and restart the ASA. If the failure is due to failover, the connections from the primary ASA are not synchronized to the standby ASA.

  • After the clear connection all command is issued on an ASA enabled with a UC-IME Proxy and the IME call fails over to the PSTN, the next IME call between an originating and terminating SCCP IP phone completes but does not have audio and is dropped after the signaling session is established.

An IME call between SCCP IP phones use the IME SIP trunk in both directions. Namely, the signaling from the calling to called party uses the IME SIP trunk. Then, the called party uses the reverse IME SIP trunk for the return signaling and media exchange. However, this connection is already cleared on the ASA, which causes the IME call to fail.

The next IME call (the third call after the clear connection all command is issued), will be completely successful.


Note This limitation does not apply when the originating and terminating IP phones are configured with SIP.


This limitation occurs because an IME call cannot fall back to the PSTN when there are not enough TLS proxy sessions left to complete the IME call. An IME call between two SCCP IP phones requires the ASA to use two TLS proxy sessions to successfully complete the TLS handshake.

Assume for example, the ASA is configured to have a maximum of 100 TLS proxy sessions and IME calls between SCCP IP phones establish 101 TLS proxy sessions. In this example, the next IME call is initiated successfully by the originating SCCP IP phone but fails after the call is accepted by the terminating SCCP IP phone. The terminating IP phone rings and on answering the call, the call hangs due to an incomplete TLS handshake. The call does not fall back to the PSTN.

Configuring Cisco Intercompany Media Engine Proxy

This section contains the following topics:

Task Flow for Configuring Cisco Intercompany Media Engine

Figure 20-5 provides an example for a basic deployment of the Cisco Intercompany Media Engine. The following tasks include command line examples based on Figure 20-5.

Figure 20-5 Example for Basic (in-line) Deployment Tasks

 


Note Step 1 through Step 8 apply to both basic (in-line) and off path deployments and Step 9 applies only to off path deployment.


To configure a Cisco Intercompany Media Engine for a basic deployment, perform the following tasks.


Step 1 Configure static NAT for Cisco UCM. See Configuring NAT for Cisco Intercompany Media Engine Proxy.

Or

Configure PAT for the UCM server. See Configuring PAT for the Cisco UCM Server.

Step 2 Create ACLs for Cisco Intercompany Media Engine Proxy. See Creating ACLs for Cisco Intercompany Media Engine Proxy.

Step 3 Create the media termination address instance for Cisco Intercompany Media Engine Proxy. See Creating the Media Termination Instance.

Step 4 Create the Cisco Intercompany Media Engine Proxy. See Creating the Cisco Intercompany Media Engine Proxy.

Step 5 Create trustpoints and generate certificates for the Cisco Intercompany Media Engine Proxy. See Creating Trustpoints and Generating Certificates.

Step 6 Create the TLS proxy. See Creating the TLS Proxy.

Step 7 Configure SIP inspection for the Cisco Intercompany Media Engine Proxy. See Enabling SIP Inspection for the Cisco Intercompany Media Engine Proxy.

Step 8 (Optional) Configure TLS within the enterprise. See (Optional) Configuring TLS within the Local Enterprise.

Step 9 (Optional) Configure off path signaling. See (Optional) Configuring Off Path Signaling.


Note You only perform Step 9 when you are configuring the Cisco Intercompany Media Engine Proxy in an off path deployment.



 

Configuring NAT for Cisco Intercompany Media Engine Proxy

To configure auto NAT, you first configure an object; then use the nat command in the object configuration mode.

The example command lines in this task are based on a basic (in-line) deployment. See Figure 20-5 for an illustration explaining the example command lines in this task.

Alternatively, you can configure PAT for the Cisco Intercompany Media Engine Proxy. See Configuring PAT for the Cisco UCM Server.

Figure 20-6 Example for Configuring NAT for a Deployment

 

To configure auto NAT rules for the Cisco UCM server, perform the following steps:

 

 
Command
Purpose

Step 1

hostname(config)# object network name
Examples:
hostname(config)# object network ucm_real_192.168.10.30
hostname(config)# object network ucm_real_192.168.10.31

Configures a network object for the real address of Cisco UCM that you want to translate.

Step 2

hostname(config-network-object)# host ip_address
Examples:
hostname(config-network-object)# host 192.168.10.30
hostname(config-network-object)# host 192.168.10.31

Specifies the real IP address of the Cisco UCM host for the network object.

Step 3

(Optional)

hostname(config-network-object)# description string
Example:
hostname(config-network-object)# description “Cisco UCM Real Address”

Provides a description of the network object.

Step 4

hostname(config-network-object)# exit

Exits from the objects configuration mode.

Step 5

hostname(config)# object network name
Example:
hostname(config)# object network ucm_map_209.165.200.228

Configures a network object for the mapped address of the Cisco UCM.

Step 6

hostname(config-network-object)# host ip_address
Example:
hostname(config-network-object)# host 209.165.200.228

Specifies the mapped IP address of the Cisco UCM host for the network object.

Step 7

(Optional)

hostname(config-network-object)# description string
Example:
hostname(config-network-object)# description “Cisco UCM Mapped Address”

Provides a description of the network object.

Step 8

hostname(config-network-object)# exit

Exits from the objects configuration mode.

Step 9

hostname(config)# nat (inside,outside) source static real_obj mapped_obj
Examples:
hostname(config)# nat (inside,outside) source static ucm_real_192.168.10.30 ucm_209.165.200.228
hostname(config)# nat (inside,outside) source static ucm_real_192.168.10.31 ucm_209.165.200.228

Specifies the address translation on the network objects created in this procedure.

Where real_obj is the name that you created in in this task.

Where mapped_obj is the name that you created in in this task.

What to Do Next

Create the ACLs for the Cisco Intercompany Media Engine Proxy. See Creating ACLs for Cisco Intercompany Media Engine Proxy.

Configuring PAT for the Cisco UCM Server

Perform this task as an alternative to configuring NAT for the Cisco Intercompany Media Engine Proxy.

Figure 20-7 Example for Configuring PAT for a Deployment

 


Note You only perform this step when NAT is not configured for the Cisco UCM server.


To configure PAT for the Cisco UCM server, perform the following steps:

 

 
Command
Purpose

Step 1

hostname(config)# object network name
Examples:
hostname(config)# object network ucm-pat-209.165.200.228

Configures a network object for the outside IP address of Cisco UCM that you want to translate.

Step 2

hostname(config-network-object)# host ip_address
Example:
hostname(config-network-object)# host 209.165.200.228

Specifies the real IP address of the Cisco UCM host for the network object.

Step 3

hostname(config-network-object)# exit

Exits from the objects configuration mode.

Step 4

hostname(config)# object service name
Examples:
hostname(config)# object service tcp_5070
hostname(config)# object service tcp_5071

Creates a service object for the outside Cisco Intercompany Media Engine port.

Step 5

hostname(config-service-object)# tcp source eq port
Examples:
hostname(config-service-object)# tcp source eq 5070
hostname(config-service-object)# tcp source eq 5071

Specifies the port number.

Step 6

hostname(config-service-object)# exit

Exits from the objects configuration mode.

Step 7

hostname(config)# object network name
Examples:
hostname(config)# object network ucm-real-192.168.10.30
hostname(config)# object network ucm-real-192.168.10.31

Configures a network object to represent the real IP address of Cisco UCM.

Step 8

hostname(config-network-object)# host ip_address
Examples:
hostname(config-network-object)# host 192.168.10.30
hostname(config-network-object)# host 192.168.10.31

Specifies the real IP address of the Cisco UCM host for the network object.

Step 9

hostname(config-network-object)# exit

Exits from the objects configuration mode.

Step 10

hostname(config)# object service name
Examples:
hostname(config)# object service tcp_5570
hostname(config)# object service tcp_5571

Creates a service objects for Cisco UCM SIP port.

Step 11

hostname(config-service-object)# tcp source eq port
Example:
hostname(config-service-object)# tcp source eq 5570
hostname(config-service-object)# tcp source eq 5571

Specifies the port number.

Step 12

hostname(config-service-object)# exit

Exits from the objects configuration mode.

Step 13

hostname(config)# nat (inside,outside) source static real_obj mapped_obj service real_port mapped_port
Examples:
hostname(config)# nat (inside,outside) source static ucm-real-192.168.10.30 ucm-pat-209.165.200.228 service tcp_5070 tcp_5570
hostname(config)# nat (inside,outside) source static ucm-real-192.168.10.31 ucm-pat-128.106.254.5 service tcp_5071 tcp_5571

Creates a static mapping for Cisco UCM.

Where real_obj is the name that you created in in this task.

Where mapped_obj is the name that you created in in this task.

Where real_port is the name that you created in in this task.

Where mapped_obj is the name that you created in in this task.

Creating ACLs for Cisco Intercompany Media Engine Proxy

To configure ACLs for the Cisco Intercompany Media Engine Proxy to reach the Cisco UCM server, perform the following steps.

The example command lines in this task are based on a basic (in-line) deployment. See Figure 20-5 for an illustration explaining the example command lines in this task.

 

 
Command
Purpose

Step 1

hostname(config)# access-list id extended permit tcp any host ip_address eq port
Example:
hostname(config)# access-list incoming extended permit tcp any host 192.168.10.30 eq 5070

Adds an Access Control Entry (ACE). An ACL is made up of one or more ACEs with the same ACL ID. This ACE provides access control by allowing incoming access for Cisco Intercompany Media Engine connections on the specified port.

In the ip_address argument, provide the real IP address of Cisco UCM.

Step 2

hostname(config)# access-group access-list in interface interface_name
Example:
hostname(config)# access-group incoming in interface outside

Binds the ACL to an interface.

Step 3

hostname(config)# access-list id extended permit tcp any host ip_address eq port
Example:
hostname(config)# access-list ime-inbound-sip extended permit tcp any host 192.168.10.30 eq 5070

Adds an ACE. This ACE allows the ASA to allow inbound SIP traffic for Cisco Intercompany Media Engine. This entry is used to classify traffic for the class and policy map.

Note The port that you configure here must match the trunk settings configured on Cisco UCM. See the Cisco Unified Communications Manager documentation for information about this configuration setting.

Step 4

hostname(config)# access-list id extended permit tcp ip_address mask any range range
Example:
hostname(config)# access-list ime-outbound-sip extended permit tcp 192.168.10.30 255.255.255.255 any range 5000 6000

Adds an ACE. This ACE allows the ASA to allow outbound SIP traffic for Cisco Intercompany Media Engine (in the example, any TCP traffic with source as 192.168.10.30 and destination port range between 5000 and 6000). This entry is used to classify traffic for the class and policy map.

Note Ensure that TCP traffic between Cisco UCM and the Cisco Intercompany Media Engine server does not use this port range (if that connection goes through the ASA).

Step 5

hostname(config)# access-list id permit tcp any host ip_address eq 6084
Example:
hostname(config)# access-list ime-traffic permit tcp any host 192.168.10.12 eq 6084

Adds an ACE. This ACE allows the ASA to allow traffic from the Cisco Intercompany Media Engine server to remote Cisco Intercompany Media Engine servers.

Step 6

hostname(config)# access-list id permit tcp any host ip_address eq 8470
Example:
hostname(config)# access-list ime-bootserver-traffic permit tcp any host 192.168.10.12 eq 8470

Adds an ACE. This ACE allows the ASA to allow traffic from the Cisco Intercompany Media Engine server to the Bootstrap server for the Cisco Intercompany Media Engine.

What to Do Next

Create the media termination instance on the ASA for the Cisco Intercompany Media Engine Proxy. See Creating the Media Termination Instance.

Creating the Media Termination Instance

Guidelines

The media termination address you configure must meet these requirements:

  • If you decide to configure a media-termination address on interfaces (rather than using a global interface), you must configure a media-termination address on at least two interfaces (the inside and an outside interface) before applying the service policy for the Cisco Intercompany Media Engine Proxy. Otherwise, you will receive an error message when enabling the proxy with SIP inspection.

Note Cisco recommends that you configure the media-termination address for the Cisco Intercompany Media Engine Proxy on interfaces rather than configuring a global media-termination address.


  • The Cisco Intercompany Media Engine Proxy can use only one type of media termination instance at a time; for example, you can configure a global media-termination address for all interfaces or configure a media-termination address for different interfaces. However, you cannot use a global media-termination address and media-termination addresses configured for each interface at the same time.

Note If you change any Cisco Intercompany Media Engine Proxy settings after you create the media-termination address for the proxy, you must reconfigure the media-termination address by using the no media-termination command, and then reconfiguring it as described in this procedure.

Procedure

Create the media termination instance to use with the Cisco Intercompany Media Engine Proxy.

The example command lines in this task are based on a basic (in-line) deployment. See Figure 20-5 for an illustration explaining the example command lines in this task.

To create the media termination instance for the Cisco Intercompany Media Engine Proxy, perform the following steps:

 

 
Command
Purpose

Step 1

hostname(config)# media-termination instance_name
Example:
hostname(config)# media-termination uc-ime-media-term

Creates the media termination instance that you attach to the Cisco Intercompany Media Engine Proxy.

Step 2

hostname(config-media-termination)# address ip_address interface intf_name
Examples:
hostname(config-media-termination)# address 209.165.200.228 interface outside

Configures the media-termination address used by the outside interface of the ASA.

The outside IP address must be a publicly routable address that is an unused IP address within the address range on that interface.

See Creating the Cisco Intercompany Media Engine Proxy for information about the UC-IME proxy settings. See CLI configuration guide for information about the no service-policy command.

Step 3

hostname(config-media-termination)# address ip_address interface intf_name
Examples:
hostname(config-media-termination)# address 192.168.10.3 interface inside

Configures a media termination address used by the inside interface of the ASA.

Note The IP address must be an unused IP address within the same subnet on that interface.

Step 4

(Optional)
hostname(config-media-termination)# rtp-min-port port1 rtp-maxport port2
Examples:
hostname(config-media-termination)# rtp-min-port 1000 rtp-maxport 2000

Configures the rtp-min-port and rtp-max-port limits for the Cisco Intercompany Media Engine Proxy. Configure the RTP port range for the media termination point when you need to scale the number of calls that the Cisco Intercompany Media Engine supports.

Where port1 specifies the minimum value for the RTP port range for the media termination point, where port1 can be a value from 1024 to 65535. By default, the value for port1 is 16384.

Where port2 specifies the maximum value for the RTP port range for the media termination point, where port2 can be a value from 1024 to 65535. By default, the value for port2 is 32767.

What To Do Next

Once you have created the media termination instance, create the Cisco Intercompany Media Engine Proxy. See Creating the Cisco Intercompany Media Engine Proxy.

Creating the Cisco Intercompany Media Engine Proxy

To create the Cisco Intercompany Media Engine Proxy, perform the following steps.

The example command lines in this task are based on a basic (in-line) deployment. See Figure 20-5 for an illustration explaining the example command lines in this task.

Note You cannot change any of the configuration settings for the Cisco Intercompany Media Engine Proxy described in this procedure when the proxy is enabled for SIP inspection. Remove the Cisco Intercompany Media Engine Proxy from SIP inspection before changing any of the settings described in this procedure.

 

 
Command
Purpose

Step 1

hostname(config)# uc-ime uc_ime_name
Example:
hostname(config)# uc-ime local-ent-ime

Configures the Cisco Intercompany Media Engine Proxy.

Where uc_ime_name is the name of the Cisco Intercompany Media Engine Proxy. The name is limited to 64 characters.

Only one Cisco Intercompany Media Engine Proxy can be configured on the ASA.

Step 2

hostname(config-uc-ime)# media-termination mta_instance_name
Example:
hostname(config-uc-ime)# media-termination ime-media-term

Specifies the media termination instance used by the Cisco Intercompany Media Engine Proxy.

Note You must create the media termination instance before you specify it in the Cisco Intercompany Media Engine Proxy.

Where mta_instance_name is the instance_name that you created in of Creating the Media Termination Instance.

See Creating the Media Termination Instance for the steps to create the media termination instance.

Step 3

hostname(config-uc-ime)# ucm address ip_address trunk-security-mode [ nonsecure | secure ]
Example:
hostname(config-uc-ime)# ucm address 192.168.10.30 trunk-security-mode non-secure

Specifies the Cisco UCM server in the enterprise. You must specify the real IP address of the Cisco UCM server. Do not specify a mapped IP address for the server.

Note You must include an entry for each Cisco UCM in the cluster with Cisco Intercompany Media Engine that has a SIP trunk enabled.

Where the nonsecure and secure options specify the security mode of the Cisco UCM or cluster of Cisco UCMs.

Note Specifying secure for Cisco UCM or Cisco UCM cluster indicates that Cisco UCM or Cisco UCM cluster is initiating TLS; therefore, you must configure TLS for components. See (Optional) Configuring TLS within the Local Enterprise.

You can specify the secure option in this task or you can update it later while configuring TLS for the enterprise. See Step 11 in (Optional) Configuring TLS within the Local Enterprise.

Step 4

hostname(config-uc-ime)# ticket epoch n password password
Example:
hostname(config-uc-ime)# ticket epoch 1 password password1234

Configures the ticket epoch and password for Cisco Intercompany Media Engine.

Where n is an integer from 1-255. The epoch contains an integer that updates each time that the password is changed. When the proxy is configured the first time and a password entered for the first time, enter 1 for the epoch integer. Each time you change the password, increment the epoch to indicate the new password. You must increment the epoch value each time your change the password.

Typically, you increment the epoch sequentially; however, the ASA allows you to choose any value when you update the epoch.

If you change the epoch value, the current password is invalidated and you must enter a new password.

Where password contains a minimum of 10 and a maximum of 64 printable character from the US-ASCII character set. The allowed characters include 0x21 to 0x73 inclusive, and exclude the space character.

We recommend a password of at least 20 characters. Only one password can be configured at a time.

The ticket password is stored onto flash. The output of the show running-config uc-ime command displays ***** instead of the password string.

Note The epoch and password that you configure on the ASA must match the epoch and password configured on the Cisco Intercompany Media Engine server. See the Cisco Intercompany Media Engine server documentation for information.

Step 5

(Optional)

hostname(config-uc-ime)# fallback monitoring timer timer_millisec | hold-down timer timer_sec
Examples:
hostname(config-uc-ime)# fallback monitoring timer 120
hostname(config-uc-ime)# fallback hold-down timer 30

Specifies the fallback timers for Cisco Intercompany Media Engine.

Specifying monitoring timer sets the time between which the ASA samples the RTP packets received from the Internet. The ASA uses the data sample to determine if fallback to the PSTN is needed for a call.

Where timer_millisec specifies the length of the monitoring timer. By default, the length is 100 milliseconds for the monitoring timer and the allowed range is 10-600 ms.

Specifying hold-down timer sets the amount of time that ASA waits before notifying Cisco UCM whether to fall back to PSTN.

Where timer_sec specifies the length of the hold-down timer. By default, the length is 20 seconds for the hold-down timer and the allowed range is 10-360 seconds.

If you do not use this command to specify fallback timers, the ASA uses the default settings for the fallback timers.

Step 6

(Optional)

hostname(config-uc-ime)# fallback sensitivity-file file_name
Example:
hostname(config-uc-ime)# fallback sensitivity-file ime-fallback-sensitvity.fbs

Specifies the file to use for mid-call PSTN fallback.

Where file_name must be the name of a file on disk that includes the .fbs file extension.

The fallback file is used to determine whether the QoS of the call is poor enough for the Cisco Intercompany Media Engine to move the call to the PSTN.

What to Do Next

Install the certificate on the local entity truststore. You could also enroll the certificate with a local CA trusted by the local entity.

Creating Trustpoints and Generating Certificates

You need to generate the keypair for the certificate used by the ASA, and configure a trustpoint to identify the certificate sent by the ASA in the TLS handshake.

The example command lines in this task are based on a basic (in-line) deployment. See Figure 20-5 for an illustration explaining the example command lines in this task.


Note This task instructs you on how to create trustpoints for the local enterprise and the remote enterprise and how to exchange certificates between these two enterprises. This task does not provide steps for creating trustpoints and exchanging certificates between the local Cisco UCM and the local ASA. However, if you require additional security within the local enterprise, you must perform the optional task (Optional) Configuring TLS within the Local Enterprise. Performing that task allows for secure TLS connections between the local Cisco UCM and the local ASA. The instructions in that task describe how to create trustpoints between the local Cisco UCM and the local ASA.


Prerequisites for Installing Certificates

To create a proxy certificate on the ASA that is trusted by the remote entity, obtain a certificate from a trusted CA or export it from the remote enterprise ASA.

To export the certificate from the remote enterprise, you enter the following command on the remote ASA:

hostname(config)# crypto ca export trustpoint identity-certificate

The ASA prompts displays the certificate in the terminal screen. Copy the certificate from the terminal screen. You will need the certificate text in Step 5 of this task.

Procedure

To create the trustpoints and generate certificates, perform the following steps:

 

 
Command
Purpose

Step 1

hostname(config)# crypto key generate rsa label key-pair-label modulus size
Example:
hostname(config)# crypto key generate rsa label local-ent-key modulus 2048

On the local ASA, creates the RSA keypair that can be used for the trustpoints. This is the keypair and trustpoint for the local entities signed certificate.

The modulus key size that you select depends on the level of security that you want to configure and on any limitations imposed by the CA from which you are obtaining the certificate. The larger the number that you select, the higher the security level will be for the certificate. Most CAs recommend 2048 for the key modulus size; however,

Note GoDaddy requires a key modulus size of 2048.

Step 2

hostname(config)# crypto ca trustpoint trustpoint_name
Example:
hostname(config)# crypto ca trustpoint local_ent

Enters the trustpoint configuration mode for the specified trustpoint so that you can create the trustpoint for the local entity.

A trustpoint represents a CA identity and possibly a device identity, based on a certificate issued by the CA. Maximum name length is 128 characters.

Step 3

hostname(config-ca-trustpoint)# subject-name X.500_name
Example:
hostname(config-ca-trustpoint)# subject-name cn=Ent-local-domain-name**

Includes the indicated subject DN in the certificate during enrollment.

Note The domain name that you enter here must match the domain name that has been set for the local Cisco UCM.
For information about how to configure the domain name for Cisco UCM, see the Cisco Unified Communications Manager documentation for information.

Step 4

hostname(config-ca-trustpoint)# keypair keyname
Example:
hostname(config-ca-trustpoint)# keypair local-ent-key

Specifies the key pair whose public key is to be certified.

Step 5

hostname(config-ca-trustpoint)# enroll terminal

Specifies that you will use the “copy and paste” method of enrollment with this trustpoint (also known as manual enrollment).

Step 6

hostname(config-ca-trustpoint)# exit

Exits from the CA Trustpoint configuration mode.

Step 7

hostname(config)# crypto ca enroll trustpoint
Example:
hostname(config)# crypto ca enroll remote-ent
%
% Start certificate enrollment ...
% The subject name in the certificate will be:
% cn=enterpriseA
% The fully-qualified domain name in the certificate will @ be: ciscoasa
% Include the device serial number in the subject name? [yes/no]: no
Display Certificate Request to terminal? [yes/no]: yes
 

Starts the enrollment process with the CA.

Where trustpoint is the same as the value you entered for trustpoint_name in Step 2.

When the trustpoint is configured for manual enrollment ( enroll terminal command), the ASA writes a base-64-encoded PKCS10 certification request to the console and then displays the CLI prompt. Copy the text from the prompt.

Submit the certificate request to the CA, for example, by pasting the text displayed at the prompt into the certificate signing request enrollment page on the CA website.

When the CA returns the signed identity certificate, proceed to Step 8 in this procedure.

Step 8

hostname(config)# crypto ca import trustpoint certificate
Example:
hostname(config)# crypto ca import remote-ent certificate

Imports the signed certificate received from the CA in response to a manual enrollment request.

Where trustpoint specifies the trustpoint you created in Step 2.

The ASA prompts you to paste the base-64 formatted signed certificate onto the terminal.

Step 9

hostname(config)# crypto ca authenticate trustpoint
Example:
hostname(config)# crypto ca authenticate remote-ent

Authenticates the third-party identity certificate received from the CA. The identity certificate is associated with a trustpoint created for the remote enterprise.

The ASA prompts you to paste the base-64 formatted identity certificate from the CA onto the terminal.

What to Do Next

Create the TLS proxy for the Cisco Intercompany Media Engine. See the “Creating the TLS Proxy” section.

Creating the TLS Proxy

Because either enterprise, namely the local or remote Cisco UCM servers, can initiate the TLS handshake (unlike IP Telephony or Cisco Mobility Advantage, where only the clients initiate the TLS handshake), you must configure by-directional TLS proxy rules. Each enterprise can have an ASA as the TLS proxy.

Create TLS proxy instances for the local and remote entity initiated connections respectively. The entity that initiates the TLS connection is in the role of “TLS client.” Because the TLS proxy has a strict definition of “client” and “server” proxy, two TLS proxy instances must be defined if either of the entities could initiate the connection.

The example command lines in this task are based on a basic (in-line) deployment. See Figure 20-5 for an illustration explaining the example command lines in this task.

To create the TLS proxy, perform the following steps:

 

 
Command
Purpose

Step 1

hostname(config)# tls-proxy proxy_name
Example:
hostname(config)# tls-proxy local_to_remote-ent

Creates the TLS proxy for the outbound connections.

Step 2

hostname(config-tlsp)# client trust-point proxy_trustpoint
Example:
hostname(config-tlsp)# client trust-point local-ent

For outbound connections, specifies the trustpoint and associated certificate that the adaptive security appliance uses in the TLS handshake when the adaptive security appliance assumes the role of the TLS client. The certificate must be owned by the adaptive security appliance (identity certificate).

Where proxy_trustpoint specifies the trustpoint defined by the crypto ca trustpoint command in Step 2 in “Creating Trustpoints and Generating Certificates” section.

Step 3

hostname(config-tlsp)# client cipher-suite cipher_suite
Example:
hostname(config-tlsp)# client cipher-suite aes128-sha1 aes256-sha1 3des-sha1 null-sha1

For outbound connections, controls the TLS handshake parameter for the cipher suite.

Where cipher_suite includes des-sha1, 3des-sha1, aes128-sha1, aes256-sha1, or null-sha1.

For client proxy (the proxy acts as a TLS client to the server), the user-defined cipher suite replaces the default cipher suite, or the one defined by the ssl encryption command. Use this command to achieve difference ciphers between the two TLS sessions. You should use AES ciphers with the Cisco UCM server.

Step 4

hostname(config-tlsp)# exit

Exits from the TLS proxy configuration mode.

Step 5

hostname(config)# tls-proxy proxy_name
Example:
hostname(config)# tls-proxy remote_to_local-ent

Create the TLS proxy for inbound connections.

Step 6

hostname(config-tlsp)# server trust-point proxy_trustpoint
Example:
hostname(config-tlsp)# server trust-point local-ent

For inbound connections, specifies the proxy trustpoint certificate presented during TLS handshake. The certificate must be owned by the adaptive security appliance (identity certificate).

Where proxy_trustpoint specifies the trustpoint defined by the crypto ca trustpoint command in Step 2 in “Creating Trustpoints and Generating Certificates” section.

Because the TLS proxy has strict definition of client proxy and server proxy, two TLS proxy instances must be defined if either of the entities could initiate the connection.

Step 7

hostname(config-tlsp)# client cipher-suite cipher_suite
Example:
hostname(config-tlsp)# client cipher-suite aes128-sha1 aes256-sha1 3des-sha1 null-sha1

For inbound connections, controls the TLS handshake parameter for the cipher suite.

Where cipher_suite includes des-sha1, 3des-sha1, aes128-sha1, aes256-sha1, or null-sha1.

Step 8

hostname(config-tlsp)# exit

Exits from the TSL proxy configuration mode.

Step 9

hostname(config)# ssl encryption 3des-shal aes128-shal [ algorithms ]

Specifies the encryption algorithms that the SSL/TLS protocol uses. Specifying the 3des-shal and aes128-shal is required. Specifying other algorithms is optional.

Note The Cisco Intercompany Media Engine Proxy requires that you use strong encryption. You must specify this command when the proxy is licensed using a K9 license.

What to Do Next

Once you have created the TLS proxy, enable it for SIP inspection.

Enabling SIP Inspection for the Cisco Intercompany Media Engine Proxy

Enable the TLS proxy for SIP inspection and define policies for both entities that could initiate the connection.

The example command lines in this task are based on a basic (in-line) deployment. See Figure 20-5 for an illustration explaining the example command lines in this task.


Note If you want to change any Cisco Intercompany Media Engine Proxy settings after you enable SIP inspection, you must enter the no service-policy command, and then reconfigure the service policy as described in this procedure. Removing and reconfiguring the service policy does not affect existing calls; however, the first call traversing the Cisco Intercompany Media Engine Proxy will fail. Enter the clear connection command and restart the ASA.


To enable SIP inspection for the Cisco Intercompany Media Engine Proxy, perform the following steps:

 

 
Command
Purpose

Step 1

hostname(config)# class-map class_map_name
Examples:
hostname(config)# class-map ime-inbound-sip

Defines a class for the inbound Cisco Intercompany Media Engine SIP traffic.

Step 2

hostname(config-cmap)# match access-list access_list_name
Examples:
hostname(config-cmap)# match access-list ime-inbound-sip

Identifies the SIP traffic to inspect.

Where the access_list_name is the ACL you created in of the task Creating ACLs for Cisco Intercompany Media Engine Proxy.

Step 3

hostname(config-cmap)# exit

Exits from the class map configuration mode.

Step 4

hostname(config)# class-map class_map_name
Examples:
hostname(config)# class-map ime-outbound-sip

Defines a class for the outbound SIP traffic from Cisco Intercompany Media Engine.

Step 5

hostname(config)# match access-list access_list_name
Examples:
hostname(config-cmap)# match access-list ime-outbound-sip

Identifies which outbound SIP traffic to inspect.

Where the access_list_name is the ACL you created in of the task Creating ACLs for Cisco Intercompany Media Engine Proxy.

Step 6

hostname(config-cmap)# exit

Exits from the class map configuration mode.

Step 7

hostname(config)# policy-map name
Examples:
hostname(config)# policy-map ime-policy

Defines the policy map to which to attach the actions for the class of traffic.

Step 8

hostname(config-pmap)# class classmap_name
Examples:
hostname(config-pmap)# class ime-outbound-sip

Assigns a class map to the policy map so that you can assign actions to the class map traffic.

Where classmap_name is the name of the SIP class map that you created in in this task.

Step 9

hostname(config-pmap-c)# inspect sip [ sip_map ] tls-proxy proxy_name uc-ime uc_ime_map
Examples:
hostname(config-pmap-c)# inspect sip tls-proxy local_to_remote-ent uc-ime local-ent-ime

Enables the TLS proxy and Cisco Intercompany Media Engine Proxy for the specified SIP inspection session.

Step 10

hostname(config-cmap-c)# exit

Exits from the policy map class configuration mode.

Step 11

hostname(config-pmap)# class class_map_name
Examples:
hostname(config-pmap)# class ime-inbound-sip

Assigns a class map to the policy map so that you can assign actions to the class map traffic.

Where classmap_name is the name of the SIP class map that you created in in this task.

Step 12

hostname(config-pmap-c)# inspect sip [ sip_map ] tls-proxy proxy_name uc-ime uc_ime_map
Examples:
hostname(config-pmap-c)# inspect sip tls-proxy remote-to-local-ent uc-ime local-ent-ime

Enables the TLS proxy and Cisco Intercompany Media Engine Proxy for the specified SIP inspection session.

Step 13

hostname(config-pmap-c)# exit

Exits from the policy map class configuration mode.

Step 14

hostname(config-pmap)# exit

Exits from the policy map configuration mode.

Step 15

hostname(config)# service-policy policymap_name global
Examples:
hostname(config)# service-policy ime-policy global

Enables the service policy for SIP inspection for all interfaces.

Where policymap_name is the name of the policy map you created in of this task.

See Creating the Cisco Intercompany Media Engine Proxy for information about the UC-IME proxy settings. See CLI configuration guide for information about the no service-policy command.

What to Do Next

Once you have enabled the TLS proxy for SIP inspection, if necessary, configure TLS within the enterprise. See (Optional) Configuring TLS within the Local Enterprise.

(Optional) Configuring TLS within the Local Enterprise

This task is not required if TCP is allowable within the inside network.

TLS within the enterprise refers to the security status of the Cisco Intercompany Media Engine trunk as seen by the ASA.


Note If the transport security for the Cisco Intercompany Media Engine trunk changes on Cisco UCM, it must be changed on the ASA as well. A mismatch will result in call failure. The ASA does not support SRTP with non-secure IME trunks. The ASA assumes SRTP is allowed with secure trunks. So ‘SRTP Allowed’ must be checked for IME trunks if TLS is used. The ASA supports SRTP fallback to RTP for secure IME trunk calls.


Prerequisites

On the local Cisco UCM, download the Cisco UCM certificate. See the Cisco Unified Communications Manager documentation for information. You will need this certificate when performing Step 6 of this procedure.

Procedure

To configure TLS within the local enterprise, perform the following steps on the local ASA:

 

 
Commands
Purpose

Step 1

hostname(config)# crypto key generate rsa label key-pair-label
hostname(config)# crypto ca trustpoint trustpoint_name
hostname(config-ca-trustpoint)# enroll self
hostname(config-ca-trustpoint)# keypair keyname
hostname(config-ca-trustpoint)# subject-name x.500_name
Example:
hostname(config)# crypto key generate rsa label local-ent-key
hostname(config)# crypto ca trustpoint local-asa
hostname(config-ca-trustpoint)# enroll self
hostname(config-ca-trustpoint)# keypair key-local-asa
hostname(config-ca-trustpoint)# subject-name cn=Ent-local-domain-name** ., o="Example Corp"

Creates an RSA key and trustpoint for the self-signed certificate.

Where key-pair-label is the RSA key for the local ASA.

Where trustpoint_name is the trustpoint for the local ASA.

Where keyname is key pair for the local ASA.

Where x.500_name includes the X.500 distinguished name of the local ASA; for example, cn=Ent-local-domain-name** .

Note The domain name that you enter here must match the domain name that has been set for the local Cisco UCM. For information about how to configure the domain name for Cisco UCM, see the Cisco Unified Communications Manager documentation for information.

Step 2

hostname(config-ca-trustpoint)# exit

Exits from Trustpoint Configuration mode.

Step 3

hostname(config)# crypto ca export trustpoint identity-certificate
Example:
hostname(config)# crypto ca export local-asa identity-certificate

Exports the certificate you created in Step 1. The certificate contents appear on the terminal screen.

Copy the certificate from the terminal screen. This certificate enables Cisco UCM to validate the certificate that the ASA sends in the TLS handshake.

On the local Cisco UCM, upload the certificate into the Cisco UCM trust store. See the Cisco Unified Communications Manager documentation for information.

Note The subject name you enter while uploading the certificate to the local Cisco UCM is compared with the X.509 Subject Name field entered on the SIP Trunk Security Profile on Cisco UCM. For example, “Ent-local-domain-name” was entered in Step 1 of this task; therefore, “Ent-local-domain-name” should be entered in the Cisco UCM configuration.

Step 4

hostname(config)# crypto ca trustpoint trustpoint_name
hostname(config-ca-trustpoint)# enroll terminal
Example:
hostname(config)# crypto ca trustpoint local-ent-ucm
hostname(config-ca-trustpoint)# enroll terminal

Creates a trustpoint for local Cisco UCM.

Where trustpoint_name is the trustpoint for the local Cisco UCM.

Step 5

hostname(config-ca-trustpoint)# exit

Exits from Trustpoint Configuration mode.

Step 6

hostname(config)# crypto ca authenticate trustpoint
Example:
hostname(config)# crypto ca authenticate local-ent-ucm

Imports the certificate from local Cisco UCM.

Where trustpoint is the trustpoint for the local Cisco UCM.

Paste the certificate downloaded from the local Cisco UCM. This certificate enables the ASA to validate the certificate that Cisco UCM sends in the TLS handshake.

Step 7

hostname(config)# tls-proxy proxy_name
hostname(config-tlsp)# server trust-point proxy_trustpoint
hostname(config-tlsp)# client trust-point proxy_trustpoint
hostname(config-tlsp)# client cipher-suite aes128-sha1 aes256-sha1 3des-sha1 null-sha1
Example:
hostname(config)# tls-proxy local_to_remote-ent
hostname(config-tlsp)# server trust-point local-ent-ucm
hostname(config-tlsp)# client trust-point local-ent
hostname(config-tlsp)# client cipher-suite aes128-sha1 aes256-sha1 3des-sha1 null-sha1

Updates the TLS proxy for outbound connections.

Where proxy_name is the name you entered in Step 1 of the task Creating the TLS Proxy.

Where proxy_trustpoint for the server trust-point command is the name you entered in Step 4 of this procedure.

Where proxy_trustpoint for the client trust-point command is the name you entered in Step 2 of the task Creating Trustpoints and Generating Certificates.

Note In this step, you are creating different trustpoints for the client and the server.

Step 8

hostname(config-tlsp)# exit

Exits from TLS Proxy Configuration mode.

Step 9

hostname(config)# tls-proxy proxy_name
hostname(config-tlsp)# server trust-point proxy_trustpoint
hostname(config-tlsp)# client trust-point proxy_trustpoint
hostname(config-tlsp)# client cipher-suite aes128-sha1 aes256-sha1 3des-sha1 null-sha1
Example:
hostname(config)# tls-proxy remote_to_local-ent
hostname(config-tlsp)# server trust-point local-ent
hostname(config-tlsp)# client trust-point local-ent-ucm
hostname(config-tlsp)# client cipher-suite aes128-sha1 aes256-sha1 3des-sha1 null-sha1

Updates the TLS proxy for inbound connections.

Where proxy_name is the name you entered in Step 5 of the task Creating the TLS Proxy.

Where proxy_trustpoint for the server trust-point command is the name you entered in Step 2 of the task Creating Trustpoints and Generating Certificates.

Where proxy_trustpoint for the client trust-point command is the name you entered in Step 4 of this procedure.

Step 10

hostname(config-tlsp)# exit

Exits from TLS Proxy Configuration mode.

Step 11

hostname(config)# uc-ime uc_ime_name
hostname(config-uc-ime)# ucm address ip_address trunk-security-mode secure
Example:
hostname(config)# uc-ime local-ent-ime
hostname(config-uc-ime)# ucm address 192.168.10.30 trunk-security-mode secure

Updates the Cisco Intercompany Media Engine Proxy for trunk-security-mode.

Where uc_ime_name is the name you entered in Step 1 of the task Creating the Cisco Intercompany Media Engine Proxy.

Only perform this step if you entered nonsecure in Step 3 of the task Creating the Cisco Intercompany Media Engine Proxy.

What to Do Next

Once you have configured the TLS within the enterprise, if necessary, configure off path signaling for an off path deployment. See (Optional) Configuring Off Path Signaling.

(Optional) Configuring Off Path Signaling

Perform this task only when you are configuring the Cisco Intercompany Media Engine Proxy as part of an off path deployment. You might choose to have an off path deployment when you want to use the Cisco Intercompany Media Engine but do not want to replace your existing Internet firewall with an ASA enabled with the Cisco Intercompany Media Engine Proxy.

In an off path deployment, the existing firewall that you have deployed in your environment is not capable of transmitting Cisco Intercompany Media Engine traffic.

Off path signaling requires that outside IP addresses translate to an inside IP address. The inside interface address can be used for this mapping service configuration. For the Cisco Intercompany Media Engine Proxy, the ASA creates dynamic mappings for external addresses to the internal IP address; therefore, using the dynamic NAT configuration on outbound calls, Cisco UCM sends SIP traffic to this internal IP address, and the ASA uses that mapping to determine the real destination on inbound calls. The static NAT or PAT mapping is used for inbound calls in an off path configuration.

Figure 20-8 Example for Configuring Off Path Signaling in an Off Path Deployment

 

After you configure off path signaling, the ASA mapping service listens on interface “inside” for requests. When it receives a request, it creates a dynamic mapping for the “outside” as the destination interface.

To configure off path signaling for the Cisco Intercompany Media Engine Proxy, perform the following steps:

 

 
Command
Purpose

Step 1

hostname(config)# object network name
Example:
hostname(config)# object network outside-any

For the off path ASA, creates a network object to represent all outside addresses.

Step 2

hostname(config-network-object)# subnet ip_address
Example:
hostname(config-network-object)# subnet 0.0.0.0 0.0.0.0

Specifies the IP address of the subnet.

Step 3

hostname(config-network-object)# nat (outside,inside) dynamic interface inside

Creates a mapping for the Cisco UCM of remote enterprises.

Step 4

hostname(config-network-object)# exit

Exits from the objects configuration mode.

Step 5

hostname(config)# uc-ime uc_ime_name
Example:
hostname(config)# uc-ime local-ent-ime

Specifies the Cisco Intercompany Media Engine Proxy that you created in the task Creating the Cisco Intercompany Media Engine Proxy.

Where uc_ime_name is the name you specified in Step 1 of Creating the Cisco Intercompany Media Engine Proxy.

Step 6

hostname(config)# mapping-service listening-interface interface_name [ listening-port port ] uc-ime-interface uc-ime-interface_name
Example:
hostname(config-uc-ime)# mapping-service listening-interface inside listening-port 8060 uc-ime-interface outside

For the off path ASA, adds the mapping service to the Cisco Intercompany Media Engine Proxy.

Specifies the interface and listening port for the ASA mapping service.

You can only configure one mapping server for the Cisco Intercompany Media Engine Proxy.

Where interface_name is the name of the interface on which the ASA listens for the mapping requests.

Where port is the TCP port on which the ASA listens for the mapping requests. The port number must be between 1024 and 65535 to avoid conflicts with other services on the device, such as Telnet or SSH. By default, the port number is TCP 8060.

Where uc-ime-interface_name is the name of the interface that connects to the remote Cisco UCM.

This section contains the following sections:

Configuring the Cisco UC-IMC Proxy by using the UC-IME Proxy Pane

Use the Configure Cisco Intercompany Media Engine (UC-IME) proxy pane to add or edit a Cisco Intercompany Media Engine Proxy instance.


Note The Cisco Intercompany Media Engine Proxy does not appear as an option under the Unified Communications section of the navigation pane unless the license required for this proxy is installed on the ASA.


Use this pane to create the proxy instance; however, for the UC-IME proxy to be fully functionally, you must complete additional tasks, such as create the required NAT statements, ACLs, and MTA, set up the certificates, create the TLS Proxy, and enable SIP inspection.

Depending on whether the UC-IME proxy is deployed off path or in-line of Internet traffic, you must create the appropriate network objects with embedded NAT/PAT statements for the Cisco UCMs.

This pane is available from the Configuration > Firewall > Unified Communications > UC-IME Proxy.


Step 1 Open the Configuration > Firewall > Unified Communications > UC-IME Proxy pane.

Step 2 Check the Enable Cisco UC-IME proxy check box to enable the feature.

Step 3 In the Unified CM Servers area, enter an IP address or hostname for the Cisco Unified Communications Manager (Cisco UCM) or click the ellipsis to open a dialog and browse for an IP address or hostname.

Step 4 In the Trunk Security Mode field, click a security option. Specifying secure for Cisco UCM or Cisco UCM cluster indicates that Cisco UCM or Cisco UCM cluster is initiating TLS.

Step 5 Click Add to add the Cisco UCM for the Cisco Intercompany Media Engine Proxy. You must include an entry for each Cisco UCM in the cluster with Cisco Intercompany Media Engine that has a SIP trunk enabled.

Step 6 In the Ticket Epoch field, enter an integer from 1-255.

The epoch contains an integer that updates each time that the password is changed. When the proxy is configured the first time and a password entered for the first time, enter 1 for the epoch integer. Each time you change the password, increment the epoch to indicate the new password. You must increment the epoch value each time your change the password.

Typically, you increment the epoch sequentially; however, the ASA allows you to choose any value when you update the epoch.

If you change the epoch value, the current password is invalidated and you must enter a new password.


Note The epoch and password that you configure in this step on the ASA must match the epoch and password that you configure on the Cisco Intercompany Media Engine server. See the Cisco Intercompany Media Engine server documentation for information.


Step 7 In the Ticket Password field, enter a minimum of 10 printable character from the US-ASCII character set. The allowed characters include 0x21 to 0x73 inclusive, and exclude the space character. The ticket password can be up to 64 characters. Confirm the password you entered. Only one password can be configured at a time.

Step 8 Check the Apply MTA to UC-IME Link proxy check box to associate the media termination address with the Cisco Intercompany Media Engine Proxy.


Note You must create the media termination instance before you associate it with the Cisco Intercompany Media Engine Proxy. If necessary, click the Configure MTA button to configure a media termination address instance.


Step 9 If the Cisco Intercompany Media Engine Proxy is being configured as part of off path deployment, check the Enable off path address mapping service checkbox and configure the off path deployment settings:

a. From the Listening Interface field, select an ASA interface. This is the interface on which the ASA listens for the mapping requests.

b. In the Port field, enter a number between 1024 and 65535 as the TCP port on which the ASA listens for the mapping requests. The port number must be 1024 or higher to avoid conflicts with other services on the device, such as Telnet or SSH. By default, the port number is TCP 8060.

c. From the UC-IME Interface field, select an interface from the list. This is the interface that the ASA uses to connect to the remote Cisco UCM.


Note In an off path deployment any existing ASA that you have deployed in your environment are not capable of transmitting Cisco Intercompany Media Engine traffic. Off-path signaling requires that outside addresses are translated (using NAT) to an inside IP address. The inside interface address can be used for this mapping service configuration. For the Cisco Intercompany Media Engine Proxy, the ASA creates dynamic mappings for external addresses to the internal IP address.


Step 10 In the Fallback area, configure the fallback timer for the Cisco Intercompany Media Engine by specifying the following settings:

a. In the Fallback Sensitivity File field, enter the path to a file in flash memory that the ASA uses for mid-call PSTN fallback. The file name that you enter must be the name of a file on disk that includes the .fbs file extension. Alternatively, click the Browse Flash button to locate and select the file from flash memory.

b. In the Call Quality Evaluation Interval field, enter a number between 10-600 (in milliseconds). This number controls the frequency at which the ASA samples the RTP packets received from the Internet. The ASA uses the data sample to determine if fallback to the PSTN is needed for a call. By default, the length is 100 milliseconds for the timer.

c. In the Notification Interval field, enter a number between 10-360 (in seconds). This number controls the amount of time that the ASA waits before notifying Cisco UCM whether to fall back to PSTN. By default, the length is 20 seconds for this timer.


Note When you change the fallback timer for the Cisco Intercompany Media Engine Proxy, ASDM automatically removes the proxy from SIP inspection and then reapplies SIP inspection when the proxy is re-enabled.


Step 11 Click Apply to save the configuration changes for the Cisco Intercompany Media Engine Proxy.


 

Configuring the Cisco UC-IMC Proxy by using the Unified Communications Wizard

To configure the Cisco Intercompany Media Engine Proxy by using ASDM, choose Wizards > Unified Communications Wizard from the menu. The Unified Communications Wizard opens. From the first page, select the Cisco Intercompany Media Engine Proxy option under the Business-to-Business section.

The wizard automatically creates the necessary TLS proxy, then guides you through creating the Intercompany Media Engine proxy, importing and installing the required certificates, and finally enables the SIP inspection for the Intercompany Media Engine traffic automatically.

The wizard guides you through these steps to create the Cisco Intercompany Media Engine Proxy:


Step 1 Select the Intercompany Media Engine Proxy option.

Step 2 Select the topology of the Cisco Intercompany Media Engine Proxy, namely whether the ASA is an edge firewall with all Internet traffic flowing through it or whether the ASA is off the path of the main Internet traffic (referred to as an off path deployment).

Step 3 Specify private network settings such as the Cisco UCM IP addresses and the ticket settings.

Step 4 Specify the public network settings.

Step 5 Specify the media termination address settings of Cisco UCM.

Step 6 Configure the local-side certificate management, namely the certificates that are exchanged between the local Cisco Unified Communications Manager servers and the ASA. The identity certificate that the wizard generates in this step needs to be installed on each Cisco Unified Communications Manager (UCM) server in the cluster with the proxy and each identity certificate from the Cisco UCMs need to be installed on the ASA. The certificates are used by the ASA and the Cisco UCMs to authenticate each other, respectively, during TLS handshakes. The wizard only supports self-signed certificates for this step.

Step 7 Configure the remote-side certificate management, namely the certificates that are exchanged between the remote server and the ASA. In this step, the wizard generates a certificate signing request (CSR). After successfully generating the identity certificate request for the proxy, the wizard prompts you to save the file.

You must send the CSR text file to a certificate authority (CA), for example, by pasting the text file into the CSR enrollment page on the CA website. When the CA returns the Identity Certificate, you must install it on the ASA. This certificate is presented to remote servers so that they can authenticate the ASA as a trusted server.

Finally, this step of the wizard assists you in installing the root certificates of the CA from the remote servers so that the ASA can determine that the remote servers are trusted.


 

The wizard completes by displaying a summary of the configuration created for Cisco Intercompany Media Engine. See the Unified Communications Wizard section in this documentation for more information.

 

Troubleshooting Cisco Intercompany Media Engine Proxy

This section describes how to certain options of the show uc-ime command to obtain troubleshooting information for the Cisco Intercompany Media Engine Proxy. See the command reference for detailed information about the syntax for these commands.

show uc-ime signaling-sessions

Displays the corresponding SIP signaling sessions stored by the Cisco Intercompany Media Engine Proxy. Use this command to troubleshoot media or signaling failure. The command also displays the fallback parameters extracted from the SIP message headers, whether RTP monitoring is enabled or disabled, and whether SRTP keys are set.

Through the use of the Cisco Intercompany Media Engine Proxy, not only signaling but also media is secured for communication. It provides signaling encryption and SRTP/RTP conversion with SRTP enforced on the Internet side. The Cisco Intercompany Media Engine Proxy inserts itself into the media path by modifying the SIP signaling messages from Cisco UCMs.The Cisco Intercompany Media Engine Proxy sits on the edge of the enterprise and inspects SIP signaling between SIP trunks created between enterprises. It terminates TLS signaling from the Internet and initiates TCP or TLS to the local Cisco UCM.

hostname# show uc-ime signaling-sessions
1 in use, 3 most used
inside 192.168.10.30:39608 outside 10.194.108.118:5070
Local Media (audio) conn: 10.194.108.119/29824 to 10.194.108.109/21558
Local SRTP key set : Remote SRTP key set
Remote Media (audio) conn: 192.168.10.51/19520 to 192.168.10.3/30930
Call-ID: ab6d7980-a7d11b08-50-1e0aa8c0@192.168.10.30
FB Sensitivity: 3
Session ID: 2948-32325449-0@81a985c9-f3a1-55a0-3b19-96549a027259
SIP Trunk URI: 81a985c9-f3a1-55a0-3b19-9654@UCM-30;maddr=192.168.10.30
Codec-name: G722
Payload type: 9
 

Note If calls are not going through the Cisco Intercompany Media Engine, you can also use the show tls-proxy session command to troubleshoot the success of the TLS handshake between the components in the Cisco Intercompany Media Engine system. See the command reference for information about this command.


show uc-ime signaling-sessions statistics

Displays statistical information about corresponding signaling sessions stored by Cisco Intercompany Media Engine Proxy. Failure of signaling sessions in the Cisco Intercompany Media Engine can occur for different call-related reasons; such as failure of ticket verification or domain name verification, or offering RTP over the Internet.

hostname# show uc-ime signaling-sessions statistics
10 in use, 20 most used
15 terminated
Ticket integrity check failed: 2
Ticket decode failed: 1
Ticket epoch mismatch: 1
Ticket DID mismatch: 0
Ticket timestamp invalid: 4
Ticket domain check failed: 2
Ticket not found: 0
Route domain name check failed: 1
RTP over UC-IME: 2
 

Note Call-related failures, for example, can be due to the service policy rule being reconfigured or the primary ASA operating in failover mode. If a service policy rule for the Cisco Intercompany Media Engine Proxy is removed (by using the no service policy command) and reconfigured, the first call trasversing the ASA will fail. To resolve this issue, you must additionally enter the clear connection command and restart the ASA. If the failure is due to failover, the connections from the primary ASA are not synchronized to the standby ASA.


show uc-ime media-sessions detail

Displays the details about all active media sessions (calls) stored for the Cisco Intercompany Media Engine Proxy. Use this command to display output from successful calls. Additionally, use this command to troubleshoot problems with IP phone audio, such as one-way audio. If no calls are currently up, this output will be blank.

hostname(config)# show uc-ime media-sessions detail
2 in use, 5 most used
Media-session: 10.194.108.109/21558 :: client ip 192.168.10.51/19520
Call ID: ab6d7980-a7d11b08-50-1e0aa8c0@192.168.10.30
Session ID: 2948-32325449-0@81a985c9-f3a1-55a0-3b19-96549a027259
Lcl SRTP conn 10.194.108.109/21558 to 10.194.108.119/29824 tx_pkts 20203 rx_pkts 20200
refcnt 3 : created by Inspect SIP, passthrough not set
RTP monitoring is enabled
Failover_state : 0
Sum_all_packets : 20196
Codec_payload_format : 9
RTP_ptime_ms : 20
Max_RBLR_pct_x100 : 0
Max_ITE_count_in_8_sec : 0
Max_BLS_ms : 0
Max_PDV_usec : 1000
Min_PDV_usec : 0
Mov_avg_PDV_usec : 109
Total_ITE_count : 0
Total_sec_count : 403
Concealed_sec_count : 0
Severely_concealed_sec_count : 0
Max_call_interval_ms : 118
Total_SequenceNumber_Resets : 0
Media-session: 192.168.10.3/30930 :: client ip 10.194.108.119/29824
Call ID: N/A
Lcl RTP conn 192.168.10.3/30930 to 192.168.10.51/19520 tx_pkts 20201 rx_pkts 20203
 

show uc-ime fallback-notification statistics

Displays statistics about the PSTN fallback notifications to the Cisco UMC. Even if a call is sent over VoIP because the quality of the connection was good, the connection quality might worsen mid-call. To ensure an overall good experience for the end user, Cisco Intercompany Media Engine attempts to perform a mid-call fallback. Performing a mid-call fallback requires the adaptive security appliance to monitor the RTP packets coming from the Internet. If fallback is required, the adaptive security appliance sends a REFER message to Cisco UCM to tell it that it needs to fallback the call to PSTN.

Cisco Intercompany Media Engine uses a configurable hold-down timer to set the amount of time that adaptive security appliance waits before notifying Cisco UCM whether to fall back to PSTN.

hostname# show uc-ime fallback-notification statistics
UCM address: 172.23.32.37
Total Notifications Sent: 10
 

show uc-ime mapping-service-sessions

When the Cisco Intercompany Media Engine Proxy is configured for an off path deployment, displays mapping-service requests and replies between the proxy and the local Cisco UMC. A TCP port on the ASA is configured to listen for mapping requests.

The port number must be 1024 or higher to avoid conflicts with other services on the device, such as Telnet or SSH. By default, the port number is TCP 8060.

Hostname# show uc-b2blink mapping-service-sessions
Total active sessions: 2
Session client (IP:Port) Idle time
192.168.1.10:2001 0:01:01
192.168.1.20:3001 0:10:20
 

show uc-ime mapping-service-sessions statistics

Displays statistical information about the Cisco Intercompany Media Engine Proxy mapping service used in off path signaling.

Hostname# show uc-ime mapping-service-sessions statistics
Total active sessions: 2
Session client Total Responses Failed Pending Idle
(IP:Port) requests sent requests responses time
192.168.1.10:2001 10 9 1 0 0:01:01
192.168.1.20:3001 19 19 0 0 0:10:20

Feature History for Cisco Intercompany Media Engine Proxy

Table 20-1 lists the release history for this feature.

 

Table 20-1 Feature History for Cisco Phone Proxy

Feature Name
Releases
Feature Information

Cisco Intercompany Media Engine Proxy

8.3(1)

The Cisco Intercompany Media Engine Proxy was introduced.

The following commands were added to the CLI to support configuration of this new feature.

[no] uc-ime uc_ime_name

[no] fallback hold-down | monitoring timer value

[no] fallback sensitivity-file filename

[no] mapping-service listening-interface ifc_name [ listening-port port ] uc-ime-interface b2b-ifc

[no] ticket epoch epoch password pwd

[no] ucm address ip_addr trunk-security-mode nonsecure | secure

clear configure uc-ime [ uc_ime_name ]

[no] debug uc-ime [ mapping-service | media | notification | rma | signaling ] [ errors | events ]

show uc-ime

show running-config [ all ] uc-ime [uc_ime_map ]

The following command was updated by adding options for the UC-IME proxy.

inspect sip uc-ime uc-ime-name tls-proxy tls-proxy-name