> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/it/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/pstn-integration-considerations.md).
# Considerazioni sulle Integrazioni PSTN
Questa sezione si applica ai Clienti che stanno valutando l'integrazione del modulo ZPLS con un SBC e una connessione PSTN per una sopravvivenza aggiuntiva. I Clienti che non prevedono di integrare il modulo ZPLS con connettività PSTN possono ignorare questa sezione senza conseguenze.
### Considerazioni sulle Integrazioni SBC
#### Requisiti SBC
Per integrare un SBC con Zoom per la sopravvivenza, un SBC deve soddisfare i seguenti requisiti:
* TLS 1.2 e SRTP
* Assistenza per Mutual TLS
* Protocollo di Avvio sessione (SIP)
* DTMF (RFC-2833)
* Occultamento 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 sessione border controller (SBC) collegato a una connessione legacy oppure a un SIP trunk con una connessione cellulare o alternativa (ad esempio DSL). I Clienti devono tenere presente che qualsiasi SIP trunk distribuito sull'SBC potrebbe dipendere dallo stesso servizio internet che sta subendo un'interruzione. Per questa possibilità, i Clienti dovrebbero valutare una connessione terziaria affidabile per la connettività PSTN.
#### È possibile utilizzare qualsiasi SBC certificato BYOC per Zoom Phone
Qualsiasi sessione 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ò essere utilizzato anche con il modulo ZPLS. I Clienti con un piano BYOC Zoom Phone esistente non richiedono un SBC aggiuntivo o separato ai fini della sopravvivenza.
#### I certificati DigiCert di Zoom devono essere installati sull'SBC
Per stabilire la connettività TLS sia al modulo ZPLS sia al 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 entrata ai data center Zoom Phone come prima e seconda scelta di Instradamento, e al modulo ZPLS come terza
Gli SBC del cliente 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 sopravvivenza, poiché altrimenti l'SBC e i data center Zoom Phone dovrebbero mantenere una connettività stabile.
Il mancato rispetto di questa logica può causare errori di consegna delle chiamate, poiché il modulo ZPLS non può instradare le chiamate verso dispositivi registrati nel cloud.
{% hint style="info" %}
Una volta che il cloud Zoom Phone è Disponibile dopo un Evento di sopravvivenza, un SBC può tentare temporaneamente di instradare i numeri BYOC al cloud Zoom mentre il Dispositivo client del numero interessato è registrato al modulo ZPLS. In questo caso, l'inoltro chiamate seguirà le Impostazioni per [**Quando una chiamata non riceve risposta**](https://support.zoom.us/hc/en-us/articles/360059966372-Customizing-call-handling-settings#h_86f4bf1b-51ea-4d70-9e40-4a84a5ca1c2c) durante questo periodo provvisorio.
{% endhint %}
#### Le chiamate In uscita dal modulo ZPLS devono essere instradate verso l'SBC e il SIP trunk PSTN
Quando la modalità di sopravvivenza è Attiva, le chiamate da ZPLS verso l'SBC devono essere instradate al SIP Trunk 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 sopravvivenza nel formato E.164.
### Considerazioni sulla sopravvivenza locale dell'inoltro delle chiamate
#### Durante un Evento di sopravvivenza, i Numeri telefonici forniti da Zoom Phone non saranno raggiungibili esternamente a meno che non vengano reindirizzati tramite l'inoltro delle chiamate
Durante un Evento di sopravvivenza, i Numeri telefonici forniti da Zoom non saranno raggiungibili esternamente dal punto di vista del cloud. Di conseguenza, gli utenti che si trovano 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, Reception automatiche (AR), Gruppi linea condivisa (SLG) e Code di chiamata (CQ).
{% endhint %}
#### I Clienti che utilizzano un BYOC basato on-premises non richiedono configurazioni avanzate e possono ignorare l'inoltro delle chiamate aggiungendo un percorso terziario al loro modulo ZPLS dal loro SBC
I Clienti che utilizzano un piano BYOC basato on-premises (ovvero, Clienti che non utilizzano numeri registrati a Zoom Phone) non richiedono configurazioni avanzate per Abilita l'inoltro delle chiamate. Invece, i Clienti BYOC possono Aggiungi un percorso terziario al modulo ZPLS dall'SBC basato nei locali.
#### Le configurazioni di inoltro delle chiamate vengono 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 delle chiamate](#_1od0waijmvaz) dal portale web tramite [inserimento manuale o caricamento massivo CSV](#_aezu04x8z043).
#### Agli utenti configurati per l'inoltro delle chiamate verranno assegnati tre numeri
Dopo aver applicato un numero BYOC a un utente per la sopravvivenza dell'inoltro delle chiamate, al Dispositivo client verranno assegnati *almeno* tre numeri:
1. Un interno con codice sede anteposto
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, puoi inoltrare più Numeri telefonici allo stesso numero BYOC.
Ad esempio, se a John è assegnato il Numero telefonico X55-555-5555, il Numero telefonico di John può essere inoltrato al numero dell’operatore del suo edificio al numero 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, ciascun utente può avere il proprio Numero telefonico inoltrato a un numero completamente univoco, ad esempio X55-555-5554 con Instradamento verso X99-999-9998 e X55-555-5553 con Instradamento verso 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 chiamare deve rimanere disabilitato finché non si verifica un Evento di survivability
Anche se un amministratore può preconfigurare in anticipo la logica di inoltro delle chiamare per una sede, la funzionalità di inoltro delle chiamare deve rimanere disabilitata finché non si verifica un Evento di survivability. Se l’inoltro delle chiamare è abilitato durante le normali operazioni, tutte le chiamate in entrata a un numero registrato su Zoom Phone verranno reindirizzate al SBC on-premises e al corrispondente numero telefonico BYOC, bypassando i servizi Zoom Phone. Pertanto, per mantenere il normale Instradamento di Zoom Phone, l’inoltro delle chiamare deve essere disabilitato durante le normali operazioni.
#### L’inoltro delle chiamare può essere abilitato solo da un utente autorizzato o admin con una connessione Internet funzionante
Durante un Evento di modalità survivability, si presume che la connessione Internet di una sede non sia disponibile. Tuttavia, poiché l’inoltro delle chiamare deve rimanere disabilitato per il normale funzionamento, può essere abilitato solo da un utente autorizzato o admin con una connessione Internet funzionante, come un piano dati del telefono o una connessione Internet alternativa in una Posizione diversa.
{% hint style="info" %}
Per ridurre al minimo i tempi di inattività e garantire la continuità Business, Zoom consiglia alle aziende di stabilire procedure affidabili per Abilita la logica di inoltro delle chiamare dal portale web durante un Evento di survivability.
{% endhint %}
#### Le regole di inoltro delle chiamare possono essere applicate all’intera sede o ai singoli numeri
Durante un Evento di survivability, un amministratore o un utente autorizzato può Abilita le regole di inoltro delle chiamare per l’intera sede o per numeri specifici dal portale web.
#### Una volta che l'inoltro delle chiamate è abilitato 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 è abilitato per un numero registrato su Zoom Phone, Zoom non tenterà di instradare alcuna chiamare verso l'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 in modalità di survivability 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 farà** squillare il loro 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 è abilitato per un utente durante un evento di survivability, 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 gestite in base alla [logica di gestione chiamata](https://support.zoom.us/hc/en-us/articles/360059966372-Customizing-call-handling-settings) per ciascun utente. Se un utente non ha un client telefonico di backup registrato nel cloud, come un telefono cellulare, i chiamanti saranno soggetti alle regole definite dalla **Quando una chiamare non viene risposta** sezione delle preferenze di gestione chiamata.
#### Il trasferimento di chiamata si applica solo alle chiamate in arrivo PSTN
Il trasferimento di chiamata per la survivability si applica solo alle chiamare instradate tramite la PSTN e/o il cloud Zoom Phone. Le chiamate originate da estensioni registrate su Zoom all'interno della stessa sede tenteranno prima di connettersi tramite il modulo ZPLS e, se è collegato un SBC, tramite la PSTN in secondo luogo. Le chiamate che non possono connettersi saranno altrimenti soggette al trattamento definito dalla **Quando una chiamare non viene risposta** sezione delle regole di gestione chiamata nelle Impostazioni del telefono di un utente.
### Flusso di inoltro chiamata
Il seguente diagramma illustra in dettaglio la logica per il trasferimento di chiamata (una volta abilitato) durante un Evento di survivability. Questa logica resterà in vigore fino a quando il trasferimento di chiamata non verrà disabilitato o non verranno ripristinate le operazioni Standard. Tuttavia, se il trasferimento di chiamata rimane abilitato *dopo* che le operazioni Standard sono state ripristinate, le chiamate inoltrate faranno hairpin dal cloud Zoom Phone, all'SBC e di nuovo al cloud, prima di essere recapitate al Dispositivo di un utente. Per questo motivo, il trasferimento di chiamata dovrebbe essere disabilitato tempestivamente dopo un Evento di survivability.
1. Un chiamante esterno avvia una chiamata verso un numero registrato a Zoom Phone ed è instradato tramite la PSTN.
2. La chiamata è instradata al cloud Zoom Phone e il numero di telefono composto viene identificato come interessato dal trasferimento di chiamata.
{% hint style="info" %}
Se l'inoltro di chiamate non è abilitato, Zoom Phone seguirà il **Quando una chiamare non viene risposta** logica per quello specifico utente o estensione.
{% endhint %}
3. Poiché l’inoltro di chiamare è abilitato, Zoom non tenterà di avviso l’utente e invece reindirizzerà la chiamare verso il numero di inoltro di chiamare designato attraverso il PSTN.
4. Il chiamare viene instradato dalla PSTN al SBC di survivability.
5. L'SBC di survivability 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 della sede 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 utilizzato dai Punti di risposta per la sicurezza pubblica (centro 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, al fine di contribuire a garantire che l'indirizzo sia elencato in un database di identificazione automatica della Posizione (ALI) quando il chiamare viene ricevuto da un operatore del centro di raccolta delle chiamate di emergenza.
Ad esempio, considera 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 da registrare per la sede, a condizione che la Posizione sia configurata e aggiornata presso il fornitore di servizi.
#### Ogni sede può supportare più ELIN
I Clienti possono Assegna più ELIN a una sede per un pool di risorse di numero di emergenza. In caso di un Evento 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 effettuano una chiamare di ritorno.
Inoltre, un ELIN può essere assegnato a un utente o a un telefono area comune, offrendo un’assegnazione ELIN più granulare rispetto al livello della sede, e 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 chiamata di emergenza durante un Evento di survivability, il numero di chiamata dell’utente, se uno è Disponibile, verrà sostituito con l’ELIN designato a livello di sede. Ciò consente agli utenti che non hanno un numero diretto di chiamare i servizi di emergenza ed essere raggiungibili per richiamare dall’operatore di emergenza.
#### Un numero ELIN deve essere un numero BYOC associato al trunk PSTN SBC della sede
Un ELIN della sede **deve** essere un numero BYOC che termina su un trunk PSTN situato presso l’SBC di failover della sede. Non è possibile utilizzare nessun altro tipo di numero.
#### Il modulo ZPLS instraderà automaticamente le chiamate del fornitore di emergenza verso l’ELIN di nuovo al numero interno dell’utente che ha originariamente composto il numero per un massimo di 2 ore
Se un operatore di emergenza restituisce una chiamare all’ELIN, il modulo ZPLS instraderà la chiamare di nuovo all’utente originale che ha effettuato la chiamata 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 rimosso.
#### I Clienti sono responsabili del mantenimento e dell’aggiornamento degli indirizzi fisici associati al proprio 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 attraverso il modulo ZPLS
Quando la modalità di sopravvivenza è abilitata, i client non comunicano direttamente con un SBC o altri client interni; invece, i pacchetti multimediali sono ancorati o “hairpinned” attraverso il modulo ZPLS, senza supporto per l’offload dei media.
Il diagramma seguente illustra il percorso di segnalazione e dei media per le chiamate interne ed esterne attive.
#### Le chiamate tenteranno prima di essere instradate localmente
Quando 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 URI di richiesta del SIP Invita in ingresso non corrisponde a un interno registrato.
{% hint style="info" %}
Un interno registrato è un interno breve senza il codice sede, un interno lungo con il codice sede, un numero assegnato 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 sopravvivenza, le chiamate esterne, In uscita mostreranno il numero BYOC dell’utente
Durante un Evento di sopravvivenza, le chiamate esterne, In uscita dai dispositivi registrati ZPLS conterranno il numero chiamante BYOC. Il diagramma seguente illustra il flusso di chiamata della modalità di sopravvivenza per un utente:
#### Le chiamate restituite 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 possono restituire una chiamare utilizzando un numero BYOC invece del numero di telefono dell’utente registrato su Zoom. Se l’Evento di sopravvivenza è terminato, le chiamate verranno instradate nuovamente attraverso il cloud [se è configurata la corretta priorità di Instradamento](#_zgofkpkt74xr). Tuttavia, se l’Evento è ancora in corso, l’SBC instraderà la chiamare al modulo ZPLS e al Dispositivo registrato dal 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 variazione del bitrate dei codec audio non è supportata. Tutte le parti coinvolte in una chiamata attiva devono supportare lo stesso codec e la stessa frequenza di campionamento.
### Considerazioni sul gruppo di distribuzione per la sopravvivenza
Questa sezione tratta considerazioni sui gruppi di distribuzione per la sopravvivenza (SDG). I Clienti che non prevedono di utilizzare gli SDG o di integrare il modulo ZPLS con la connettività PSTN possono saltare questa sezione senza conseguenze.
#### I gruppi di distribuzione per la sopravvivenza forniscono opzioni sfumate di inoltro chiamate durante un Evento di sopravvivenza
I gruppi di distribuzione per la 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) finché le operazioni standard non vengono ripristinate.
#### 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 farà** ereditano le Impostazioni o le configurazioni di un gruppo di distribuzione delle operazioni standard (ossia, coda delle chiamate, centralinista automatico, IVR, ecc.)
#### Gli SDG si abbinano al meglio con una Integrazioni BYOC-PSTN e con l’inoltro di chiamata abilitato
Sebbene gli SDG possano fornire un supporto solo interno (ossia chiamate non PSTN), si abbinano al meglio con 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. Questo consente a un’azienda di offrire un’esperienza di flusso delle chiamate coerente per i compositori esterni finché le operazioni standard non vengono ripristinate.
Il diagramma seguente dimostra la logica di inoltro chiamate per un SDG abilitato PSTN:
#### Gli SDG possono essere personalizzati nei modi seguenti
Gli SDG supportano le seguenti opzioni:
* Numero interno dedicato
* Numero di selezione diretta in ingresso assegnato
* Fuso orario
* Orario lavorativo
* Messaggi di saluto registrati
* Membri del gruppo
* Instrada 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 dispositivi telefonici. Dopo aver letto questa sezione, ci si può aspettare di comprendere le comunicazioni di rete e le configurazioni necessarie per un’implementazione ZPLS.
{% hint style="info" %}
Questa sezione è dedicata alla distribuzione dell'hardware e alle considerazioni sulla rete *di progettazione*. Fare riferimento alla sezione su [la distribuzione di ZPLS](#_wrba5u2ahyc) per istruzioni dettagliate sulla distribuzione.
{% 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 dispositivi Zoom Phone e ai client desktop. Al momento, il modulo ZPLS non supporta 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 account e impostazioni 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 può essere utilizzata una rete DMZ; tuttavia, gli amministratori di rete devono assicurarsi che la comunicazione sia possibile attraverso il firewall enterprise. In entrambi i casi, gli amministratori devono modificare la policy del firewall aziendale per Abilita la comunicazione tra il modulo ZPLS e cloud Zoom.
**Il modulo ZPLS deve mantenere un ping OPTIONS regolare con il cloud Zoom Phone**
Mentre è in stato di inattività, il modulo ZPLS deve mantenere un ping keepalive OPTIONS con il 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 il cloud 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 sulla rete dell'SBC
**Un SBC deve essere raggiungibile da ZPLS e cloud Zoom ogni volta che sia possibile**
I Clienti devono assicurarsi che l'SBC mantenga la connettività sia con il modulo ZPLS sia con cloud Zoom Phone, ogni volta che sia possibile. I Clienti possono predisporre un SBC dual-NIC configurato con un indirizzo IPv4 privato e pubblico, oppure assicurarsi che le regole statiche NAT 1:1 siano presenti sul firewall perimetrale, oltre ad aprire le porte richieste.
**Un SBC deve mantenere la connettività TLS e UDP tra il cloud Zoom Phone e il modulo ZPLS**
Durante le operazioni ordinarie, un SBC deve mantenere la connettività TLS e UDP sia con il 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 [attraverso il 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 per client Zoom e dispositivi telefonici
**I client e i dispositivi devono poter individuare il modulo ZPLS della sede all'interno della rete locale**
I client e i dispositivi supportati [Abilitato per la resilienza telefonica](#_ah8xua8wdq10) individuano il modulo ZPLS di failover appropriato dal cloud Zoom Phone durante il processo di avvio. Tuttavia, il modulo deve già essere [collegato alla sede del sistema telefonico](#_k11n5zxkx1pq) con un indirizzo IPv4 rilevabile internamente.
**I dispositivi dovrebbero avere un IP statico o essere assegnati a un IP privato tramite un server DHCP locale**
Per mitigare potenziali problemi, ai dispositivi telefonici dovrebbe essere assegnato un IP statico o un IP interno tramite un server DHCP locale. Se a un dispositivo non viene assegnato un IP statico, oppure se 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 un ping OPTIONS regolare con il cloud Zoom Phone**
Analogamente al modulo ZPLS, i client e i dispositivi supportati devono mantenere un ping keepalive OPTIONS verso il cloud Zoom Phone per determinare lo stato di connettività del data center. In caso di interruzione, il client continua a inviare messaggi keepalive al fine di 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
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## 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, and the optional `goal` 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=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.