Noções básicas do fluxo de chamadas
A seção a seguir fornece uma visão geral dos fluxos de chamada nos Serviços de Comunicação do Azure. Os fluxos de sinalização e de mídia dependem dos tipos de chamadas que os usuários estão fazendo. Exemplos de tipos de chamada incluem VoIP de um para um, PSTN de um para um e chamadas em grupo contendo uma combinação de VoIP e participantes conectados a PSTN. Examine os Tipos de chamada.
Sobre protocolos de mídia e sinalização
Quando você estabelece uma chamada em grupo ou ponto a ponto, dois protocolos são usados em segundo plano: o HTTPS (REST) para a sinalização e o SRTP para mídia.
Para lidar com a sinalização entre os SDKs ou entre os SDKs e os Controladores de Sinalização dos Serviços de Comunicação usamos HTTP REST (TLS). Os Serviços de Comunicação do Azure usam TLS 1.2. Para o Tráfego de Mídia em Tempo Real (RTP), o protocolo UDP é preferencial. Se o uso do UDP for impedido pelo firewall, o SDK usará o protocolo TCP para a mídia.
Vamos examinar os protocolos de sinalização e de mídia em vários cenários.
Casos de fluxo de chamadas
Caso 1: VoIP no qual uma conexão direta entre dois dispositivos é possível
Em chamadas de vídeo ou VoIP de um para um, 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. Geralmente, isso é possível quando dois SDKs estão na mesma sub-rede (por exemplo, em uma sub-rede 192.168.1.0/24) ou quando os dispositivos residem em sub-redes que podem ver umas às outras (os SDKs na sub-rede 10.10.0.0/16 e 192.168.1.0/24 podem alcançar um ao outro).
Caso 2: VoIP no qual uma conexão direta entre dispositivos não é possível, mas a conexão entre dispositivos de NAT é
Se dois dispositivos estiverem localizados em sub-redes que estiverem fora do alcance uma da outra (por exemplo, Alice trabalha em uma cafeteria e Pedro trabalha de casa), mas a conexão entre os dispositivos NAT for possível, os SDKs do lado do cliente estabelecerão a conectividade por meio de dispositivos NAT.
Para Alice, ele será o NAT da cafeteria e, para Pedro, será o NAT da casa dele. O dispositivo da Alice enviará o endereço externo do NAT dela e o do Pedro fará o mesmo. Os SDKs aprendem os endereços externos de um serviço STUN (Utilitários Transversais de Sessão para NAT) que os Serviços de Comunicação do Azure fornecem gratuitamente. A lógica que manipula o handshake entre a Alice e o Pedro é inserida nos SDKs fornecidos pelos Serviços de Comunicação do Azure. (Você não precisa de nenhuma configuração adicional)
Caso 3: VoIP no qual nem uma conexão direta nem uma conexão de NAT são possíveis
Se um ou ambos os dispositivos cliente estiverem protegidos por um NAT simétrico, será necessário que um serviço de nuvem separado retransmita a mídia entre os dois SDKs. Esse serviço é chamado TURN (Atravessamento Usando Retransmissões ao redor de NAT) e também é fornecido pelos Serviços de Comunicação. O SDK de Chamada dos Serviços de Comunicação usa automaticamente os serviços TURN com base nas condições de rede detectadas. Os encargos do TURN estão incluídos no preço da chamada.
Caso 4: chamadas em grupo com PSTN
Tanto a sinalização quanto a mídia para Chamadas PSTN usam o recurso de telefonia dos Serviços de Comunicação do Azure. Esse recurso é interconectado com outras operadoras.
O tráfego de mídia PSTN é transmitido por meio de um componente chamado Processador de Mídia.
Observação
Para as pessoas acostumadas com processamento de mídia, nosso Processador de Mídia é também um Agente de Usuário Back-to-Back, conforme definido em RFC 3261 de SIP: Protocolo de Iniciação de Sessão, o que significa que consegue traduzir codecs ao lidar com as chamadas entre redes da Microsoft e da Operadora. O Controlador de Sinalização dos Serviços de Comunicação do Azure é a implementação da Microsoft de um Proxy SIP de acordo com o mesmo RFC.
Chamadas em grupo, mídia e sinalização sempre são transmitidas por meio do back-end dos Serviços de Comunicação do Azure. O áudio e/ou vídeo de todos os participantes é mixado no componente de Processador de Mídia. Todos os membros de uma chamada em grupo enviam os fluxos de áudio e/ou vídeo para o processador de mídia, que retorna fluxos de mídia mixados.
O RTP (protocolo em tempo real) padrão para chamadas em grupo é o protocolo UDP.
Observação
O Processador de Mídia pode atuar como uma MCU (Unidade de Controle de Multipontos) ou SFU (Unidade de Encaminhamento Seletivo)
Se o SDK não puder usar o UDP para mídia devido a restrições de firewall, será feita uma tentativa de usar o protocolo TCP. Observe que o componente de Processador de Mídia requer o UDP, portanto, quando isso acontece, o serviço TURN dos Serviços de Comunicação será adicionado à chamada em grupo para converter TCP em UDP. Os encargos do TURN estão incluídos no preço da chamada.
Caso 5: SDK dos Serviços de Comunicação e do Microsoft Teams em uma reunião agendada do Teams
A sinalização flui pelo controlador de sinalização. A mídia flui pelo 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: mídia antecipada
Refere-se à mídia (por exemplo, áudio e vídeo) que é trocada antes que uma sessão específica seja aceita pelo usuário chamado. Se houver um fluxo de mídia antecipado, o SBC deve se apegar ao primeiro ponto de extremidade que começa a transmitir mídia; o fluxo de mídia pode começar antes que os candidatos sejam nomeados. O SBC deve ser compatível com o envio de DTMF durante esse estágio para habilitar cenários de IVR/correio de voz. Se as nomeações não forem executadas, o SBC deve usar o caminho de máxima prioridade no qual recebeu verificações.
Próximas etapas
Os seguintes documentos podem ser do seu interesse:
- Saiba mais sobre os tipos de chamada
- Saiba mais sobre a Arquitetura de cliente/servidor
- Saiba mais sobre Topologias do fluxo de chamadas