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 chamada é criptografado. Para obter uma introdução aos fluxos de chamadas dos Serviços de Comunicação do Azure, consulte a rede de chamadas internas.

Contexto

Conceitos de rede

Antes de examinar topologias de fluxo de chamadas, é útil entender os termos que este artigo usa.

Uma rede de cliente contém todos os segmentos de rede que você gerencia. A rede do cliente pode incluir redes com fio e sem fio em 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ê execute uma avaliação de rede abrangente para obter o desempenho e a qualidade ideais da 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 gerencia essa rede e a distribui em todo o mundo com os datacenters de propriedade da Microsoft que estão mais próximos dos clientes finais. Essa rede é responsável pela retransmissão de transporte, processamento de mídia para chamadas de grupo e outros componentes que dão suporte a comunicações de mídia avançadas 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 por meio do RTP (Protocolo de Transporte Real-Time). Esse protocolo dá suporte à transmissão de dados de áudio, vídeo e compartilhamento de tela. Esses dados são confidenciais 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 dar suporte a experiências de usuário final de alto desempenho. As cargas de mídia transmitidas por RTP são protegidas por meio de RTP seguro (SRTP).

Os usuários da solução dos Serviços de Comunicação do Azure conectam-se aos seus serviços a partir de seus dispositivos cliente. A sinalização manipula a comunicação entre esses dispositivos e seus servidores. Por exemplo, a sinalização entre dispositivos e seu serviço dá suporte à iniciação de chamadas e ao chat em tempo real. A maioria dos tráfegos de sinalização usa HTTPS REST. Em alguns cenários, você pode usar o SIP (Protocolo de Iniciação de Sessão) 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 fornece uma experiência agradável do usuário final.

Criptografia de mídia

Os fluxos de chamadas nos Serviços de Comunicação do Azure que chamam clientes do SDK e do Teams são baseados na oferta RFC 8866 do Protocolo de Descrição da Sessão (SDP) e no modelo de resposta por HTTPS. Quando o destinatário da chamada aceita uma chamada de entrada, o chamador e o destinatário concordam com os parâmetros de sessão.

O tráfego de mídia é criptografado e flui entre o chamador e o chamador via SRTP, um perfil de RTP que fornece confidencialidade, autenticação e proteção de ataque de reprodução para o tráfego RTP. Na maioria dos casos, o tráfego de mídia cliente a cliente é negociado por meio da sinalização de conexão cliente a servidor e é criptografado via SRTP ao ir diretamente de cliente para cliente.

As instâncias dos Serviços de Comunicação do Azure que chamam clientes do SDK usam DTLS (Segurança de Camada de Transporte de Datagrama) para derivar uma chave de criptografia. Depois que o handshake DTLS é concluído, 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. As retransmissões de mídia trocam o token por um canal seguro TLS (Transport Layer Security).

O tráfego de mídia que está 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 SRTP para criptografar o fluxo de mídia. Chaves criptográficas são negociadas entre os dois pontos de extremidade por meio 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 chamadas 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 podem ser encontradas posteriormente 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 pontos de extremidade de mídia. As chamadas de 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 na qual 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 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 é direta para o par remoto (cliente). Se uma rota direta não estiver disponível, uma ou mais retransmissões de transporte encaminharão o tráfego. O tráfego de mídia não deve percorrer servidores que agem como shapers de pacote ou servidores vpn (rede virtual privada) 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 a documentação conceitual de fluxos de chamadas.

Chamar fluxos em várias topologias

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

Este exemplo de topologia de fluxo de chamadas ilustra os clientes que usam os Serviços de Comunicação do Azure da nuvem sem nenhuma implantação local, como o roteamento direto do Azure. Nesta 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 corporativos. Para mídia UDP, os primeiros pacotes podem fluir na direção inversa, mas esses pacotes podem ser bloqueados até que os pacotes fluam 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. Esse conjunto inclui candidatos locais, retransmissão e reflexivos (o endereço IP público do cliente, conforme visto pela retransmissão). O SDK de chamada envia esses candidatos ao partido chamado. O partido chamado recebe um conjunto semelhante de candidatos e os envia ao chamador.

O sistema usa mensagens de verificação de conectividade STUN para localizar quais caminhos de mídia de chamadas/chamadas de partes 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. A mídia (pacotes RTP/RTCP protegidos via SRTP) é enviada por meio 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. Essa seleção requer conectividade UDP direta dentro da rede do cliente. Se os clientes forem usuários de nuvem nômades, dependendo do NAT/firewall, a mídia poderá 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 à retransmissão de transporte de qualquer cliente. Por exemplo, o cliente interno obteve um candidato de retransmissão da retransmissão de transporte no Azure e o cliente externo precisa ser capaz de enviar pacotes STUN/RTP/RTCP para a retransmissão de transporte. Outra opção é que o cliente interno envia ao candidato de retransmissão obtido pelo cliente de nuvem móvel. Embora seja altamente recomendável conectividade UDP para mídia, há suporte para TCP.

Etapas de alto nível

1. O usuário dos Serviços de Comunicação do Azure A resolve o DNS (nome de domínio de 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 envia um convite com candidatos do ICE (Interactive Connectivity Establishment) usando o Flow 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 Flow 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 uma resposta com os candidatos do ICE usando o Flow 4, que é encaminhado de volta para o Usuário A usando o Flow 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. Examine 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 Flow 4.

Rede do cliente (intranet)

Na etapa 7, a mídia ponto a ponto Flow 5 está selecionada.

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

Rede do cliente para usuário externo (mídia retransmitida pela retransmissão 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 Flow 3 (de um usuário remoto dos Serviços de Comunicação do Azure móvel para os Serviços de Comunicação do Azure) são selecionados.

A retransmissão de transporte do Teams manipula esses fluxos no Azure.

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

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 retransmitido 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 de uma perspectiva de conectividade.

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

A sinalização entre a VPN para a rede do cliente usa o Fluxo 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 da Retransmissão de Mídia do Azure.

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

A sinalização entre a VPN para a rede do cliente usa o Fluxo 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 do 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 de uma perspectiva de conectividade.

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

A sinalização entre o usuário VPN para a rede do cliente usa o Flow 2' e o Flow 4 para o Azure. No entanto, a mídia ignora a VPN e é roteada por meio do 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 de uma perspectiva 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 você quiser conectar seu próprio tronco PSTN local aos Serviços de Comunicação do Azure, poderá 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 tanto da rede do cliente quanto de um cliente de nuvem nômade. Cada cliente e ponto de extremidade precisam ser capazes de se conectar ao serviço.

Os clientes internos obtêm candidatos locais, reflexivos e de reencaminhamento da mesma forma que são descritos para chamadas um-para-um. Os clientes enviam esses candidatos para o serviço em um convite. O serviço não usa uma retransmissão porque tem um endereço IP acessível publicamente, portanto, ele 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.

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 retransmitê-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 de terceiros e/ou gateway pode percorrer proxies SIP nativos da Microsoft (assim como o Teams). Não há suporte para interoperabilidade com proxies SIP de terceiros.

• B2BUA de terceiros (ou SBC): um SBC de terceiros encerra esses fluxos de mídia dos Serviços de Comunicação do Azure de e para o PSTN. Não há suporte para a interoperabilidade com um SBC de terceiros na rede dos Serviços de Comunicação do Azure (no qual um SBC de terceiros media dois pontos de extremidade dos Serviços de Comunicação do Azure).

Tecnologias sem suporte

• VPN: os Serviços de Comunicação do Azure não dão suporte à transmissão de mídia por meio de VPNs. Se os usuários estiverem usando clientes VPN, o cliente deverá dividir e rotear o tráfego de mídia por uma conexão não VPN, conforme especificado na habilitação da mídia do Lync para ignorar um túnel VPN.

  Observação

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

• Shapers de pacote: não há suporte para snipping de pacotes, inspeção de pacotes ou modelagem de pacotes e pode prejudicar significativamente a qualidade.

Próxima etapa

Conteúdo relacionado

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