Considerazioni relative alle Integrazioni PSTN

Questa sezione si applica ai clienti che stanno valutando di integrare il modulo ZPLS con un SBC e una connessione PSTN per una sopravvivenza aggiuntiva. I clienti che non intendono integrare il modulo ZPLS con connettività PSTN possono saltare questa sezione senza conseguenze.

Considerazioni sull'integrazione 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 TLS reciproco

• Protocollo di iniziazione della sessione (SIP)

• DTMF (RFC-2833)

• Nascondimento della topologia (RFC-5853)

• Offerta anticipata SIP (obbligatoria)

• codec Opus, G.711 μ-law, G.711 A-law e G.729

Le Integrazioni PSTN richiedono un SBC e un provider di terze parti affidabile

Per la connettività PSTN, i clienti devono fornire un controller di bordo della 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 distribuiti presso l'SBC possono dipendere dallo stesso servizio Internet che sta subendo un'interruzione. Per questa possibilità, i clienti dovrebbero prendere in considerazione una connessione terziaria affidabile per la connettività PSTN.

Può essere utilizzato qualsiasi SBC certificato BYOC di Zoom Phone

Qualsiasi controller di bordo della sessione (SBC) che sia certificato per Zoom Phone 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 sopravvivenza.

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 di Zoom i certificati root e intermedi DigiCert devono essere installati sull'SBC.

Gli SBC devono instradare le chiamate In Entrata verso i 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 sopravvivenza, poiché l'SBC e i data center di Zoom Phone dovrebbero altrimenti 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.

Una volta che il cloud Zoom Phone è Disponibile dopo un Evento di sopravvivenza, un SBC può tentare temporaneamente di instradare i Numeri telefonici BYOC verso cloud Zoom mentre il dispositivo client del numero interessato è registrato al modulo ZPLS. Se ciò dovesse accadere, l'inoltro chiamate seguirà le Impostazioni per Quando una chiamata non riceve risposta durante questo periodo intermedio.

Le chiamate In Uscita dal modulo ZPLS devono essere instradate verso l'SBC e il trunk SIP PSTN

Quando la modalità di sopravvivenza è Attiva, le chiamate da ZPLS all'SBC devono essere instradate 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 sopravvivenza in formato E.164.

Considerazioni sulla sopravvivenza locale dell'inoltro chiamate

Durante un Evento di sopravvivenza, i Numeri telefonici forniti da Zoom Phone non saranno raggiungibili dall'esterno a meno che non vengano reindirizzati tramite l'inoltro chiamate

Durante un Evento di sopravvivenza, i Numeri telefonici forniti da Zoom non saranno raggiungibili dall'esterno 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.

Tra gli esempi comuni di numeri interessati possono figurare i numeri assegnati a: Utenti, Aree comuni, Auto Receptions (AR), Gruppi di linea condivisa (SLG) e Code di chiamata (CQ).

I clienti che utilizzano un BYOC on-premises non richiedono configurazioni avanzate e possono bypassare l'inoltro chiamate aggiungendo un percorso terziario al loro modulo ZPLS dal loro SBC

I clienti che utilizzano un piano BYOC on-premises (ovvero clienti che non utilizzano Numeri telefonici 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 dal 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 dal portale web tramite immissione manuale o caricamento in blocco CSV.

Gli utenti configurati per l'inoltro chiamate avranno tre numeri assegnati

Dopo aver applicato un numero BYOC a un utente per la sopravvivenza dell'inoltro chiamate, al Dispositivo client verranno assegnati almeno tre numeri:

1. Un interno con il 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 di 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 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 unico, ad esempio X55-555-5554 instradato verso X99-999-9998 e X55-555-5553 instradato 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 chiamate deve rimanere disabilitato fino a quando non si verifica un Evento di sopravvivenza

Sebbene un amministratore possa preconfigurare in anticipo la logica di inoltro chiamate per una sede, la funzionalità di inoltro chiamate deve rimanere disabilitata fino a quando non si verifica un Evento di sopravvivenza. Se l'inoltro chiamate è Abilita durante le operazioni ordinarie, tutte le chiamate In Entrata verso un numero registrato a Zoom Phone verranno reindirizzate all'SBC on-premises e al numero telefonico BYOC associato, bypassando i servizi di Zoom Phone. Pertanto, per mantenere il normale Instradamento di Zoom Phone, l'inoltro chiamate deve essere disabilitato durante le operazioni ordinarie.

L'inoltro chiamate può essere Abilita solo da un utente autorizzato o da un admin con una connessione Internet funzionante

Durante un Evento della modalità survivability, si presume che la connessione Internet di una sede non sia disponibile. Tuttavia, poiché l’inoltro delle chiamate deve rimanere disabilitato per il normale funzionamento, può essere abilitato solo da un utente autorizzato o da un admin con una connessione Internet funzionante, come un piano dati telefonico, oppure da una connessione Internet alternativa in una Posizione diversa.

Per ridurre al minimo i tempi di inattività e garantire la continuità operativa, Zoom consiglia alle aziende di stabilire procedure affidabili per abilitare la logica di inoltro delle chiamate dal portale web durante un Evento di survivability.

Le regole di inoltro delle chiamate possono applicarsi all'intera sede o ai singoli numeri

Durante un Evento di survivability, un amministratore o un utente autorizzato può abilitare le regole di inoltro delle chiamate 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 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 all'SBC dell'azienda.

Ad esempio, una sede sta vivendo un Evento della modalità survivability e il telefono cellulare di un utente è connesso al cloud di Zoom Phone tramite la connessione dati del proprio operatore mobile. Se il numero di telefono di un utente è contrassegnato per l'inoltro delle chiamate, il cloud di Zoom Phone non lo farà far squillare il proprio 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 saranno trattate in base alle logica di gestione chiamata per ogni singolo 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 chiamata non riceve risposta sezione delle preferenze di gestione chiamata.

L'inoltro chiamate si applica solo alle chiamate PSTN in entrata

L'inoltro chiamate per la continuità operativa si applica solo alle chiamate instradate attraverso il PSTN e/o il cloud di Zoom Phone. Le chiamate provenienti da interni registrati con Zoom all'interno della stessa sede tenteranno prima la connessione tramite il modulo ZPLS e, in secondo luogo, tramite il PSTN se è connesso un SBC. Le chiamate che non possono connettersi saranno altrimenti soggette al trattamento definito dalla Quando una chiamata non riceve risposta sezione delle regole di gestione chiamata all'interno delle Impostazioni del telefono di un utente.

Flusso di inoltro chiamate

Il seguente diagramma illustra in dettaglio la logica per l'inoltro chiamate (una volta abilitato) durante un Evento di continuità operativa. Questa logica rimarrà in vigore fino a quando l'inoltro chiamate non verrà disabilitato o le operazioni standard non verranno ripristinate. Tuttavia, se l'inoltro chiamate rimane abilitato dopo una volta ripristinate le operazioni standard, le chiamare inoltrate faranno hairpin dal cloud di Zoom Phone, allo SBC e di nuovo al cloud, prima di essere recapitate al Dispositivo di un utente. Per questo motivo, l'inoltro delle chiamare dovrebbe essere disabilitato tempestivamente dopo un Evento di survivability.

1. Un chiamante esterno avvia una chiamare a un numero registrato a Zoom Phone ed è instradato attraverso la PSTN.

2. La chiamare viene instradata al cloud di Zoom Phone e il numero di telefono composto viene identificato come interessato dall'inoltro delle chiamare.

Se l'inoltro delle chiamare non è abilitato, Zoom Phone seguirà la Quando una chiamata non riceve risposta logica per quello specifico utente o interno.

1. Poiché l'inoltro delle chiamare è abilitato, Zoom non tenterà di inviare un avviso all'utente e reindirizzerà invece la chiamare verso il numero di inoltro delle chiamare designato attraverso la PSTN.

2. La chiamare viene instradata dalla PSTN allo SBC di survivability.

3. Lo SBC di survivability inoltra la chiamare al modulo ZPLS.

4. Il modulo ZPLS inoltra la chiamare al client registrato dell'utente, se connesso.

Considerazioni su Emergency Posizione Identification Number (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 pubblica sicurezza (centro di raccolta delle chiamate di emergenza) per identificare l'indirizzo fisico di un chiamante quando deve chiamare 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, contribuendo a garantire che l'indirizzo sia elencato in un database di identificazione automatica della Posizione (ALI) quando il centro di raccolta delle chiamate di emergenza riceve la richiesta di chiamare i servizi di emergenza.

Ad esempio, si consideri un campus universitario che si estende su più edifici, con ogni edificio rappresentato da una sede Zoom Phone separata. Se un utente chiama i servizi di emergenza durante un Evento di sopravvivenza da un telefono o Dispositivo associato alla sede, i servizi di emergenza riceveranno automaticamente l'indirizzo completo nel registrare relativo alla sede, a condizione che la Posizione sia configurata e aggiornata presso il fornitore di servizi.

Ogni sede può fornire Assistenza a più ELIN

I Clienti possono Assegna più ELIN a una sede per creare un pool di risorse di numeri di emergenza. In caso di emergenza durante un Evento di sopravvivenza, ciò può consentire a più chiamanti di avere ciascuno un ELIN assegnato in modo univoco, aiutando i servizi di emergenza a raggiungere il chiamante originale in caso debbano chiamare nuovamente.

Inoltre, un ELIN può essere Assegna 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 sopravvivenza, tutte le richieste di chiamare i servizi di emergenza vengono sostituite dall'ELIN

Quando un utente deve chiamare i servizi di emergenza durante un Evento di sopravvivenza, il numero da cui chiama l'utente, se disponibile, verrà sostituito con l'ELIN designato a livello di sede. Ciò consente agli utenti che non dispongono di un numero diretto di chiamare i servizi di emergenza e di essere ricontattabili dall'operatore di emergenza.

Un numero ELIN deve essere un numero BYOC associato al trunk PSTN SBC della sede

L'ELIN di una sede devono deve essere un numero BYOC terminato su un trunk PSTN che si trova nell'SBC di failover della sede. Non può essere usato nessun altro tipo di numero.

Il modulo ZPLS instraderà automaticamente le chiamate del fornitore di emergenza all'ELIN di nuovo verso l'interno dell'utente che ha composto originariamente il numero da richiamare 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 chiamata di emergenza. Il modulo ZPLS Continua a instradare le richiamate 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 a un 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 ad altre entità Zoom Phone a meno che non venga prima disassegnato.

I Clienti sono responsabili del mantenimento 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 survivability è attiva, i pacchetti multimediali vengono instradati tramite il modulo ZPLS

Quando la modalità di survivability è abilitata, i client non comunicano direttamente con un SBC o con altri client interni; invece, i pacchetti multimediali vengono ancorati o “hairpinnati” tramite il modulo ZPLS, senza supporto per il caricamento dei media.

Il seguente diagramma mostra il percorso di segnalazione e dei media per le chiamate interne ed esterne attive.

Le chiamate tenteranno prima l'instradamento locale

Per quanto 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 della SIP Invita in arrivo non corrisponde a un numero interno registrato.

Un numero interno registrato è un numero interno breve senza il codice sede, un numero interno lungo con il codice sede, un numero Zoom assegnato e registrato, oppure un numero BYOC assegnato. Gli amministratori devono tenere presente che il modulo ZPLS aggiorna questi dati una volta ogni 10 ore.

Durante un evento di survivability, le chiamate esterne In uscita saranno in grado di mostrare il numero BYOC dell'utente

Durante un evento di survivability, le chiamate esterne In uscita dai Dispositivi registrati su ZPLS conterranno il numero di chiamata BYOC. Il seguente diagramma mostra il flusso delle chiamate in modalità di survivability per un utente:

Le chiamate di ritorno possono essere instradate verso il numero BYOC di un utente

Poiché le chiamate esterne In uscita effettuate durante un evento di survivability utilizzeranno un numero BYOC, i chiamanti esterni possono richiamare usando un numero BYOC invece del numero di telefono registrato su Zoom dell'utente. Se l'evento di survivability è terminato, le chiamate torneranno a essere instradate tramite il cloud se è configurata la corretta priorità di Instradamento. Tuttavia, se l'evento è in corso, l'SBC instraderà la chiamata al modulo ZPLS e al Dispositivo registrato dal client.

Codec di survivability supportati

I codec di survivability supportati sono Opus, G.711 μ-law, G.711 A-law e G.729. La transcodifica o il transrating dei codec audio non sono supportati. Tutte le parti coinvolte in una chiamata attiva devono supportare lo stesso codec e la stessa frequenza di campionamento.

Considerazioni sui gruppi di distribuzione della survivability

Questa sezione illustra le considerazioni per i Survivability Distribution Groups (SDG). I Clienti che non prevedono di utilizzare gli SDG o di integrare il modulo ZPLS con connettività PSTN possono saltare questa sezione senza conseguenze.

I Survivability Distribution Groups offrono opzioni di inoltro chiamate raffinate durante un evento di survivability

I Survivability distribution groups (SDG) offrono alle aziende opzioni raffinate di inoltro chiamate — come code delle chiamate e menu di Risposta vocale interattiva (IVR) — durante un evento di survivability. Con gli SDG, le aziende possono continuare a supportare i servizi core di telefonia e le configurazioni di inoltro chiamate (simili a code delle chiamate, centralinista automatico e gruppi di linea condivisa) fino al ripristino delle operazioni standard.

Gli SDG non sono la stessa cosa dei gruppi di distribuzione in operatività standard e devono essere creati e mantenuti separatamente

Sebbene gli SDG offrano una funzionalità di inoltro chiamate simile a quella dei gruppi di distribuzione in operatività standard, gli SDG sono unici e specifici per gli eventi di survivability e, di conseguenza, devono essere creati e mantenuti separatamente. In altre parole, gli SDG non lo farà ereditano le Impostazioni o le configurazioni di un gruppo di distribuzione in operatività standard (ad es., coda delle chiamate, centralinista automatico, IVR, ecc.)

Gli SDG sono ideali se abbinati a Integrazioni BYOC-PSTN e con l'inoltro delle chiamate abilitato

Sebbene gli SDG possano fornire supporto solo interno (ovvero, chiamate non PSTN), sono ideali se abbinati a un'integrazione BYOC-PSTN. Con un SDG abilitato per PSTN, una volta che l'inoltro delle chiamate è abilitato durante un evento di survivability, 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 coerente di flusso di chiamata ai chiamanti esterni fino al ripristino delle operazioni standard.

Il seguente diagramma 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 benvenuto registrati

• Membri del gruppo

• Instrada a:

  • utente

  • Menu di Risposta vocale interattiva (IVR)

  • Membri del gruppo

  • Numero telefonico

• Distribuzione delle chiamate:

  • Simultaneo

  • Sequenziale

Considerazioni su hardware e rete

Questa sezione tratta le considerazioni su hardware e rete per il modulo ZPLS, un'integrazione SBC, i client Zoom e i dispositivi telefonici. Dopo aver letto questa sezione, ci si può aspettare di avere una comprensione delle comunicazioni di rete e delle configurazioni necessarie per una distribuzione ZPLS.

Questa sezione è dedicata alla distribuzione dell'hardware e alla rete considerazioni di progettazione. Fare riferimento alla sezione su la distribuzione di ZPLS per istruzioni di distribuzione passo passo.

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. 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 le Impostazioni dell'account e dell'utente.

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 sono tenuti ad adattare la policy del firewall aziendale per abilitare la comunicazione tra il modulo ZPLS e il 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 OPTIONS keepalive 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 tramite TLS v1.2.

Considerazioni sulla distribuzione e sul networking SBC

Un SBC deve essere raggiungibile da ZPLS e da cloud Zoom, ove possibile

I Clienti dovrebbero assicurarsi che l'SBC mantenga la connettività sia con il modulo ZPLS sia con il cloud Zoom Phone, ove possibile. I Clienti possono predisporre un SBC dual-NIC configurato con un indirizzo IPv4 privato e uno pubblico, oppure assicurarsi 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 il cloud Zoom Phone e il modulo ZPLS

Durante le operazioni di routine, 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. Il meccanismo OPTIONS keepalive è abilitato automaticamente tra ZPLS e l'SBC ed è Facoltativo tra l'SBC e il cloud.

Considerazioni sui client Zoom e i dispositivi telefonici

I client e i dispositivi devono essere in grado di individuare il modulo ZPLS della sede nella rete locale

Client e dispositivi supportati abilitati per la sopravvivenza telefonica individuare il modulo ZPLS di failover appropriato dal cloud Zoom Phone durante il processo di avvio. Tuttavia, il modulo deve già essere associato alla sede del sistema telefonico con un indirizzo IPv4 individuabile internamente.

I dispositivi dovrebbero avere un IP statico o ricevere un IP privato tramite un server DHCP locale

Per mitigare potenziali problemi, ai dispositivi telefonici dovrebbe essere assegnato un IP statico o interno tramite un server DHCP locale. Se a un dispositivo non viene assegnato un IP statico, o se un server DHCP non è disponibile durante un Evento di sopravvivenza, i dispositivi telefonici potrebbero non riuscire a registrarsi.

I client e i dispositivi devono mantenere regolarmente un ping OPTIONS con il cloud Zoom Phone

Analogamente al modulo ZPLS, i client e i dispositivi supportati devono mantenere un ping OPTIONS keepalive verso il 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 dati.