Su Cisco Expressway l’instradamento delle chiamate SIP e H.323 si basa su un modello a zone: contenitori logici che rappresentano “da dove arriva” e “verso dove va” una chiamata. Ogni zona è associata a una o più search rules che, valutando l’alias di destinazione, decidono su quale zona proseguire la ricerca. Capire la tassonomia delle zone è il cuore del design edge di CLCEI.

Local zone e subzone

La Local Zone non si configura come le altre: esiste sempre e rappresenta tutto ciò che è “locale” all’Expressway. È suddivisa in subzone, tra cui la Default Subzone (dove finiscono gli endpoint registrati che non corrispondono a una membership rule) e la Traversal Subzone, il punto interno da cui transitano le chiamate traversal. Gli endpoint che si registrano direttamente su Expressway (tipicamente Expressway-C in scenari MRA o registrazione diretta) vivono qui. Le subzone membership rules classificano le registrazioni per subnet o alias, e le pipe applicano limiti di banda tra subzone.

Neighbor zone

Una neighbor zone definisce un peering statico verso un sistema noto: un cluster CUCM, un altro Expressway, un gateway o un VCS legacy. Si configura indicando IP o FQDN dei peer (fino a sei per la ridondanza), la porta e il protocollo (SIP/H.323). È deterministica: la destinazione è fissa e conosciuta a priori. L’esempio classico è la neighbor zone tra Expressway-C e CUCM per l’integrazione B2B/MRA, con SIP trunk speculare lato Call Manager. Se il peer è raggiungibile e “attivo”, la zona risulta Active; questo stato è verificato con probe SIP OPTIONS.

Traversal client e traversal server zone

Le zone traversal risolvono il problema dell’attraversamento firewall senza aprire porte in ingresso verso la rete interna. Il modello è client/server e la direzione è sempre dall’interno verso l’esterno:

Ruolo Dove vive Comportamento
Traversal client zone Expressway-C (interno) Inizia la connessione outbound verso E
Traversal server zone Expressway-E (DMZ) Rimane in ascolto, accetta la sessione da C

Expressway-C avvia il collegamento verso Expressway-E; il firewall interno deve quindi permettere solo traffico in uscita, mai pinhole in ingresso verso C. Media e signaling viaggiano poi su quella sessione già stabilita. I due lati devono condividere credenziali di autenticazione, la stessa porta SIP traversal (default 7001) e coerenza sul media port range (default 36000–59999). Questo è ciò che rende possibile MRA e B2B senza NAT inbound sulla rete aziendale.

DNS zone

La DNS zone abilita l’instradamento dinamico verso domini esterni non conosciuti in anticipo. Invece di un peer fisso, esegue una risoluzione DNS SRV (_sips._tcp.<dominio>, _sip._tcp, _h323ls._udp) per scoprire l’edge remoto del dominio di destinazione e instradarvi la chiamata. Vive tipicamente su Expressway-E, perché è l’unico nodo con visibilità DNS pubblica, ed è il meccanismo standard per le chiamate B2B interdominio verso qualsiasi organizzazione su Internet. Supporta la verifica TLS del certificato remoto (parametro TLS verify mode) per garantire che l’edge risolto sia legittimo.

Il flusso end-to-end B2B

In una chiamata verso alice@partner.com: l’endpoint interno → Local Zone su Expressway-C → search rule → traversal client zone verso Expressway-E → traversal server zone su E → search rule → DNS zone → SRV lookup di partner.com → edge del partner. Neighbor, traversal e DNS zone lavorano in catena, ciascuna nel suo ruolo.

Trappole tipiche d’esame

  • Neighbor zone al posto di DNS zone per B2B esterno → per chiamare domini Internet arbitrari serve una DNS zone su Expressway-E: la neighbor zone è statica e richiederebbe di conoscere in anticipo ogni peer, quindi non scala. Risposta giusta: DNS zone.
  • DNS zone verso CUCM interno → per un peer noto e interno (CUCM) usa una neighbor zone statica, non una DNS zone: non c’è nulla da risolvere via SRV. Risposta giusta: neighbor zone.
  • Direzione traversal invertita → scenario “il firewall blocca la chiamata in ingresso”: ricorda che è Expressway-C a iniziare verso E. Se aspetti connessioni inbound verso C, hai il modello al contrario. Risposta giusta: outbound C→E.
  • Traversal server sul lato sbagliato → la traversal server zone sta su Expressway-E, la client su Expressway-C. Invertirle rompe MRA/B2B. Risposta giusta: server su E, client su C.
  • Endpoint “spariti” dopo la registrazione → se non compaiono in nessuna subzone dedicata, sono nella Default Subzone della Local Zone; verifica le subzone membership rules prima di sospettare un problema di traversal. Risposta giusta: Default Subzone / Local Zone.