The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter contains configuration tasks that describe how to complete the base configuration that provides Mobile and Remote Access for compatible endpoints. These procedures can be used for single cluster, multi-cluster, single domain and multi-domain scenarios.
Review the MRA Requirements chapter before you configure MRA.
Make sure that your system has the required certificates to deploy MRA. For details, refer to Certificate Requirements
| Command or Action | Purpose | |
|---|---|---|
| Step 1 |
Set the System host name, domain name, and NTP source for each Expressway-C and E server. |
|
| Step 2 |
Make sure that SIP is enabled on both Expressway-E and Expressway-C. |
|
| Step 3 |
Recommended. Disable Automated Intrusion Prevention on Expressway-C and enable it on Expressway-E. |
|
| Step 4 |
Set the Unified Communications mode to Mobile and Remote Access. |
|
| Step 5 |
On Expressway-C, add internal UC domains and any other relevant domains, such as edge domains, and Presence domains. |
|
| Step 6 |
Add Internal UC Clusters: |
From each Expressway-C cluster, create connections to your internal UC clusters. |
| Step 7 |
Configure settings for MRA Access Control, including OAuth authentication and SAML SSO settings. |
|
| Step 8 |
Recommended. If your system supports it, configure OAuth authentication. |
|
| Step 9 |
Optional. Configure SAML SSO, allowing for common identity between external Jabber clients and users' Unified CM profiles. |
|
| Step 10 |
Configure an encrypted UC traversal zone between Expressway-C and Expressway-E. |
ICE Media Path Optimization—ICE is an optional feature that optimizes the media path for MRA calls. ICE lets MRA-registered endpoints send media to each other directly, such that the media bypasses the WAN and Expressway servers.
Features and Additional Configurations—Refer to this chapter for information on MRA features and optional configurations.
Onboarding MRA Devices—After you have configured your system, device activation codes provide a secure method to onboard remote MRA devices.
 Note |
A single Expressway server can have a single host name and domain name, even if you have multiple Edge domains. |
| Step 1 |
On Cisco Expressway-C, configure server address information: |
| Step 2 |
Configure NTP settings: |
| Step 3 |
Repeat this procedure on each server in the Expressway-C cluster. |
| Step 4 |
After configuring Expressway-C, repeat this procedure for each server in the Expressway-E cluster. |
Note |
SIP and H.323 protocols are disabled by default on new installs of X8.9.2 and later versions. |
| Step 1 |
On the Expressway-C primar peer, go to . |
| Step 2 |
Set SIP mode to On. |
| Step 3 |
Click Save. |
| Step 4 |
Repeat the procedure on Expressway-E primary peer. |
Note |
If your Expressway-C is newly installed from X8.9 onwards, the automated intrusion protection service is running by default on both Expressway-C and Expressway-E (check this). |
| Step 1 |
On Expressway-C, disable Automated Intrusion Protection:
|
||
| Step 2 |
On Expressway-E, enable Automated Intrusion Protection (the service is On by default):
|
| Step 1 |
On the Expressway-C, go to . |
| Step 2 |
Set Unified Communications mode to Mobile and Remote Access. |
| Step 3 |
Click Save. |
| Step 4 |
Repeat this procedure on Expressway-E. |
Enterprise domain
Internal UC domains (if they are different from the enterprise domain)
Edge domains (if they are different from the other domains)
Presence domains (if they are different from the other domains)
| Step 1 |
On Expressway-C, go to . |
| Step 2 |
Enter the Domain name. |
| Step 3 |
For each of the following services, set the corresponding drop-down to On or Off depending on whether you want to apply that service to this domain.
|
| Step 4 |
If you have multiple Deployments configured, assign the deployment to which this domain applies. Note that this field appears only if you have configured multiple Deployments. |
| Step 5 |
Click Save. |
| Step 6 |
Repeat this procedure if you need to add additional domains. |
| Step 1 |
On the Expressway-C primary peer, go to . |
| Step 2 |
Click New and add the following details for the publisher node:
 |
| Step 3 |
Click Add Address to test the connection. |
| Step 4 |
If you have multiple Unified CM clusters, repeat the above steps to add the publisher nodes for the additional Unified CM clusters to this Expressway-C cluster. |
| Step 5 |
After you have added all Unified CM publisher nodes, click Refresh Servers. |
| Step 6 |
If you have multiple Expressway-C clusters, repeat this procedure on other Expressway-C clusters until all Expressway-C clusters have connections to all Unified CM clusters and nodes. |
Expressway-C automatically generates non-configurable neighbor zones between itself and each discovered Unified CM node. A TCP zone is always created, and a TLS zone is created also if the Unified CM node is configured with a Cluster Security Mode () of 1 (Mixed) (so that it can support devices provisioned with secure profiles). The TLS zone is configured with its 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. Each zone is created with a name in the format 'CEtcp-<node name>' or 'CEtls-<node name>'.
From version X12.5, Expressway automatically generates a neighbor zone named "CEOAuth <Unified CM name>" between itself and each discovered Unified CM node when SIP OAuth Mode is enabled on Unified CM. For details, see Configure SIP OAuth Mode.
A non-configurable search rule, following the same naming convention, is also created automatically for each zone. The rules are created with a priority of 45. If the Unified CM node that is targeted by the search rule has a long name, the search rule will use a regex for its address pattern match.
Note that load balancing is managed by Unified CM when it passes routing information back to the registering endpoints.
| Step 1 |
On Expressway-C go to . |
| Step 2 |
Click New and add the following details for the database publisher node:
|
| Step 3 |
Click Add Address to test the connection. |
| Step 4 |
If you have multiple IM and Presence clusters, repeat the above steps to add the database publisher nodes for those additional clusters to this Expressway-C cluster. |
| Step 5 |
After you have added all IM and Presence database publisher ndoes, click Refresh Servers. |
| Step 6 |
If you have multiple Expressway-C clusters, repeat this procedure on other Expressway-C clusters until each Expressway-C cluster has a connection to each IM and Presence cluster node. |
| Step 1 |
On Expressway-C go to . |
| Step 2 |
Click New and add the following details for the publisher node:
|
| Step 3 |
Click Add Address to test the connection. |
| Step 4 |
If you have multiple Unity Connection clusters, repeat the above steps to add the publisher nodes for those additional clusters to this Expressway-C cluster. |
| Step 5 |
After you have added all Unity Connection clusters to this Expressway-C, click Refresh Servers. |
| Step 6 |
If you have multiple Expressway-C clusters, repeat this procedure on other Expressway-C clusters until each Expressway-C cluster has a connection to each Unity Connection cluster node. |
Define how clients must authenticate for Mobile and Remote Access (MRA) requests.
 Caution |
If you are upgrading from X8.9 or earlier, the settings applied after the upgrade are not the same as listed here. R refer instead to the upgrade instructions in the Expressway Release Notes. |
| Step 1 |
On the Expressway-C, go to . |
| Step 2 |
Configure authentication settings:
|
| Step 3 |
Configure the additional fields. For additional information about the field settings, see Expressway (Expressway-C) Settings for Access Control |
The following table provides descriptions that appear under MRA Access Control (). You can use this configuration page to configure OAuth authentication settings and SAML SSO settings for Mobile and Remote Access.
|
Field |
Description |
|---|---|
|
Authentication path |
Hidden field until MRA is enabled. Defines how MRA authentication is controlled.
Default Setting: None before MRA is turned on. After MRA is turned on, the default is UCM/LDAP. |
|
Authorize by OAuth token with refresh |
This option requires self-describing tokens for authorization. It's our recommended authorization option for all deployments that have the infrastructure to support them. OAuth is supported by Cisco Jabber and Cisco Webex clients as well as by Cisco IP Phones that onboard using device activation codes in MRA mode. Important: From X8.10.1, the Expressway fully supports the benefits of self-describing tokens (including token refresh, fast authorization, and access policy support). However, not all of the benefits are actually available throughout the wider solution. Depending on what other products you use (Unified CM, IM and Presence Service, Cisco Unity Connection) and what versions they are on, not all products fully support all benefits of self-describing tokens. If you use this option on Expressway, you must also enable OAuth with refresh on the Unified CMs, and on Cisco Unity Connection if used. The process is summarized below. Default Setting: On |
|
Authorize by OAuth token (previously SSO Mode) |
Available if Authentication path is SAML SSO or SAML SSO and UCM/LDAP. This option requires authentication through the IdP. Currently, only Cisco Jabber and Cisco Webex clients are capable of using this authorization method, which is not supported by other MRA endpoints. Default Setting: Off |
|
Authorize by user credential |
Available if Authentication path is UCM/LDAP or SAML SSO and UCM/LDAP. Clients attempting to perform authentication by user credentials are allowed through MRA. This includes Jabber, and supported IP phone and TelePresence devices. Default Setting: Off |
|
Identity providers: Create or modify IdPs |
Available if Authentication path is SAML SSO or SAML SSO and UCM/LDAP. For more information, see Identity Provider Selection. Default Setting: — |
|
SAML Metadata |
Available if Authentication path is SAML SSO or SAML SSO and UCM/LDAP. Determines how to generate the metadata file for the SAML agreement. The possible modes are:
|
|
Identity providers: Export SAML data |
Available if Authentication path is SAML SSO or SAML SSO and UCM/LDAP. For details about working with SAML data, see SAML SSO Authentication Over the Edge. Default Setting: — |
|
Allow Jabber iOS clients to use embedded Safari |
By default the IdP or Unified CM authentication page is displayed in an embedded web browser (not the Safari browser) on iOS devices. That default browser is unable to access the iOS trust store, and so cannot use any certificates deployed to the devices. This setting optionally allows Jabber on iOS devices to use the native Safari browser. Because the Safari browser is able to access the device trust store, you can now enable password-less authentication or two-factor authentication in your OAuth deployment. A potential security issue exists for this option. The mechanism to return browser control from Safari to Jabber after the authentication completes, uses a custom URL scheme that invokes a custom protocol handler. It's possible that another application other than Jabber could intercept the scheme and gain control from iOS. In that case, the application would have access to the OAuth token in the URL. If you are confident that your iOS devices will not have other applications that register the Jabber custom URL scheme, for example because all mobile devices are managed, then it's safe to enable the option. If you are concerned about the possibility of another app intercepting the custom Jabber URL, then do not enable the embedded Safari browser. Default Setting: No |
|
Check for internal authentication availability |
Available if Authorize by OAuth token with refresh or Authorize by OAuth token is enabled. The default is No, for optimal security and to reduce network traffic. Controls how the Expressway-E reacts to remote client authentication requests by selecting whether or not the Expressway-C should check the home nodes. The request asks whether the client may try to authenticate the user by OAuth token, and includes a user identity with which the Expressway-C can find the user's home cluster:
The option to choose depends on your implementation and security policy. If all Unified CM nodes support OAuth tokens, you can reduce response time and overall network traffic by selecting No. Or select Yes if you want clients to use either mode of getting the edge configuration—during rollout or because you can't guarantee OAuth on all nodes. Caution: Setting this to Yes has the potential to allow rogue inbound requests from unauthenticated remote clients. If you specify No for this setting, the Expressway prevents rogue requests. Default Setting: No |
|
Allow activation code onboarding |
Only available if Authorize by OAuth token with refresh or Authorize by OAuth token is enabled. This setting enables onboarding by activation code in the Expressway. The default value is No. Set the value to Yes to enable this option. Default Setting: No |
|
SIP token extra time to live |
Available if Authorize by OAuth token is On. Optionally extends the time-to-live for simple OAuth tokens (in seconds). Gives users a short window to accept calls after their credentials expire. However, it increases the potential security exposure. Default Setting: 0 seconds |
Note |
On Expressway, you can check what authorization methods your Unified CM servers support. This displays the version numbers in use. On Expressway, go to . |
SAML-based SSO is an option for authenticating Unified Communications service requests. The requests can originate inside the enterprise network, or, as described here, from clients requesting Unified Communications services from outside through MRA.
SAML SSO authentication over the edge requires an external identity provider (IdP). It relies on the secure traversal capabilities of the Expressway pair at the edge, and on trust relationships between the internal service providers and an externally resolvable IdP.
The endpoints do not need to connect via VPN. They use one identity and one authentication mechanism to access multiple Unified Communications services. Authentication is owned by the IdP, and there is no authentication at the Expressway, nor at the internal Unified CM services.
The Expressway supports two types of OAuth token authorization with SAML SSO:
Simple (standard) tokens. These always require SAML SSO authentication.
Self-describing tokens with refresh. These can also work with Unified CM-based authentication
Note |
|
Cisco Jabber 10.6 or later. Jabber clients are the only endpoints supported for OAuth token authorization through Mobile and Remote Access (MRA).
Cisco Unified Communications Manager 10.5(2) or later
Cisco Unity Connection 10.5(2) or later
Cisco Unified Communications Manager IM and Presence Service 10.5(2) or later
Cisco Jabber determines whether it is inside the organization's network before requesting a Unified Communications service. If Jabber is outside the network, it requests the service from the Expressway-E on the edge of the network. If SAML SSO authentication is enabled at the edge, the Expressway-E redirects Jabber to the IdP with a signed request to authenticate the user.
The IdP challenges the client to identify itself. When this identity is authenticated, the IdP redirects Jabber's service request back to the Expressway-E with a signed assertion that the identity is authentic.
The Unified Communications service trusts the IdP and the Expressway-E, so it provides the service to the Jabber client.
Expressway supports using self-describing tokens as an MRA authorization option from X8.10.1. (Set Authorize by OAuth token with refresh to Yes.) Self-describing tokens offer significant benefits:
Token refresh capability, so users do not have to repeatedly re-authenticate.
Fast authorization.
Access policy support. The Expressway can enforce MRA access policy settings applied to users on the Unified CM.
Roaming support. Tokens are valid on-premises and remotely, so roaming users do not need to re-authenticate if they move between on-premises and off-premises.
Expressway uses self-describing tokens in particular to facilitate Cisco Jabber users. Jabber users who are mobile or work remotely, can authenticate while away from the local network (off-premises). If they originally authenticate on the premises, they do not have to re-authenticate if they later move off-premises. Similarly, users do not have to re-authenticate if they move on-premises after authenticating off-premises. Either case is subject to any configured access token or refresh token limits, which may force re-authentication.
For users with Jabber iOS devices, the high speeds supported by self-describing tokens optimize Expressway support for Apple Push Notifications (APNs).
We recommend self-describing token authorization for all deployments, assuming the necessary infrastructure exists to support it. Subject to proper Expressway configuration, if the Jabber client presents a self-describing token then the Expressway simply checks the token. No password or certificate-based authentication is needed. The token is issued by Unified CM (regardless of whether the configured authentication path is by external IdP or by the Unified CM). Self-describing token authorization is used automatically if all devices in the call flow are configured for it.
The Expressway-C performs token authorization. This avoids authentication and authorization settings being exposed on Expressway-E.
Expressway is already providing Mobile and Remote Access for Cisco Jabber.
All other devices in the call flow are similarly enabled.
You have the following minimum product versions installed, or later:
Expressway X8.10.1
Cisco Jabber iOS 11.9
If you have a mix of Jabber devices, with some on an older software version, the older ones will use simple OAuth token authorization (assuming SSO and an IdP are in place).
Cisco Unified Communications Manager 11.5(SU3)
Cisco Unified Communications Manager IM and Presence Service 11.5(SU3)
Cisco Unity Connection 11.5(SU3)
Make sure that self-describing authentication is enabled on the Cisco Expressway-C (Authorize by OAuth token with refresh setting) and on Unified CM and/or IM and Presence Service (OAuth with Refresh Login Flow enterprise parameter).
You must refresh the Unified CM nodes defined on the Expressway. This fetches keys from the Unified CM that the Expressway needs to decrypt the tokens.
This topic provides information on the prerequisites that your deployment must meet for OAuth tokens.
An Expressway-E and an Expressway-C are configured to work together at your network edge.
A Unified Communications traversal zone is configured between the Expressway-C and the Expressway-E.
The SIP domain that will be accessed via OAuth is configured on the Expressway-C.
The Expressway-C has MRA enabled and has discovered the required Unified CM resources.
The required Unified CM resources are in the HTTP allow list on the Expressway-C.
If you are using multiple deployments, the Unified CM resources to be accessed by OAuth are in the same deployment as the domain to be called from Jabber clients.
Clients are configured to request the internal services using the correct domain names / SIP URIs / Chat aliases.
The default browser can resolve the Expressway-E and the IdP.
Users who are associated with non-OAuth MRA clients or endpoints, have their credentials stored in Unified CM. Or Unified CM is configured for LDAP authentication
The domain that is on the IdP certificate must be published in the DNS so that clients can resolve the IdP.
Cisco Collaboration solutions use SAML 2.0 (Security Assertion Markup Language) to enable SSO (singlesign-on) for clients consuming Unified Communications services.
If you choose SAML-based SSO for your environment, note the following:
SAML 2.0 is not compatible with SAML 1.1 and you must select an IdP that uses the SAML 2.0 standard.
SAML-based identity management is implemented in different ways by vendors in the computing and networking industry, and there are no widely accepted regulations for compliance to the SAML standards.
The configuration of and policies governing your selected IdP are outside the scope of Cisco TAC (Technical Assistance Center) support. Use your relationship and support contract with your IdP Vendor to assist in configuring the IdP properly. Cisco cannot accept responsibility for any errors, limitations, or specific configuration of the IdP.
Although Cisco Collaboration infrastructure may prove to be compatible with other IdPs claiming SAML 2.0 compliance, only the following IdPs have been tested with Cisco Collaboration solutions:
OpenAM 10.0.1
Active Directory Federation Services 2.0 (AD FS 2.0)
PingFederate® 6.10.0.4
| Step 1 |
On Expressway-C, verify that your MRA Access Control settings have OAuth token refresh enabled.
|
| Step 2 |
On the Cisco Unified Communications Manager publisher node, enable the OAuth Refresh Login Flow enterprise parameter:
|
| Step 3 |
On Cisco Unity Connection, enable OAuth Refresh Logins and then configure the Authz Server.
|
Note |
For more detailed information on SIP OAuth Mode, refer to the "Configure SIP OAuth Mode" chapter of the Feature Configuration Guide for Cisco Unified Communications Manager Releases 12.5(1) or higher. |
| Step 1 |
For each server that uses SIP OAuth, set the SIP OAuth ports.
|
| Step 2 |
Configure an OAuth Connection to Expressway-C:
|
| Step 3 |
Enable SIP OAuth Mode:
|
| Step 4 |
Restart the Cisco CallManager service:
|
| Step 5 |
Enable OAuth Authentication within the Phone Security Profile.
|
Configure SAML SSO for your internal UC applications. For details, see SAML SSO Deployment Guide for Cisco Unified Communications Solutions.
Within the MRA Access Control settings on Expressway-C, the Authentication path field must be set to either SAML SSO authentication or SAML SSO and UCM/LDAP.
| Command or Action | Purpose | |
|---|---|---|
| Step 1 |
Export a metadata file from Expressway-C. |
|
| Step 2 |
Configure the Identity Provider |
Import the Expressway metadata to the Identity Provider (IdP), configure the IdP and then export a metadata file from the IdP. |
| Step 3 |
Import the Idp metadata to Expressway-C and complete the configuration |
|
| Step 4 |
In Expressway-C, associate the domain to the Identity Provider. |
|
| Step 5 |
ADFS only. If you are using is Active Directory Federation Services, complete these additional tasks on the IdP to complete the configuration. |
From X12.5, Cisco Expressway supports using a single, cluster-wide metadata file for SAML agreement with an IdP. Previously, you had to generate metadata files per peer in an Expressway-C cluster (for example, six metadata files for a cluster with six peers). For the cluster-wide option, run this procedure on the Expressway-C primary peer.
Note |
If you change any of the following Expressway settings in a SAML SSO deployment, you must re-export metadata from the primary peer and reimport metadata to the IdP:
|
Note |
The Expressway-C must have a valid connection to the Expressway-E before you can export the Expressway-C's SAML metadata. |
| Step 1 |
Go to . |
| Step 2 |
In MRA Access Control section, choose a mode from the SAML Metadata list:
For new deployments, the SAML Metadata mode always defaults to Cluster. For existing deployments, the mode defaults to Cluster if SAML SSO was disabled in your previous Expressway release, or to Peer if SAML SSO was previously enabled. |
| Step 3 |
Click Export SAML data. This page lists the connected Expressway-E, or all the Expressway-E peers if it's a cluster. These are listed because data about them is included in the SAML metadata for the Expressway-C. |
| Step 4 |
If you choose Cluster for SAML Metadata, click Generate Certificate. |
| Step 5 |
Do the following:
|
| Step 6 |
Copy the resulting file(s) to a secure location that you can access when you need to import SAML metadata to the IdP. |
| Step 1 |
On the Expressway-C, go to . You only need to do this on the primary peer of the cluster. |
||
| Step 2 |
Click Import new IdP from SAML. |
||
| Step 3 |
Use the Import SAML file control to locate the SAML metadata file from the IdP. |
||
| Step 4 |
Set the Digest to the required SHA hash algorithm. The Expressway uses this digest for signing SAML authentication requests for clients to present to the IdP. The signing algorithm must match the one expected by the IdP for verifying SAML authentication request signatures. |
||
| Step 5 |
Click Upload. The Expressway-C can now authenticate the IdP's communications and encrypt SAML communications to the IdP.
|
You need to associate a domain with an IdP if you want the MRA users of that domain to authenticate through the IdP. The IdP adds no value until you associate at least one domain with it.
There is a many-to-one relationship between domains and IdPs. A single IdP can be used for multiple domains, but you may associate just one IdP with each domain.
| Step 1 |
On the Expressway-C, open the IdP list () and verify that your IdP is in the list. The IdPs are listed by their entity IDs. The associated domains for each are shown next to the ID. |
| Step 2 |
Click Associate domains in the row for your IdP. This shows a list of all the domains on this Expressway-C. There are checkmarks next to domains that are already associated with this IdP. It also shows the IdP entity IDs if there are different IdPs associated with other domains in the list. |
| Step 3 |
Check the boxes next to the domains you want to associate with this IdP. If you see (Transfer) next to the check box, checking it breaks the domain's existing association and associates the domain with this IdP. |
| Step 4 |
Click Save. The selected domains are associated with this IdP. |
After creating Relying Party Trusts for the Expressway-Es, you must set some properties of each entity, to ensure that Active Directory Federation Services (ADFS) formulates the SAML responses as Expressway-E expects them. In addition, you also need to add a claim rule, for each relying party trust,
| Step 1 |
Configure ADFS to sign the whole response. In Windows PowerShell®, run the following command for each Expressway-E's <EntityName> once per Relying Party Trust created on ADFS: Set-ADFSRelyingPartyTrust -TargetName "<EntityName>" -SAMLResponseSignatureMessageAndAssertion where <EntityName> must be a display name for the Relying Party Trust of Expressway-E as set in ADFS. |
| Step 2 |
Add a Claim Rule for each relying party trust:
|
Note |
This configuration automatically sets up an appropriate traversal zone (a traversal client zone when selected on Expressway-C or a traversal server zone when selected on Expressway-E) that uses SIP TLS with TLS verify mode set to On, and Media encryption mode set to Force encrypted. |
Make sure that Expressway-C and Expressway-E trust each other's certificates. As each Expressway acts both as a client and as a server you must ensure that each Expressway’s certificate is valid both as a client and as a server. For detailed information on certificate exchance requirements, see Certificate Requirements.
Be aware that Expressway uses the SAN attribute to validate received certificates, not the CN.
If an H.323 or a non-encrypted connection is also required, a separate pair of traversal zones must be configured.
| Step 1 |
On the Expressway-C primary peer, go to . |
||||||||||||||||||||||||||||||||||||||||||
| Step 2 |
Click New. |
||||||||||||||||||||||||||||||||||||||||||
| Step 3 |
Configure the fields in the below table. Apply the settings for the appropriate Expressway server (C or E).
|
||||||||||||||||||||||||||||||||||||||||||
| Step 4 |
Click Create zone. |
||||||||||||||||||||||||||||||||||||||||||
| Step 5 |
Repeat these steps on the Expressway-E primary peer, applying the settings in the Expressway-E column. |
||||||||||||||||||||||||||||||||||||||||||
This deployment requires secure communications between the Expressway-C and the Expressway-E, and between the Expressway-E and endpoints located outside the enterprise. This involves the mandating of encrypted TLS communications for HTTP, SIP and XMPP, and, where applicable, the exchange and checking of certificates. Jabber endpoints must supply a valid username and password combination, which will be validated against credentials held in Unified CM. All media is secured over SRTP.
Expressway-C automatically generates non-configurable neighbor zones between itself and each discovered Unified CM node. A TCP zone is always created, and a TLS zone is created also if the Unified CM node is configured with a Cluster Security Mode () of 1 (Mixed) (so that it can support devices provisioned with secure profiles). The TLS zone is configured with its 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 |
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:
It needs to be routable using that name.
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 ( in the Cisco Unified OS Administration application).
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.
The encryption is physically applied to the media as it passes through the B2BUA on the Expressway-C.
Feedback