# Considerazioni sull'Integrazioni PSTN
Questa sezione si applica ai Clienti che stanno considerando l'integrazione del modulo ZPLS con un SBC e una connessione PSTN per una maggiore resilienza. I Clienti che non intendono integrare il modulo ZPLS con connettività PSTN possono ignorare questa sezione senza conseguenze.
### Considerazioni sull'integrazione SBC
#### Requisiti SBC
Per integrare un SBC con Zoom per la resilienza, un SBC deve soddisfare i seguenti requisiti:
* TLS 1.2 e SRTP
* Assistenza per Mutual TLS
* Protocollo di Inizio sessione (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 controller di frontiera di sessione (SBC) collegato a una connessione legacy oppure a un trunk SIP con una connessione cellulare o alternativa (ad es. DSL). I Clienti devono tenere presente che eventuali trunk SIP implementati presso l'SBC possono dipendere dallo stesso servizio Internet che sta subendo un'interruzione. A causa di questa possibilità, i Clienti dovrebbero considerare una connessione terziaria affidabile per la connettività PSTN.
#### Qualsiasi SBC certificato BYOC di Zoom Phone può essere utilizzato
Qualsiasi controller di frontiera di sessione (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ò essere utilizzato anche con il modulo ZPLS. I Clienti con un piano Zoom Phone BYOC 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 cloud Zoom, i [certificati root e intermedi DigitCert di Zoom](https://support.zoom.us/hc/en-us/articles/360044092031) devono essere installati sull'SBC.
#### Gli SBC devono instradare le chiamate in entrata 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 entrata dalla PSTN alla zona 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.
La mancata osservanza di questa logica può causare errori di consegna delle chiamate, poiché il modulo ZPLS non può instradare le chiamate ai dispositivi registrati nel cloud.
{% hint style="info" %}
Una volta che il cloud Zoom Phone è disponibile in seguito a un evento di resilienza, un SBC può temporaneamente tentare di instradare i numeri BYOC al cloud Zoom mentre il dispositivo client del numero interessato è registrato al modulo ZPLS. Se ciò accade, 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 instradarsi all'SBC e al trunk SIP PSTN
Quando la modalità di resilienza è attiva, le chiamate dal ZPLS verso l'SBC devono instradarsi al trunk SIP PSTN per stabilire connessioni telefoniche esterne. Tutte le chiamate ai numeri non registrati al modulo ZPLS vengono inviate all'SBC configurato per la resilienza in formato E.164.
### Considerazioni sull'inoltro chiamate per la resilienza locale
#### Durante un evento di resilienza, i Numeri telefonici forniti da Zoom Phone non saranno raggiungibili esternamente a meno che non vengano reindirizzati tramite inoltro chiamate
Durante un evento di resilienza, i Numeri telefonici 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 i numeri assegnati a: Utenti, Aree comuni, Reception automatiche (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 aggirare l'inoltro chiamate aggiungendo un percorso terziario al loro modulo ZPLS dal loro SBC
I Clienti che utilizzano un piano BYOC basato on-premises (ossia Clienti che non utilizzano numeri registrati a Zoom Phone) non richiedono configurazioni avanzate per abilitare l'inoltro chiamate. Invece, i Clienti BYOC possono aggiungere un percorso terziario al modulo ZPLS dall'SBC basato presso la sede.
#### Le configurazioni di inoltro chiamate sono impostate da un admin o da un utente autorizzato dal portale web
Un admin dell'account o un utente autorizzato può [configura la logica di inoltro chiamate](#_1od0waijmvaz) dal portale web tramite [inserimento manuale o caricamento CSV in blocco](#_aezu04x8z043).
#### Gli utenti configurati per l'inoltro chiamate avranno tre numeri assegnati
Dopo aver applicato un numero BYOC a un utente per la resilienza dell'inoltro chiamate, al dispositivo client verrà assegnato *almeno* tre numeri:
1. Un interno con prefisso del codice sede
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 **un** altro numero BYOC. Tuttavia, è possibile inoltrare più Numeri telefonici allo stesso numero BYOC.
Ad esempio, se a John viene assegnato il numero di telefono X55-555-5555, il numero di telefono di John può essere inoltrato al numero dell'operatore del suo 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 di telefono inoltrato a un numero completamente univoco, ad esempio X55-555-5554 che instrada a X99-999-9998 e X55-555-5553 che instrada 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 chiamate deve rimanere disabilitato finché non si verifica un evento di resilienza
Anche se un amministratore può preconfigurare la logica di inoltro chiamate per una sede in anticipo, la funzionalità di inoltro chiamate deve rimanere disabilitata finché non si verifica un evento di resilienza. Se l'inoltro chiamate è abilitato durante le normali operazioni, tutte le chiamate in entrata a un numero registrato a Zoom Phone verranno reindirizzate all'SBC on-premises e al numero di telefono BYOC associato, bypassando i servizi Zoom Phone. Pertanto, per mantenere il normale instradamento di Zoom Phone, l'inoltro chiamate deve essere disabilitato durante le normali operazioni.
#### L’inoltro delle chiamate può essere Abilita solo da un utente autorizzato o admin con una connessione Internet funzionante
Durante un Evento di modalità di sopravvivenza, si presume che la connessione Internet di una sede non sia disponibile. Tuttavia, poiché l’inoltro delle chiamate deve rimanere disabilitato per il funzionamento Standard, può essere Abilita solo da un utente autorizzato o admin con una connessione Internet funzionante, ad esempio un piano dati del telefono, oppure una connessione Internet alternativa in un’altra Posizione.
{% hint style="info" %}
Per ridurre al minimo i tempi di inattività e garantire la continuità operativa del Business, Zoom consiglia alle aziende di stabilire procedure affidabili per Abilita la logica di inoltro delle chiamate dal portale web durante un Evento di sopravvivenza.
{% endhint %}
#### Le regole di inoltro delle chiamate possono essere applicate all’intera sede o ai numeri individuali
Durante un Evento di sopravvivenza, un amministratore o un utente autorizzato può Abilita le regole di inoltro delle chiamate per l’intera sede o per numeri specifici dal portale web.
#### Una volta che l’inoltro delle chiamate è Abilita per il numero di telefono di un utente, Zoom non farà squillare il client registrato nel cloud dell’utente, anche se mantiene una connessione cloud indipendente
Quando l’inoltro delle chiamate è Abilita per un numero registrato a Zoom Phone, Zoom non tenterà di instradare alcuna chiamata all’utente tramite il cloud. Di conseguenza, anche se un utente interessato ha un Dispositivo registrato nel cloud come un telefono cellulare, se il numero di telefono è contrassegnato per l’inoltro delle chiamate, tutte le chiamate verranno instradate tramite il PSTN verso l’SBC dell’azienda.
Ad esempio, una sede sta vivendo un Evento di modalità di sopravvivenza e il telefono cellulare di un utente è connesso al cloud di Zoom Phone tramite la connessione dati del proprio operatore cellulare. Se il numero di telefono di un utente è contrassegnato per l’inoltro delle chiamate, il cloud di Zoom Phone **non sarai** farà squillare il suo numero Zoom Phone tramite l’app per dispositivi mobili, nonostante la connessione stabile. Invece, tutte le chiamate continueranno a essere instradate tramite il PSTN verso l’SBC del cliente.
#### Se l’inoltro delle chiamate non è Abilita per un utente durante un Evento di sopravvivenza, le chiamate in arrivo seguiranno le preferenze di gestione chiamata di ciascun utente
Se l’inoltro delle chiamate non è abilitato durante un Evento di survivability, le chiamate in arrivo verranno trattate in base alla [logica di gestione chiamata](https://support.zoom.us/hc/en-us/articles/360059966372-Customizing-call-handling-settings) per ciascun singolo utente. Se un utente non ha un client telefonico di backup registrato nel cloud, come un telefono cellulare, chi chiama sarà soggetto alle regole definite dalla **Quando una chiamata non viene risposta** sezione delle preferenze di gestione chiamata.
#### L’inoltro delle chiamate si applica solo alle chiamate PSTN in arrivo
L’inoltro delle chiamate per la survivability si applica solo alle chiamate instradate tramite PSTN e/o Zoom Phone cloud. Le chiamate originate da estensioni registrate su Zoom all’interno della stessa sede tenteranno di connettersi prima tramite il modulo ZPLS e, se è connesso un SBC, in secondo luogo tramite PSTN. 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 chiamata all’interno delle Impostazioni del telefono di un utente.
### Flusso di inoltro delle chiamate
Il seguente diagramma illustra in dettaglio la logica per l’inoltro delle chiamate (una volta abilitato) durante un Evento di survivability. Questa logica rimarrà in vigore fino a quando l’inoltro delle chiamate non verrà disabilitato o non verranno ripristinate le operazioni Standard. Tuttavia, se l’inoltro delle chiamate rimane abilitato *dopo* una volta ripristinate le operazioni standard, 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 delle chiamate dovrebbe essere disabilitato tempestivamente dopo un Evento di survivability.
1. Un chiamante esterno avvia una chiamare a un numero registrato su Zoom Phone e viene instradato attraverso il PSTN.
2. La chiamare viene instradata al cloud di Zoom Phone e il numero di telefono composto viene identificato come interessato dall'inoltro delle chiamate.
{% hint style="info" %}
Se l'inoltro delle chiamate non è abilitato, Zoom Phone seguirà la **Quando una chiamata non viene risposta** logica per quello specifico utente o interno.
{% endhint %}
3. Poiché l'inoltro delle chiamate è abilitato, Zoom non tenterà di avvisare l'utente e reindirizzerà invece la chiamare verso il numero designato per l'inoltro delle chiamate attraverso il PSTN.
4. La chiamare viene instradata dal PSTN all'SBC di survivability.
5. L'SBC di survivability inoltra la chiamare al modulo ZPLS.
6. Il modulo ZPLS inoltra la chiamare al/ai client registrato/i dell'utente, se connesso.
### Considerazioni sul Numero di Identificazione della Posizione di Emergenza (ELIN)
#### Un ELIN è un numero di telefono esclusivo della sede che comunica le informazioni sulla Posizione ai servizi di emergenza quando viene composto
Un Numero di Identificazione della Posizione di Emergenza (ELIN) è un numero di telefono dedicato utilizzato dai centri di raccolta delle chiamate di emergenza per identificare l'indirizzo fisico di un chiamante quando chiama i servizi di emergenza. Per questa Funzionalità, le aziende devono collaborare con il proprio fornitore di servizi PSTN per associare 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 del centro di raccolta delle chiamate di emergenza.
Ad esempio, si consideri un campus universitario che si estende su più edifici, con ogni edificio rappresentato da una sede separata di Zoom Phone. Se un utente compone i servizi di emergenza durante un Evento di survivability da un telefono o Dispositivo [associato alla sede](#_ggwzik1hd9xi), i servizi di emergenza riceveranno automaticamente l'indirizzo completo registrato per la sede, a condizione che la Posizione sia configurata e aggiornata con il fornitore di servizi.
#### Ogni sede può supportare più ELIN
I Clienti possono Assegna più ELIN a una sede per un pool di risorse per i numeri di emergenza. In caso di emergenza durante un Evento di survivability, 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 richiamano.
Inoltre, un ELIN può essere Assegna a un utente o a un telefono area comune, offrendo un'assegnazione dell'ELIN più granulare rispetto al livello della sede, e fornendo una Posizione più precisa per i servizi di emergenza.
#### Durante un Evento di survivability, tutte le chiamate di emergenza vengono sostituite dall'ELIN
Quando un utente effettua una chiamare di emergenza durante un evento di survivability, il numero di chiamata dell’utente, se uno è Disponibile, sarà sostituito con l’ELIN designato a livello di sede. Questo consente agli utenti che non hanno un numero diretto di chiamare i servizi di emergenza ed essere raggiungibili per il richiamo dall’operatore di emergenza.
#### Un numero ELIN deve essere un numero BYOC associato al trunk PSTN SBC della sede
L’ELIN di una sede **deve** essere un numero BYOC terminato su un trunk PSTN che si trova presso l’SBC di failover della sede. Non è possibile utilizzare nessun altro tipo di numero.
#### Il modulo ZPLS instraderà automaticamente le chiamate dei fornitori di emergenza all’ELIN verso l’interno dell’utente che ha composto originariamente per un massimo di 2 ore
Se un operatore di emergenza richiama l’ELIN, il modulo ZPLS reindirizzerà la chiamata all’utente originale che ha effettuato la chiamare di emergenza. Il modulo ZPLS continuerà a instradare i callback del centro di raccolta delle chiamate di emergenza al chiamante originale per un massimo di 2 ore. Al momento 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 una sede, il numero BYOC non può essere assegnato a nessun utente o altra entità Zoom Phone a meno che non venga annullata l’assegnazione.
#### I Clienti sono responsabili della manutenzione e dell’aggiornamento degli indirizzi fisici associati al loro ELIN per ciascuna sede
Zoom non si assume la responsabilità di aggiornare i carrier BYOC con gli indirizzi fisici che corrispondono a ciascun ELIN. I Clienti sono responsabili di garantire che gli indirizzi di emergenza siano mappati correttamente all’indirizzo fisico appropriato.
### Considerazioni sull'Instradamento PSTN
#### Quando la modalità di sopravvivenza è attiva, i pacchetti multimediali vengono instradati tramite il modulo ZPLS
Quando la modalità di sopravvivenza è abilitata, i client non comunicano direttamente con un SBC o con altri client interni; invece, i pacchetti multimediali vengono ancorati o "hairpinned" tramite il modulo ZPLS, senza supporto per l'offloading dei contenuti multimediali.
Il diagramma seguente illustra il percorso di segnalazione e dei contenuti multimediali per le chiamate interne ed esterne attive.
#### Le chiamate tenteranno prima di essere instradate localmente
Quando possibile, il modulo ZPLS tenterà di instradare localmente le chiamate provenienti da client Zoom registrati verso destinazioni registrate localmente. Le chiamate vengono inoltrate all'SBC solo se la destinazione contenuta nel campo Request URI del SIP Invita in ingresso non corrisponde a un interno registrato.
{% hint style="info" %}
Un interno registrato è un interno breve senza il codice della sede, un interno lungo con il codice della sede, un numero assegnato registrato su Zoom oppure 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 sopravvivenza, le chiamate esterne, In uscita saranno impostate per mostrare il numero BYOC dell'utente
Durante un Evento di sopravvivenza, le chiamate esterne, In uscita dai Dispositivo registrati su ZPLS conterranno il numero chiamante BYOC. Il diagramma seguente illustra il flusso di chiamata in modalità di sopravvivenza per un utente:
#### Le chiamate di ritorno possono essere instradate al numero BYOC di un utente
Poiché le chiamate esterne, In uscita effettuate durante un Evento di sopravvivenza utilizzeranno un numero BYOC, i chiamanti esterni potrebbero richiamare utilizzando un numero BYOC invece del numero di telefono dell'utente registrato su Zoom. Se l'Evento di sopravvivenza è terminato, le chiamate verranno instradate di nuovo tramite il cloud [se è configurata la corretta priorità di Instradamento](#_zgofkpkt74xr). Tuttavia, se l'Evento è ancora in corso, l'SBC instraderà la chiamata al modulo ZPLS e al Dispositivo registrato del client.
#### Codec di sopravvivenza supportati
I codec di sopravvivenza supportati sono Opus, G.711 μ-law, G.711 A-law e G.729. La transcodifica o la modifica del bitrate dei codec audio non sono supportate. Tutte le parti coinvolte in una chiamata attiva devono supportare lo stesso codec e la stessa frequenza di campionamento.
### Considerazioni sui gruppi di distribuzione di sopravvivenza
Questa sezione tratta le considerazioni relative ai gruppi di distribuzione di sopravvivenza (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 di sopravvivenza offrono opzioni articolate di inoltro chiamate durante un Evento di sopravvivenza
I gruppi di distribuzione di sopravvivenza (SDG) forniscono alle aziende opzioni articolate di inoltro chiamate, come code delle chiamate e menu di Risposta vocale interattiva (IVR), durante un Evento di sopravvivenza. Con gli SDG, le aziende possono continuare a supportare i servizi principali di telefonia e le configurazioni di inoltro chiamate (simili a code delle chiamate, centralinisti automatici e gruppi di linea condivisa) fino al ripristino delle operazioni standard.
#### Gli SDG non sono uguali ai gruppi di distribuzione delle operazioni standard e devono essere creati e mantenuti separatamente
Sebbene gli SDG offrano funzionalità di inoltro chiamate simili a quelle dei gruppi di distribuzione delle operazioni standard, gli SDG sono unici e specifici per gli Eventi di sopravvivenza e, di conseguenza, devono essere creati e mantenuti separatamente. In altre parole, gli SDG **non sarai** ereditano le Impostazioni o le configurazioni di un gruppo di distribuzione delle operazioni standard (ovvero coda delle chiamate, centralinista automatico, IVR, ecc.)
#### Gli SDG si abbinano al meglio a una Integrazioni BYOC-PSTN con l'inoltro di chiamata abilitato
Sebbene gli SDG possano fornire supporto solo interno (ovvero chiamate non PSTN), si abbinano al meglio a una Integrazioni BYOC-PSTN. Con un SDG abilitato per PSTN, una volta che l'inoltro di chiamata è abilitato durante un Evento di sopravvivenza, un numero aziendale principale può essere instradato al numero di telefono SDG designato e la chiamata seguirà il profilo di Instradamento configurato. Ciò consente a un'azienda di offrire un'esperienza di flusso di chiamata coerente ai chiamanti esterni fino al ripristino delle operazioni standard.
Il diagramma seguente mostra la logica di inoltro chiamate per un SDG abilitato per PSTN:
#### Gli SDG possono essere personalizzati nei seguenti modi
Gli SDG supportano le seguenti opzioni:
* numero interno dedicato
* Numero DID assegnato
* Fuso orario
* orario lavorativo
* Messaggi di saluto registrati
* Membri del gruppo
* Instradare a:
* utente
* Menu di Risposta vocale interattiva (IVR)
* Membri del gruppo
* Numero di telefono
* distribuzione delle chiamate:
* Simultaneo
* Sequenziale
### Considerazioni su hardware e rete
Questa sezione tratta le considerazioni su hardware e rete per il modulo ZPLS, una Integrazioni SBC, i client Zoom e i Dispositivo telefonici. Dopo aver letto questa sezione, si prevede di acquisire una comprensione delle comunicazioni di rete e delle configurazioni necessarie per una distribuzione ZPLS.
{% hint style="info" %}
Questa sezione è dedicata alla distribuzione hardware e alla rete *considerazioni sulla progettazione*. Fare riferimento alla sezione su [distribuzione di ZPLS](#_wrba5u2ahyc) per istruzioni di distribuzione dettagliate passo dopo passo.
{% endhint %}
#### Considerazioni sulla distribuzione e sulla rete del modulo ZPLS
**Il modulo ZPLS richiede un indirizzo IPv4 statico all'interno della rete**
Il modulo ZPLS deve essere distribuito su una LAN interna con un indirizzo IPv4 statico accessibile ai Dispositivo Zoom Phone e ai client desktop. Al momento il modulo ZPLS non supporta gli indirizzi IPv6.
**Il modulo ZPLS deve mantenere connessioni HTTPS periodiche con il cloud Zoom Phone**
Il modulo ZPLS richiede connessioni HTTPS periodiche con il cloud Zoom Phone per [sincronizzare le Impostazioni di account e utente](#_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 è possibile utilizzare una rete DMZ; tuttavia, gli amministratori di rete devono নিশ্চিতare che la comunicazione sia possibile attraverso il firewall aziendale. In entrambi i casi, gli amministratori devono modificare la policy del firewall aziendale per abilitare la comunicazione tra il modulo ZPLS e cloud Zoom.
**Il modulo ZPLS deve mantenere un ping OPTIONS regolare con cloud Zoom Phone**
Quando è in stato inattivo, il modulo ZPLS deve mantenere un ping keepalive OPTIONS con cloud Zoom Phone per monitorare la connettività. Nel caso in cui sia i dispositivi client sia il modulo ZPLS all'interno di una sede perdano la connettività con cloud Zoom Phone, i client e i dispositivi supportati si registreranno al modulo ZPLS utilizzando autenticazione SIP Digest su TLS v1.2.
#### Considerazioni su distribuzione e networking SBC
**Un SBC deve essere raggiungibile da ZPLS e cloud Zoom ogni volta che è possibile**
Clienti devono garantire che l'SBC mantenga la connettività sia con il modulo ZPLS sia con cloud Zoom Phone, ogni volta che è possibile. Clienti possono predisporre un SBC dual-NIC configurato con un indirizzo IPv4 privato e pubblico, oppure garantire che regole NAT statiche 1:1 siano presenti sul firewall perimetrale oltre ad aprire le porte richieste.
**Un SBC deve mantenere la connettività TLS e UDP tra cloud Zoom Phone e il modulo ZPLS**
Durante le normali operazioni, un SBC deve mantenere la connettività TLS e UDP sia con cloud Zoom Phone sia con il modulo ZPLS della sede associata. Questa connessione viene utilizzata per instradare eventuali chiamate verso un numero di telefono elencato in BYOC [tramite cloud Zoom Phone](#_zgofkpkt74xr). Il meccanismo di keepalive OPTIONS viene abilitato automaticamente tra ZPLS e l'SBC ed è Facoltativo tra l'SBC e il cloud.
#### Considerazioni su client Zoom e dispositivi telefonici
**I client e i dispositivi devono essere in grado di rilevare il modulo ZPLS della sede all'interno della rete locale**
Client e dispositivi supportati [abilitati per la survivability telefonica](#_ah8xua8wdq10) rilevano il modulo ZPLS di failover appropriato da cloud Zoom Phone durante il processo di avvio. Tuttavia, il modulo deve già essere [associato alla sede del sistema telefonico](#_k11n5zxkx1pq) con un indirizzo IPv4 rilevabile internamente.
**I dispositivi devono avere un IP statico oppure essere assegnati a un IP privato tramite un server DHCP locale**
Per mitigare i potenziali problemi, ai dispositivi telefonici deve essere assegnato un IP statico oppure un IP interno tramite un server DHCP locale. Se a un dispositivo non viene assegnato un IP statico, oppure un server DHCP non è disponibile durante un evento di survivability, i dispositivi telefonici potrebbero non riuscire a registrarsi.
**I client e i dispositivi devono mantenere un ping OPTIONS regolare con cloud Zoom Phone**
Analogamente al modulo ZPLS, i client e i dispositivi supportati devono mantenere un ping keepalive OPTIONS verso cloud Zoom Phone per determinare lo stato della connettività del data center. In caso di interruzione, il client continua a inviare messaggi keepalive per rilevare il ripristino del servizio cloud e avviare la ripresa delle normali operazioni. Questo processo è automatico e non può essere disabilitato.
#### Firewall e flusso dei dati di rete
Vedere la sezione su [Porte di rete e flusso dei dati](#_pswiusfsww6t).
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://library.zoom.com/technical-library/it/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/pstn-integration-considerations.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.