Requisitos de infraestrutura de roteamento direto do Azure

  • Artigo

Este artigo descreve os detalhes de infraestrutura, licenciamento e conectividade SBC (Controlador de Borda de Sessão) que você deverá ter em mente como seu plano de implantação de roteamento direto do Azure.

Requisitos de infraestrutura

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

Requisito de infraestrutura Você precisará do seguinte
SBC (controlador de borda de sessão) Um SBC com suporte. Para obter mais informações, confira SBCs compatíveis.
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 via roteamento direto. O SBC também pode se conectar a entidades de telefonia de terceiros, como PBXs, Adaptadores de Telefonia Analógica e assim por diante. Qualquer opção de conectividade PSTN (Rede Pública de Telefonia Comutada) conectada ao SBC funciona. (Para obter a configuração dos troncos PSTN para o SBC, veja os fornecedores de SBC ou os provedores de troncos.)
Assinatura 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 dos Serviços de Comunicação Para fazer chamadas, você precisa de um Token de Acesso válido com o escopo voip. Confira Tokens de Acesso
Endereço IP público para o 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, confira Certificados SBC e nomes de domínio.
Entrada DNS pública para o SBC Uma entrada DNS pública que mapeia o FQDN de 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, confira Certificados SBC e nomes de domínio.
Portas e endereços IP de firewall para sinalização e mídia SIP O SBC se comunica com os seguintes serviços na nuvem:

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

Esses dois serviços têm endereços IP separados na nuvem da Microsoft, descritos mais adiante neste documento.

Certificados SBC e nomes de domínio

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

Observação

A maioria das CAs (autoridades de certificação) exige que o tamanho da chave privada seja pelo menos 2048. Lembre-se disso ao gerar a CSR.

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

Como alternativa, o roteamento direto dos Serviços de Comunicação dá suporte a um caractere curinga no CN e/ou na SAN, e o curinga precisa estar em conformidade com o HTTP por TLS do RFC padrão.

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

Um exemplo será usar *.contoso.com, que corresponderá ao FQDN de SBC sbc.contoso.com, mas não terá correspondência com sbc.test.contoso.com.

Observação

O roteamento direto do FQDN de SBC nos Serviços de Comunicação do Azure precisa ser diferente do roteamento direto do FQDN de SBC no Teams.

Os Serviços de Comunicação confiam apenas em certificados assinados por ACs (autoridades de certificação) que fazem parte do Programa de Certificado Raiz Confiável da Microsoft. Verifique se o certificado SBC é assinado por uma AC que faz parte do programa e se a extensão EKU (Uso Estendido de Chave) do seu certificado inclui a Autenticação do Servidor. Saiba mais:

Requisitos do programa – Programa raiz confiável da Microsoft

Lista de certificados de AC incluídos

Importante

O roteamento direto dos Serviços de Comunicação do Azure é compatível apenas com o TLS 1.2 (ou uma versão posterior). Para evitar qualquer impacto no serviço, verifique se os SBCs estão configurados para oferecer suporte a TLS1.2 e podem se conectar usando um dos seguintes conjuntos de codificação para sinalização SIP:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 i.e. ECDHE-RSA-AES256-GCM-SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 i.e. ECDHE-RSA-AES128-GCM-SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 i.e. ECDHE-RSA-AES256-SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 i.e. ECDHE-RSA-AES128-SHA256

Somente para mídia SRTP há suporte para AES_CM_128_HMAC_SHA1_80.

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

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 de certificado TLS do Office.

Sinalização SIP: FQDNs

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

  • sip.pstnhub.microsoft.com – FQDN global – precisa ser tentado 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 baseia-se nas métricas de desempenho dos datacenters e da proximidade geográfica com o SBC. O endereço IP retornado corresponde ao FQDN primário.
  • sip2.pstnhub.microsoft.com – FQDN secundário – faz o mapeamento geográfico para a segunda região prioritária.
  • sip3.pstnhub.microsoft.com – FQDN terciário – faz o mapeamento geográfico para a terceira região prioritária.

Esses três FQDNs, na ordem, são necessários para:

  • Fornecer uma experiência ideal (menos carregada e mais próxima do datacenter do SBC atribuído pela consulta do primeiro FQDN).
  • Fornecer failover quando a conexão de um SBC é estabelecida com um datacenter que está apresentando um problema temporário. Para obter mais informações, confira Mecanismo de failover.

Os FQDNs sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com e sip3.pstnhub.microsoft.com serão resolvidos 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 todas essas faixas de endereço IP para permitir o tráfego de entrada e saída entre 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áfego De Para Porta de origem Porta de destino
SIP/TLS Proxy SIP SBC 1024–65535 Definido no SBC
SIP/TLS SBC Proxy SIP Definido no SBC 5061

Mecanismo de failover para a sinalização SIP

O SBC faz uma consulta DNS para resolver sip.pstnhub.microsoft.com. Com base na localização do SBC e nas métricas de desempenho do datacenter, o datacenter primário é selecionado. Se o datacenter primário apresentar um problema, o SBC tentará sip2.pstnhub.microsoft.com, que resolve para o segundo datacenter atribuído e, se os datacenters em duas regiões não estiverem disponíveis (o que é raro), 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 entre um serviço separado denominado Processador de Mídia. Os intervalos de endereços IP para tráfego de mídia são os mesmos 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 porta

O intervalo de portas dos Processadores de Mídia é mostrado na seguinte tabela:

Tráfego 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

Observação

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 dos proxies SIP:

  • NOAM (data centers do Centro-Sul dos EUA, dois no Oeste dos EUA e Leste dos EUA)
  • Europa (UE Oeste, UE Norte, Suécia, França Central)
  • Ásia (datacenter de Cingapura)
  • Japão (datacenters das regiões Leste e Oeste do Japão)
  • Austrália (datacenters das regiões Leste e Sudeste da Austrália)
  • LATAM (Sul do Brasil)
  • África (Norte da África do Sul)

Tráfego de mídia: Codecs

Ligação entre o SBC e o processador de mídia em nuvem.

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

  • SILK, 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.

Segmento entre aplicativo SDK da Chamada dos Serviços de Comunicação e o Processador de Mídia de Nuvem

No segmento entre o Processador de Mídia de Nuvem e o aplicativo SDK da Chamada dos Serviços de Comunicação, o G.722 é usado. O trabalho de adicionar mais codecs neste segmento está em andamento.

SBCs (Controladores de Borda de Sessão) com suporte

Próximas etapas

Documentação conceitual

Inícios rápidos