- HTTP Allow List Formats
Book Title
Mobile and Remote Access Through Cisco Expressway Deployment Guide (X14.0)
MRA Requirements and Prerequisites
- PDF - Complete Book (9.1 MB)PDF - This Chapter (1.11 MB) View with Adobe Reader on a variety of devices
Results
Updated: April 26, 2021Chapter: MRA Requirements and Prerequisites
Chapter Contents- MRA Requirements and Prerequisites
- Mobile and Remote Access Ports
- Network Infrastructure Requirements
- IP Addresses
- Network Domain
- DNS
- SRV Records
- Public DNS (External Domains)
- Local DNS (Internal Domains)
- Product Versions
- Unified CM Requirements
- IM and Presence Service Requirements
- MRA-Compatible Clients
- MRA-Compatible Endpoints
- EX, MX, and SX Series Endpoints (Running TC Software)
- Considerations for Android-based DX650, DX80, and DX70 Devices and Supported IP Phone 7800 and 8800 models
- Which MRA Features are Supported
- UC Feature Support and Limitations
- Unsupported Expressway Features and Limitations
- Partial Support for Cisco Jabber SDK
MRA Requirements and Prerequisites
This chapter contains information on the requirements and prerequisites that your deployment must meet in order to configure and deploy Mobile and Remote Access.
Mobile and Remote Access Ports
For MRA port information, go to the Cisco Expressway IP Port Usage Configuration Guide at Cisco Expressway Series Configuration Guides. The guide describes the ports that you can use between Expressway-C in the internal network, Expressway-E in the DMZ, and the public internet.
Network Infrastructure Requirements
IP Addresses
Assign separate IP addresses to the Expressway-C and the Expressway-E. Do not use a shared address for both elements, as the firewall cannot distinguish between them.
Network Domain
The ideal scenario for MRA is to have a single domain with a split DNS configuration, and this is the recommended approach. This is not always possible, so there are some other approaches to deal with various alternative scenarios.
The domain to which the calls are routed must match with the MRA domain to which the endpoints were registered. For example, if endpoints are registered with the domain exp.example.com , the calls must be routed to this domain, and it must not be routed to the domain cluster1.exp.example.com .
DNS
Single Domain with Split DNS - Recommended
A single domain means that you have a common domain ( example.com ) with separate internal and external DNS servers. This allows DNS names to be resolved differently by clients on different networks depending on DNS configuration, and aligns with basic Jabber service discovery requirements.
Dual Domain without Split DNS
From X12.5, the Cisco Expressway Series supports the case where MRA clients use an external domain to lookup the _collab-edge SRV record, and the _cisco-uds SRV record for that same external domain cannot be resolved by the Expressway-C. This is typically the case when split DNS is not available for the external domain. And prior to X12.5 this required a pinpoint subdomain or some other DNS workaround on the Expressway-C, to satisfy the client requirements for resolving the _cisco-uds record.
Limitation: This case is not supported for Unified CM nodes identified by IP addresses, only for FQDNs.
This feature also supports a secondary case, for MRA deployments that only allow Jabber access over MRA even if users are working on-premises. In this case only one domain is required and typically the DNS records are publicly resolvable (although this is not required if MRA access is disallowed for users when off premises). The change in X12.5 means that there is no need to have a _cisco-uds._tcp. DNS SRV record available to Cisco Expressway-C or to the Jabber clients.
Single Domain without Split DNS
Deployments that require Jabber clients to always connect over MRA also benefit from the X12.5 update that no longer requires the Expressway-C to resolve the _cisco-uds DNS SRV record. So administrators only need to configure the _collab-edge DNS SRV record, and Jabber clients using service discovery will only have the option of connecting over MRA.
URL for Cisco Meeting Server Web Proxy and MRA domain cannot be the same
If you use both the CMS Web Proxy service and MRA on the same Expressway, the following configuration items must be assigned different values per service. If you try to use the same value, the service that was configured first will work, but the other one will fail:
- MRA domain(s). The domain(s) configured on Expressway and enabled for Unified CM registration
- CMS Web Proxy URL link. Defined in the Expressway "Guest account client URI" setting on the Expressway > Configuration > Unified Communications > Cisco Meeting Server page.
Multiple External Domains for Mobile and Remote Access
Cisco Expressway supports Mobile and Remote Access with multiple external domains. With this deployment, you will have more than one external domain where your MRA clients may reside. Expressway-E must be able to connect to all of them. To configure this deployment, do the following:
- On Expressway-E, configure _collab-edge._tls. and _sips_tcp. DNS SRV records for each Edge domain.
- Configure A records that point the Expressway-E hostname to the public IP address of Expressway-E.
- For internal DNS, add A and PTR records that point to Expressway-E FQDN. Add these records to all Expressway-C nodes.
- Configure the _cisco_uds SRV record for every domain to point to your Unified Communications Manager clusters.
- On the Domains page of Expressway-C, add each of the internal domains that point to the Unified Communications Manager cluster.
For more detail, including a configuration checklist that summarizes the domain-specific configuration tasks for multiple domains, see Multidomain Configuration Summary.
SRV Records
This section summarizes the public (external) and local (internal) DNS requirements for MRA. For more information, see the Cisco Jabber Planning Guide for your version on the Jabber Install and Upgrade Guides page.
Public DNS (External Domains)
The public, external DNS must be configured with _collab-edge._tls. SRV records so that endpoints can discover the Expressway-Es to use for Mobile and Remote Access. You also need SIP service records for general deployment (not specifically for MRA).
Local DNS (Internal Domains)
Although we recommend that the local, internal DNS is configured with _cisco-uds._tcp. SRV records, from X12.5 this is no longer a requirement.
From version X8.8, if you use the IM and Presence Service over MRA (or any XMPP federation that uses XCP TLS connections between Expressway-C and Expressway-E), you must create forward and reverse DNS entries for each Expressway-E system. This is so that Expressway-C systems making TLS connections to them can resolve the Expressway-E FQDNs and validate the Expressway-E certificates. This requirement affects only the internal, LAN-side interface and does not apply to the external IP-side.
Create internal DNS records, for both forward and reverse lookups, for all Unified Communications nodes used with MRA. This allows Expressway-C to find the nodes when IP addresses or hostnames are used instead of FQDNs.
Ensure that the cisco-uds SRV records are NOT resolvable outside of the internal network, otherwise the Jabber client will not start MRA negotiation via the Expressway-E.
Firewall Configuration
- Ensure that the relevant ports are configured on your firewalls between your internal network (where the Expressway-C is located) and the DMZ (where the Expressway-E is located) and between the DMZ and the public internet. No inbound ports are required to be opened on the internal firewall. The internal firewall must allow the following outbound connections from Expressway-C to Expressway-E: SIP: TCP 7001; Traversal Media: UDP 2776 to 2777 (or 36000 to 36011 for large VM/appliance); XMPP: TCP 7400; HTTPS (tunneled over SSH between C and E): TCP 2222. The external firewall must allow the following inbound connections to Expressway: SIP: TCP 5061; HTTPS: TCP 8443; XMPP: TCP 5222; Media: UDP 36002 to 59999. For more information, see Cisco Expressway IP Port Usage Configuration Guide , for your version, on the Cisco Expressway Series configuration guides page.
- Do not use a shared address for the Expressway-E and the Expressway-C, as the firewall cannot distinguish between them. If you use static NAT for IP addressing on the Expressway-E, make sure that any NAT operation on the Expressway-C does not resolve to the same traffic IP address. We do not support shared NAT addresses between Expressway-E and Expressway-C.
- The traversal zone on the Expressway-C points to the Expressway-E through the Peer address field on the traversal zone, which specifies the address of the Expressway-E server.
- For dual NIC deployments, you can specify the Expressway-E address using a FQDN that resolves to the IP address of the internal interface. With split DNS you can optionally use the same FQDN as is available on the public DNS. If you don't use split DNS you must use a different FQDN.
- For single NIC with static NAT (this deployment is NOT recommended), you must specify the Expressway-E address using a FQDN that resolves to the public IP address. This also means that the external firewall must allow traffic from the Expressway-C to the external FQDN of the Expressway-E. This is known as NAT reflection, and may not be supported by all types of firewalls.
For more information, see the "Advanced networking deployments" appendix in the Expressway Basic Configuration (Expressway-C with Expressway-E) Deployment Guide
Bandwidth Restrictions
The Maximum Session Bit Rate for Video Calls on the default region on Cisco Unified Communications Manager is 384 kbps by default. The Default call bandwidth on Expressway-C is also 384 kbps by default. These settings may be too low to deliver the expected video quality for MRA-connected devices.
Unified Communications Requirements
Product Versions
The following table provides minimum releases of Cisco UC products in order for MRA to be supported with various features.
Legacy Authentication (LDAP)
Legacy Authentication with SSO
OAuth with Refresh
OAuth Refresh with SSO
IM and Presence Service (optional)
Cisco Unity Connection (optional)
Clusterwide SAML SSO: 11.5(1)
Per node SSO: OpenAM: 8.6(2) SAML SSO: 10.0(1)
Unified CM Requirements
The following Cisco Unified Communications Manager configuration requirements exist for deploying Mobile and Remote Access:
Basic MRA Requirements for Unified CM
- IP addressing—Unified CM must be using IPv4 addressing as Expressway does not support IPv6.
- Cisco AXL Web Service —This service must be running on the publisher node.
- Multiple Unified CM clusters—If you have multiple Unified CM clusters, configure Home Cluster Discovery . End users must have the Home Cluster field assigned in End User Configuration so that Expressway-C can direct MRA users to the correct Unified CM cluster. Use either of the following configuration methods:
- Option 1: ILS Network—Configure an Intercluster Lookup Service (ILS) network between your remote Unified CM clusters. ILS completes cluster discovery automatically, populating the Cluster View for each cluster, connecting your clusters into an intercluster network. ILS can also replicate your enterprise dial plan across all Unified CM clusters, although this functionality is not required by MRA. ILS is the recommended approach, particularly for large intercluster networks.
- Option 2: Manual Connections—Configure each Unified CM cluster manually with connections to the other remote clusters. From Cisco Unified CM Administration, choose Advanced Features > Cluster View and add the remote clusters. Note that this option does not allow for dial plan replication.
- The Enable Mobile and Remote Access check box must be checked (the default setting is checked).
- The Jabber Desktop Client Policy and Jabber Mobile Client Policy fields must be set to allow the appropriate Jabber services for your deployment (the default setting is IM & Presence, Voice and Video calls ).
Additional Requirements for ICE Media Path Optimization
Additional requirements exist if you are deploying ICE Media Path Optimization. For details, see Prerequisites for ICE Media Path Optimization.
IM and Presence Service Requirements
To deploy IM clients over MRA, the following configuration requirements exist for the IM and Presence Service:
- The Cisco AXL Web Service must be running on the IM and Presence Service database publisher node.
- If you have multiple IM and Presence Service clusters within the same domain, you must configure intercluster peering between the clusters.
- IPv4 addressing must be used as Expressway does not support IPv6 addressing.
- For information on certificate requirements, see Certificate Requirements.
Certificate Requirements
This topic covers the following certificate requirements for Mobile and Remote Access (MRA):
- Certificate exchange requirements for your UC servers
- Certificate signing request (CSR) requirements for Expressway servers that deploy MRA
Certificate Exchange Requirements
We recommend that you use CA-signed certificates for Mobile and Remote Access.
The following table shows the certificates that each application uses for Mobile and Remote Access along with the certificate upload requirements for those applications. This table assumes that you're using CA-signed certificates for all certificates that MRA uses.
Presents these certificates for MRA
Each Unified CM cluster must trust the Expressway-C certificate. For each cluster, make sure of the following:
- If Mixed mode is enabled —The Expressway-C certificate must be installed to the CallManager-trust store on Unified CM.
- If Mixed mode is disabled —The root CA certificate that signs the Expressway-C certificate must be installed to the CallManager-trust store on Unified CM.
IM and Presence Service
Each IM and Presence Service cluster must trust the Expressway-C certificate. For each cluster, make sure of the following:
- The root CA certificate that signs the Expressway-C certificate is installed to the cup-xmpp-trust store of the IM and Presence Service. (CONFIRM THIS)
Expressway-C certificate (CA-signed)
Expressway-C must trust the certificates presented by each Unified CM and IM and Presence Service cluster. In addition, Expressway-C must trust the Expressway-E certificates. Make sure of the following:
- Expressway-C's trusted CA list must include the root CA certificate that signs the Unified CM and IM and Presence Service certificates for all UC clusters.
- Expressway-C's trusted CA list must include the CA certificate chain (root and intermediate certificates) that signs the Expressway-E certificate.
- If appropriate, Expressway-C's trusted CA list must include any endpoint certificates.
Expressway-E certificate (CA-signed)
Expressway-E must trust the Expressway-C certificate. Make sure of the following:
- Expressway-E's trusted CA list must include the CA certificate chain (root and intermediate certificates) that signs the Expressway-C certificate.
- If appropriate, Expressway-E's trusted CA list must include any endpoint certificates.
Certificate management is simplified if you use the same CA to sign certificates for all applications as it is already installed on each application. However, you may want to limit certificate costs by using a public CA for Expressway-E and an enterprise CA for internal applications.
NoteYou can also use self-signed certificates for Cisco Unified Communications Manager and the IM and Presence Service. Then, the certificate requirements will be same as in the above table with one exception. On Expressway-C, rather than installing the root CA certificate(s) that signs the Unified CM and IM and Presence Service certificates, install the actual certificates that Unified CM (CallManager, Tomcat) and IM and Presence Service (cup-xmpp, Tomcat) use for Mobile and Remote Access.
NoteFor the UC traversal zone between Expressway-C and Expressway-E, it's not sufficient to install the root CA certificate that the other Expressway application uses. You must install the CA certificate chain (root plus intermediate certificates) that the other Expressway application uses. CSR Requirements for Expressway Servers
The Expressway certificate signing request (CSR) tool prompts for and incorporates the relevant Subject Alternative Name (SAN) entries as appropriate for the Unified Communications features that are supported on that Expressway.
The following table highlights CSR requirements when generating the Expressway-C and Expressway-E certificates for Mobile and Remote Access.
Subject Alternative Names
The Expressway-C list of Subject Alternative Names must include:
- Phone Security Profiles used by MRA endpoints
- Expressway cluster name (for clustered Expressways only)
- IM and Presence chat node aliases (for Federated group chat)
The Expressway-E list of Subject Alternative Names must include:
- Unified CM Registration Domains
- XMPP Federation Domains
- IM and Presence chat node aliases (for Federated group chat)
The certificate must include the Client Authentication extension. The system won't let you upload a certificate without this extension.
Note Make sure that the CA that signs the request doesn't strip out the client authentication extension. The certificate must include the Client Authentication extension. The system won't let you upload a certificate without this extension.
Note Make sure that the CA that signs the request doesn't strip out the client authentication extension.
NoteWe recommend that you use DNS format for the chat node aliases when generating the CSRs for both Expressways.
NoteExpressway-C automatically includes the chat node aliases in the certificate signing request (CSR), providing it has discovered a set of IM and Presence Service servers. Generating CSRs and Uploading Certificates on Expressway
The following steps describe how to generate CSRs and to upload certificates onto Expressway.
- Go to Maintenance > Security > Server to generate a CSR and upload a server certificate to Expressway.
- Go to Maintenance > Security > Trusted CA and upload trusted Certificate Authority (CA) certificates to Expressway.
- Restart the Expressway for the new trusted CA certificate to take effect.
NoteFor detailed procedures and information on how to use the Certificate Signing Request tool to generate CSRs for Cisco Expressway certificates, and how to upload and download certificates on Expressway refer to the Cisco Expressway Certificate Creation and Use Deployment Guide on the Expressway Configuration Guides page. MRA-Compatible Clients
Legacy Authentication (LDAP)
Legacy Authentication with SSO
OAuth with Refresh
OAuth Refresh with SSO
Cisco Jabber for Windows
Cisco Jabber for iPhone and iPad
Cisco Jabber for Android
Cisco Jabber for Mac
Jabber clients verify the identity of the Expressway-E they are connecting to by validating its server certificate. To do this, they must have the certificate authority that was used to sign the Expressway-E's server certificate in their list of trusted CAs.
Jabber uses the underlying operating system's certificate mechanism:
- Windows: Certificate Manager
- MAC OS X: Key chain access
- IOS: Trust store
- Android: Location & Security settings
Jabber client configuration details for MRA are provided in the installation and configuration guide for the relevant client:
- Cisco Jabber for Windows
- Cisco Jabber for iPhone and iPad
- Cisco Jabber for Android
- Cisco Jabber for Mac (requires X8.2 or later)
Cisco Webex Clients
Expressway supports calling for MRA-connected Webex clients that are running a compatible software version:
- Cisco Webex for Windows
- Cisco Webex for Mac
- Cisco Webex for iPhone and iPad
- Cisco Webex for Android
MRA-Compatible Endpoints
Cisco IP Phone 7800 Series
Cisco IP Phone 8800 Series except Cisco Wireless IP Phone 8821 and 8821-EX and Cisco Unified IP Conference Phone 8831
Cisco IP Conference Phone 7832
Cisco IP Conference Phone 8832
Android-based Cisco DX650, DX70, and DX80 devices
Cisco Webex Desk Series endpoints, such as:
- Cisco Webex DX80
- Cisco Webex Desk Pro
All CE releases supported by the hardware
Cisco Webex Board Series endpoints, such as:
- Cisco Webex Board 55
- Cisco Webex Board 70
- Cisco Webex Board 85s
All CE releases supported by the hardware
Cisco Webex Room Series endpoints, such as:
- Cisco Webex Room 55
- Cisco Webex Room 70 G2
- Cisco Webex Room 55 Dual
- Cisco Webex Room 70 Dual G2
- Cisco Webex Room Panorama
- Cisco Webex Room 70 Panorama
- Cisco Webex Room 70D Panorama Upgrade
- Cisco Webex Room Kit
- Cisco Webex Room Kit Pro
- Cisco Webex Room Kit Plus
- Cisco Webex Room Kit Mini
- Cisco WebEx Codec Plus
All CE releases supported by the hardware
Cisco TelePresence endpoints: SX Series, EX Series, MX Series, Profile Series, C Series
Cisco TelePresence and Webex endpoints:
EX, MX, and SX Series Endpoints (Running TC Software)
Ensure that the provisioning mode is set to Cisco UCM via Expressway.
These devices must verify the identity of the Expressway-E they are connecting to by validating its server certificate. To do this, they must have the certificate authority that was used to sign the Expressway-E's server certificate in their list of trusted CAs.
The devices ship with a list of default CAs which cover the most common providers (including Verisign and Thawte). If the relevant CA is not included, it must be added (for instructions, see the endpoint administrator guide).
Mutual authentication is optional, and these devices are not required to provide client certificates. If you do want to configure mutual TLS, you cannot use CAPF enrolment to provision the client certificates. Instead, manually apply the certificates to the devices. The client certificates must be signed by an authority that is trusted by the Expressway-E.
Considerations for Android-based DX650, DX80, and DX70 Devices and Supported IP Phone 7800 and 8800 models
If you deploy these devices to register with Cisco Unified Communications Manager through MRA, be aware of the following points. For DX endpoints, these considerations only apply to Android-based devices and do not apply to DX70 or DX80 devices running CE software:
- Trust list: You cannot modify the root CA trust list on Cisco IP Phone 7800 Series and Cisco IP Phone 8800 Series devices. Make sure that the Expressway-E's server certificate is signed by one of the CAs that the devices trust, and that the CA is trusted by the Expressway-C and the Expressway-E.
- Off-hook dialing: The way KPML dialing works between these devices and Unified CM means that you need Cisco Unified Communications Manager 10.5(2)SU2 or later to be able to do off-hook dialing via MRA. You can work around this dependency by using on-hook dialing.
Which MRA Features are Supported
For information about which features are supported over MRA for specific clients and endpoints, refer to the relevant product documentation:
See "Supported Services” in the “Remote Access” chapter of the Planning Guide for Cisco Jabber (for your version).
Cisco IP Phone 7800 Series
See “Phone Features Available for Mobile and Remote Access Through Expressway” in the “Phone Features and Setup” chapter, Cisco IP Phone 7800 Series Administration Guide for Cisco Unified Communications Manager .
Cisco IP Conference Phone 7832
See “Phone Features Available for Mobile and Remote Access Through Expressway” in the “Phone Features and Setup” chapter, Cisco IP Conference Phone 7832 Administration Guide for Cisco Unified Communications Manager .
Cisco IP Phone 8800 Series
See “Phone Features Available for Mobile and Remote Access Through Expressway” in the “Phone Features and Setup” chapter, Cisco IP Phone 8800 Series Administration Guide for Cisco Unified Communications Manager .
Cisco IP Conference Phone 8832
See “Phone Features Available for Mobile and Remote Access Through Expressway” in the “Phone Features and Setup” chapter, Cisco IP Conference Phone 8832 Administration Guide for Cisco Unified Communications Manager .
Limitations and Feature Support
MRA supports different features in different deployment scenarios, and when different clients and endpoints are used. This section provides information about:
- Key unsupported features for clients and endpoints
- Unsupported Expressway features that don't work in certain MRA situations
UC Feature Support and Limitations
This section lists some key client and endpoint features that we know don't work with MRA-connected devices.
NoteRefer to your endpoint or client documentation for more information. The following list isn't exhaustive. - Multiple IM and Presence clusters with different releases—If you have multiple IM and Presence Service clusters configured on Cisco Expressway-C , and some of them run pre-11.5 software, MRA endpoints may not be able to use features that require 11.5. The reason is that, using a round robin approach, Cisco Expressway-C may select a cluster on an older software version.
- Expressway-E with dual network interface—In Expressway-E systems that use dual network interfaces, XCP connections (for IM and Presence Service XMPP traffic) always use the internal interface. XCP connections may fail if the Expressway-E internal interface is on a separate network segment and is used for system management only, and where the Expressway-C traversal zone connects to the Expressway-E external interface.
- Cisco Jabber with E911—If you deploy Cisco Jabber clients over MRA with the E911NotificationURL feature, configure a static HTML page for the notification. MRA does not support scripts and link tags for the web page.
- Cisco Jabber Directory access—MRA supports Cisco Jabber directory access using the Cisco User Data Services (UDS). MRA doesn't support other directory access methods for Jabber.
- Unified Contact Center Express feature support—MRA doesn't support some Cisco Unified Contact Center Express features. For details, refer to the Unified Contact Center Express documentation.
- Endpoint failover behavior:
- 78XX / 88XX series phones registered over MRA and using OAuth token may get de-registered when a CUCM node goes down but, will continue to communicate with another active node. And the phones will re-register after some time. Jabber registered over MRA and using OAuth token may get de-registered when a CUCM node goes down and displays a message "Your session is expired. Sign in again to keep using Cisco Jabber" . You can sign in to your Jabber to continue using the service.
- Cisco Jabber clients support IM and Presence Service and SIP Registration Failover over MRA. For more information, see SIP Registration Failover for Cisco Jabber. However, they don't support any other type of MRA - related redundancy or failover - including Voicemail and User Data Services (UDS). Clients use a single UDS server only. If an Expressway-C or Expressway-E node fails, active MRA calls through the failed Expressway node also fail. This behavior applies to all device types, including Jabber clients. For Unified CM failover over MRA, Cisco IP Phones need clustered Expressway-C and Expressway-E servers. IP Phones need at least the same number of Expressway-C and Expressway-E servers in the cluster as the number of Unified CMs in the Call Manager group configured on the IP phone. Note that devices running TC or CE software don't need clustered Expressway servers for Unified CM failover.
- MRA supports recording tones for Cisco Jabber clients and Webex Unified CM registered applications. Also note that CTI monitoring of Jabber mobile devices requires Unified CM 12.5(1)SU1 or later.
- Silent Monitoring is supported from X12.6.1.
- Whisper Coaching and Whisper Announcements are supported from X12.6.2.
NoteFor iX to work over MRA, configure the conferencing server with an encrypted trunk to Unified CM and make sure that the endpoints/ Jabber are running a suitable, iX-capable software version. - Request to display the security icon on MRA endpoints for end-to-end secure calls
- Request to change the caller ID to display name or number on MRA endpoints
Unsupported Expressway Features and Limitations
- Currently, if one Expressway node in a clustered deployment fails or loses network connectivity for any reason (including if the Unified CM restarts or fails), all active calls going through the affected node will fail. The calls are not handed over to another cluster peer. Bug ID CSCtr39974 refers. This is not an MRA-specific issue and applies to all call types.
- We don’t support third-party network load balancers between MRA clients and Expressway-E.
- The Expressway cannot be used for Jabber Guest when it's used for Mobile and Remote Access (MRA).
- The Expressway-C used for MRA cannot also be used for Microsoft gateway service. Microsoft gateway service requires a dedicated Expressway-C.
- Maintenance mode is not supported over MRA for endpoints running CE software. The Expressway drops MRA calls from these endpoints when you enable maintenance mode.
- As Expressway only supports IPv4 mode for MRA connections, the IP configuration settings "IPv6 only" or "Both" are not supported. In the case of "Both", as Expressway does not proxy IPv6 MRA traffic from clients, intermittent issues may arise if clients send IPv6 instead of IPv4.
- Endpoint management capability (SNMP, SSH/HTTP access) is not supported.
- Multitple Presence Domains over MRA—This feature is supported from Expressway X12.6.3 with IM and Presence Service 10.0(x) or later. Compatible clients can be deployed into an infrastructure that has users in more than one domain or in domains with subdomains. We recommend no more than 75 domains in a Unified Communications default deployment. For XMPP/chat & presence federation through Expressway, the existing requirement that XMPP federation is supported on a single Expressway cluster only still applies. Note that for Expressway releases prior to X12.6.3, support for multiple presence domains was a preview feature with the following limitations:
- Before X8.5, each Expressway deployment supported only one Presence domain. (Even though IM and Presence Service 10.0 and later supports Multiple Presence Domains.)
- As of X8.5, you can create multiple deployments on the Expressway-C, but this feature is still limited to one domain per deployment.
- As of X8.5.1, a deployment can have Multiple Presence Domains. However, this feature is in preview status only, and we recommend that you do not exceed 50 domains.
Partial Support for Cisco Jabber SDK
You can use the following supported Cisco Jabber SDK features over MRA:
- Sign in, sign out
- Register phone services
- Make or receive audio/video calls
- Hold and resume, mute/unmute, and call transfer
