Requisitos da infraestrutura de roteamento direto do Azure

Importante

A funcionalidade descrita neste documento está em versão prévia pública. Essa versão prévia é fornecida sem contrato de nível de serviço e não é recomendada para cargas de trabalho de produção. Alguns recursos podem não ter suporte ou podem ter restrição de recursos. Para obter mais informações, consulte Termos de Uso Complementares de Versões Prévias do Microsoft Azure.

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 conectada ao SBC funcionará. (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 dos 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 Um FQDN para o SBC, em que a parte do domínio do FQDN não corresponde aos domínios registrados na sua organização do Microsoft 365 ou do Office 365. Para obter mais informações, confira Nomes de domínio do SBC.
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 Certificado confiável público para o SBC.
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.

Nomes de domínio do SBC

Os clientes sem o Office 365 podem usar qualquer nome de domínio para o qual possam obter um certificado público.

A seguinte tabela mostra exemplos de nomes DNS registrados para o locatário, se o nome pode ser usado como um FQDN (nome de domínio totalmente qualificado) para o SBC e exemplos de nomes de FQDN válidos:

Nome DNS Pode ser usado para o FQDN de SBC Exemplos de nomes FQDN
contoso.com Yes Nomes válidos:
sbc1.contoso.com
ssbcs15.contoso.com
europe.contoso.com
contoso.onmicrosoft.com No Não há suporte para o uso de domínios *.onmicrosoft.com para nomes de SBC

Se você for um cliente do Office 365, o nome de domínio SBC não precisará corresponder ao registrado nos domínios do locatário do Office 365. Veja abaixo o exemplo da coexistência do Office 365 e do Serviço de Comunicação do Azure:

Domínio registrado no Office 365 Exemplos de um FQDN de SBC no Teams Exemplos de nomes FQDN de SBC em Serviços de Comunicação do Azure
contoso.com (domínio de segundo nível) sbc.contoso.com (nome no domínio de segundo nível) sbc.acs.contoso.com (nome no domínio de terceiro nível)
sbc.fabrikam.com (qualquer nome em um domínio diferente)
o365.contoso.com (domínio de terceiro nível) sbc.o365.contoso.com (nome no domínio de terceiro nível) sbc.contoso.com (nome no domínio de segundo nível)
sbc.acs.o365.contoso.com (nome no domínio de quarto nível)
sbc.fabrikam.com (qualquer nome em um domínio diferente)

O emparelhamento de SBC funciona no nível de recurso dos Serviços de Comunicação, o que significa que você pode emparelhar muitos SBCs com um só recurso do Serviços de Comunicação, mas não pode emparelhar um 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.

Certificado público confiável para o SBC

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. Tenha isso em mente ao gerar o 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 sobre TLS do RFC padrão.

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.

O certificado precisa ser gerado por uma das seguintes autoridades de certificação raiz:

  • AffirmTrust
  • AddTrust External CA Root
  • Baltimore CyberTrust Root*
  • Buypass
  • Cybertrust
  • Class 3 Public Primary Certification Authority
  • Comodo Secure Root CA
  • Deutsche Telekom
  • DigiCert Global Root CA
  • DigiCert High Assurance EV Root CA
  • Entrust
  • GlobalSign
  • Go Daddy
  • GeoTrust
  • Verisign, Inc.
  • SSL.com
  • Starfield
  • Symantec Enterprise Mobile Root for Microsoft
  • SwissSign
  • Thawte Timestamping CA
  • Trustwave
  • TeliaSonera
  • T-Systems International GmbH (Deutsche Telekom)
  • QuoVadis
  • Autoridade de Certificação USERTrust RSA
  • AC Raiz 1, 2, 3 postagem Hongkong
  • AC Raiz Sectigo

A Microsoft está trabalhando para adicionar outras autoridades de certificação com base nas solicitações do cliente.

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.

É necessário colocar esses três FQDNs em ordem 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 abaixo.

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.1 to 52.115.255.254)
  • 52.120.0.0/14 (IP addresses from 52.120.0.1 to 52.123.255.254)

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. Se o firewall der suporte a nomes DNS, o FQDN sip-all.pstnhub.microsoft.com será resolvido para todos esses endereços IP.

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 (Para GCC High/DoD do Office 365, somente a porta 5061 precisa ser usada)
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, caso os datacenters em duas regiões não estejam 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: intervalos de porta e IP

O tráfego de mídia flui entre um serviço separado denominado Processador de Mídia. No momento da publicação, o Processador de Mídia para Serviços de Comunicação pode usar qualquer endereço IP do Azure. Baixe a lista completa de endereços.

Intervalo de portas

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 3478-3481 e 49152 – 53247 Definido no SBC
UDP/SRTP SBC Processador de mídia Definido no SBC 3478-3481 e 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

O tráfego de mídia flui por meio de componentes denominados processadores de mídia. Os processadores de mídia são colocados nos mesmos datacenters que os proxies SIP. Além disso, há processadores de mídia adicionais para otimizar o fluxo de mídia. Por exemplo, não temos no momento um componente de proxy SIP na Austrália (o SIP flui via Singapura ou RAE de Hong Kong), mas temos o processador de mídia localmente na Austrália. A necessidade dos processadores de mídia localmente é determinada pela latência que experimentamos ao enviar o tráfego para longas distâncias, por exemplo, da Austrália para Singapura ou para a RAE de Hong Kong. Embora a latência no exemplo de tráfego que flui da Austrália para Singapura ou para a RAE de Hong Kong seja aceitável para preservar a boa qualidade da chamada no tráfego SIP, no tráfego de mídia em tempo real ela não é.

Locais em que os componentes de proxy SIP e processador de mídia estão implantados:

  • EUA (dois nos datacenters das regiões Oeste dos EUA e Leste dos EUA)
  • Europa (datacenters de Amsterdã e Dublin)
  • Ásia (datacenters de Singapura e da RAE de Hong Kong)
  • Austrália (datacenters das regiões Leste e Sudeste da Austrália)

Locais em que apenas os processadores de mídia são implantados (o SIP flui por meio do datacenter mais próximo listado acima):

  • Japão (datacenters das regiões Leste e Oeste do Japão)

Tráfego de mídia: codecs

Segmento entre o SBC e o Processador de Mídia na nuvem ou o cliente do Microsoft Teams.

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. A Microsoft está trabalhando para adicionar mais codecs nesse segmento.

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

Próximas etapas

Documentação conceitual

Inícios rápidos