Troubleshooting MRA

Perché MRA rompe in modi ambigui

Mobile and Remote Access (MRA) consente a client Jabber/Webex e telefoni di registrarsi al CUCM attraverso la coppia Expressway-C (interno) ed Expressway-E (DMZ), senza VPN. La catena è lunga — DNS, certificati, firewall, traversal zone, UDS — e ogni anello genera sintomi diversi. Un troubleshooting efficace non parte dal firewall: segue l’ordine con cui il client stabilisce la sessione (discovery → sign-in → registrazione → media) e isola il primo passo che fallisce.

Il metodo, passo per passo

1. Service discovery (DNS SRV)

Il client cerca prima _cisco-uds._tcp.<dominio> (interno). Fuori rete usa _collab-edge._tls.<dominio>, che deve puntare all’FQDN pubblico di Expressway-E sulla porta 8443.

nslookup -type=SRV _collab-edge._tls.example.com

Se il record manca, punta al C invece che all’E, o restituisce un FQDN non risolvibile pubblicamente, il sign-in fallisce prima di qualsiasi handshake TLS. È l’errore più comune scambiato per “problema di rete”.

2. Certificati: validità, SAN e trust store

• Expressway-E: certificato firmato da CA pubblica, perché il client lo valida senza avere la CA aziendale. La SAN deve contenere tutti i domini MRA (quelli usati nell’SRV _collab-edge) e le voci _collab-edge.<dominio>. Un CN corretto ma SAN incompleta = handshake respinto dal client.
• Traversal zone C↔E: TLS mutuo. Il trust store (CA certificates) di C deve contenere la CA che ha firmato E e viceversa. Se manca, la zona resta Failed e nessun servizio MRA passa.
• CUCM Tomcat: il suo certificato deve essere fidato da Expressway-C per il traffico UDS/8443.

Verifica SAN e scadenza:

openssl x509 -in expe.pem -noout -dates -ext subjectAltName

3. Raggiungibilità delle porte

L’8443 governa la fase di sign-in/config; il 5061 la registrazione; le porte UDP media governano solo il flusso RTP. Questa separazione è la chiave diagnostica.

4. Log e diagnostic logging

Su Expressway usa Maintenance → Diagnostics → Diagnostic logging (Start → riproduci il problema → Stop → download), affiancato a tcpdump integrato. Cerca nei log la get_edge_config, l’esito della traversal zone e i messaggi SIP 401/403. La utility Check pattern e i Network log confermano dove la catena si spezza.

Correlare sintomo → causa radice

• Sign-in fallisce del tutto → DNS SRV _collab-edge assente/errato, TCP 8443 bloccato, o certificato Expressway-E non fidato dal client (SAN o CA pubblica).
• Registrazione OK ma le chiamate non partono → signaling (5061) funziona, ma la traversal zone o l’instradamento CUCM ha un problema; controlla search rules e SIP trunk.
• Registrazione e chiamata si stabiliscono ma audio/video assenti → porte media UDP bloccate sul firmware/firewall, NAT reflection mancante, o configurazione dual-NIC/NAT statica errata sull’Expressway-E.
• IM&P non funziona ma le chiamate sì → TCP 5222 (XMPP) bloccato o certificato senza il dominio IM&P in SAN.

Trappole tipiche d’esame

• Scenario: sign-in esterno fallisce, ping verso Expressway-E OK. → Risposta giusta: non è la rete; verifica il record SRV _collab-edge._tls e che la SAN del certificato E copra il dominio MRA. Assumere il firewall è l’errore da evitare.
• Scenario: traversal zone tra C ed E in stato Failed dopo rinnovo certificati. → Risposta giusta: trust store incompleto — la CA che ha firmato il nuovo certificato non è stata caricata sul peer.
• Scenario: registrazione riuscita, chiamata connessa, ma nessun audio. → Risposta giusta: problema nel media path UDP (porte/NAT sull’Expressway-E), non nel signaling.
• Scenario: Jabber interno funziona, esterno no. → Risposta giusta: il record _collab-edge pubblico o la porta 8443 verso l’E è il punto di rottura, non _cisco-uds.
• Scenario: certificato Expressway-E con CN corretto ma client rifiuta la connessione. → Risposta giusta: SAN mancante del dominio MRA — il CN non basta, i client validano la SAN.