Noções básicas sobre fluxo de chamadas

A seção abaixo fornece uma visão geral dos fluxos de chamada nos Serviços de Comunicação do Azure. A sinalização e os fluxos de mídia dependem dos tipos de chamadas que seus usuários estão fazendo. Exemplos de tipos de chamada incluem VoIP um-para-um, PSTN um-para-um e chamadas em grupo contendo uma combinação de participantes conectados a VoIP e PSTN. Revise os tipos de chamada.

Sobre sinalização e protocolos de mídia

Quando você estabelece uma chamada ponto a ponto ou em grupo, dois protocolos são usados nos bastidores - HTTPS (REST) para sinalização e SRTP para mídia.

A sinalização entre os SDKs ou entre SDKs e Controladores de Sinalização dos Serviços de Comunicação é tratada com HTTPS REST (TLS). Os Serviços de Comunicação do Azure usam o TLS 1.2. Para o tráfego de mídia em tempo real (RTP), o protocolo UDP (User Datagram Protocol) é preferido. Se o uso do UDP for impedido pelo firewall, o SDK usará o protocolo TCP (Transmission Control Protocol) para mídia.

Vamos rever os protocolos de sinalização e mídia em vários cenários.

Casos de fluxo de chamadas

Caso 1: VoIP onde é possível uma conexão direta entre dois dispositivos

Em chamadas de vídeo ou VoIP individuais, o tráfego prefere o caminho mais direto. "Caminho direto" significa que, se dois SDKs puderem alcançar um ao outro diretamente, eles estabelecerão uma conexão direta. Isso geralmente é possível quando dois SDKs estão na mesma sub-rede (por exemplo, em uma sub-rede 192.168.1.0/24) ou dois quando os dispositivos vivem em sub-redes que podem se ver (SDKs na sub-rede 10.10.0.0/16 e 192.168.1.0/24 podem alcançar um ao outro).

Caso 2: VoIP onde uma conexão direta entre dispositivos não é possível, mas onde a conexão entre dispositivos NAT é possível

Se dois dispositivos estiverem localizados em sub-redes que não podem alcançar um ao outro (por exemplo, Alice trabalha em uma cafeteria e Bob trabalha em seu escritório em casa), mas a conexão entre os dispositivos NAT é possível, os SDKs do lado do cliente estabelecerão conectividade por meio de dispositivos NAT.

Para Alice será o NAT do café e para Bob será o NAT do home office. O dispositivo de Alice enviará o endereço externo de seu NAT e Bob's fará o mesmo. Os SDKs aprendem os endereços externos de um serviço STUN (Session Traversal Utilities for NAT) que os Serviços de Comunicação do Azure fornecem gratuitamente. A lógica que manipula o handshake entre Alice e Bob está incorporada nos SDKs fornecidos pelos Serviços de Comunicação do Azure. (Você não precisa de nenhuma configuração adicional)

Caso 3: VoIP onde não é possível uma ligação direta nem NAT

Se um ou ambos os dispositivos cliente estiverem atrás de um NAT simétrico, será necessário um serviço de nuvem separado para retransmitir a mídia entre os dois SDKs. Este serviço chama-se TURN (Traversal Using Relays around NAT) e é também fornecido pelos Serviços de Comunicação. O SDK de Chamada de Serviços de Comunicação usa automaticamente os serviços TURN com base nas condições de rede detetadas. As taxas TURN estão incluídas no preço da chamada.

Caso 4: Chamadas em grupo com RTPC

Tanto a sinalização quanto a mídia para chamadas PSTN usam o recurso de telefonia dos Serviços de Comunicação do Azure. Este recurso está interligado com outras operadoras.

O tráfego de mídia PSTN flui através de um componente chamado Media Processor.

Nota

Para aqueles familiarizados com o processamento de mídia, nosso processador de mídia também é um agente de usuário Back to Back, conforme definido no RFC 3261 SIP: Session Initiation Protocol, o que significa que ele pode traduzir codecs ao lidar com chamadas entre a Microsoft e as redes da operadora. O Controlador de Sinalização dos Serviços de Comunicação do Azure é a implementação da Microsoft de um Proxy SIP pela mesma RFC.

Para chamadas em grupo, a mídia e a sinalização sempre fluem por meio do back-end dos Serviços de Comunicação do Azure. O áudio e/ou vídeo de todos os participantes é misturado no componente Processador de mídia. Todos os membros de uma chamada de grupo enviam seus fluxos de áudio e/ou vídeo para o processador de mídia, que retorna fluxos de mídia mista.

O protocolo em tempo real (RTP) padrão para chamadas em grupo é UDP (User Datagram Protocol).

Nota

O processador de mídia pode atuar como uma unidade de controle multiponto (MCU) ou unidade de encaminhamento seletivo (SFU)

Se o SDK não puder usar UDP para mídia devido a restrições de firewall, será feita uma tentativa de usar o protocolo TCP (Transmission Control Protocol). Observe que o componente Processador de mídia requer UDP, portanto, quando isso acontecer, o serviço TURN dos Serviços de Comunicação será adicionado à chamada de grupo para traduzir TCP para UDP. As taxas TURN estão incluídas no preço da chamada.

Caso 5: SDK dos Serviços de Comunicação e Microsoft Teams numa reunião agendada do Teams

A sinalização flui através do controlador de sinalização. A mídia flui através do processador de mídia. O controlador de sinalização e o processador de mídia são compartilhados entre os Serviços de Comunicação e o Microsoft Teams.

Caso 6: Primeiros meios de comunicação social

Refere-se a mídia (por exemplo, áudio e vídeo) que é trocada antes de uma sessão específica ser aceita pelo usuário chamado. Se houver fluxo de mídia inicial, o SBC deve se prender ao primeiro ponto de extremidade que inicia o streaming de mídia; O fluxo de mídia pode começar antes que os candidatos sejam nomeados. O SBC deve ter suporte para enviar DTMF durante esta fase para habilitar cenários de IVR/correio de voz. O SBC deve utilizar o caminho de prioridade mais elevada em que recebeu verificações se as nomeações não tiverem sido concluídas.

Próximos passos

Introdução às chamadas

Os seguintes documentos podem ser interessantes para si:

• Saiba mais sobre os tipos de chamada
• Saiba mais sobre a arquitetura cliente-servidor
• Saiba mais sobre topologias de fluxo de chamadas