Perché le chiamate d’emergenza sono un capitolo a sé

In telefonia tradizionale il numero è legato a una presa a muro, quindi la posizione è implicita: il PSAP che riceve la chiamata sa dove mandare i soccorsi perché l’indirizzo è quello registrato per quella linea. In Teams Phone il numero segue l’identità, non il cavo: lo stesso utente può chiamare dalla sede di Milano, da una filiale, da un hotel o da casa, sempre con lo stesso numero. Se la posizione restasse quella statica registrata alla sottoscrizione del numero, i soccorsi partirebbero verso l’indirizzo sbagliato. Da qui il dynamic emergency calling: la posizione deve essere calcolata al momento della chiamata, in base a dove il client si trova davvero sulla rete.

Questo è anche il motivo per cui l’argomento è trasversale e non appartiene a una sola opzione di connettività PSTN. Con Microsoft Calling Plan e Operator Connect l’instradamento verso il PSAP è responsabilità dell’operatore; con Direct Routing l’instradamento resta un problema tuo, perché la chiamata esce dal tuo SBC e devi decidere esplicitamente dove mandarla. La rilevazione della posizione, invece, è comune a tutti i modelli.

Il Location Information Service

Il Location Information Service (LIS) è la tabella che traduce “dove sei sulla rete” in “dove sei nel mondo fisico”. Si popola associando identificatori di rete a indirizzi civici: subnet, wireless access point (per BSSID), switch (per chassis ID) e switch port. La granularità cresce scendendo la lista: una subnet può coprire un intero edificio, un access point identifica un’ala o un piano, una porta di switch identifica una scrivania. La scelta è un trade-off classico: più l’identificatore è fine, più la posizione è precisa, ma più la manutenzione del LIS diventa onerosa e sensibile ai cambi di cablaggio o di copertura Wi-Fi.

Gli indirizzi usati dal LIS devono essere emergency address validati: la validazione conferma che l’indirizzo civico sia riconosciuto e utilizzabile dai servizi di emergenza. Sopra un indirizzo validato si possono definire place (piano, stanza, area) che dettagliano la posizione senza richiedere una nuova validazione dell’indirizzo. La rilevazione dinamica funziona quando il client è riconosciuto come “in rete aziendale”, il che dipende dai trusted IP address del tenant: se l’IP pubblico da cui il client si presenta non è fra quelli attendibili, il lookup nel LIS non viene fatto e la posizione dinamica non compare.

Le due policy: cosa succede e dove va la chiamata

Sono oggetti distinti e l’esame gioca su questa distinzione.

La Teams emergency calling policy definisce il comportamento durante la chiamata: chi viene notificato (tipicamente un gruppo di sicurezza o una reception), con quale modalità — sola notifica, oppure notifica con inserimento in conferenza in ascolto silenzioso — e come si comporta il client quando l’utente è fuori dalla rete aziendale, caso in cui l’indirizzo può essere inserito manualmente. Non decide l’instradamento.

La Teams emergency call routing policy definisce i numeri di emergenza, l’eventuale dial mask e il PSTN usage con cui la chiamata viene instradata: è l’oggetto rilevante per Direct Routing, dove serve una voice route che porti il numero di emergenza verso l’SBC corretto per quella sede. Con Calling Plan e Operator Connect questa policy non serve nello stesso modo, perché l’instradamento è gestito dall’operatore.

Entrambe le policy si possono assegnare all’utente oppure al network site: l’assegnazione per sito è preferibile quando il comportamento dipende dal luogo e non dalla persona, ed evita di riassegnare policy a ogni spostamento.

Verificare dal client

La prova finale è sempre lato client: il client Teams mostra all’utente l’indirizzo di emergenza rilevato in quel momento. Se l’indirizzo è assente o è quello statico del numero, il sospetto va nell’ordine su: IP pubblico non fra i trusted IP, identificatore di rete non presente nel LIS, indirizzo non validato, policy non assegnata all’utente o al sito. Un test end-to-end verso il PSAP non si improvvisa: si usano, dove disponibili, i numeri di test previsti dall’operatore.

Trappole tipiche d’esame

  • L’utente si sposta fra sedi e i soccorsi ricevono l’indirizzo della sede centrale → LIS con identificatori di rete mappati su indirizzi validati: non si risolve assegnando un secondo numero né aggiornando l’indirizzo di emergenza del numero, che è statico per definizione.
  • Serve avvisare il security desk senza toccare l’instradamento → emergency calling policy: notifica e ascolto silenzioso stanno lì; la routing policy risponde alla domanda “dove va la chiamata”, non “chi viene informato”.
  • Con Direct Routing la chiamata d’emergenza esce dal trunk sbagliato → emergency call routing policy con PSTN usage e voice route dedicati: popolare il LIS migliora la posizione, non l’instradamento. Con Calling Plan o Operator Connect la stessa domanda si risolve lato operatore.
  • Impedire l’aggiramento delle tariffe fra sedi in un paese che lo vieta → Location-Based Routing: LBR usa la topologia di rete come il dynamic emergency calling, ma risponde a un requisito regolatorio sulle tariffe, non alle emergenze.
  • Utente in smart working o in viaggio → indirizzo dichiarato manualmente, abilitato dalla emergency calling policy: fuori dai trusted IP il lookup dinamico non avviene, e un indirizzo inserito dall’utente non ha la stessa garanzia di uno validato.
  • La posizione non compare pur avendo popolato il LIS → controlla trusted IP e validazione dell’indirizzo: un place aggiunto sotto un indirizzo già validato non richiede nuova validazione, ma un indirizzo mai validato non produce alcuna posizione utile.