Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
In che modo il Pannello di controllo dei contatti (CCP) utilizza WebRTC
Questo argomento avanzato è destinato agli amministratori IT che potrebbero essere interessati a conoscere in che modo Contact Control Panel (CCP) fornisce chiamate vocali. Fornisce inoltre alcuni dettagli di rete.
CCP utilizza WebRTC come tecnologia di base per consentire la comunicazione in tempo reale tra agenti di contact center e clienti. Consente agli agenti di gestire le chiamate e le videoconferenze in entrata e in uscita direttamente dal proprio browser web.
Argomenti
Che cos’è WebRTC?
WebRTC è una specifica tecnologica open source per abilitare la comunicazione in tempo reale (RTC) tra browser e applicazioni mobili utilizzando semplici API.
WebRTC utilizza tecniche di peering per lo scambio di dati in tempo reale tra peer connessi. Fornisce lo streaming multimediale a bassa latenza necessario per l’interazione umana.
La specifica WebRTC include una serie di protocolli IETF, tra cui Interactive Connectivity Establishment
Poiché Connect Customer utilizza WebRTC, non è necessario creare e mantenere un'infrastruttura complessa per la comunicazione in tempo reale. Consente di implementare rapidamente soluzioni di coinvolgimento dei clienti omnicanale tramite Connect Customer, beneficiando al contempo della bassa latenza, dello streaming multimediale di alta qualità e della connettività peer-to-peer sicura offerta da WebRTC.
Terminologia
- Session Traversal Utilities for NAT (STUN)
-
Un protocollo utilizzato per individuare l’indirizzo pubblico e determinare eventuali restrizioni nel router che impedirebbero una connessione diretta con un peer.
Un componente che gestisce gli endpoint STUN. Gli endpoint consentono alle applicazioni di individuare il proprio indirizzo IP pubblico quando si trovano dietro una tecnologia NAT o un firewall.
- Traversal Using Relays around NAT (TURN)
-
Un server utilizzato per aggirare la restrizione Symmetric NAT aprendo una connessione con un server TURN e inoltrando tutte le informazioni attraverso tale server.
Un componente che gestisce gli endpoint TURN. Gli endpoint abilitano il relay multimediale utilizzando il cloud quando le applicazioni non sono in grado di trasmettere contenuti multimediali peer-to-peer.
- Session Description Protocol (SDP)
-
Uno standard per descrivere il contenuto multimediale della connessione, ad esempio risoluzione, formati, codec, crittografia e altro ancora, in modo che entrambi i peer possano comprendersi a vicenda una volta che i dati vengono trasferiti.
- Offerta SDP
-
Un messaggio SDP inviato da un agente che genera una descrizione della sessione per creare o modificare una sessione. Descrive gli aspetti della comunicazione multimediale desiderata.
- Risposta SDP
-
Un messaggio SDP inviato da un rispondente in risposta a un’offerta ricevuta da un offerente. La risposta indica gli aspetti accettati. Ad esempio, se tutti i flussi audio e video dell’offerta sono accettati.
- Interactive Connectivity Establishment (ICE)
-
Un framework che consente al browser web di connettersi tramite peer-to-peer.
- Candidato ICE
-
Un metodo che il peer mittente è in grado di utilizzare per comunicare.
- Peer
-
Qualsiasi dispositivo o applicazione (ad esempio, un’applicazione mobile o web) configurata per comunicazioni bidirezionali in tempo reale con WebRTC.
- Segnalazione
-
Il componente di segnalazione gestisce gli endpoint di segnalazione WebRTC che consentono alle applicazioni di connettersi in modo sicuro tra loro per lo streaming multimediale peer-to-peer in tempo reale.
Funzionamento di WebRTC
WebRTC utilizza protocolli di segnalazione, JavaScript come Session Establishment Protocol (JSEP) per i browser o protocolli personalizzati integrati WebSockets/XMPP, per avviare e gestire le sessioni di comunicazione. Utilizza inoltre codec per la codifica e la decodifica di dati audio e video, Secure Real-time Transport Protocol (SRTP) per crittografare i flussi multimediali per garantire la privacy e utilizza i protocolli ICE, STUN e TURN per navigare e stabilire connessioni peer-to-peer attraverso gateway e firewall NAT.
Come interagiscono STUN, TURN e ICE
Consideriamo lo scenario in cui l'agente CCP (Contact Control Panel) è peer A e Connect Customer è peer B, utilizzando WebRTC per un flusso multimediale bidirezionale (ad esempio, una chiamata vocale).
Ecco cosa succede quando l'agente CCP desidera stabilire una connessione con Connect Customer:
-
Il CCP dell’agente genera un’offerta SDP contenente informazioni sulla sessione desiderata, ad esempio i codec da utilizzare, se si tratta di una sessione audio o video e altro ancora. Include anche un elenco di candidati ICE, ovvero le IP/port coppie che Connect Customer può tentare di utilizzare per connettersi all'agente CCP.
-
Per raccogliere i candidati ICE, CCP invia una serie di richieste a un server STUN. Il server STUN restituisce la coppia indirizzo IP-porta che ha originato la richiesta. L'agente CCP crea anche un canale TURN per il servizio TURN di Connect Customer per ottenere un indirizzo di trasmissione multimediale. Questo indirizzo di inoltro è una IP/port coppia in grado di inoltrare pacchetti tra l'agente CCP e altri servizi multimediali in Connect Customer. L'agente CCP aggiunge ogni IP/port coppia all'elenco dei candidati ICE. Successivamente, l'agente CCP invia l'offerta SDP a Connect Customer tramite un canale di segnalazione su un. WebSocket
-
Connect Customer genera una risposta SDP seguendo lo stesso processo: raccoglie i candidati ICE e li invia con la risposta SDP all'agente CCP tramite il. WebSocket Dopo lo scambio di SDP, l'agente CCP e Connect Customer eseguono una serie di controlli di connettività. Ciascuna parte prende una IP/port coppia di candidati dall'SDP dell'altra e le invia una richiesta STUN. Se viene ricevuta una risposta, quella IP/port coppia viene contrassegnata come coppia di candidati ICE valida.
-
Una volta completati i controlli di connettività per tutte le IP/port coppie, l'agente CCP e Connect Customer negoziano e decidono su una delle coppie valide da utilizzare per lo streaming multimediale.
Il diagramma seguente illustra la comunicazione tra CCP e Connect Customer tramite WebRTC.
Best practice
-
Per un’esperienza audio ottimale e affidabile, è vivamente consigliabile verificare che il traffico multimediale tra la workstation degli agenti e AWS venga scambiato direttamente e non passi attraverso VPN o altri hop di acceleratori di rete.
-
Per garantire che la tua azienda sia in grado di supportare con successo le connessioni WebRTC e mitigare i comportamenti di errore, assicurati di avere traffico UDP in entrata in elenco consentito sulla porta 3478 (). SEND/RECEIVE Per ulteriori informazioni, consulta Opzione 1 (consigliata): sostituire i requisiti di Amazon EC2 e dell'intervallo CloudFront IP con una lista di domini consentiti. Nella tabella, vedi la riga per
TurnNlb-*.elb.region.amazonaws.com. -
Se utilizzi Opzione 2 (non consigliata): consentire gli intervalli di indirizzi IP, ti consigliamo quanto segue per mitigare i comportamenti di errore:
-
Monitora gli intervalli IP consentiti elencati dalla tua azienda per Connect Customer.
-
Assicurati che le modifiche all’interno degli intervalli IP siano monitorate.
-
Assicurati che tutte le nuove aggiunte all'elenco siano accompagnate da elenchi di porte e protocolli 3478 (UDP) consentiti per il traffico. SEND/RECEIVE
-
-
Prima di passare all’ambiente di produzione, esegui le operazioni seguenti:
-
Testa la connettività WebRTC utilizzando lo strumento di test Connect Customer Endpoint Connectivity. Questo strumento consente di verificare se gli endpoint Connect Customer WebRTC Media sono accessibili dalle postazioni degli agenti.
-
Testa e monitora le modifiche agli ambienti di rete e alle architetture di rete on-premises come aggiornamenti del firewall, router edge e VPN.
-
-
Se utilizzi un firewall stateless, assicurati di aver aggiunto l’intervallo di porte temporanee all’elenco elementi consentiti, come descritto in Firewall stateless.
