Partilhar via

Chamadas internas de rede

O artigo descreve os 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, rede telefônica pública comutada (PSTN) um-para-um e chamadas em grupo contendo uma combinação de participantes conectados a VoIP e PSTN. Para obter mais informações, consulte Tipos de chamada.

Protocolos de sinalização e 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 Secure Real-time Transport Protocol (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 tráfego de mídia em tempo real (RTP), recomendamos o protocolo de datagrama do usuário (UDP). Se o firewall impedir o uso de UDP, o SDK usará o protocolo de controle de transmissão (TCP) 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 com 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 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 vivem em sub-redes que podem se ver (SDKs na sub-rede 10.10.0.0/16 e 192.168.1.0/24 podem comunicar-se entre si).

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

Caso 2: VoIP em que 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ços de rede) é possível, os SDKs do lado do cliente estabelecem conectividade por meio de dispositivos NAT. Por exemplo, se Alice trabalha em um café e Bob trabalha em home office.

Para a Alice, é o NAT do café e, para o Bob, é o NAT do escritório de casa. 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 utilitário de passagem de sessão para o serviço NAT (STUN) 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.

Diagrama que mostra uma chamada VOIP, usando utilitários de atravessamento de sessão para conexão NAT (STUN).

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

Se um ou ambos os dispositivos cliente estiverem atrá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 de travessia usando relés em torno de NAT (TURN) e também é fornecido pelos Serviços de Comunicação do Azure. 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.

Diagrama mostrando um VOIP, ao longo de uma travessia usando relés em torno da conexão NAT (TURN).

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 de processador de mídia.

Diagrama que mostra uma chamada de grupo PSTN com os serviços de comunicação.

Observação

O 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 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 mista.

O protocolo em tempo real (RTP) padrão para chamadas em grupo é o protocolo de datagrama do usuário (UDP).

Observação

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

Diagrama que mostra o fluxo 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, por isso, o serviço TURN dos Serviços de Comunicação é adicionado à chamada de grupo para traduzir TCP para UDP. As taxas TURN estão incluídas no preço da chamada.

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

Caso 5: SDK de Serviços de Comunicação e Microsoft Teams numa reunião agendada no 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.

Diagrama que apresenta o SDK dos Serviços de Comunicação e o cliente do Teams numa reunião agendada no Teams.

Caso 6: Primeiros meios de comunicação social

Refere-se à mídia que é trocada, como áudio e vídeo, antes que o destinatário aceite a sessão. Para o fluxo de mídia inicial, o controlador de borda de sessão (SBC) deve fixar-se ao primeiro ponto de terminação que começa a transmitir mídia; o fluxo de mídia pode começar antes que os candidatos sejam nomeados. O SBC deve suportar o envio de DTMF (dual tone multi-frequency) durante esta fase para suportar cenários de IVR/correio de voz. O SBC deve usar o caminho de prioridade mais alta no qual recebe cheques, se as nomeações não forem concluídas.

Próximos passos

Começar com chamadas