Jabber MRA: Sign-In Works, Media Does Not, and Certificates Block BYOD
Contoso has 2,800 remote workers using Jabber through Mobile and Remote Access with a pair of Expressway-C (internal) and Expressway-E (DMZ) appliances. Expressway-E is dual-homed with static NAT. Sign-in, presence, and directory lookups work. Since a firewall firmware upgrade last week, users can place calls but hear nothing in either direction; the firewall vendor insists 'all Cisco ports are open'. Business-to-business calls to a partner's Expressway also fail, and the partner reports a TLS handshake error on their side. Expressway-C registration counts did not change and no alarms were raised. Security will permit only 443 and 5061 inbound from the internet and forbids a VPN client. Expressway-E certificates were issued by an internal CA; corporate laptops trust that root, but personal Android and iOS devices do not. The business also wants to federate with 500 partner organizations. You must restore audio, enable B2B, and keep the security posture intact.
1. Diagnose the one-way or no-way audio and state what you would check on the firewall and on Expressway-E.
Read the worked answer
The pattern is diagnostic: signaling succeeds because 443 and 5061 are open, and media fails because media does not travel on those ports. For MRA, voice and video media between the remote Jabber client and the traversal zone is relayed through Expressway-E, which means UDP 3478 for the TURN service and the UDP media port range (36000 to 36099 by default) must be permitted inbound and outbound to and from the internet-facing interface. A firewall firmware upgrade that turned on SIP or VoIP application inspection, or that narrowed the UDP range to 'well-known' ports, produces exactly this symptom while leaving signaling untouched.
Check, in order: first, confirm the traversal media ports are open and not inspected on the NAT device, and ask the firewall team to show the rule, not to confirm it verbally. Second, confirm Expressway-E's default gateway is on the internal (LAN) interface, not the external one; a gateway on the wrong side gives you registration without media. Third, confirm static NAT is mapping the public address to the external interface address and that the Expressway is told it is behind NAT, so it advertises the correct media address in its candidate list. Fourth, verify TURN is enabled and healthy on Expressway-E and that the traversal zone between C and E is active.
The firewall vendor's 'all ports open' is the least useful sentence in this ticket. Ask for a packet capture of a failed call and find whether the client's TURN allocation request ever reaches Expressway-E. That single capture splits the problem into 'the network drops it' versus 'Expressway advertises the wrong address', and everything after that is mechanical.
2. Resolve the certificate problem without issuing internal-CA public trust to personal devices.
Read the worked answer
Separate the two certificate chains, because they serve different populations.
The client-facing certificate on Expressway-E must be trusted by whatever device is connecting, and personal devices trust only public roots. That is not negotiable and cannot be worked around by distributing an internal root to managed laptops, because half your users are on BYOD. Issue the Expressway-E certificate from a public CA, and check the subject alternative names carefully: the certificate must cover the Edge FQDN that the _collab-edge._tls SRV record resolves to, as well as any additional discovery names in use. A public certificate with the wrong SAN produces the same failure as no certificate at all, and it is the most common mistake in this exact deployment.
The internal side is different. The traversal zone between Expressway-C and Expressway-E can use certificates from your internal PKI as long as both sides trust the issuing chain, and doing so keeps your internal name space out of public certificate transparency logs. Keep those two chains explicitly separate in the certificate management runbook so nobody 'simplifies' them into one later.
Operationally, two things prevent repeats: document renewal ownership with a named team and a calendar reminder well ahead of expiry, and add monitoring that checks the certificate expiry and chain on Expressway-E from an external vantage point. Internal monitoring cannot see what a BYOD phone sees. For the partner TLS handshake failure, ask them to confirm which chain and which SNI value they send; a partner that only trusts one root store will fail on a valid public certificate if their own Expressway uses a different chain, and that is their fix, not yours.
3. Design the 500-partner federation requirement. Would you use per-partner neighbor zones, and what does the certificate and firewall design need to allow?
Read the worked answer
No. Five hundred static neighbor zones is an operational liability: every partner add becomes a change window, every typo becomes a support ticket, and nobody can audit the resulting configuration. Use DNS-based federation instead. Partners resolve your SIP domain through SRV records to your Expressway-E, and you resolve theirs the same way; you maintain one DNS zone and a domain allow list rather than 500 zone objects. If the estate later grows beyond what Expressway should handle for SIP routing policy, that is the point to introduce a dedicated SIP proxy tier, not before.
Firewall: inbound TCP 5061 from the internet to Expressway-E only, with the rest of the DMZ closed. That matches the security constraint of 443 and 5061 inbound. Do not open media ports broadly for B2B; media for federated calls is negotiated and traversed through the same Expressway-E traversal mechanisms, so keep the UDP range restricted to the partners you actually allow, or rely on the traversal zone's TURN service rather than a wide static hole.
Certificate: public CA on Expressway-E, SANs covering the SIP domain and the federation FQDN that the SRV records return, and a full chain that partners' systems can build without fetching intermediates from your server.
Policy: this is where judgement matters most. An allow list keyed on domain is necessary but not sufficient, because it authorizes an organization, not a user. Agree the dialing scheme (URI dialing with domain, never DN-based) and the presentation rules with the business before you open federation to anyone, and stage the rollout in small batches so a misconfigured partner cannot flood your edge with failed transactions.