Requisiti dell'infrastruttura dell'instradamento diretto di Azure

  • Articolo

Questo articolo descrive i dettagli di connettività SBC (Infrastructure, Licensing e Session Border Controller) che si vuole tenere presente come pianificare la distribuzione del routing diretto di Azure.

Requisiti dell'infrastruttura

I requisiti dell'infrastruttura per gli SBC, i domini e altri requisiti di connettività di rete supportati per distribuire il routing diretto di Azure sono elencati nella tabella seguente:

Requisito dell'infrastruttura Sono necessari gli elementi seguenti
Session Border Controller (SBC) SBC supportato. Per altre informazioni, vedere SBC supportati.
Trunk di telefonia connessi al SBC Uno o più trunk di telefonia connessi al SBC. In un'unica estremità, il SBC si connette al servizio di comunicazione di Azure tramite routing diretto. Il SBC può anche connettersi a entità di telefonia di terze parti, ad esempio PBX, adattatori di telefonia analogica. Qualsiasi opzione di connettività PSTN (Public Switched Telephoney Network) connessa al SBC funziona. Per la configurazione dei trunk PSTN al SBC, fare riferimento ai fornitori SBC o ai provider trunk.
Sottoscrizione di Azure Una sottoscrizione di Azure usata per creare una risorsa di Servizi di comunicazione e la configurazione e la connessione al SBC.
Token di accesso di Servizi di comunicazione Per effettuare chiamate, è necessario un token di accesso valido con voip ambito. Vedere Token di accesso
Indirizzo IP pubblico per SBC Indirizzo IP pubblico che può essere usato per connettersi al SBC. In base al tipo di SBC, il SBC può usare NAT.
Nome di dominio completo (FQDN) per SBC Per altre informazioni, vedere Certificati SBC e nomi di dominio.
Voce DNS pubblica per SBC Voce DNS pubblica che esegue il mapping dell'FQDN SBC all'indirizzo IP pubblico.
Certificato attendibile pubblico per SBC Certificato per il SBC da usare per tutte le comunicazioni con il routing diretto di Azure. Per altre informazioni, vedere Certificati SBC e nomi di dominio.
Indirizzi IP e porte del firewall per la segnalazione SIP e i supporti Il SBC comunica con i servizi seguenti nel cloud:

Proxy SIP, che gestisce la segnalazione
Processore di supporti, che gestisce i supporti

Questi due servizi hanno indirizzi IP separati in Microsoft Cloud, descritti più avanti in questo documento.

Certificati E nomi di dominio SBC

Microsoft consiglia di richiedere il certificato per il SBC tramite una richiesta di firma di certificazione (CSR). Per istruzioni specifiche su come generare una richiesta di firma del certificato per un SBC, vedere le istruzioni di interconnessione o la documentazione fornita dai fornitori di SBC.

Nota

La maggior parte delle autorità di certificazione (CA) richiede che le dimensioni della chiave privata siano almeno 2048. Tenere presente questo aspetto quando si genera la richiesta di firma del certificato.

Il certificato deve avere il nome FQDN SBC come nome comune (CN) o il campo nome alternativo soggetto (SAN). Il certificato deve essere emesso direttamente da un'autorità di certificazione, non da un provider intermedio.

In alternativa, il routing diretto di Servizi di comunicazione supporta un carattere jolly nel cn e/o san e il carattere jolly deve essere conforme allo standard RFC HTTP su TLS.

I clienti che usano già Office 365 e hanno un dominio registrato in Amministrazione Microsoft 365 Center possono usare il nome di dominio completo SBC dallo stesso dominio.

Un esempio è l'uso *.contoso.comdi , che corrisponde all'FQDN sbc.contoso.comSBC, ma non corrisponde a sbc.test.contoso.com.

Nota

L'FQDN SBC in Servizi di comunicazione di Azure routing diretto deve essere diverso dal nome di dominio completo SBC nell'instradamento diretto di Teams.

Servizi di comunicazione considera attendibili solo i certificati firmati dalle autorità di certificazione (CA) che fanno parte del Programma di certificati radice attendibile Microsoft. Assicurarsi che il certificato SBC sia firmato da una CA che fa parte del programma e che l'estensione EKU (Extended Key Usage) del certificato includa l'autenticazione server. Altre informazioni:

Requisiti del programma - Programma radice attendibile Microsoft

Elenco di certificati CA incluso

Importante

Servizi di comunicazione di Azure routing diretto supporta solo TLS 1.2. Per evitare alcun impatto sul servizio, assicurarsi che gli SBC siano configurati per supportare TLS1.2 e possano connettersi usando uno dei pacchetti di crittografia seguenti per la segnalazione SIP:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, ad esempio ECDHE-RSA-AES256-GCM-SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, ad esempio ECDHE-RSA-AES128-GCM-SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, ad esempio ECDHE-RSA-AES256-SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, ad esempio ECDHE-RSA-AES128-SHA256

Per i supporti SRTP è supportato solo AES_CM_128_HMAC_SHA1_80.

L'associazione SBC funziona a livello di risorsa di Servizi di comunicazione. Ciò significa che è possibile associare molti SBC a una singola risorsa di Servizi di comunicazione. Tuttavia, non è possibile associare un singolo SBC a più di una risorsa di Servizi di comunicazione. Gli FQDN SBC univoci sono necessari per l'associazione a risorse diverse.

Se il supporto di MUTUAL TLS (MTLS) è abilitato per la connessione di routing diretto nel SBC, è necessario installare i certificati Baltimore CyberTrust Root e DigiCert Global Root G2 nell'archivio radice attendibile SBC del contesto TLS di routing diretto. Poiché i certificati del servizio Microsoft usano uno di questi due certificati radice. Per scaricare questi certificati radice, vedere Catene di crittografia di Office 365. Per altre informazioni, vedere Modifiche al certificato TLS di Office.

Segnalazione SIP: FQDN

I punti di connessione per il routing diretto di Servizi di comunicazione sono i tre nomi di dominio completi seguenti:

  • sip.pstnhub.microsoft.com - FQDN globale - deve essere provato per primo. Quando il SBC invia una richiesta per risolvere questo nome, i server DNS di Microsoft Azure restituiscono un indirizzo IP che punta al data center di Azure primario assegnato al SBC. L'assegnazione si basa sulle metriche delle prestazioni dei data center e sulla prossimità geografica al SBC. L'indirizzo IP restituito corrisponde al nome di dominio completo primario.
  • sip2.pstnhub.microsoft.com - FQDN secondario - mappa geograficamente alla seconda area prioritaria.
  • sip3.pstnhub.microsoft.com — FQDN terziario — mappa geograficamente alla terza area prioritaria.

Questi tre FQDN sono necessari per:

  • Offrire un'esperienza ottimale (meno caricata e più vicina al data center SBC assegnato eseguendo una query sul primo FQDN).
  • Fornire il failover quando viene stabilita la connessione da un SBC a un data center che riscontra un problema temporaneo. Per altre informazioni, vedere Meccanismo di failover.

I nomi di dominio completi ( sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com e sip3.pstnhub.microsoft.com ) risolvono in uno degli indirizzi IP seguenti:

  • 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)

Aprire le porte del firewall per tutti questi intervalli di indirizzi IP per consentire il traffico in ingresso e in uscita da e verso gli indirizzi per la segnalazione.

Segnalazione SIP: porte

Usare le porte seguenti per il routing diretto di Servizi di comunicazione di Azure:

Traffico Da Per Porta di origine Porta di destinazione
SIP/TLS SIP Proxy SBC 1024–65535 Definito nel SBC
SIP/TLS SBC SIP Proxy Definito nel SBC 5061

Meccanismo di failover per la segnalazione SIP

SBC esegue una query DNS per risolvere sip.pstnhub.microsoft.com. In base alla posizione SBC e alle metriche delle prestazioni del data center, viene selezionato il data center primario. Se il data center primario riscontra un problema, il SBC prova l'sip2.pstnhub.microsoft.com, che si risolve nel secondo data center assegnato e, nel raro caso in cui i data center in due aree non siano disponibili, il SBC ritenta l'ultimo FQDN (sip3.pstnhub.microsoft.com), che fornisce l'IP del data center terziario.

Traffico multimediale: intervalli ip e porte

Il traffico multimediale passa da e verso un servizio separato denominato Processore di contenuti multimediali. Gli intervalli di indirizzi IP per il traffico multimediale sono gli stessi per la segnalazione:

  • 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)

Intervalli porte

Gli intervalli di porte dei processori multimediali sono illustrati nella tabella seguente:

Traffico Da Per Porta di origine Porta di destinazione
UDP/SRTP Processore multimediale SBC 49152–53247 Definito nel SBC
UDP/SRTP SBC Processore multimediale Definito nel SBC 49152–53247

Nota

Microsoft consiglia almeno due porte per ogni chiamata simultanea sul SBC.

Traffico multimediale: area geografica processori multimediali

I processori multimediali vengono posizionati negli stessi data center dei proxy SIP:

  • NOAM (Stati Uniti centro-meridionali, due nei data center stati Uniti occidentali e Stati Uniti orientali)
  • Europa (UE occidentale, UE settentrionale, Svezia, Francia centrale)
  • Asia (data center singapore)
  • Giappone (data center JP orientali e occidentali)
  • Australia (data center orientali e sud-orientali)
  • LATAM (Brasile meridionale)
  • Africa (Sudafrica settentrionale)

Traffico multimediale: codec

Gamba tra SBC e Cloud Media Processor.

L'interfaccia di routing diretto di Azure tra Session Border Controller e Cloud Media Processor può usare i codec seguenti:

  • SILK, G.711, G.722, G.729

È possibile forzare l'uso del codec specifico nel Session Border Controller escludendo i codec indesiderati dall'offerta.

Leg between Communication Services Calling SDK app and Cloud Media Processor

Nella fase tra l'app Cloud Media Processor e Communication Services Calling SDK viene usata la versione G.722. È in corso l'aggiunta di altri codec su questa gamba.

SBC (Session Border Controller) supportati

Passaggi successivi

Documentazione concettuale

Avvi rapidi