Perché il dial plan è il cuore dell’integrazione
In uno scenario CLCEI, Expressway-C funge da ponte tra il mondo B2B/mobile (via Expressway-E) e l’infrastruttura on-prem gestita da CUCM. Il compito del dial plan è instradare una chiamata verso i pattern registrati su CUCM (numeri E.164, URI SIP, alias) senza loop né percorsi duplicati. I tre mattoni fondamentali sono: neighbor zone, transforms e search rules.
Neighbor zone verso CUCM
Il collegamento Expressway↔CUCM si realizza con una neighbor zone su Expressway-C che punta al nodo (o ai nodi) CUCM del gruppo di call processing. Lato CUCM esiste il corrispettivo SIP trunk con il relativo SIP Trunk Security Profile. I parametri devono essere speculari:
| Parametro | Expressway (neighbor zone) | CUCM (SIP Trunk Security Profile) |
|---|---|---|
| Transport | TCP o TLS | TCP o TLS (Device Security Mode) |
| Porta | 5060 (TCP) / 5061 (TLS) | Incoming Port 5060 (Non Secure) / 5061 (Encrypted) |
| SIP Profile | Standard / custom | — |
| Media encryption | opzionale (SRTP) | “Encrypted” richiede TLS |
Regola d’oro: transport e porta devono coincidere su entrambi i lati. Un SIP trunk security profile CUCM impostato su Non Secure / 5060 non risponderà mai a una neighbor zone Expressway configurata in TLS su 5061, e viceversa.
Per SIP TLS servono inoltre: certificati validi con SAN corrette su entrambi i lati, la CA reciprocamente fidata negli store, e — se si vuole media cifrato — SRTP con Device Security Mode Encrypted su CUCM. Il TLS verify mode sulla zone impone la validazione del certificato peer: se il CN/SAN del certificato CUCM non è nella TLS verify subject name, l’handshake fallisce anche con certificati validi.
Transforms e search rules
- I transforms agiscono globalmente e prima delle search rules: normalizzano l’alias in ingresso (es. rimuovere un dominio, aggiungere
@certup.local, convertire un numero corto in E.164). - Le search rules decidono dove cercare l’alias già normalizzato: un pattern (
regexoprefix) associato a una zone di destinazione, con priorità crescente (numero più basso = valutata prima). La rule può a sua volta riscrivere l’alias con l’azione Replace prima di inoltrarlo alla neighbor zone CUCM.
Esempio concettuale: una rule con priorità 100, pattern .*@cucm\.certup\.local, azione Replace verso la neighbor zone CUCM instrada tutti gli URI del dominio interno. Le rule verso Expressway-E (traversal) restano a priorità più alta per il traffico esterno.
Interworking SIP ↔ H.323
Expressway può fare interworking trasparente tra un lato SIP e un lato H.323 (utile con endpoint legacy o gatekeeper H.323). L’impostazione è Configuration > Protocols > Interworking con tre stati: On, Off, Registered only (default: interworking solo per endpoint registrati localmente).
Quando conviene disabilitarlo o limitarlo:
- Se l’ambiente è SIP-only (CUCM moderno, endpoint SIP), l’interworking pieno On è inutile e apre percorsi ridondanti.
- Se una chiamata può essere risolta sia via SIP sia via H.323, un interworking troppo permissivo genera due call leg per la stessa destinazione (fork indesiderato) o loop di ricerca.
- La modalità Registered only è il compromesso tipico: interworking solo per gli endpoint che si registrano su Expressway, evitando interworking spurio sul traffico di transito.
xConfiguration Zones Zone [n] Neighbor Interworking Mode: <On/Off/RegisteredOnly>Trappole tipiche d’esame
- Scenario: neighbor zone Expressway in TLS 5061, ma il SIP Trunk Security Profile CUCM è Non Secure su 5060 → La chiamata fallisce per mismatch di transport/porta. Allineare Device Security Mode = Encrypted e Incoming Port = 5061 su CUCM (o portare la zone a TCP/5060).
- Scenario: ambiente SIP-only ma chiamate duplicate verso lo stesso destinatario → Interworking impostato su On globale. Portarlo a Off o Registered only per eliminare i percorsi di chiamata ridondanti.
- Scenario: search rule verso CUCM configurata ma la chiamata non parte, mentre i transforms sembrano corretti → L’alias non matcha il pattern perché il transform lo ha già normalizzato in un formato diverso. Ricordare che i transforms si applicano prima delle search rules; il pattern va scritto sull’alias trasformato.
- Scenario: TLS handshake fallito nonostante certificati validi → TLS verify subject name non corrisponde al SAN/CN del certificato CUCM (o CA non fidata nel trust store).
- Scenario: due search rule con priorità sovrapposte instradano lo stesso pattern su zone diverse → Vince la priorità numerica più bassa; verificare che la rule verso CUCM non sia scavalcata da una rule traversal a priorità inferiore.