# Considerazioni sull’integrazione con PSTN Questa sezione si applica ai clienti che stanno valutando l'integrazione del modulo ZPLS con un SBC e una connessione PSTN per una maggiore resilienza. I clienti che non prevedono di integrare il modulo ZPLS con connettività PSTN possono saltare questa sezione senza conseguenze. ### Considerazioni sull'integrazione dell'SBC #### Requisiti dell'SBC Per integrare un SBC con Zoom per la resilienza, un SBC deve soddisfare i seguenti requisiti: * TLS 1.2 e SRTP * Supporto per Mutual TLS * Session Initiation Protocol (SIP) * DTMF (RFC-2833) * Nascondimento della topologia (RFC-5853) * SIP Early Offer (**obbligatorio**) * Codec Opus, G.711 μ-law, G.711 A-law e G.729 #### Le integrazioni PSTN richiedono un SBC e un provider terzo affidabile Per la connettività PSTN, i clienti devono fornire un session border controller (SBC) connesso a una connessione legacy o a un trunk SIP con una connessione cellulare o alternativa (ad es. DSL). I clienti devono considerare che eventuali trunk SIP configurati sull'SBC potrebbero dipendere dallo stesso servizio internet soggetto a interruzione. Per questa ragione, i clienti dovrebbero valutare una connessione terziaria affidabile per la connettività PSTN. #### Qualsiasi SBC certificato BYOC per Zoom Phone può essere utilizzato Qualsiasi session border controller (SBC) che sia [certificato per Zoom Phone](https://support.zoom.us/hc/en-us/articles/360001299063-Zoom-Phone-Certified-Hardware#h_ec5008d4-3581-46e7-a06d-32599511d089) può anche essere utilizzato con il modulo ZPLS. I clienti con un piano BYOC Zoom Phone esistente non richiedono un SBC aggiuntivo o separato ai fini della resilienza. #### I certificati DigiCert di Zoom devono essere installati sull'SBC Per stabilire la connettività TLS sia con il modulo ZPLS sia con il cloud Zoom, i [certificati root e intermedi DigitCert](https://support.zoom.us/hc/en-us/articles/360044092031) di Zoom devono essere installati sull'SBC. #### Gli SBC devono instradare le chiamate in ingresso ai data center di Zoom Phone come prima e seconda scelta di instradamento, e il modulo ZPLS come terza Gli SBC dei clienti devono instradare le chiamate in ingresso dalla PSTN alle zone SIP primaria e secondaria prima di tentare il modulo ZPLS. Con questa configurazione, le chiamate verranno instradate al modulo ZPLS solo durante un evento di resilienza, poiché l'SBC e i data center di Zoom Phone dovrebbero altrimenti mantenere una connettività stabile. Il mancato rispetto di questa logica può provocare errori nella consegna delle chiamate, poiché il modulo ZPLS non può instradare chiamate verso dispositivi registrati sul cloud. {% hint style="info" %} Una volta che il cloud di Zoom Phone è nuovamente disponibile dopo un evento di resilienza, un SBC può temporaneamente tentare di instradare numeri BYOC verso il cloud Zoom mentre il dispositivo client del numero interessato è registrato al modulo ZPLS. Se ciò dovesse verificarsi, l'instradamento delle chiamate seguirà le impostazioni per [**Quando una chiamata non viene risposta**](https://support.zoom.us/hc/en-us/articles/360059966372-Customizing-call-handling-settings#h_86f4bf1b-51ea-4d70-9e40-4a84a5ca1c2c) durante questo periodo intermedio. {% endhint %} #### Le chiamate in uscita dal modulo ZPLS devono instradare verso l'SBC e il trunk SIP PSTN Quando la modalità di resilienza è attiva, le chiamate dal ZPLS verso l'SBC devono instradare al Trunk SIP PSTN per stabilire connessioni telefoniche esterne. Tutte le chiamate verso numeri che non sono registrati al modulo ZPLS vengono inviate all'SBC configurato per la resilienza in formato E.164. ### Considerazioni sulla resilienza locale per l'inoltro delle chiamate #### Durante un evento di resilienza, i numeri di telefono forniti da Zoom Phone non saranno raggiungibili esternamente a meno che non vengano reindirizzati tramite inoltro di chiamata Durante un evento di resilienza, i numeri di telefono forniti da Zoom non saranno raggiungibili esternamente dal punto di vista del cloud. Di conseguenza, gli utenti situati nelle sedi interessate potrebbero non essere raggiungibili a meno che le chiamate ai loro numeri principali non vengano inoltrate a un numero alternativo associato a un SBC on-premises. {% hint style="info" %} Esempi comuni di numeri interessati possono includere numeri assegnati a: Utenti, Aree comuni, Centralini automatici (AR), Gruppi di linea condivisa (SLG) e Code di chiamata (CQ). {% endhint %} #### I clienti che utilizzano un BYOC basato on-premises non richiedono configurazioni avanzate e possono bypassare l'inoltro chiamate aggiungendo una route terziaria al loro modulo ZPLS dall'SBC I clienti che utilizzano un piano BYOC basato on-premises (cioè clienti che non utilizzano numeri registrati con Zoom Phone) non richiedono configurazioni avanzate per abilitare l'inoltro delle chiamate. Invece, i clienti BYOC possono aggiungere una route terziaria al modulo ZPLS dall'SBC basato presso la sede. #### Le configurazioni di inoltro chiamate vengono impostate da un amministratore o un utente autorizzato tramite il portale web Un admin dell'account o un utente autorizzato può [configurare la logica di inoltro chiamate](#_1od0waijmvaz) dal portale web tramite [inserimento manuale o un caricamento CSV in blocco](#_aezu04x8z043). #### Gli utenti configurati per l'inoltro chiamate avranno tre numeri assegnati Dopo aver assegnato un numero BYOC a un utente per la resilienza tramite inoltro chiamate, al dispositivo client verranno assegnati *almeno* tre numeri: 1. Un interno con prefisso del codice sito 2. Un numero PSTN fornito da Zoom 3. Un numero PSTN BYOC
#### I numeri telefonici possono essere inoltrati a un massimo di un numero BYOC Ogni numero Zoom Phone può essere inoltrato a un massimo di **uno** altro numero BYOC. Tuttavia, è possibile inoltrare più numeri telefonici allo stesso numero BYOC. Ad esempio, se a John viene assegnato il numero X55-555-5555, il numero di John può essere inoltrato al numero dell'operatore dell'edificio X99-999-9999. Allo stesso modo, anche i colleghi di John possono avere i loro numeri (X55-555-5554, X55-555-5553, ecc.) inoltrati a X99-999-9999. In alternativa, ogni utente può avere il proprio numero inoltrato a un numero completamente unico, come X55-555-5554 instradato a X99-999-9998 e X55-555-5553 instradato a X99-999-9997. Tuttavia, nessun singolo utente può avere il proprio numero inoltrato sia a X99-999-9999 sia a X99-999-9998. #### L'inoltro delle chiamate deve rimanere disabilitato fino al verificarsi di un evento di resilienza Sebbene un amministratore possa pre-configurare la logica di inoltro chiamate per un sito in anticipo, la funzionalità di inoltro chiamate deve rimanere disabilitata fino al verificarsi di un evento di resilienza. Se l'inoltro chiamate è abilitato durante le operazioni di routine, tutte le chiamate in ingresso verso un numero registrato su Zoom Phone verranno reindirizzate all'SBC on-premises e al numero BYOC associato, bypassando i servizi di Zoom Phone. Pertanto, per mantenere l'instradamento normale di Zoom Phone, l'inoltro chiamate deve rimanere disabilitato durante le operazioni di routine. #### L'inoltro chiamate può essere abilitato solo da un utente autorizzato o admin con una connessione internet funzionante Durante un evento in modalità di resilienza, si presume che la connessione internet di un sito sia non disponibile. Tuttavia, poiché l'inoltro chiamate deve rimanere disabilitato per il funzionamento standard, può essere abilitato solo da un utente autorizzato o da un admin con una connessione internet funzionante come un piano dati del telefono o una connessione internet alternativa in una ubicazione diversa. {% hint style="info" %} Per ridurre al minimo i tempi di inattività e garantire la continuità aziendale, Zoom raccomanda alle aziende di stabilire procedure affidabili per abilitare la logica di inoltro chiamate dal portale web durante un evento di resilienza. {% endhint %} #### Le regole di inoltro chiamate possono applicarsi all'intero sito o a numeri individuali Durante un evento di resilienza, un amministratore o un utente autorizzato può abilitare le regole di inoltro chiamate per l'intero sito o per numeri specifici dal portale web. #### Una volta che l'inoltro chiamate è abilitato per il numero di telefono di un utente, Zoom non farà squillare il client registrato sul cloud dell'utente, anche se mantiene una connessione cloud indipendente Quando l'inoltro chiamate è abilitato per un numero registrato su Zoom Phone, Zoom non tenterà di instradare alcuna chiamata all'utente tramite il cloud. Di conseguenza, anche se un utente interessato dispone di un dispositivo registrato sul cloud come un telefono cellulare, se il numero di telefono è contrassegnato per l'inoltro chiamate, tutte le chiamate verranno instradate tramite la PSTN verso l'SBC dell'azienda. Ad esempio, un sito sta sperimentando un evento in modalità resilienza e il telefono cellulare di un utente è connesso al cloud di Zoom Phone tramite la connessione dati del suo operatore. Se il numero di telefono di un utente è contrassegnato per l'inoltro chiamate, il cloud di Zoom Phone **non** farà squillare il loro numero Zoom Phone tramite l'app mobile, nonostante la connessione stabile. Invece, tutte le chiamate continueranno a instradare tramite la PSTN verso l'SBC del cliente. #### Se l'inoltro chiamate non è abilitato per un utente durante un evento di resilienza, le chiamate in arrivo seguiranno le preferenze di gestione delle chiamate di ciascun utente Se l'inoltro chiamate non è abilitato durante un evento di resilienza, le chiamate in arrivo saranno gestite secondo la [logica di gestione delle chiamate](https://support.zoom.us/hc/en-us/articles/360059966372-Customizing-call-handling-settings) per ciascun utente. Se un utente non dispone di un client telefonico di backup registrato sul cloud, come un telefono cellulare, i chiamanti saranno soggetti alle regole definite dalla **Quando una chiamata non viene risposta** sezione delle preferenze di gestione delle chiamate. #### L'inoltro chiamate si applica solo alle chiamate PSTN in entrata L'inoltro chiamate per la resilienza si applica solo alle chiamate instradate attraverso la PSTN e/o il cloud Zoom Phone. Le chiamate originate da interni registrati su Zoom all'interno dello stesso sito tenteranno prima di connettersi tramite il modulo ZPLS e, secondariamente, tramite la PSTN se è connesso un SBC. Le chiamate che non riescono a connettersi saranno altrimenti soggette al trattamento definito dalla **Quando una chiamata non viene risposta** sezione delle regole di gestione delle chiamate nelle impostazioni del telefono di un utente. ### Flusso di inoltro chiamate Il diagramma seguente illustra la logica per l'inoltro chiamate (una volta abilitato) durante un evento di resilienza. Questa logica rimarrà in vigore fino a quando l'inoltro chiamate non verrà disabilitato o fino al ripristino delle operazioni standard. Tuttavia, se l'inoltro chiamate rimane abilitato *dopo* che le operazioni standard sono state ripristinate, le chiamate inoltrate faranno hairpin dal cloud di Zoom Phone, all'SBC e di nuovo al cloud, prima di essere consegnate al dispositivo dell'utente. Per questo motivo, l'inoltro chiamate dovrebbe essere disabilitato prontamente dopo un evento di resilienza.
1. Un chiamante esterno avvia una chiamata a un numero registrato su Zoom Phone ed è instradato attraverso la PSTN. 2. La chiamata viene instradata al cloud di Zoom Phone e il numero chiamato viene identificato come interessato dall'inoltro chiamate. {% hint style="info" %} Se l'inoltro chiamate non è abilitato, Zoom Phone seguirà la **Quando una chiamata non viene risposta** logica per quell'utente o interno particolare. {% endhint %} 3. Poiché l'inoltro chiamate è abilitato, Zoom non tenterà di avvisare l'utente e reindirizzerà invece la chiamata verso il numero designato per l'inoltro chiamate attraverso la PSTN. 4. La chiamata viene instradata dalla PSTN all'SBC di resilienza. 5. L'SBC di resilienza inoltra la chiamata al modulo ZPLS. 6. Il modulo ZPLS inoltra la chiamata ai client registrati dell'utente, se connessi. ### Considerazioni sul Numero di Identificazione della Posizione di Emergenza (ELIN) #### Un ELIN è un numero di telefono esclusivo per il sito che comunica informazioni sulla posizione ai servizi di emergenza quando viene composto Un Numero di Identificazione della Posizione di Emergenza (ELIN) è un numero di telefono dedicato che viene utilizzato dai Public Safety Answering Points (PSAP) per identificare l'indirizzo fisico di un chiamante quando chiama i servizi di emergenza. Per questa funzionalità, le aziende devono collaborare con il loro fornitore di servizi PSTN per mappare un indirizzo a un numero di telefono, per contribuire a garantire che l'indirizzo sia elencato in un database di identificazione automatica della posizione (ALI) quando la chiamata viene ricevuta da un operatore PSAP. Ad esempio, considera un campus universitario che si estende su più edifici, con ogni edificio rappresentato da un sito Zoom Phone separato. Se un utente chiama i servizi di emergenza durante un evento di resilienza da un telefono o dispositivo [associato al sito](#_ggwzik1hd9xi), i servizi di emergenza riceveranno automaticamente l'indirizzo completo registrato per il sito, purché la posizione sia configurata e aggiornata con il fornitore di servizi. #### Ogni sito può supportare più ELIN I clienti possono assegnare più ELIN a un sito per avere una riserva di numeri di emergenza. In caso di emergenza durante un evento di resilienza, ciò consentirà a più chiamanti di avere ciascuno un ELIN assegnato in modo univoco, il che può aiutare i servizi di emergenza a raggiungere il chiamante originale se restituiscono la chiamata. Inoltre, un ELIN può essere assegnato a un utente o a un telefono di area comune, fornendo un'assegnazione ELIN più granulare rispetto al livello del sito, offrendo una posizione più precisa per i servizi di emergenza. #### Durante un evento di resilienza, tutte le chiamate di emergenza vengono sostituite dall'ELIN Quando un utente effettua una chiamata di emergenza durante un evento di resilienza, il numero chiamante dell'utente, se disponibile, verrà sostituito con l'ELIN designato a livello di sito. Ciò consente agli utenti che non dispongono di un numero diretto di chiamare i servizi di emergenza ed essere raggiunti per una richiamata dall'operatore di emergenza. #### Un numero ELIN deve essere un numero BYOC associato al trunk PSTN dell'SBC del sito L'ELIN di un sito **deve** essere un numero BYOC terminato su un trunk PSTN situato nell'SBC di failover del sito. Nessun altro tipo di numero può essere utilizzato. #### Il modulo ZPLS instraderà automaticamente le chiamate dei provider di emergenza verso l'ELIN di ritorno all'interno dell'estensione dell'utente che ha chiamato originariamente per fino a 2 ore Se un operatore di emergenza richiama l'ELIN, il modulo ZPLS instraderà la chiamata all'utente originale che ha effettuato la chiamata di emergenza. Il modulo ZPLS continuerà a instradare le richiamate PSAP al chiamante originale per un massimo di 2 ore. Attualmente questa funzionalità è limitata al primo chiamante. #### Una volta che un numero di telefono è designato come ELIN, non può essere assegnato a un utente o dispositivo Una volta che un amministratore ha assegnato un numero BYOC come ELIN designato per un sito, il numero BYOC non può essere assegnato a nessun utente o altra entità Zoom Phone a meno che non venga rimosso dall'assegnazione. #### I clienti sono responsabili di mantenere e aggiornare gli indirizzi fisici associati ai loro ELIN per ciascun sito Zoom non si assume la responsabilità di aggiornare i provider BYOC con gli indirizzi fisici correlati a ciascun ELIN. I clienti sono responsabili di garantire che gli indirizzi di emergenza siano correttamente mappati all'indirizzo fisico appropriato. ### Considerazioni sull'instradamento PSTN #### Quando la modalità di resilienza è attiva, i pacchetti multimediali vengono instradati attraverso il modulo ZPLS Quando la modalità di resilienza è abilitata, i client non comunicano direttamente con un SBC o altri client interni; invece, i pacchetti multimediali vengono ancorati o “hairpinati” attraverso il modulo ZPLS, senza supporto per il rilascio del carico multimediale. Il diagramma seguente rappresenta il percorso di segnalazione e multimediale per le chiamate interne ed esterne attive.
#### Le chiamate tenteranno di instradare localmente prima Ogni volta che è possibile, il modulo ZPLS tenterà di instradare le chiamate originate da client Zoom registrati verso destinazioni registrate localmente. Le chiamate vengono inoltrate all'SBC solo se la destinazione contenuta nel campo Request URI dell'SIP Invite in arrivo non corrisponde a un interno registrato. {% hint style="info" %} Un interno registrato è un interno breve senza il codice sito, un interno lungo con il codice sito, un numero assegnato e registrato su Zoom o un numero BYOC assegnato. Gli amministratori devono tenere presente che il modulo ZPLS aggiorna questi dati [una volta ogni 10 ore](#_54gf3fuxcnk5). {% endhint %} #### Durante un evento di resilienza, le chiamate esterne in uscita visualizzeranno il numero BYOC dell'utente Durante un evento di resilienza, le chiamate esterne in uscita dai dispositivi registrati su ZPLS conterranno il numero chiamante BYOC. Il diagramma seguente rappresenta il flusso di chiamata in modalità resilienza per un utente:
#### Le chiamate di ritorno possono instradare al numero BYOC di un utente Poiché le chiamate esterne in uscita effettuate durante un evento di resilienza utilizzeranno un numero BYOC, i chiamanti esterni potrebbero richiamare utilizzando un numero BYOC invece del numero registrato su Zoom dell'utente. Se l'evento di resilienza è terminato, le chiamate instraderanno di nuovo attraverso il cloud [se è configurata la corretta priorità di instradamento](#_zgofkpkt74xr). Tuttavia, se l'evento è in corso, l'SBC instraderà la chiamata al modulo ZPLS e al dispositivo registrato dal client.
#### Codec supportati per la resilienza I codec supportati per la resilienza sono Opus, G.711 μ-law, G.711 A-law e G.729. Non è supportata la transcodifica o la modifica del bitrate dei codec audio. Tutte le parti coinvolte in una chiamata attiva devono supportare lo stesso codec e la stessa frequenza di campionamento. ### Considerazioni sui Gruppi di Distribuzione per la Resilienza Questa sezione illustra le considerazioni per i Survivability Distribution Groups (SDG). I clienti che non intendono utilizzare gli SDG o integrare il modulo ZPLS con la connettività PSTN possono saltare questa sezione senza conseguenze. #### I Gruppi di Distribuzione per la Resilienza forniscono opzioni di instradamento chiamate più dettagliate durante un evento di resilienza I survivability distribution groups (SDG) offrono alle aziende opzioni di instradamento chiamate più sofisticate — come code di chiamata e menu IVR (Interactive Voice Response) — durante un evento di resilienza. Con gli SDG, le aziende possono continuare a supportare i servizi telefonici principali e le configurazioni di instradamento delle chiamate (simili a code di chiamata, centralini automatici e gruppi di linea condivisa) fino al ripristino delle operazioni standard. #### Gli SDG non sono gli stessi dei gruppi di distribuzione per operazioni standard e devono essere creati e mantenuti separatamente Sebbene gli SDG offrano funzionalità di instradamento delle chiamate simili ai gruppi di distribuzione per operazioni standard, gli SDG sono unici e specifici per eventi di resilienza e, di conseguenza, devono essere creati e mantenuti separatamente. In altre parole, gli SDG **non** ereditano le impostazioni o le configurazioni di un gruppo di distribuzione per operazioni standard (ad es. coda di chiamata, centralino automatico, IVR, ecc.) #### Gli SDG funzionano al meglio se abbinati a un'integrazione BYOC-PSTN e all'inoltro chiamate abilitato Sebbene gli SDG possano fornire supporto solo interno (cioè chiamate non PSTN), funzionano al meglio se abbinati a un'integrazione BYOC-PSTN. Con un SDG abilitato per PSTN, una volta abilitato l'inoltro chiamate durante un evento di resilienza, il numero principale dell'azienda può instradare verso il numero designato dell'SDG e la chiamata seguirà il profilo di instradamento configurato. Ciò consente a un'azienda di offrire un flusso di chiamata coerente per i chiamanti esterni fino al ripristino delle operazioni standard. Il diagramma seguente dimostra la logica di instradamento delle chiamate per un SDG abilitato per PSTN:
#### Gli SDG possono essere personalizzati nei seguenti modi Gli SDG supportano le seguenti opzioni: * Numero di interno dedicato * Numero diretto DID assegnato * Fuso orario * Orari lavorativi * Saluti registrati * Membri del gruppo * Instrada verso: * Utente * Menu di risposta vocale interattiva (IVR) * Membri del gruppo * Numero di telefono * Distribuzione delle chiamate: * Simultanea * Sequenziale ### Considerazioni hardware e di rete Questa sezione tratta le considerazioni hardware e di rete per il modulo ZPLS, un'integrazione SBC, i client Zoom e i dispositivi telefonici. Dopo aver letto questa sezione, dovresti avere una comprensione delle comunicazioni e delle configurazioni di rete necessarie per una distribuzione ZPLS. {% hint style="info" %} Questa sezione è dedicata alla distribuzione hardware e al *considerazioni sul design*. Fare riferimento alla sezione su [distribuzione del ZPLS](#_wrba5u2ahyc) per istruzioni di distribuzione passo passo. {% endhint %} #### Considerazioni sulla distribuzione del modulo ZPLS e sulla rete **Il modulo ZPLS richiede un indirizzo IPv4 statico all'interno della tua rete** Il modulo ZPLS dovrebbe essere distribuito su una LAN interna con un indirizzo IPv4 statico accessibile ai dispositivi Zoom Phone e ai client desktop. Il modulo ZPLS al momento non supporta indirizzi IPv6. **Il modulo ZPLS deve mantenere connessioni HTTPS periodiche con il cloud di Zoom Phone** Il modulo ZPLS richiede connessioni HTTPS periodiche con il cloud di Zoom Phone per [sincronizzare impostazioni dell'account e degli utenti](#_54gf3fuxcnk5). Nella maggior parte dei casi, un modulo ZPLS può essere distribuito su una LAN interna all'interno della rete di un cliente. In alternativa, in alcune circostanze può essere utilizzata una rete DMZ; tuttavia, gli amministratori di rete devono assicurare che la comunicazione sia possibile attraverso il firewall aziendale. In entrambi i casi, gli amministratori sono tenuti ad adeguare la politica del firewall aziendale per consentire la comunicazione tra il modulo ZPLS e il Cloud Zoom. **Il modulo ZPLS deve mantenere un ping OPTIONS regolare con il cloud di Zoom Phone** Mentre è in stato di inattività, il modulo ZPLS deve mantenere un ping OPTIONS di keepalive con il cloud di Zoom Phone per monitorare la connettività. Nel caso in cui sia i dispositivi client sia il modulo ZPLS in un sito perdano la connettività con il cloud di Zoom Phone, i client e i dispositivi supportati si registreranno al modulo ZPLS utilizzando l'autenticazione SIP Digest su TLS v1.2. #### Considerazioni sulla distribuzione e rete dell'SBC **Un SBC deve essere raggiungibile da ZPLS e dal cloud Zoom quando possibile** I clienti devono assicurarsi che l'SBC mantenga la connettività sia con il modulo ZPLS sia con il cloud di Zoom Phone, quando possibile. I clienti possono fornire un SBC con doppia NIC configurato con un indirizzo IPv4 privato e pubblico, o assicurarsi che siano presenti regole NAT statiche 1:1 sul firewall di periferia oltre all'apertura delle porte richieste. **Un SBC deve mantenere connettività TLS e UDP tra il cloud Zoom Phone e il modulo ZPLS** Durante le operazioni di routine, un SBC deve mantenere connettività TLS e UDP sia verso il cloud di Zoom Phone sia verso il modulo ZPLS del sito associato. Questa connessione è utilizzata per instradare eventuali chiamate verso un numero telefonico elencato BYOC [attraverso il cloud di Zoom Phone](#_zgofkpkt74xr). Il meccanismo OPTIONS keepalive è abilitato automaticamente tra ZPLS e l'SBC ed è opzionale tra l'SBC e il cloud. #### Considerazioni su client Zoom e dispositivi telefonici **I client e i dispositivi devono poter individuare il modulo ZPLS del sito all'interno della rete locale** Client e dispositivi supportati [abilitati per la resilienza telefonica](#_ah8xua8wdq10) individuano il modulo ZPLS di failover appropriato dal cloud di Zoom Phone durante il processo di avvio. Tuttavia, il modulo deve già essere [associato al sito del sistema telefonico](#_k11n5zxkx1pq) con un indirizzo IPv4 internamente individuabile. **I dispositivi dovrebbero avere un IP statico o essere assegnati a un IP privato tramite un server DHCP locale** Per mitigare potenziali problemi, i dispositivi telefonici dovrebbero essere assegnati a un IP statico o a un IP interno tramite un server DHCP locale. Se un dispositivo non riceve un IP statico o un server DHCP non è disponibile durante un evento di resilienza, i dispositivi telefonici potrebbero non riuscire a registrarsi. **I client e i dispositivi devono mantenere regolarmente un ping OPTIONS con il cloud di Zoom Phone** Analogamente al modulo ZPLS, i client e i dispositivi supportati devono mantenere un ping OPTIONS di keepalive verso il cloud di Zoom Phone per determinare lo stato di connettività dei data center. In caso di interruzione, il client continua a inviare messaggi di keepalive per rilevare il ritorno del servizio cloud e avviare la ripresa delle operazioni normali. Questo processo è automatico e non può essere disattivato. #### Firewall e flusso dei dati di rete Vedi la sezione su [Porte di rete e flusso dei dati](#_pswiusfsww6t).