Compartilhar via

Chamar elementos internos de rede

O artigo descreve os fluxos de chamadas nos Serviços de Comunicação do Azure. A sinalização e os fluxos de mídia dependem dos tipos de chamadas que os usuários estão fazendo. Exemplos de tipos de chamada incluem VoIP um-para-um, PSTN (rede telefônica pública comutada) e chamadas de grupo que contêm uma combinação de participantes conectados a VoIP e PSTN. Para obter mais informações, consulte Tipos de chamada.

Sinalização e protocolos de mídia

Quando você estabelece uma chamada ponto a ponto ou de grupo, dois protocolos são usados nos bastidores – HTTPS (REST) para sinalização e SRTP (Secure Real-time Transport Protocol) 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 tráfego de mídia em tempo real (RTP), recomendamos o Protocolo de Datagrama de Usuário (UDP). Se o firewall impedir o uso do UDP, o SDK usará o TCP (protocolo de controle de transmissão) para mídia.

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

Casos de fluxo de chamadas

Caso 1: VoIP com uma conexão direta entre dois dispositivos

Em chamadas voIP ou vídeo um para um, o tráfego prefere o caminho mais direto. O caminho direto significa que, se dois SDKs podem alcançar um ao outro diretamente, eles estabelecem uma conexão direta. O caminho direto é possível quando dois SDKs estão na mesma sub-rede (como em uma sub-rede 192.168.1.0/24) ou quando dois dispositivos estão em sub-redes que podem se ver (os SDKs nas sub-redes 10.10.0.0/16 e 192.168.1.0/24 podem se comunicar entre si).

Diagrama mostrando uma chamada VOIP Direta entre usuários e Serviços de Comunicação.

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

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

Para Alice, ele será o NAT da cafeteria e, para Pedro, será o NAT da casa dele. O dispositivo de Alice envia o endereço externo de seu NAT e Bob's faz o mesmo. Os SDKs aprendem os endereços externos de um serviço Utilitários Transversais de Sessão para NAT (STUN) que os Serviços de Comunicação do Azure fornecem gratuitamente. A lógica que manipula o handshake entre Alice e Bob é inserida nos SDKs fornecidos pelos Serviços de Comunicação do Azure. Você não precisa de nenhuma configuração adicionada.

Diagrama mostrando uma chamada VOIP, usando um utilitário de passagem de sessão para conexão NAT (STUN).

Caso 3: VoIP em que uma conexão direta nem NAT é possível

Se um ou ambos os dispositivos cliente estiverem por trás de um NAT simétrico, um serviço de nuvem separado será necessário para retransmitir a mídia entre os dois SDKs. Esse serviço é chamado Atravessamento Usando Retransmissões ao redor da NAT (TURN) 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 TURN são incluídos no preço da chamada.

Diagrama mostrando um VOIP, em uma passagem usando retransmissões em torno da conexão NAT (TURN).

Caso 4: Chamadas em grupo com PSTN

A sinalização e a mídia para chamadas PSTN usam o recurso de telefonia dos Serviços de Comunicação do Azure. Esse recurso está interconectado com outras operadoras.

O tráfego de mídia PSTN flui por meio de um componente de processador de mídia.

Diagrama que mostra uma chamada de grupo na Rede Telefônica Pública Comutada (PSTN) com os Serviços de Comunicação.

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.

Para chamadas de 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 processador de mídia. Todos os membros de uma chamada de grupo enviam seus fluxos de áudio e vídeo para o processador de mídia, que retorna fluxos de mídia mistos.

O protocolo padrão RTP (Protocolo em Tempo Real) para chamadas de grupo é o UDP (Protocolo de Datagramas de Usuário).

Observação

O Processador de Mídia pode atuar como uma MCU (unidade de controle de vários pontos) ou uma SFU (unidade de encaminhamento seletivo).

Diagrama mostrando o fluxo de processo de mídia UDP nos Serviços de Comunicação.

Se o SDK não puder usar UDP para mídia devido a restrições de firewall, ele tentará usar o protocolo de controle de transmissão (TCP). O componente do processador de mídia requer UDP, portanto, nesse caso, o serviço TURN dos Serviços de Comunicação é adicionado à chamada de grupo para traduzir TCP para UDP. Os encargos TURN são incluídos no preço da chamada.

Diagrama mostrando o fluxo de processo de mídia TCP nos Serviços de Comunicação.

Caso 5: SDK de Serviços de Comunicação e 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.

Diagrama mostrando o SDK dos Serviços de Comunicação e o cliente do Teams em uma reunião agendada do Teams.

Caso 6: Mídia inicial

Refere-se à mídia trocada, como áudio e vídeo, antes que o receptor aceite a sessão. 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 dar suporte ao envio de multifrequência de tom duplo (DTMF) durante essa fase para habilitar cenários de IVR/caixa postal. O SBC deve usar o caminho de prioridade mais alta no qual recebe verificações, se as nomeações não estiverem concluídas.

Próximas etapas

Comece a usar as chamadas

  • Last updated on