Cisco Cisco Expressway
TLS verify mode set to On if the Unified CM discovery had TLS verify mode enabled. This means that the
Expressway-C will verify the CallManager certificate for subsequent SIP communications. Note that secure
profiles are downgraded to use TCP if Unified CM is not in mixed mode.
Expressway-C will verify the CallManager certificate for subsequent SIP communications. Note that secure
profiles are downgraded to use TCP if Unified CM is not in mixed mode.
The Expressway neighbor zones to Unified CM use the names of the Unified CM nodes that were returned
by Unified CM when the Unified CM publishers were added (or refreshed) to the Expressway. The
Expressway uses those returned names to connect to the Unified CM node. If that name is just the host
name then:
by Unified CM when the Unified CM publishers were added (or refreshed) to the Expressway. The
Expressway uses those returned names to connect to the Unified CM node. If that name is just the host
name then:
n
it needs to be routable using that name
n
this is the name that the Expressway expects to see in the Unified CM's server certificate
If you are using secure profiles, ensure that the root CA of the authority that signed the Expressway-C
certificate is installed as a CallManager-trust certificate (
certificate is installed as a CallManager-trust certificate (
Security > Certificate Management
in the
Cisco
Unified OS Administration
application).
Media encryption
Media encryption is enforced on the call legs between the Expressway-C and the Expressway-E, and
between the Expressway-E and endpoints located outside the enterprise.
between the Expressway-E and endpoints located outside the enterprise.
The encryption is physically applied to the media as it passes through the B2BUA on the Expressway-C.
Limitations
n
The IPV4 protocol only is supported for mobile and remote access users
n
In Expressway-E systems that use dual network interfaces, XCP connections (for IM&P XMPP traffic)
always use the non-external (i.e. internal) interface. This means that XCP connections may fail in
deployments where the Expressway-E internal interface is on a separate network segment and is used for
system management purposes only, and where the traversal zone on the Expressway-C connects to the
Expressway-E's external interface.
always use the non-external (i.e. internal) interface. This means that XCP connections may fail in
deployments where the Expressway-E internal interface is on a separate network segment and is used for
system management purposes only, and where the traversal zone on the Expressway-C connects to the
Expressway-E's external interface.
Unsupported Jabber features when using mobile and remote access
n
Calls to/from additional lines on IP phones and endpoints that support multiple lines; only the primary line is
supported via Mobile and Remote Access
supported via Mobile and Remote Access
n
Directory access mechanisms other than UDS
n
Certificate provisioning to remote endpoints e.g. CAPF
n
Features that rely on the SIP UPDATE method (
) will not work as expected because the
Expressway does not support this method. For example, CUCM and endpoints use UPDATE to implement
blind transfer, which does not work correctly via MRA.
blind transfer, which does not work correctly via MRA.
n
Peer-to-peer file transfer when using IM and Presence Service and Jabber is unsupported via MRA
l
Managed File Transfer (MFT) with IM and Presence Service 10.5.2 (and later) and Jabber 10.6 (and
later) clients is supported via MRA
later) clients is supported via MRA
l
File transfer with WebEx Messenger Service and Cisco Jabber is supported via MRA
n
Deskphone control (QBE/CTI)
n
Additional mobility features including DVO-R, GSM handoff and session persistency
n
Hunt group/hunt pilot/hunt list
n
Self-care portal
Unified Communications Mobile and Remote Access via Cisco Expressway Deployment Guide (X8.5.2)
Page 42 of 54
Additional information