As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Como o Painel de Controle de Contatos (CCP) usa o WebRTC
Este tópico avançado é para administradores de TI que possam estar interessados em como o Painel de Controle de Contato (CCP) fornece chamadas de voz. Ele também fornece alguns detalhes da rede.
O CCP usa o WebRTC como tecnologia subjacente para permitir a comunicação em tempo real entre atendentes da central de atendimento e clientes. Ele permite que os atendentes gerenciem chamadas de entrada e saída e videoconferências diretamente do navegador da web.
Tópicos
O que é WebRTC?
O WebRTC é uma especificação de tecnologia de código aberto para permitir a comunicação em tempo real (RTC) entre navegadores e aplicações móveis por meio de APIs simples.
O WebRTC usa técnicas de emparelhamento para troca de dados em tempo real entre pares conectados. Ele fornece streaming de mídia de baixa latência necessário para a interação entre as pessoas.
A especificação do WebRTC inclui um conjunto de protocolos IETF, incluindo Interactive Connectivity Establishment
Como o Connect Customer usa o WebRTC, você não precisa criar e manter uma infraestrutura complexa para comunicação em tempo real. Com o WebRTC, você pode implantar rapidamente soluções omnichannel de engajamento de clientes por meio do Connect Customer, enquanto se beneficia da baixa latência, do streaming de mídia de alta qualidade e da conectividade segura ponto a ponto que o WebRTC oferece.
Terminologia
- Session Traversal Utilities for NAT (STUN)
-
Um protocolo usado para descobrir seu endereço público e determinar quaisquer restrições no roteador que impeçam uma conexão direta com um par.
Um componente que gerencia os endpoints STUN. Os endpoints permitem que as aplicações descubram seu endereço IP público quando estão localizados atrás de um NAT ou firewall.
- Traversal Using Relays around NAT (TURN)
-
Um servidor usado para contornar a restrição de NAT simétrico abrindo uma conexão com um servidor TURN e retransmitindo todas as informações por meio desse servidor.
Um componente que gerencia os endpoints do TURN. Os endpoints permitem a retransmissão de mídia utilizando a nuvem quando as aplicações não conseguem transmitir mídia ponto a ponto.
- Session Description Protocol (SDP)
-
Um padrão para descrever o conteúdo multimídia da conexão, como resolução, formatos, codecs, criptografia e muito mais, para que os dois pares possam se entender após a transferência dos dados.
- Oferta do SDP
-
Uma mensagem SDP enviada por um agente que gera uma descrição da sessão para criar ou modificar uma sessão. Descreve os aspectos da comunicação de mídia desejada.
- Resposta do SDP
-
Uma mensagem SDP enviada por um atendente em resposta a uma oferta recebida de um ofertante. A resposta indica os aspectos que são aceitos. Por exemplo, se todos os fluxos de áudio e vídeo da oferta forem aceitos.
- Interactive Connectivity Establishment (ICE)
-
Uma estrutura que permite que seu navegador se conecte com pares.
- Candidato do ICE
-
Um método que o par remetente pode usar para se comunicar.
- Par
-
Qualquer dispositivo ou aplicação (por exemplo, uma aplicação móvel ou web) configurado para comunicações bidirecionais em tempo real com o WebRTC.
- Sinalização
-
O componente de sinalização gerencia os endpoints de sinalização WebRTC que permitem que os aplicativos se conectem com segurança entre si para streaming de mídia ao vivo ponto a ponto.
Como funciona o WebRTC
O WebRTC usa protocolos de sinalização, como o JavaScript Session Establishment Protocol (JSEP) para navegadores ou protocolos personalizados incorporados WebSockets/XMPP, para iniciar e gerenciar sessões de comunicação. Ele também emprega codecs para codificar e decodificar dados de áudio e vídeo, protocolo de Real-time transporte seguro (SRTP) para criptografar fluxos de mídia para garantir a privacidade e usa os protocolos ICE, STUN e TURN para navegar e estabelecer conexões ponto a ponto em gateways e firewalls NAT.
Como STUN, TURN e ICE trabalham juntos
Vamos considerar o cenário em que o agente CCP (Painel de controle de contato) é o par A e o Connect Customer é o par B, usando o WebRTC para um fluxo de mídia bidirecional (por exemplo, uma chamada de voz).
Veja o que acontece quando o agente CCP quer estabelecer uma conexão com o Connect Customer:
-
O CCP do atendente gera uma oferta de SDP contendo informações sobre a sessão desejada, como os codecs a serem usados, se é uma sessão de áudio ou vídeo etc. Também inclui uma lista de candidatos ao ICE, que são os IP/port pares que o Connect Customer pode tentar usar para se conectar ao agente CCP.
-
Para reunir os candidatos do ICE, o CCP faz uma série de solicitações a um servidor STUN. O servidor exibe o endereço IP público e o par de portas que originou a solicitação. O agente CCP também cria um canal TURN para conectar o serviço TURN do cliente para obter um endereço de retransmissão de mídia. Esse endereço de retransmissão é um IP/port par que pode encaminhar pacotes entre o agente CCP e outros serviços de mídia no Connect Customer. O agente CCP adiciona cada IP/port par à lista de candidatos do ICE. Em seguida, o agente CCP envia a oferta de SDP para o Connect Customer por meio de um canal de sinalização em um. WebSocket
-
O Connect Customer gera uma resposta SDP seguindo o mesmo processo: ele reúne os candidatos do ICE e os envia com a resposta do SDP ao agente CCP pelo. WebSocket Depois de trocar SDPs, o agente CCP e o Connect Customer realizam uma série de verificações de conectividade. Cada lado pega um IP/port par de candidatos do SDP do outro e envia uma solicitação STUN para ele. Se uma resposta for recebida, esse IP/port par será marcado como um par candidato válido ao ICE.
-
Depois que as verificações de conectividade de todos os IP/port pares forem concluídas, o agente CCP e o Connect Customer negociam e decidem sobre um dos pares válidos a serem usados no fluxo de mídia.
O diagrama a seguir ilustra a comunicação entre a CCP e o Connect Customer usando o WebRTC.
Práticas recomendadas
-
Para obter a melhor e mais confiável experiência de áudio, é altamente recomendável garantir que o tráfego de mídia entre a estação de trabalho do agente e a estação de trabalho do agente AWS seja trocado diretamente e não passe por VPNs ou outros saltos aceleradores de rede.
-
Para garantir que sua empresa consiga ajudar com êxito as conexões WebRTC e mitigar comportamentos de erro, certifique-se de ter o tráfego UDP de entrada listado na porta 3478 (). SEND/RECEIVE Para obter mais informações, consulte Opção 1 (recomendada): substituir os requisitos de intervalo de CloudFront IP e do Amazon EC2 por uma lista de permissões de domínio. Na tabela, veja a linha para
TurnNlb-*.elb.region.amazonaws.com. -
Se você estiver usando Opção 2 (não recomendada): permitir intervalos de endereços IP, recomendamos o seguinte para atenuar os comportamentos de erro:
-
Monitore os intervalos de IP permitidos pela sua empresa para o Connect Customer.
-
Garanta que as alterações nos intervalos de IP sejam monitoradas.
-
Certifique-se de que todas as novas adições à lista sejam acompanhadas por listas de permissões de portas e protocolos 3478 (UDP) para tráfego. SEND/RECEIVE
-
-
Antes de passar para a produção, faça o seguinte
-
Teste a conectividade WebRTC usando a ferramenta de teste Connect Customer Endpoint Connectivity. Essa ferramenta ajuda você a verificar se os endpoints WebRTC Media do Connect Customer estão acessíveis a partir das estações do agente.
-
Teste e acompanhe alterações nos ambientes de rede e nas arquiteturas de rede on-premises, como atualizações de firewall, roteadores de borda e VPNs.
-
-
Se você estiver usando um firewall sem estado, adicione o intervalo de portas efêmeras à lista de permissões, conforme descrito em Firewalls sem estado.
