Topologias de fluxo de chamadas

Este artigo descreve topologias de fluxo de chamadas dos Serviços de Comunicação do Azure e detalha como o tráfego de chamadas é criptografado. Para obter uma introdução aos fluxos de chamadas dos Serviços de Comunicação do Azure, consulte Internos de rede de chamadas.

Contexto geral

Conceitos de rede

Antes de analisar as topologias de fluxo de chamadas, é útil entender os termos usados neste artigo.

Uma rede de clientes contém todos os segmentos de rede que você gerencia. A rede do cliente pode incluir redes com e sem fio dentro do seu escritório ou entre escritórios, datacenters e provedores de serviços de Internet.

Uma rede de clientes geralmente tem vários perímetros de rede com firewalls ou servidores proxy que impõem as políticas de segurança da sua organização. Recomendamos que você realize uma avaliação abrangente da rede para alcançar o desempenho e a qualidade ideais de sua solução de comunicação.

A rede dos Serviços de Comunicação do Azure é a rede que dá suporte aos Serviços de Comunicação do Azure. A Microsoft gere esta rede e distribui-a para todo o mundo com os datacenters de 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 e em tempo real.

Tipos de tráfego

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

A mídia em tempo real é transmitida via Real-Time Transport Protocol (RTP). Este protocolo suporta 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 mídia em tempo real usando TCP ou HTTP, recomendamos que você use o UDP (User Datagram Protocol) como o protocolo de camada de transporte para oferecer suporte a experiências de usuário final de alto desempenho. As cargas úteis transmitidas através de RTP são protegidas através de RTP seguro (SRTP).

Os utilizadores da sua solução dos Serviços de Comunicação do Azure ligam-se aos seus serviços a partir dos respetivos dispositivos cliente. A sinalização lida com a comunicação entre esses dispositivos e seus servidores. Por exemplo, a sinalização entre dispositivos e seu serviço suporta o início de chamadas e o bate-papo em tempo real. A maioria do tráfego de sinalização usa HTTPS REST. Em alguns cenários, você pode usar o SIP (Session Initiation Protocol) 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 uma experiência agradável ao usuário final.

Encriptação de multimédia

Os fluxos de chamada nos Serviços de Comunicação do Azure que chamam 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 de entrada, 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 via SRTP, um perfil do 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 cliente-para-cliente é negociado através de sinalização de conexão cliente-servidor e é criptografado via SRTP quando vai diretamente de cliente para cliente.

As instâncias dos Serviços de Comunicação do Azure que chamam clientes SDK usam DTLS (Datagram Transport Layer Security) para derivar uma chave de criptografia. Depois que o handshake DTLS é feito, a mídia começa a fluir através dessa chave de criptografia negociada por DTLS sobre SRTP.

As instâncias dos 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 TURN. Os retransmissores de mídia trocam o token por meio de um canal seguro TLS (Transport Layer Security).

O tráfego de mídia que está indo entre dois pontos de extremidade que participam do compartilhamento de áudio, vídeo e vídeo dos Serviços de Comunicação do Azure usa 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 um 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 do Azure determina a região na qual a chamada está hospedada. Há exceções a essa regra em algumas topologias, que você pode encontrar mais adiante neste artigo.

• O ponto de extremidade de mídia usado para dar suporte a uma chamada dos Serviços de Comunicação do Azure é 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. 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 mistura e roteamento.

  Este endpoint é selecionado com base na região em que a chamada é realizada. O tráfego de mídia enviado de um cliente para o endpoint de mídia pode ser encaminhado diretamente. Ou, ele 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 par remoto (cliente). Se uma rota direta não estiver disponível, um ou mais relés de transporte encaminham o tráfego. O tráfego de mídia não deve atravessar servidores que agem como formadores de pacotes ou servidores de rede virtual privada (VPN), ou cumprir 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 obter mais informações sobre caminhos de mídia, consulte Documentação conceitual de fluxos de chamada.

Fluxos de chamada em várias topologias

Serviços de Comunicação do Azure (internet)

Este exemplo de topologia de fluxo de chamadas descreve clientes que usam os Serviços de Comunicação do Azure a partir da nuvem sem qualquer implantação local, como o roteamento direto do Azure. Nessa topologia, o tráfego de e para os Serviços de Comunicação do Azure flui pela Internet.

A direção das setas no diagrama anterior reflete a direção da comunicação inicial que afeta a conectividade nos perímetros da empresa. Para mídia UDP, os primeiros pacotes podem fluir na direção inversa, mas esses pacotes podem ser bloqueados até que os pacotes estejam fluindo na outra direção.

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 Azure 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 dos Serviços de Comunicação do Azure 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 do Azure móvel para pontos de extremidade dos Serviços de Comunicação do Azure.
• Fluxo 4: Representa um fluxo iniciado por um usuário na rede do cliente para os Serviços de Comunicação do Azure.
• Fluxo 5: representa um fluxo de mídia ponto a ponto entre um usuário dos Serviços de Comunicação do Azure 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 do Azure móvel e outro usuário remoto dos Serviços de Comunicação do Azure 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. Este conjunto inclui candidatos locais, de retransmissão e reflexivos (o endereço IP público do cliente visto pelo retransmissor). O SDK de chamada envia esses candidatos para a parte chamada. A parte chamada recebe um conjunto semelhante de candidatos e envia-os para o interlocutor.

O sistema usa mensagens de verificação de conectividade STUN para encontrar quais caminhos de mídia de chamador/grupo chamado funcionam e, em seguida, seleciona o melhor caminho de trabalho. Depois que o sistema estabelece o caminho de conexão, ele executa um handshake DTLS sobre a conexão para garantir a segurança. Após o handshake DTLS, o sistema deriva as chaves SRTP do processo de handshake DTLS. Os media (pacotes RTP/RTCP protegidos via SRTP) são então enviados através do 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 se você estiver usando um NAT) será selecionado para mídia. Se os clientes estiverem ambos na rede do cliente, o caminho direto deve ser selecionado. Esta seleção requer conectividade UDP direta dentro da rede do cliente. Se os clientes forem ambos usuários nômades da nuvem, 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, você pode usar um dos candidatos a revezamento de transporte de qualquer cliente. Por exemplo, o cliente interno obteve um candidato de retransmissão do relé de transporte no Azure, e o cliente externo precisa ser capaz de enviar pacotes STUN/RTP/RTCP para o relé de transporte. Outra opção é que o cliente interno envie para o candidato de retransmissão obtido pelo cliente de nuvem móvel. Embora seja altamente recomendável a conectividade UDP para mídia, o TCP é suportado.

Etapas de alto nível

1. O usuário A dos Serviços de Comunicação do Azure resolve o nome de domínio de URL (DNS) usando o Fluxo 2.

2. O usuário A aloca uma porta de retransmissão de mídia no relé de transporte do Teams usando o Fluxo 4.

3. O usuário A envia um convite com candidatos ao ICE (Estabelecimento de Conectividade Interativa) usando o Fluxo 4 para os Serviços de Comunicação do Azure.

4. Os Serviços de Comunicação do Azure notificam o Usuário B usando o Fluxo 4.

5. O usuário B aloca uma porta de retransmissão de mídia no relé de transporte do Teams usando o Flow 4.

6. O usuário B envia uma resposta com candidatos ICE usando o fluxo 4, que é encaminhado de volta para o usuário A usando o fluxo 4.

7. O usuário A e o usuário B invocam testes de conectividade ICE e o melhor caminho de mídia disponível é selecionado. Analise os diagramas a seguir para ver vários casos de uso.

8. Ambos os usuários enviam telemetria para os Serviços de Comunicação do Azure usando o Fluxo 4.

Rede de clientes (intranet)

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 a partir 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 utilizador externo (meios transmitidos pelo relé de transporte do Teams)

Na etapa 7, o Fluxo 4 (da rede do cliente para os Serviços de Comunicação do Azure) e o Fluxo 3 (de um usuário remoto móvel dos Serviços de Comunicação do Azure para os Serviços de Comunicação do Azure) são selecionados.

A retransmissão de transporte do Teams lida com esses fluxos 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, e eles usam diferentes protocolos de transporte e endereços.

Rede de clientes para utilizador externo (comunicação 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. O fluxo 2 na direção do utilizador móvel remoto indica que um dos lados inicia a comunicação do ponto de vista da conectividade.

Usuário VPN para usuário interno (mídia retransmitida pelo relé de transporte do Teams)

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 por meio dos Fluxos 3 e 4 por meio do Azure Media Relay.

Utilizador VPN para utilizador interno (media 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 usa o Flow 4. No entanto, a mídia ignora a VPN e é roteada via Fluxo 2 da rede do cliente para a internet.

Esta transmissão de mídia é bidirecional. O fluxo 2 na direção do utilizador móvel remoto indica que um dos lados inicia a comunicação do ponto de vista da conectividade.

Utilizador VPN para utilizador externo (media 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 via 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 dos Serviços de Comunicação do Azure para PSTN por meio de um tronco dos Serviços de Comunicação do Azure

Os Serviços de Comunicação do Azure permitem fazer e receber chamadas da PSTN (Rede Telefónica Pública Comutada). Se o tronco PSTN estiver conectado por meio de números de telefone fornecidos pelos Serviços de Comunicação do Azure, não haverá 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.

Nesse caso, a sinalização e a mídia da rede do cliente para o Azure usam o Flow 4.

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

O serviço que fornece áudio, vídeo e compartilhamento de tela 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 de um cliente de nuvem nômade. Cada cliente e 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 ponto a ponto. Os clientes enviam estes candidatos ao serviço através de um convite. O serviço não usa um relé porque 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.

Restrições de interoperabilidade

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

• Controlador de borda de sessão de terceiros (SBC): um SBC no limite com PSTN deve encerrar o fluxo RTP/RTCP, protegido via 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 do Azure 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: um SBC de terceiros encerra esses fluxos de mídia dos Serviços de Comunicação do Azure de e para a PSTN. Não há suporte para a interoperabilidade com um SBC de terceiros na rede dos Serviços de Comunicação do Azure (na qual um SBC de terceiros medeia dois pontos de extremidade dos Serviços de Comunicação do Azure).

Tecnologias não suportadas

• VPN: os Serviços de Comunicação do Azure não suportam a transmissão de multimédia através de 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.

  Observação

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

• Modeladores de pacotes: Os dispositivos de recorte de pacotes, inspeção de pacotes ou modelagem de pacotes não são suportados e podem degradar a qualidade significativamente.

Próximo passo

Conteúdo relacionado

• Saiba mais sobre os tipos de chamada.
• Saiba mais sobre a arquitetura cliente-servidor.