Planejar o bypass de mídia com Roteamento Direto
Acerca do bypass multimédia com o Encaminhamento Direto
O bypass de multimédia permite-lhe encurtar o caminho do tráfego de multimédia e reduzir o número de saltos em trânsito para um melhor desempenho. Com o bypass multimédia, os suportes de dados são mantidos entre o Controlador de Limite de Sessão (SBC) e o cliente em vez de o enviar através do Microsoft Teams Phone. Para configurar a desativação do suporte de dados, o SBC e o cliente têm de estar na mesma localização ou rede.
Pode controlar a desativação do suporte de dados para cada SBC através do comando Set-CSOnlinePSTNGateway com o parâmetro -MediaBypass definido como verdadeiro ou falso. Se ativar a desativação dos suportes de dados, não significa que todo o tráfego de multimédia permaneça na rede empresarial. Este artigo descreve o fluxo de chamadas em diferentes cenários.
Os diagramas abaixo ilustram a diferença no fluxo de chamadas com e sem ignorar multimédia.
Sem ignorar o suporte de dados, quando um cliente efetua ou recebe uma chamada, tanto a sinalização como o fluxo de multimédia entre o SBC, o Sistema Telefónico do Microsoft Teams e o cliente do Teams, conforme mostrado no diagrama seguinte:
No entanto, vamos supor que um utilizador está no mesmo edifício ou rede que o SBC. Por exemplo, suponha que um utilizador que se encontra num edifício em Frankfurt faz uma chamada para um utilizador rtPC:
Sem o bypass dos meios de comunicação social, os meios de comunicação fluem através de Amesterdão ou dublin (onde os datacenters da Microsoft estão implementados) e de volta ao SBC em Frankfurt.
O datacenter na Europa está selecionado porque o SBC está na Europa e a Microsoft utiliza o datacenter mais próximo do SBC. Embora esta abordagem não afete a qualidade das chamadas devido à otimização do fluxo de tráfego nas redes da Microsoft na maioria das geografias, o tráfego tem um ciclo desnecessário.
Com o bypass multimédia, o suporte de dados é mantido diretamente entre o utilizador do Teams e o SBC, conforme mostrado no diagrama seguinte:
O bypass de multimédia utiliza protocolos chamados Interactive Connectivity Establishment (ICE) no cliente teams e ICE lite no SBC. Estes protocolos permitem que o Encaminhamento Direto utilize o caminho de multimédia mais direto para uma qualidade ideal. ICE e ICE Lite são normas WebRTC. Para obter informações detalhadas sobre estes protocolos, consulte RFC 5245.
Fluxo de chamadas e planeamento da firewall
O fluxo de chamadas e o planeamento da firewall dependem se o utilizador tem acesso direto ao endereço IP público do SBC e se o utilizador está dentro ou fora da rede.
Chamar o fluxo se o utilizador tiver acesso direto ao endereço IP público do SBC
Se o utilizador tiver acesso direto ao endereço IP público do SBC, o fluxo de chamada é o seguinte:
Para ignorar os suportes de dados, o cliente do Teams tem de ter acesso ao endereço IP público do SBC mesmo a partir de uma rede interna. Se o suporte de dados direto não for o pretendido, o suporte de dados pode fluir através de Reencaminhamentos de Transporte.
Este fluxo é a solução recomendada quando um utilizador está no mesmo edifício e/ou rede que o SBC – remova os componentes do Microsoft Cloud do caminho de multimédia.
A sinalização flui sempre através da cloud da Microsoft.
O diagrama seguinte mostra o fluxo de chamadas quando a desativação do suporte de dados está ativada, o cliente é interno e o cliente pode aceder ao endereço IP público do SBC (suporte de dados direto):
As setas e os valores numéricos dos caminhos estão de acordo com os fluxos de chamadas do Microsoft Teams.
A sinalização SIP segue sempre os caminhos 4 e 4' (consoante a direção do tráfego). Os suportes de dados permanecem locais e assumem o caminho 5b.
Chamar fluxo se o utilizador não tiver acesso ao endereço IP público do SBC
O cenário seguinte descreve o fluxo de chamadas se o utilizador não tiver acesso ao endereço IP público do SBC.
Por exemplo, suponha que o utilizador é externo e o administrador inquilino decidiu não abrir o endereço IP público do SBC a todas as pessoas na Internet, mas apenas à Microsoft Cloud. Os componentes internos do tráfego podem fluir através dos Reencaminhamentos de Transporte do Teams. Considere o seguinte:
São utilizados Reencaminhamentos de Transporte do Teams.
Para ignorar os suportes de dados, a Microsoft utiliza uma versão dos Reencaminhamentos de Transporte que requer a abertura das portas 50 000 a 59 999 entre os Reencaminhamentos de Transporte do Teams e o SBC (no futuro, planeamos mudar para a versão que requer portas 3478-3481).
O diagrama seguinte mostra o fluxo de chamadas quando a desativação do suporte de dados está ativada, o cliente é externo e o cliente não consegue aceder ao endereço IP público do Controlador de Limite de Sessão (o suporte de dados é reencaminhado pelo Reencaminhamento de Transporte do Teams).
As setas e os valores numéricos dos caminhos estão de acordo com os fluxos de chamadas do Microsoft Teams.
O suporte de dados é reencaminhado através dos caminhos 3, 3', 4 e 4'.
Chamar o fluxo se um utilizador estiver fora da rede e tiver acesso ao IP público do SBC
Nota
Esta não é uma configuração recomendada porque não tira partido dos Reencaminhamentos de Transporte do Teams. Em vez disso, deve considerar o cenário anterior em que o utilizador não tem acesso ao endereço IP público do SBC.
O diagrama seguinte mostra o fluxo de chamadas quando a desativação do suporte de dados está ativada, o cliente é externo e o cliente pode aceder ao endereço IP público do SBC (suporte de dados direto).
As setas e os valores numéricos dos caminhos estão de acordo com o artigo Fluxos de chamadas do Microsoft Teams .
A sinalização SIP segue sempre os caminhos 3 e 3' (consoante a direção do tráfego). Fluxos de multimédia com o caminho 2.
Utilização de Processadores de Multimédia e Reencaminhamentos de Transporte
Existem dois componentes na Microsoft Cloud que podem estar no caminho do tráfego de multimédia: Processadores de Multimédia e Reencaminhamentos de Transporte.
O Processador de Multimédia é um componente destinado ao público que processa suportes de dados em casos de não ignorar e processa suportes de dados para aplicações de voz.
Os Processadores de Multimédia estão sempre no caminho para chamadas não ignoradas pelo utilizador final, mas nunca no caminho para chamadas ignoradas. Os Processadores de Multimédia estão sempre no caminho para todas as aplicações de voz, como Call Park, Atendedor Automático Organizacional e Filas de Chamadas.
O Reencaminhamento de Transporte é utilizado para ligar ao Serviço de Transporte mais próximo para enviar tráfego em tempo real.
Os Reencaminhamentos de Transporte podem ou não estar no caminho para chamadas ignoradas – com origem ou destinados a utilizadores finais – consoante a localização do utilizador e a forma como a rede está configurada.
O diagrama seguinte mostra dois fluxos de chamadas: um com o bypass multimédia ativado e o segundo com o media bypass desativado.
Nota
O diagrama ilustra apenas o tráfego proveniente de utilizadores de ou destinados a utilizadores finais.
O Controlador de Multimédia é um microsserviço no Azure que atribui Processadores de Multimédia e cria ofertas de Protocolo SDP (Session Description Protocol).
O Proxy SIP é um componente que traduz a sinalização REST HTTP utilizada no Teams para o SIP.
A tabela seguinte resume a diferença entre Processadores de Multimédia e Reencaminhamentos de Transporte.
| Processadores de Multimédia | Reencaminhamentos de Transporte | |
|---|---|---|
| No caminho de multimédia para chamadas não ignoradas para utilizadores finais | Sempre | Se o cliente não conseguir aceder diretamente ao Processador de Multimédia |
| No caminho de multimédia para chamadas ignoradas para utilizadores finais | Nunca | Se o cliente não conseguir aceder ao SBC no endereço IP público |
| No caminho de multimédia para aplicações de voz | Sempre | Nunca |
| Pode fazer transcodificação (B2BUA)* | Sim | Não, apenas reencaminha o áudio entre pontos finais |
Os intervalos de IP são:
- 52.112.0.0/14 (endereços IP de 52.112.0.0 a 52.115.255.255)
- 52.120.0.0/14 (endereços IP de 52.120.0.0 a 52.123.255.255)
Nota
Os intervalos de IP apresentados neste documento são específicos do Encaminhamento Direto e podem ser diferentes dos recomendados para o cliente do Teams.
* Explicação da transcodificação:
O Processador de Multimédia é B2BUA, o que significa que pode alterar codecs (por exemplo, SILK do cliente teams para MP e G.711 entre MP e SBC).
Os Reencaminhamentos de Transporte não são B2BUA, o que significa que o codec nunca é alterado entre o cliente e o SBC, mesmo que o tráfego flua através de reencaminhamentos.
Utilização de Processadores de Multimédia do Teams se o ramal estiver configurado para ignorar suportes de dados
Os Processadores de Multimédia do Teams são sempre inseridos no caminho de multimédia nos seguintes cenários:
- A chamada é escalada de 1:1 para uma chamada de grupo
- A chamada vai para um utilizador federado do Teams
- A chamada é reencaminhada ou transferida para um utilizador do Skype para Empresas
Certifique-se de que o SBC tem acesso aos intervalos Processadores de Multimédia e Reencaminhamentos de Transporte, conforme descrito abaixo.
Sinalização SIP: FQDNs
Para a sinalização SIP, os requisitos do FQDN e da firewall são os mesmos que para casos não ignorados.
O Encaminhamento Direto é oferecido nos seguintes ambientes do Microsoft 365 ou Office 365:
- Microsoft 365 ou Office 365
- Office 365 GCC
- Office 365 GCC High
- Office 365 DoD
Saiba mais sobre os ambientes do Office 365 e do Governo Norte-Americano , como GCC, GCC High e DoD.
Ambientes do Microsoft 365, Office 365 e GCC do Office 365
Os pontos de ligação para o Encaminhamento Direto são os três FQDNs seguintes:
sip.pstnhub.microsoft.com – FQDN Global – tem de ser experimentado primeiro. Quando o SBC envia um pedido para resolver este nome, os servidores DNS do Microsoft Azure devolvem um endereço IP que aponta para o datacenter primário do Azure atribuído ao SBC. A atribuição baseia-se nas métricas de desempenho dos datacenters e na proximidade geográfica do SBC. O endereço IP devolvido corresponde ao FQDN primário.
sip2.pstnhub.microsoft.com – FQDN secundário – mapeia geograficamente para a segunda região prioritária.
sip3.pstnhub.microsoft.com – FQDN Terciário – mapeia geograficamente para a terceira região prioritária.
Tem de colocar estes três FQDNs para:
Proporcionar uma experiência ideal (menos carregado e mais próximo do datacenter SBC atribuído ao consultar o primeiro FQDN).
Fornecer ativação pós-falha quando uma ligação de um SBC é estabelecida para um datacenter que está a ter um problema temporário. Para obter mais informações, veja Mecanismo de ativação pós-falha abaixo.
Os FQDNs sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com e sip3.pstnhub.microsoft.com serão resolvidos para endereços IP a partir das seguintes sub-redes:
- 52.112.0.0/14
- 52.120.0.0/14
Tem de abrir portas para todos estes intervalos de IP na firewall para permitir o tráfego de entrada e saída de e para os endereços para sinalização.
Ambiente do Office 365 GCC DoD
O ponto de ligação para o Encaminhamento Direto é o seguinte FQDN:
sip.pstnhub.dod.teams.microsoft.us – FQDN Global. Uma vez que o ambiente DoD do Office 365 existe apenas nos datacenters dos EUA, não existem FQDNs secundários e terciários.
O FQDN sip.pstnhub.dod.teams.microsoft.us será resolvido para um endereço IP a partir da seguinte sub-rede:
- 52.127.64.0/21
Tem de abrir portas para todos estes intervalos de IP na firewall para permitir o tráfego de entrada e saída de e para os endereços para sinalização. Se a firewall suportar nomes DNS, o FQDN sip.pstnhub.dod.teams.microsoft.us é resolvido para todas estas sub-redes IP.
Ambiente do Office 365 GCC High
O ponto de ligação para o Encaminhamento Direto é o seguinte FQDN:
sip.pstnhub.gov.teams.microsoft.us – FQDN Global. Como o ambiente GCC High existe apenas nos datacenters dos EUA, não existem FQDNs secundários e terciários.
O FQDN sip.pstnhub.gov.teams.microsoft.us será resolvido para um endereço IP a partir da seguinte sub-rede:
- 52.127.88.0/21
Tem de abrir portas para todos estes intervalos de IP na firewall para permitir o tráfego de entrada e saída de e para os endereços para sinalização. Se a firewall suportar nomes DNS, o FQDN sip.pstnhub.gov.teams.microsoft.us é resolvido para todas estas sub-redes IP.
Sinalização SIP: Portas
Os requisitos de porta são os mesmos para todos os ambientes do Office 365 em que o Encaminhamento Direto é oferecido:
- Microsoft 365 ou Office 365
- Office 365 GCC
- Office 365 GCC High
- Office 365 DoD
Tem de utilizar as seguintes portas:
| Tráfego | De | Até | Porta de origem | Porta de destino |
|---|---|---|---|---|
| SIP/TLS | SIP Proxy | SBC | 1024 - 65535 | Definido no SBC |
| SIP/TLS | SBC | SIP Proxy | Definido no SBC | 5061 |
Tráfego de multimédia: intervalos de IP e porta
O tráfego de multimédia flui entre o cliente SBC e Teams se a conectividade direta estiver disponível ou através de Reencaminhamentos de Transporte do Teams se o cliente não conseguir aceder ao SBC com o endereço IP público.
Requisitos para o tráfego de multimédia direto (entre o cliente do Teams e o SBC)
O cliente tem de ter acesso às portas especificadas (ver tabela) no endereço IP público do SBC.
Nota
Se o cliente estiver numa rede interna, o suporte de dados flui para o endereço IP público do SBC. Pode configurar a afixação capilar no seu dispositivo NAT para que o tráfego nunca saia do equipamento de rede empresarial.
| Tráfego | De | Até | Porta de origem | Porta de destino |
|---|---|---|---|---|
| UDP/SRTP | Cliente | SBC | 50000-50019 | Definido no SBC |
| UDP/SRTP | SBC | Cliente | Definido no SBC | 50000-50019 |
Nota
Se tiver um dispositivo de rede que traduz as portas de origem do cliente, certifique-se de que as portas traduzidas estão abertas entre o equipamento de rede e o SBC.
Requisitos para utilizar Reencaminhamentos de Transporte
Os Reencaminhamentos de Transporte estão no mesmo intervalo que os Processadores de Multimédia (para casos sem ignorar):
Ambientes do Microsoft 365, Office 365 e GCC do Office 365
- 52.112.0.0 /14 (endereços IP de 52.112.0.1 a 52.115.255.254)
Ambiente do Office 365 GCC DoD
- 52.127.64.0/21
Ambiente do Office 365 GCC High
- 52.127.88.0/21
O intervalo de portas dos Reencaminhamentos de Transporte do Teams (aplicável a todos os ambientes) é apresentado na seguinte tabela:
| Tráfego | De | Até | Porta de origem | Porta de destino |
|---|---|---|---|---|
| UDP/SRTP | Reencaminhamento de Transporte | SBC | 50000-59999 | Definido no SBC |
| UDP/SRTP | SBC | Reencaminhamento de Transporte | Definido no SBC | 50000–59999, 3478-3481 |
Nota
A Microsoft recomenda pelo menos duas portas por chamada simultânea no SBC. Uma vez que a Microsoft tem duas versões de Transport Relays, são necessárias as seguintes:
v4, que só pode funcionar com o intervalo de portas 50000 a 59999
v6, que funciona com o intervalo de portas 3478 a 3481
Requisitos para utilizar processadores de multimédia
Os Processadores de Multimédia estão sempre no caminho de multimédia para aplicações de voz e para clientes Web (por exemplo, clientes do Teams no Microsoft Edge ou Google Chrome). Os requisitos são os mesmos que para a configuração sem ignorar.
O intervalo de IP para o tráfego de multimédia é:
Ambientes do Office 365 e do Office 365 GCC
- 52.112.0.0 /14 (endereços IP de 52.112.0.1 a 52.115.255.254)
Ambiente do Office 365 GCC DoD
- 52.127.64.0/21
Ambiente do Office 365 GCC High
- 52.127.88.0/21
O intervalo de portas dos Processadores de Multimédia (aplicável a todos os ambientes) é apresentado na tabela seguinte:
| Tráfego | De | Até | Porta de origem | Porta de destino |
|---|---|---|---|---|
| UDP/SRTP | Processador de Multimédia | SBC | 3478-3481 e 49152–53247 | Definido no SBC |
| UDP/SRTP | SBC | Processador de Multimédia | Definido no SBC | 3478-3481 e 49152–53247 |
Configurar ramais separados para ignorar suportes de dados e ignorar não suportes de dados
Se estiver a migrar para o suporte de dados desativar o bypass não multimédia e quiser confirmar a funcionalidade antes de migrar toda a utilização para o media bypass, pode criar um ramal separado e separar a política de Encaminhamento de Voz Online para encaminhar para o suporte de dados ignorar o ramal e atribuir a utilizadores específicos.
Passos de configuração de alto nível:
Identifique os utilizadores para testar o bypass de multimédia.
Crie dois ramais separados com FQDNs diferentes: um ativado para ignorar suportes de dados; o outro não.
Ambos os troncos apontam para o mesmo SBC. As portas para sinalização SIP TLS têm de ser diferentes. As portas para suportes de dados têm de ser as mesmas.
Crie uma nova política de Encaminhamento de Voz Online e atribua o ramal de bypass do suporte de dados às rotas correspondentes associadas à utilização rtPC para esta política.
Atribua a nova política de Encaminhamento de Voz Online aos utilizadores que identificou para testar o bypass de multimédia.
O exemplo seguinte ilustra esta lógica.
| Conjunto de utilizadores | Número de utilizadores | FQDN de Ramal atribuído no OVRP | Desativação de multimédia ativada |
|---|---|---|---|
| Utilizadores com ramal de desativação não multimédia | 980 | sbc1.contoso.com:5061 | falso |
| Utilizadores com ramal de desaprovisionar multimédia | 20 | sbc2.contoso.com:5060 | verdadeiro |
Ambos os ramais podem apontar para o mesmo SBC com o mesmo endereço IP público. As portas de sinalização TLS no SBC têm de ser diferentes, conforme mostrado no diagrama seguinte. Tenha em atenção que terá de se certificar de que o certificado suporta ambos os ramais. No SAN, tem de ter dois nomes (sbc1.contoso.com e sbc2.contoso.com) ou ter um certificado de caráter universal.
Para obter informações sobre como configurar dois ramais no mesmo SBC, veja a documentação fornecida pelo fornecedor SBC:
- Documentação de implementação do AudioCodes
- Documentação de implementação do Oracle
- Documentação de implementação de Comunicações do Friso
- Documentação de implementação do TE-Systems (anynode)
Pontos finais de cliente suportados com o bypass de multimédia
O bypass de multimédia é suportado com todos os clientes autónomos do Teams Desktop, clientes Android e iOS e Dispositivos Telefónicos do Teams.
Para todos os outros pontos finais que não suportam o bypass de multimédia, vamos converter a chamada para não ignorar, mesmo que tenha sido iniciada como uma chamada de ignorar. Esta conversão ocorre automaticamente e não requer ações do administrador. Isto inclui Telefones 3PIP do Skype para Empresas e Clientes Web do Teams que suportam chamadas de Encaminhamento Direto (clientes baseados em WebRTC em execução no Microsoft Edge, Google Chrome, Mozilla Firefox).
Confira também
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários