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ê aprende detalhes sobre conceitos de rede para os Serviços de Comunicação do Azure, como o tráfego de chamada é criptografado e, para obter uma introdução aos fluxos de chamada dos Serviços de Comunicação, visite a documentação conceitual dos fluxos de chamada.

Tela de fundo

Conceitos de rede

Antes de revisar as topologias de fluxo de chamadas, definimos alguns termos mencionados ao longo do documento.

Uma rede do cliente contém os segmentos de rede gerenciados por você. Isso pode incluir redes com e sem fio no seu escritório ou entre escritórios, data centers e provedores de serviços de Internet.

Uma rede do cliente 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 fazer uma avaliação de rede abrangente para garantir o desempenho ideal e a qualidade da sua solução de comunicação.

A Rede de Serviços de Comunicação é a rede que dá suporte aos Serviços de Comunicação do Azure. Essa rede é gerenciada pela Microsoft e distribuída mundialmente com data centers de propriedade da Microsoft mais próximos dos clientes finais. Essa rede é responsável pela retransmissão de transporte, pelo processamento de mídia para chamadas em grupo e por outros componentes que dão suporte à comunicação de mídia avançada em tempo real.

Tipos de tráfego

Os Serviços de Comunicação foram criados principalmente em dois tipos de tráfego: mídia em tempo real e sinalização.

A mídia em tempo real é transmitida por meio do protocolo RTP. Esse protocolo dá suporte à transmissão de dados de áudio, vídeo e compartilhamento de tela. Esses dados são sensíveis a problemas de latência de rede. Embora seja possível transmitir uma mídia em tempo real usando TCP ou HTTP, recomendamos usar o UDP como o protocolo de camada de transporte para dar suporte a experiências de usuário final de alto desempenho. O conteúdo de mídia transmitido por RTP é protegido por meio do SRTP.

Os usuários da sua solução de Serviços de Comunicação estão se conectando aos seus serviços a partir de seus dispositivos clientes. A comunicação entre esses dispositivos e seus servidores é processada com a sinalização. Por exemplo: há suporte para a inicialização de chamadas e o chat em tempo real por meio da sinalização entre os dispositivos e o seu serviço. A maior parte do tráfego de sinalização usa a REST HTTPS, porém, em alguns cenários, o SIP pode 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 proporciona aos usuários da sua solução uma experiência agradável para o usuário final.

Criptografia de Mídia

Os fluxos de chamadas nos Serviços de Comunicação do Azure que chamam clientes SDK e Teams baseiam-se no modelo de oferta e resposta Protocolo de Descrição de Sessão (SDP) RFC 8866 sobre HTTPS. Depois que o receptor aceitar uma chamada de entrada, o chamador e o receptor concordarão com os parâmetros da sessão.

O tráfego de mídia é criptografado e flui entre o chamador e o receptor usando Secure RTP (SRTP), um perfil de Real-time Transport Protocol (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 por meio de sinalização de conexão de cliente para servidor e é criptografado usando SRTP quando vai diretamente de cliente para cliente.

Os Serviços de Comunicação do Azure que chamam o SDK usam DTLS para derivar uma chave de criptografia. Depois que o handshake do DTLS é concluído, 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 do SDK e do Teams usam um token baseado em credenciais para acesso seguro a retransmissões de mídia por meio do TURN. Os media relays trocam o token por meio de 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 SRTP para criptografar o fluxo de mídia. As chaves criptográficas são negociadas entre os dois terminais por meio de um protocolo de sinalização, que usa canal UDP/TCP criptografado TLS 1.2 e AES-256 (no modo GCM).

Princípios do fluxo de chamadas

Existem quatro princípios gerais que sustentam os fluxos de chamadas dos Serviços de Comunicação do Azure:

• O primeiro participante de uma chamada em grupo dos Serviços de Comunicação determina a região em que a chamada é hospedada. Há exceções a essa regra em algumas topologias, que são descritas abaixo.
• O ponto final de mídia usado para dar suporte a uma chamada de 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 a mídia para transcrição ou gravação, enquanto uma chamada com dois participantes pode não usar nenhum ponto de extremidade de mídia. As chamadas em grupo usam um ponto de extremidade de mídia para fins de mixagem 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 usar uma retransmissão de transporte no Azure se as restrições de firewall de rede do cliente exigem isso.
• O tráfego de mídia para chamadas ponto a ponto usa 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 preferencial é direcionada para o par 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 percorrer os servidores que funcionam como modeladores de pacotes, servidores VPN ou outras funções que podem 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, veja a documentação conceitual dos fluxos de chamadas.

Fluxos de chamadas em várias topologias

Serviços de Comunicação (Internet)

Essa topologia é usada pelos clientes que usam os Serviços de Comunicação na nuvem sem nenhuma implantação local, como o roteamento direto do Azure. Nessa topologia, o tráfego nos 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 início da comunicação que afeta a conectividade nos perímetros corporativos. 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 de 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 a transmissão de mídia de DNS e ponto a ponto.
• Fluxo 2` – Representa um fluxo iniciado por um usuário remoto dos Serviços de Comunicação Móvel, com VPN para a rede do cliente.
• Fluxo 3 – Representa um fluxo iniciado por um usuário móvel remoto dos Serviços de Comunicação 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 na rede do cliente.
• Fluxo 6 – Representa um fluxo de mídia ponto a ponto entre um usuário móvel remoto dos Serviços de Comunicação e outro usuário móvel remoto dos Serviços de Comunicação pela Internet.

Caso de uso: Chamada individual

Uma chamada um para um significa que um usuário liga diretamente para 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 conforme visto pela retransmissão). O SDK chamador envia esses candidatos para a parte chamada; a parte chamada também obtém um conjunto semelhante de candidatos e os envia ao chamador. As mensagens de verificação de conectividade do STUN são usadas para descobrir quais caminhos de mídia do chamador/da parte chamada funcionam e o melhor caminho de trabalho é escolhido. Uma vez estabelecido o caminho de conexão, um handshake DTLS é executado nesta 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 o SRTP) é enviada por meio do par de 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, então o caminho direto entre os clientes (ou usando um NAT) será selecionado para mídia. Se os clientes estiverem na rede do cliente, o caminho direto deverá ser selecionado. Isso exige conectividade UDP direta na rede do cliente. Se os clientes forem usuários de nuvem nômades, dependendo da NAT/do firewall, a mídia poderá usar a conectividade direta.

Se um cliente for interno na rede do cliente e um cliente for externo (por exemplo, um utilizador de nuvem móvel), então é improvável que a conectividade direta entre os candidatos locais ou reflexivos seja habilitada. Nesse caso, uma opção é usar um dos candidatos de retransmissão de transporte de um dos clientes (por exemplo, o cliente interno obteve um candidato de retransmissão da retransmissão de transporte no Azure; o cliente externo precisa conseguir enviar os pacotes STUN/RTP/RTCP para a retransmissão 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, há suporte para TCP.

Etapas de alto nível:

1. o Usuário A dos Serviços de Comunicação resolve o DNS (nome de domínio) da URL usando o Fluxo 2.
2. O Usuário A aloca uma porta de retransmissão de mídia na retransmissão de transporte do Teams usando o Fluxo 4.
3. O Usuário A dos Serviços de Comunicação envia um "convite" com os candidatos do ICE usando o Fluxo 4 para os Serviços de Comunicação.
4. Os Serviços de Comunicação notificam o Usuário B usando o Fluxo 4.
5. O Usuário B aloca uma porta de retransmissão de mídia na retransmissão de transporte do Teams usando o Fluxo 4.
6. O Usuário B envia a "resposta" com os candidatos do ICE usando o Fluxo 4, que é encaminhado novamente para o Usuário A usando o Fluxo 4.
7. O Usuário A e o Usuário B invocam testes de conectividade do ICE e o melhor caminho de mídia disponível é selecionado (confira os diagramas abaixo para conhecer os vários casos de uso).
8. Os dois usuários enviam a telemetria para os Serviços de Comunicação por meio do Fluxo 4.

Rede do cliente (intranet)

Figura 2 – Na rede do cliente

Na Etapa 7, o Fluxo 5 da mídia ponto a ponto é selecionado.

Essa transmissão de mídia é bidirecional. A direção do Fluxo 5 indica que um lado inicia a comunicação da perspectiva de conectividade. Nesse caso, não importa qual direção é usada, porque os dois pontos de extremidade estão na rede do cliente.

Rede do cliente para usuário externo (mídia retransmitida pela retransmissão de transporte do Teams)

Figura 3 – Rede do cliente para usuário externo (mídia retransmitida pela retransmissão de transporte do Azure)

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 móvel remoto dos Serviços de Comunicação para os Serviços de Comunicação do Azure) estão selecionados.

Esses fluxos são retransmitidos pela retransmissão de transporte do Teams no Azure.

Essa transmissão de mídia é bidirecional. A direção indica qual lado inicia a comunicação da perspectiva de conectividade. Nesse caso, esses fluxos são usados para sinalização e mídia, usando diferentes protocolos de transporte e endereços.

Rede do cliente para usuário externo (mídia direta)

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) está 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.

Essa 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 da perspectiva de conectividade.

Usuário de VPN para usuário interno (mídia retransmitida pela retransmissão de transporte do Teams)

Figura 5 – Usuário de VPN para usuário interno (mídia retransmitida pela Retransmissão do Azure)

A sinalização entre a VPN e a rede do cliente usa o Fluxo 2*. A sinalização entre a rede do cliente e o Azure usa o Fluxo 4. No entanto, a mídia ignora a VPN e é roteada usando os Fluxos 3 e 4 por meio da Retransmissão de Mídia do Azure.

Usuário de VPN para usuário interno (mídia direta)

Figura 6 – Usuário de VPN para usuário interno (mídia direta)

A sinalização entre a VPN e a rede do cliente usa o Fluxo 2. A sinalização entre a rede do cliente e o Azure usa o fluxo 4. No entanto, a mídia ignora a VPN e é roteada usando o fluxo 2 da rede do cliente para a Internet.

Essa 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 da perspectiva de conectividade.

Usuário de VPN para usuário externo (mídia direta)

Figura 7 – Usuário de VPN para usuário externo (mídia direta)

A sinalização entre o usuário de VPN para 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 Fluxo 6.

Essa transmissão de mídia é bidirecional. A direção do Fluxo 6 para o usuário móvel remoto indica que um lado inicia a comunicação da perspectiva de conectividade.

Caso de uso: cliente de Serviços de Comunicação para PSTN por meio de tronco de serviços de comunicação

Os Serviços de Comunicação permitem fazer e receber chamadas na PSTN (Rede Telefônica Pública Comutada). Se o tronco da PSTN estiver conectado com números de telefone fornecidos pelos Serviços de Comunicação, não haverá nenhum requisito de conectividade especial para esse caso de uso. Caso deseje conectar seu tronco PSTN local aos Serviços de Comunicação do Azure, use o roteamento direto do Azure (disponível em CY2021).

Figura 8 – Usuário dos Serviços de Comunicação para a 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 Fluxo 4.

Caso de uso: chamadas em grupo dos Serviços de Comunicação

O serviço de compartilhamento de áudio/vídeo/tela (VBSS) faz parte dos Serviços de Comunicação do Azure. Ele tem um endereço IP público que precisa ser acessado pela rede do cliente e ser acessível em um cliente de nuvem nômade. Cada cliente/ponto de extremidade precisa conseguir se conectar ao serviço.

Os clientes internos obtêm candidatos locais, reflexivos e de retransmissão da mesma maneira descrita para chamadas um para um. Os clientes enviam esses candidatos ao serviço por meio de um convite. O serviço não usa retransmissão, pois possui 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 um para um.

Figura 9 – Chamadas em grupo dos Serviços de Comunicação

Restrições de interoperabilidade

A mídia que flui pelos Serviços de Comunicação do Azure é restrita da seguinte forma:

O Session Border Controller (SBC) 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 não poderá ser compreendido.

Servidores proxy SIP de terceiros. Uma caixa de diálogo do SIP de sinalização dos Serviços de Comunicação com um SBC e/ou um gateway de terceiros pode percorrer os proxies SIP nativos da Microsoft (assim como o Teams). A interoperabilidade com proxies SIP de terceiros não é suportada.

B2BUA (ou SBC) de terceiros. O fluxo de mídia bidirecional dos Serviços de Comunicação na PSTN é encerrado por um SBC de terceiros. A interoperabilidade com um SBC de terceiros na rede dos Serviços de Comunicação (onde um SBC de terceiros medeia dois pontos finais dos Serviços de Comunicação) não é suportada.

Tecnologias sem suporte

Rede VPN. Os Serviços de Comunicação não dão suporte à transmissão de mídia por VPNs. Se os 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 Como permitir que a mídia do Lync ignore um túnel VPN.

Observação

Embora o título indique Lync, ele é aplicável ao Teams e aos Serviços de Comunicação do Azure.*

Modeladores de pacotes. Não há suporte para dispositivos de captura, inspeção ou modelagem de pacote. Eles podem degradar a qualidade de maneira significativa.

Próximas etapas

Introdução a chamadas

Os seguintes documentos podem ser do seu interesse:

• Saiba mais sobre os tipos de chamada
• Saiba mais sobre a Arquitetura de cliente/servidor