Topologias de fluxo de chamadas
Este artigo descreve as topologias de fluxo de chamadas dos Serviços de Comunicação do Azure. Neste artigo, você aprenderá detalhes sobre os conceitos de rede para os Serviços de Comunicação do Azure, como o tráfego de chamadas é criptografado e Para obter uma introdução aos fluxos de chamadas dos Serviços de Comunicação, visite a documentação conceitual de fluxos de chamada.
Fundo
Conceitos de rede
Antes de analisar as topologias de fluxo de chamadas, definimos alguns termos que são referidos ao longo do documento.
Uma rede de clientes contém todos os segmentos de rede que você gerencia. Isso pode incluir redes com e sem fio dentro do seu escritório ou entre escritórios, data centers e provedores de serviços de Internet.
Uma rede de clientes geralmente tem vários perímetros de rede com firewalls e/ou servidores proxy que impõem as políticas de segurança da sua organização. Recomendamos a realização de uma avaliação abrangente da rede para garantir o desempenho e a qualidade ideais da sua solução de comunicação.
A rede dos Serviços de Comunicação é a rede que dá suporte aos Serviços de Comunicação do Azure. Esta rede é gerida pela Microsoft e distribuída em todo o mundo com centros de dados propriedade da Microsoft mais próximos dos clientes finais. Essa rede é responsável por retransmissão de transporte, processamento de mídia para chamadas em grupo e outros componentes que suportam comunicações de mídia ricas em tempo real.
Tipos de tráfego
Os Serviços de Comunicação são construídos principalmente em dois tipos de tráfego: mídia em tempo real e sinalização.
A mídia em tempo real é transmitida usando o protocolo RTP (Real-time Transport Protocol). Este protocolo suporta áudio, vídeo e transmissão de dados de compartilhamento de tela. Esses dados são sensíveis a problemas de latência de rede. Embora seja possível transmitir mídia em tempo real usando TCP ou HTTP, recomendamos o uso do UDP como o protocolo de camada de transporte para oferecer suporte a experiências de usuário final de alto desempenho. As cargas úteis de mídia transmitidas pelo RTP são protegidas usando SRTP.
Os usuários de sua solução de Serviços de Comunicação estão se conectando aos seus serviços a partir de seus dispositivos cliente. A comunicação entre esses dispositivos e seus servidores é tratada com sinalização. Por exemplo: o início de chamadas e o chat em tempo real são suportados pela sinalização entre dispositivos e o seu serviço. A maioria do tráfego de sinalização usa HTTPS REST, embora em alguns cenários, o SIP possa ser usado como um protocolo de tráfego de sinalização. Embora esse tipo de tráfego seja menos sensível à latência, a sinalização de baixa latência oferece aos usuários de sua solução uma experiência agradável ao usuário final.
Criptografia de mídia
Os fluxos de chamada nos Serviços de Comunicação do Azure chamando clientes SDK e Teams são baseados no modelo de oferta e resposta RFC 8866 do SDP (Session Description Protocol) por HTTPS. Quando o destinatário aceita uma chamada recebida, o chamador e o destinatário concordam com os parâmetros da sessão.
O tráfego de mídia é criptografado e flui entre o chamador e o destinatário usando o Secure RTP (SRTP), um perfil do Protocolo de Transporte em Tempo Real (RTP) que fornece confidencialidade, autenticação e proteção contra ataques de repetição ao tráfego RTP. Na maioria dos casos, o tráfego de mídia de cliente para cliente é negociado através da sinalização de conexão de cliente para servidor e é criptografado usando SRTP quando vai diretamente de cliente para cliente.
O SDK de chamada dos Serviços de Comunicação do Azure usa DTLS para derivar uma chave de criptografia. Uma vez que o handshake DTLS é feito, a mídia começa a fluir usando essa chave de criptografia negociada por DTLS sobre SRTP.
Os Serviços de Comunicação do Azure que chamam clientes SDK e Teams usam um token baseado em credenciais para acesso seguro a retransmissões de mídia por TURN. Os retransmissores de mídia trocam o token por um canal protegido por TLS.
O tráfego de mídia dos Serviços de Comunicação do Azure entre dois pontos de extremidade que participam do compartilhamento de áudio, vídeo e vídeo dos Serviços de Comunicação do Azure utiliza o SRTP para criptografar o fluxo de mídia. As chaves criptográficas são negociadas entre os dois pontos finais através de um protocolo de sinalização, que usa o canal UDP/TCP criptografado TLS 1.2 e AES-256 (no modo GCM).
Princípios de fluxo de chamadas
Há quatro princípios gerais que sustentam os fluxos de chamada dos Serviços de Comunicação do Azure:
- O primeiro participante de uma chamada de grupo dos Serviços de Comunicação determina a região na qual a chamada está hospedada. Existem exceções a esta regra em algumas topologias, que são descritas abaixo.
- O ponto de extremidade de mídia usado para dar suporte a uma chamada dos Serviços de Comunicação é selecionado com base nas necessidades de processamento de mídia e não é afetado pelo número de participantes em uma chamada. Por exemplo, uma chamada ponto a ponto pode usar um ponto de extremidade de mídia na nuvem para processar mídia para transcrição ou gravação, enquanto uma chamada com dois participantes não pode usar nenhum ponto de extremidade de mídia. As chamadas em grupo usam um ponto de extremidade de mídia para fins de mistura e roteamento. Esse ponto de extremidade é selecionado com base na região em que a chamada está hospedada. O tráfego de mídia enviado de um cliente para o ponto de extremidade de mídia pode ser roteado diretamente ou pode usar uma retransmissão de transporte no Azure se as restrições de firewall de rede do cliente exigirem.
- O tráfego de mídia para chamadas ponto a ponto toma a rota mais direta disponível, supondo que a chamada não precise de um ponto de extremidade de mídia na nuvem. A rota preferida é direta para o peer remoto (cliente). Se uma rota direta não estiver disponível, um ou mais retransmissores de transporte encaminham o tráfego. O tráfego de mídia não deve atravessar servidores que atuam como formadores de pacotes, servidores VPN ou outras funções que possam atrasar o processamento e degradar a experiência do usuário final.
- O tráfego de sinalização sempre vai para qualquer servidor mais próximo do usuário.
Para saber mais sobre os detalhes sobre o caminho de mídia escolhido, consulte a documentação conceitual dos fluxos de chamada.
Fluxos de chamada em várias topologias
Serviços de Comunicação (internet)
Essa topologia é usada por clientes que usam os Serviços de Comunicação da nuvem sem nenhuma implantação local, como o roteamento direto do Azure. Nessa topologia, o tráfego de e para os Serviços de Comunicação flui pela Internet.
Figura 1 - Topologia dos Serviços de Comunicação
A direção das setas no diagrama acima reflete a direção de iniciação da comunicação que afeta a conectividade nos perímetros da empresa. No caso do UDP para mídia, os primeiros pacotes podem fluir na direção inversa, mas esses pacotes podem ser bloqueados até que os pacotes na outra direção estejam fluindo.
Descrições do fluxo:
- Fluxo 2 – Representa um fluxo iniciado por um usuário na rede do cliente para a Internet como parte da experiência dos Serviços de Comunicação do usuário. Exemplos desses fluxos incluem DNS e transmissão de mídia ponto a ponto.
- Fluxo 2' – Representa um fluxo iniciado por um usuário remoto de Serviços de Comunicação Móvel, com VPN para a rede do cliente.
- Fluxo 3 – Representa um fluxo iniciado por um usuário remoto dos Serviços de Comunicação móvel para os pontos de extremidade dos Serviços de Comunicação.
- Fluxo 4 – Representa um fluxo iniciado por um usuário na rede do cliente para os Serviços de Comunicação.
- Fluxo 5 – Representa um fluxo de mídia ponto a ponto entre um usuário dos Serviços de Comunicação e outro dentro da rede do cliente.
- Fluxo 6 – Representa um fluxo de mídia ponto a ponto entre um usuário remoto dos Serviços de Comunicação móvel e outro usuário remoto dos Serviços de Comunicação móvel pela Internet.
Caso de uso: Chamada um-para-um
Uma chamada um-para-um significa que um usuário chama diretamente outro usuário. Para inicializar a chamada, o SDK de chamada obtém um conjunto de candidatos que consiste em endereços IP e portas, incluindo candidatos locais, de retransmissão e reflexivos (endereço IP público do cliente visto pelo retransmissor). O SDK do chamador envia esses candidatos para a parte chamada; O partido chamado também obtém um conjunto semelhante de candidatos e envia-os para o interlocutor. As mensagens de verificação de conectividade STUN são usadas para encontrar quais caminhos de mídia do chamador/chamado funcionam e o melhor caminho de trabalho é selecionado. Uma vez que o caminho de conexão é estabelecido, um handshake DTLS é executado sobre essa conexão para garantir a segurança. Após o handshake DTLS, as chaves SRTP são derivadas do processo de handshake DTLS. A mídia (ou seja, pacotes RTP/RTCP protegidos usando SRTP) é então enviada usando o par candidato selecionado. A retransmissão de transporte está disponível como parte dos Serviços de Comunicação do Azure.
Se o endereço IP local e os candidatos à porta ou os candidatos reflexivos tiverem conectividade, o caminho direto entre os clientes (ou usando um NAT) será selecionado para mídia. Se os clientes estiverem ambos na rede do cliente, o caminho direto deve ser selecionado. Isso requer conectividade UDP direta dentro da rede do cliente. Se os clientes são ambos usuários nômades da nuvem, então, dependendo do NAT / firewall, a mídia pode usar conectividade direta.
Se um cliente for interno na rede do cliente e um cliente for externo (por exemplo, um usuário de nuvem móvel), é improvável que a conectividade direta entre os candidatos locais ou reflexivos seja habilitada. Nesse caso, uma opção é usar um dos candidatos a retransmissão de transporte de qualquer cliente (por exemplo, o cliente interno obteve um candidato de retransmissão do relé de transporte no Azure; o cliente externo precisa ser capaz de enviar pacotes STUN/RTP/RTCP para o relé de transporte). Outra opção é o cliente interno enviar para o candidato de retransmissão obtido pelo cliente de nuvem móvel. Embora a conectividade UDP para mídia seja altamente recomendada, o TCP é suportado.
Etapas de alto nível:
- O Usuário A dos Serviços de Comunicação resolve o nome de domínio (DNS) da URL usando o Fluxo 2.
- O usuário A aloca uma porta de retransmissão de mídia no relé de transporte do Teams usando o Flow 4.
- O Usuário A dos Serviços de Comunicação envia um "convite" com os candidatos da ICE usando o Fluxo 4 para os Serviços de Comunicação.
- Os Serviços de Comunicação notificam o Usuário B usando o Fluxo 4.
- O usuário B aloca uma porta de retransmissão de mídia no relé de transporte do Teams usando o Flow 4.
- O usuário B envia "resposta" com candidatos ICE usando o Fluxo 4, que é encaminhado de volta para o Usuário A usando o Fluxo 4.
- O usuário A e o usuário B invocam testes de conectividade ICE e o melhor caminho de mídia disponível é selecionado (consulte os diagramas abaixo para vários casos de uso).
- Ambos os usuários enviam telemetria para os Serviços de Comunicação usando o Fluxo 4.
Rede de clientes (intranet)
Figura 2 - Dentro da rede do cliente
Na Etapa 7, o fluxo de mídia ponto a ponto 5 é selecionado.
Esta transmissão de mídia é bidirecional. A direção do Fluxo 5 indica que um lado inicia a comunicação de uma perspetiva de conectividade. Nesse caso, não importa qual direção é usada, porque ambos os pontos de extremidade estão dentro da rede do cliente.
Rede de clientes para usuário externo (mídia retransmitida pelo Teams Transport Relay)
Figura 3 - Rede do cliente para usuário externo (mídia retransmitida pelo Azure Transport Relay)
Na Etapa 7, o Fluxo 4 (da rede do cliente para os Serviços de Comunicação) e o Fluxo 3 (de um usuário remoto dos Serviços de Comunicação móvel para os Serviços de Comunicação do Azure) são selecionados.
Esses fluxos são retransmitidos pelo Teams Transport Relay no Azure.
Esta transmissão de mídia é bidirecional. A direção indica qual lado inicia a comunicação de uma perspetiva de conectividade. Neste caso, esses fluxos são usados para sinalização e mídia, usando diferentes protocolos de transporte e endereços.
Rede de clientes para utilizadores externos (meios diretos)
Figura 4 - Rede do cliente para usuário externo (mídia direta)
Na etapa 7, o Fluxo 2 (da rede do cliente para o par do cliente pela Internet) é selecionado.
A mídia direta com um usuário móvel remoto (não retransmitida pelo Azure) é opcional. Em outras palavras, você pode bloquear esse caminho para impor um caminho de mídia por meio de uma retransmissão de transporte no Azure.
Esta transmissão de mídia é bidirecional. A direção do Fluxo 2 para o usuário móvel remoto indica que um lado inicia a comunicação de uma perspetiva de conectividade.
Usuário VPN para usuário interno (mídia retransmitida pelo Teams Transport Relay)
Figura 5 - Usuário VPN para usuário interno (mídia retransmitida pelo Azure Relay
A sinalização entre a VPN e a rede do cliente usa o Flow 2*. A sinalização entre a rede do cliente e o Azure usa o Flow 4. No entanto, a mídia ignora a VPN e é roteada usando os Fluxos 3 e 4 por meio do Azure Media Relay.
Usuário VPN para usuário interno (mídia direta)
Figura 6 - Usuário VPN para usuário interno (mídia direta)
A sinalização entre a VPN e a rede do cliente usa o Flow 2'. A sinalização entre a rede do cliente e o Azure está usando o fluxo 4. No entanto, a mídia ignora a VPN e é roteada usando o fluxo 2 da rede do cliente para a Internet.
Esta transmissão de mídia é bidirecional. A direção do Fluxo 2 para o usuário móvel remoto indica que um lado inicia a comunicação de uma perspetiva de conectividade.
Usuário VPN para usuário externo (mídia direta)
Figura 7 - Usuário VPN para usuário externo (mídia direta)
A sinalização entre o usuário VPN e a rede do cliente usa o Fluxo 2* e o Fluxo 4 para o Azure. No entanto, a mídia ignora a VPN e é roteada usando o Flow 6.
Esta transmissão de mídia é bidirecional. A direção do Flow 6 para o usuário móvel remoto indica que um lado inicia a comunicação de uma perspetiva de conectividade.
Caso de uso: cliente de serviços de comunicação para PSTN por meio do tronco de serviços de comunicação
Os Serviços de Comunicação permitem efetuar e receber chamadas a partir da Rede Telefónica Pública Comutada (RTPC). Se o tronco PSTN estiver conectado usando números de telefone fornecidos pelos Serviços de Comunicação, não há requisitos especiais de conectividade para esse caso de uso. Se quiser conectar seu próprio tronco PSTN local aos Serviços de Comunicação do Azure, você pode usar o roteamento direto do Azure (disponível em CY2021).
Figura 8 – Usuário dos Serviços de Comunicação para PSTN por meio do Tronco do Azure
Nesse caso, a sinalização e a mídia da rede do cliente para o Azure usam o Flow 4.
Caso de uso: chamadas em grupo dos Serviços de Comunicação
O serviço de áudio/vídeo/compartilhamento de tela (VBSS) faz parte dos Serviços de Comunicação do Azure. Ele tem um endereço IP público que deve ser acessível a partir da rede do cliente e deve ser acessível a partir de um cliente Nomadic Cloud. Cada cliente/ponto de extremidade precisa ser capaz de se conectar ao serviço.
Os clientes internos obtêm candidatos locais, reflexivos e de retransmissão da mesma maneira descrita para chamadas individuais. Os clientes enviam estes candidatos ao serviço através de um convite. O serviço não usa um retransmissor, pois tem um endereço IP acessível publicamente, portanto, responde com seu candidato a endereço IP local. O cliente e o serviço verificam a conectividade da mesma maneira descrita para chamadas individuais.
Figura 9 – Chamadas em grupo dos Serviços de Comunicação
Restrições de interoperabilidade
O fluxo de mídia pelos Serviços de Comunicação do Azure é restrito da seguinte maneira:
O SBC (Controlador de Borda de Sessão) de terceiros no limite com PSTN deve encerrar o fluxo RTP/RTCP, protegido usando SRTP, e não retransmiti-lo para o próximo salto. Se você retransmitir o fluxo para o próximo salto, ele pode não ser compreendido.
Servidores proxy SIP de terceiros. Uma caixa de diálogo SIP de sinalização dos Serviços de Comunicação com um SBC e/ou gateway de terceiros pode atravessar proxies SIP nativos da Microsoft (assim como o Teams). Não há suporte para interoperabilidade com proxies SIP de terceiros.
B2BUA (ou SBC) de terceiros. O fluxo de mídia dos Serviços de Comunicação de e para a PSTN é encerrado por um SBC de terceiros. Não há suporte para interoperabilidade com um SBC de terceiros na rede de Serviços de Comunicação (em que um SBC de terceiros medeia dois pontos de extremidade de Serviços de Comunicação).
Tecnologias não suportadas
Rede VPN. Os Serviços de Comunicação não suportam transmissão de mídia por VPNs. Se seus usuários estiverem usando clientes VPN, o cliente deverá dividir e rotear o tráfego de mídia em uma conexão não VPN, conforme especificado em Habilitando a mídia do Lync para ignorar um túnel VPN.
Nota
Embora o título indique o Lync, ele é aplicável aos Serviços de Comunicação do Azure e ao Teams.*
Formatadores de pacotes. Não há suporte para dispositivos de corte de pacotes, inspeção de pacotes ou modelagem de pacotes e podem degradar significativamente a qualidade.
Próximos passos
Os seguintes documentos podem ser interessantes para si:
- Saiba mais sobre os tipos de chamada
- Saiba mais sobre a arquitetura cliente-servidor