ICE Media Path Optimization
From X12.5, we support Interactive Connectivity Establishment (ICE) Media Path Optimization. This feature optimizes the media path for MRA endpoints, letting MRA-registered endpoints pass media directly between the endpoints, thereby bypassing the WAN and the Expressway servers.
This feature uses the ICE protocol (RFC 5245). Background information about ICE is provided in the About ICE and TURN Services section of the Cisco Expressway Administrator Guide at https://www.cisco.com/c/en/us/support/unified-communications/expressway-series/products-maintenance-guides-list.html.
How ICE Works
Before Cisco Expressway X12.5, ICE is supported only with the Cisco Expressway-C B2BUA as one of the ICE endpoints. When B2BUA acts as an endpoint, ICE candidates are negotiated between the endpoints and B2BUA. Therefore, the media always traverses through Cisco Expressway-E and Cisco Expressway-C.
The following figure shows an MRA call that does not use ICE to optimize the media path. The media traverses through both the Cisco Expressway-E and the Cisco Expressway-C.
With ICE Media Path Optimization, introduced in Cisco Expressway X12.5, each endpoint can pass the ICE candidates to the other endpoint through zones that traverse the SIP signaling. As a result, endpoints use the ICE protocol to negotiate the most optimal path for media. The most optimal path may be one of the following:
-
Host address—Represents the host IP address of the endpoint which is behind the NAT device.
-
Server-reflexive address—Represents the publicly accessible address of the endpoint on the NAT device.
-
Relay address—Represents the relay address of the endpoint configured on the TURN server.
In all ICE calls, initially media traverses through the Cisco Expressway-E and Cisco Expressway-C and then switches the media path depending on the negotiated ICE candidate type. This ensures that if endpoints are not ICE-capable, Cisco Expressway can use the legacy traversal path to pass media without disruption.
The following sections illustrate the MRA media path for each of the three ICE candidates.
MRA Call Flow with ICE using Host Address
The following figure shows an MRA call with ICE where the Host address is used to establish the media path. The media directly passes between the endpoints using the Host address, because the endpoints reside in the same network with no firewall between them.
MRA Call Flow with ICE using Server Reflexive Addressing
The following figure shows an MRA call with ICE where both endpoints are behind different firewalls, thereby preventing the Host address from being used. Instead, the media passes between the endpoints using Server-reflexive addressing because the endpoints are behind different firewalls.
MRA Call Flow with ICE using Relay Address
In cases where the Host and Server-reflexive addresses cannot negotiate successfully, like deployments with a symmetric NAT, endpoints can utilize TURN Relay as the ICE optimized media path. The following figure shows an MRA call with ICE where endpoints use the Relay address of the Cisco Expressway TURN server to send media between endpoints.
Signaling Path Encryption Between Expressway-C and Unified CM
Security and encryption are important factors when considering direct endpoint-to-endpoint messaging. Because MRA endpoints are sending signaling and media over the internet, they are forced to operate in encrypted mode. In normal MRA mode (without ICE), encryption is always required between the endpoint and the Expressway-C but optional between the Expressway-C and Unified CM. This is possible because the Expressway-C can terminate the media stream and decrypt the packets if the internal leg is unencrypted.
The following figure shows the encryption without ICE Passthrough where encryption is forced between MRA endpoints and Expressway-C, and optional in the internal network. On an MRA call, a different encryption key is exchanged on each leg (Key 1 and Key 2), and the Expressway-C decrypts and re-encrypts the media between the 2 legs. The invite to Unified CM does not need a key if the internal leg is not encrypted.
However, with ICE passthrough mode, the endpoints must be able to exchange their crypto keys end-to-end because the media packets are sent to each other directly and not through the Expressway-C. Whenever crypto keys are included in a SIP message, the message must be sent over TLS to protect the key. Because the SIP signaling path must be encrypted end-to-end to send the crypto keys end-to-end, the internal leg between the Expressway-C and Unified CM must be encrypted. If the signaling path is unencrypted, the crypto keys are dropped during call setup.
The following figure shows the encryption required with ICE Passthrough where the signaling leg between the Expressway-C and Unified CM is also encrypted.
Supported Components
Cisco Expressway-based Deployments
Currently, ICE Media Path Optimization support exists only on MRA deployments. It is not tested and supported on the following service deployments:
-
Cisco Webex Hybrid Services
-
Jabber Guest
-
Collaboration Meeting Room (CMR) Cloud
-
Business to Business Calling
HCS Deployments
ICE passthrough can be used to optimize the media path of the MRA calls in the following HCS deployment types:
-
HCS Shared Architecture
-
HCS Dedicated Server and HCS Dedicated Instance
-
Customer-owned Collaboration Architecture
Note |
HCS Contact Center does not support ICE passthrough. |
Supported Components
ICE Media Path Optimization is supported with the following components:
-
HCS 11.5 or later (for HCS deployments)
-
Cisco Unified Communications Manager (Unified CM) 11.5 or later
-
Cisco Expressway-C and Cisco Expressway-E X12.5 or later
Supported Endpoints
The following ICE-capable endpoints can send media directly to each other when they are MRA-registered and ICE Media Path Optimization is enabled:
-
Cisco Jabber clients, version 12.5 or later subject to using Unified Communications Manager 12.5 or later
-
Cisco IP Conference Phone 7832, version 12.5(1) or later
-
Cisco IP Phone 7800 Series (MRA-compatible models only), version 12.5(1) or later
-
Cisco IP Phone 8800 Series (MRA-compatible models only), version 12.5(1) or later
-
Cisco TelePresence DX, MX, SX Series, CE version 9.6.1 or later