Partilhar via

Requisitos da infraestrutura do encaminhamento direto do Azure

  • Artigo

Este artigo descreve os detalhes de infraestrutura, licenciamento e conectividade do Controlador de Borda de Sessão (SBC) que você deseja ter em mente ao planejar sua implantação de roteamento direto do Azure.

Requisitos de infraestrutura

Os requisitos de infraestrutura para os SBCs, domínios e outros requisitos de conectividade de rede suportados para implantar o roteamento direto do Azure estão listados na tabela a seguir:

Requisitos de infraestrutura Você precisa do seguinte
Controlador de borda de sessão (SBC) Um SBC suportado. Para obter mais informações, consulte SBCs suportados.
Troncos de telefonia conectados ao SBC Um ou mais troncos de telefonia conectados ao SBC. Em uma extremidade, o SBC se conecta ao Serviço de Comunicação do Azure por meio de roteamento direto. O SBC também pode se conectar a entidades de telefonia de terceiros, como PBXs, adaptadores de telefonia analógica. Qualquer opção de conectividade PSTN (Public Switched Telephony Network) conectada ao SBC funciona. (Para a configuração dos troncos PSTN para o SBC, consulte os fornecedores de SBC ou provedores de tronco.)
Subscrição do Azure Uma assinatura do Azure que você usa para criar o recurso Serviços de Comunicação e a configuração e conexão com o SBC.
Token de acesso aos serviços de comunicação Para fazer chamadas, você precisa de um token de acesso válido com voip escopo. Ver Tokens de Acesso
Endereço IP público do SBC Um endereço IP público que pode ser usado para se conectar ao SBC. Com base no tipo de SBC, o SBC pode usar NAT.
FQDN (nome de domínio totalmente qualificado) para o SBC Para obter mais informações, consulte Certificados SBC e nomes de domínio.
Entrada DNS pública para o SBC Uma entrada DNS pública mapeando o FQDN SBC para o endereço IP público.
Certificado público confiável para o SBC Um certificado para o SBC a ser usado para toda a comunicação com o roteamento direto do Azure. Para obter mais informações, consulte Certificados SBC e nomes de domínio.
Endereços IP e portas de firewall para sinalização SIP e mídia O SBC comunica com os seguintes serviços na nuvem:

Proxy SIP, que lida com a sinalização
Processador de mídia, que lida com mídia

Esses dois serviços têm endereços IP separados no Microsoft Cloud, descritos posteriormente neste documento.

Certificados SBC e nomes de domínio

A Microsoft recomenda que você solicite o certificado para o SBC por uma solicitação de assinatura de certificação (CSR). Para obter instruções específicas sobre como gerar um CSR para um SBC, consulte as instruções de interconexão ou a documentação fornecida pelos fornecedores de SBC.

Nota

A maioria das Autoridades de Certificação (CAs) exige que o tamanho da chave privada seja pelo menos 2048. Tenha isso em mente ao gerar o CSR.

O certificado deve ter o FQDN do SBC como o campo CN (nome comum) ou SAN (nome alternativo da entidade). O certificado deve ser emitido diretamente por uma autoridade de certificação e não por um fornecedor intermediário.

Como alternativa, o roteamento direto dos Serviços de Comunicação oferece suporte a um curinga no CN e/ou SAN, e o curinga deve estar em conformidade com o padrão RFC HTTP Over TLS.

Os clientes que já usam o Office 365 e têm um domínio registrado no Centro de Administração do Microsoft 365 podem usar o FQDN do SBC do mesmo domínio.

Um exemplo seria usar *.contoso.com, que corresponderia ao FQDN sbc.contoso.comdo SBC, mas não corresponderia ao sbc.test.contoso.com.

Nota

O FQDN SBC no roteamento direto dos Serviços de Comunicação do Azure deve ser diferente do FQDN do SBC no Roteamento Direto do Teams.

Os Serviços de Comunicação só confiam em certificados assinados por Autoridades de Certificação (CAs) que fazem parte do Programa de Certificados Raiz Confiáveis da Microsoft. Verifique se o certificado SBC está assinado por uma autoridade de certificação que faz parte do programa e se a extensão EKU (Uso Estendido de Chave) do certificado inclui a Autenticação do Servidor. Saiba mais:

Requisitos do programa — Microsoft Trusted Root Program

Lista de certificados de autoridade de certificação incluída

Importante

O roteamento direto dos Serviços de Comunicação do Azure dá suporte apenas ao TLS 1.2. Para evitar qualquer impacto no serviço, certifique-se de que seus SBCs estejam configurados para suportar TLS1.2 e possam se conectar usando um dos seguintes pacotes de codificação para sinalização SIP:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ou seja, ECDHE-RSA-AES256-GCM-SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ou seja, ECDHE-RSA-AES128-GCM-SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ou seja, ECDHE-RSA-AES256-SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ou seja, ECDHE-RSA-AES128-SHA256

Apenas para mídia SRTP AES_CM_128_HMAC_SHA1_80 é suportado.

O emparelhamento SBC funciona no nível de recursos dos Serviços de Comunicação. Isso significa que você pode emparelhar muitos SBCs em um único recurso de Serviços de Comunicação. Ainda assim, não é possível emparelhar um único SBC a mais de um recurso dos Serviços de Comunicação. FQDNs SBC exclusivos são necessários para emparelhamento com recursos diferentes.

Se o suporte a TLS mútuo (MTLS) estiver habilitado para a conexão de roteamento direto no SBC, você deverá instalar os certificados Baltimore CyberTrust Root e DigiCert Global Root G2 no SBC Trusted Root Store do contexto TLS de roteamento direto. (Isso ocorre porque os certificados de serviço da Microsoft usam um desses dois certificados raiz.) Para baixar esses certificados raiz, consulte Cadeias de criptografia do Office 365. Para obter mais informações, consulte Alterações no certificado TLS do Office.

Sinalização SIP: FQDNs

Os pontos de conexão para roteamento direto dos Serviços de Comunicação são os três FQDNs a seguir:

  • sip.pstnhub.microsoft.com — Global FQDN — deve ser julgado primeiro. Quando o SBC envia uma solicitação para resolver esse nome, os servidores DNS do Microsoft Azure retornam um endereço IP que aponta para o datacenter primário do Azure atribuído ao SBC. A atribuição é baseada em métricas de desempenho dos datacenters e proximidade geográfica com o SBC. O endereço IP retornado corresponde ao FQDN primário.
  • sip2.pstnhub.microsoft.com — FQDN secundário — mapeia geograficamente a segunda região prioritária.
  • sip3.pstnhub.microsoft.com — FQDN terciário — traça geograficamente a terceira região prioritária.

Estes três FQDNs são necessários para:

  • Forneça uma experiência ideal (menos carregado e mais próximo do datacenter SBC atribuído consultando o primeiro FQDN).
  • Forneça failover quando a conexão de um SBC for estabelecida com um datacenter que esteja enfrentando um problema temporário. Para obter mais informações, consulte Mecanismo de failover.

Os FQDNs — sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com e sip3.pstnhub.microsoft.com — resolvem para um dos seguintes endereços IP:

  • 52.112.0.0/14 (IP addresses from 52.112.0.0 to 52.115.255.255)
  • 52.120.0.0/14 (IP addresses from 52.120.0.0 to 52.123.255.255)

Abra portas de firewall para todos esses intervalos de endereços IP para permitir o tráfego de entrada e saída de e para os endereços para sinalização.

Sinalização SIP: Portas

Use as seguintes portas para o roteamento direto do Azure dos Serviços de Comunicação:

Trânsito De Para 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

Mecanismo de failover para sinalização SIP

O SBC faz uma consulta DNS para resolver sip.pstnhub.microsoft.com. Com base no local do SBC e nas métricas de desempenho do datacenter, o datacenter principal é selecionado. Se o datacenter primário tiver um problema, o SBC tentará o sip2.pstnhub.microsoft.com, que será resolvido para o segundo datacenter atribuído e, no caso raro de datacenters em duas regiões não estarem disponíveis, o SBC tentará novamente o último FQDN (sip3.pstnhub.microsoft.com), que fornece o IP do datacenter terciário.

Tráfego de mídia: IP e intervalos de portas

O tráfego de mídia flui de e para um serviço separado chamado Media Processor. Os intervalos de endereços IP para tráfego de mídia são os mesmos que para sinalização:

  • 52.112.0.0/14 (IP addresses from 52.112.0.0 to 52.115.255.255)
  • 52.120.0.0/14 (IP addresses from 52.120.0.0 to 52.123.255.255)

Intervalos de portas

Os intervalos de portas dos processadores de mídia são mostrados na tabela a seguir:

Trânsito De Para Porta de origem Porta de destino
UDP/SRTP Processador de mídia SBC 49152–53247 Definido no SBC
UDP/SRTP SBC Processador de mídia Definido no SBC 49152–53247

Nota

A Microsoft recomenda pelo menos duas portas por chamada simultânea no SBC.

Tráfego de mídia: geografia dos processadores de mídia

Os processadores de mídia são colocados nos mesmos datacenters que os proxies SIP:

  • NOAM (US South Central, dois em datacenters Oeste e Leste dos EUA)
  • Europa (UE Oeste, UE Norte, Suécia, França Central)
  • Ásia (datacenter de Singapura)
  • Japão (centros de dados JP Leste e Oeste)
  • Austrália (datacenters Leste e Sudeste da UA)
  • LATAM (Sul do Brasil)
  • África (África do Sul Norte)

Tráfego de mídia: Codecs

Perna entre SBC e Cloud Media Processor.

A interface de roteamento direto do Azure na perna entre o Controlador de Borda de Sessão e o Processador de Mídia em Nuvem pode usar os seguintes codecs:

  • SEDA, G.711, G.722, G.729

Você pode forçar o uso do codec específico no Controlador de Borda de Sessão excluindo codecs indesejáveis da oferta.

Perna entre o aplicativo SDK de chamada dos Serviços de Comunicação e o processador de mídia na nuvem

Na perna entre o Cloud Media Processor e o aplicativo SDK de Chamada de Serviços de Comunicação, o G.722 é usado. O trabalho para adicionar mais codecs nesta etapa está em andamento.

Controladores de borda de sessão (SBCs) suportados

Próximos passos

Documentação conceptual

Guias de Início Rápido