Remote Jabber Works for One Domain but Not the Acquired Domain
Acme uses Cisco Jabber with Mobile and Remote Access through Expressway-C and Expressway-E. Internal Jabber clients register to CUCM without issues. Remote users in the example.com domain can sign in, but users in the acquired emea.example.com domain cannot; Jabber shows cannot find server or sign-in failed. DNS has a _collab-edge._tls.example.com SRV record pointing to Expressway-E, and _cisco-uds._tcp.example.com resolves internally to the CUCM publisher. No SRV record exists for emea.example.com. The Expressway-E certificate is from a public CA and contains SAN collab-edge.example.com; the Expressway-C certificate is from the internal CA and is trusted by Expressway-E. The traversal zone is active. Firewall rules allow 5061 and 8443 inbound to Expressway-E. Internal users in emea.example.com register fine.
1. Why do emea.example.com users fail remotely while internal registration and example.com remote users work?
Read the worked answer
MRA service discovery is domain-based. A remote Jabber client derives its domain from the sign-in address and queries _collab-edge._tls.. For emea.example.com there is no SRV record, so the client cannot locate Expressway-E and reports that it cannot find the server. Internal clients do not use the _collab-edge record; they use _cisco-uds._tcp, which resolves to the CUCM publisher, so internal registration succeeds. The example.com remote users succeed because their SRV record exists. Before changing anything, confirm the client is actually querying the emea domain and not falling back to example.com; if the client is configured with a manual server, the behavior can differ. Also verify that the Expressway allows the emea domain for MRA, because some deployments restrict allowed domains on the Expressway.
2. What DNS, certificate, and Expressway changes are required to bring emea.example.com users online?
Read the worked answer
Add a _collab-edge._tls.emea.example.com SRV record pointing to the Expressway-E target hostname, with the same priority and weight scheme as the existing domain. The TLS certificate on Expressway-E must match the hostname the client connects to. If the SRV target is exp-e.example.com, the certificate must include that name; if the target is a name in emea.example.com, the certificate needs that SAN. A certificate with only collab-edge.example.com is sufficient only if the client connects to a name it covers. On Expressway-C, verify Unified Communications is enabled, the traversal zone to Expressway-E is active and configured for Unified Communications, and the domain is not blocked by allowed-domain policy. On CUCM, verify the emea users have valid URIs and that the SIP domain used by the cluster matches the domain the clients use.
3. A few emea users can now sign in remotely but cannot place calls, while internal calls work. What MRA-specific items would you check?
Read the worked answer
First separate registration from call signaling. Sign-in uses HTTPS/UDS, while calls use SIP over TLS on 5061 through the traversal zone. Check that 5061 is allowed end to end and that the traversal zone is configured for Unified Communications on both Expressway-C and Expressway-E, not just as a generic traversal zone. Confirm the CUCM SIP domain and the Expressway's SIP domains include emea.example.com; a mismatch can let UDS sign-in succeed but reject call signaling. Check the user's device and line CSS for calling permissions, but note that internal calls may use different partitions than external calls. Finally, verify codec and region configuration for the remote leg and check for any certificate name mismatch on the SIP TLS connection.