Pianificare Instradamento diretto

Direct Routing consente di connettere un session border controller (SBC) supportato dal cliente a Microsoft Teams Phone. Con questa funzionalità, è possibile configurare la connettività PSTN (Public Switched Telephone Network) locale con Teams, come illustrato nel diagramma seguente:

Pianificare la distribuzione del routing diretto è fondamentale per un'implementazione corretta. Questo articolo descrive i requisiti di infrastruttura e licenze e fornisce informazioni sulla connettività SBC. Leggere questo articolo prima di avviare la configurazione, descritta in Configurare il routing diretto.

Con Direct Routing, puoi connettere il tuo SBC a quasi tutti i trunk di telefonia o interconnetterti con apparecchiature PSTN di terze parti. Direct Routing consente di:

• Usare praticamente qualsiasi trunk PSTN con Teams Phone.

• Configurare l'interoperabilità tra dispositivi di telefonia di proprietà dei clienti, ad esempio PBX (Private Branch Exchange) di terze parti, dispositivi analogici e Teams.

Microsoft offre anche soluzioni vocali all-in-the-cloud, come il piano per chiamate Microsoft. Tuttavia, il routing diretto potrebbe essere la soluzione migliore per l'organizzazione se:

• Il piano per chiamate Microsoft non è disponibile nel tuo paese/area geografica.

• L'organizzazione richiede la connessione a dispositivi analogici di terze parti, call center e così via.

• L'organizzazione ha un contratto esistente con un gestore PSTN.

Per altre informazioni sulle soluzioni vocali, vedere Pianificare la soluzione vocale di Teams.

Con l'instradamento diretto, quando gli utenti partecipano a una riunione pianificata, il numero di accesso esterno viene fornito dal servizio Di audioconferenza Microsoft, che richiede licenze appropriate. Durante la chiamata in uscita, l'audioconferenza effettua la chiamata con funzionalità di chiamata online, che richiedono una licenza appropriata. Se un utente non dispone di una licenza per i servizi di audioconferenza Microsoft, la chiamata viene instradata tramite Direct Routing. Per ulteriori informazioni, vedi Routing diretto con audioconferenza.

Direct Routing supporta anche gli utenti che hanno un'altra licenza per il piano per chiamate Microsoft. Per ulteriori informazioni, vedi Routing diretto con piano per chiamate e Operator Connect.

Requisiti dell'infrastruttura

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

Licenze e altri requisiti

Gli utenti di Direct Routing devono avere le licenze seguenti assegnate in Microsoft 365:

• Telefono di Teams
• Microsoft Teams

Per informazioni su quando è necessaria una licenza per i servizi di audioconferenza, consulta Routing diretto con audioconferenza.

Direct Routing supporta anche gli utenti con licenza per il piano per chiamate Microsoft. Per ulteriori informazioni, vedi Routing diretto con piano per chiamate e Operator Connect.

Per altre informazioni sulle licenze, vedere Licenze di Microsoft Teams e Licenze per i componenti aggiuntivi di Microsoft Teams.

Nota: il routing diretto non è supportato in modalità Isole.

Routing diretto con audioconferenza

In questa sezione vengono descritti i requisiti e le considerazioni da considerare quando si utilizza l'instradamento diretto e le audioconferenze.

• Per gli utenti GCC High e DoD G5, Microsoft consiglia di disabilitare il componente Audioconferenza incluso in G5 fino a quando non configuri Direct Routing e di aggiungere i numeri di audioconferenza al tenant dell'organizzazione.

• Per gli utenti GCC High e DoD G3, Microsoft consiglia di non assegnare il componente aggiuntivo della licenza per i servizi di audioconferenza finché non configuri Direct Routing e non hai aggiunto numeri di audioconferenza al tenant dell'organizzazione.

Per ulteriori informazioni, vedi Audioconferenza con routing diretto per GCC High e DoD.

Escalation delle chiamate non pianificate e licenza per i servizi di audioconferenza

Un utente di Teams può avviare una chiamata Teams-a-PSTN o Teams-to-Teams uno-a-uno e aggiungervi un partecipante PSTN. Il percorso della chiamata dipende dal fatto che all'utente che effettua l'escalation della chiamata sia assegnata o meno una licenza per i servizi di audioconferenza Microsoft:

• Se all'utente di Teams che effettua l'escalation della chiamata è assegnata una licenza per i servizi di audioconferenza Microsoft, l'escalation avviene tramite il servizio Di audioconferenza Microsoft. Il partecipante PSTN remoto invitato alla chiamata esistente riceve una notifica sulla chiamata in arrivo e vede il numero del bridge Microsoft assegnato all'utente di Teams che ha avviato l'escalation.

• Se all'utente di Teams che effettua l'escalation della chiamata non è assegnata la licenza Per i servizi di audioconferenza Microsoft, l'escalation avviene tramite un controller dei confini della sessione connesso all'interfaccia routing diretto. Il partecipante PSTN remoto invitato alla chiamata riceve una notifica sulla chiamata in arrivo e vede il numero dell'utente di Teams che ha avviato l'escalation. La SBC specifica utilizzata per l'escalation è definita dal criterio di routing dell'utente.

È necessario verificare quanto segue:

• CsOnlineVoiceRoutingPolicy viene assegnato all'utente.

• Consenti chiamate private è abilitato a livello di tenant per Microsoft Teams.

Routing diretto con Piani per chiamate e Operator Connect

Il routing diretto supporta anche gli utenti con licenza per il piano per chiamate Microsoft o a cui è assegnato un numero di telefono Operator Connect. Gli utenti di Teams Phone con piano per chiamate o Operator Connect possono instradare alcune chiamate usando l'interfaccia Routing diretto.

La combinazione di piani per chiamate o connessione operatore e connettività per l'instradamento diretto per lo stesso utente è facoltativa, ma potrebbe essere utile. Ad esempio, quando all'utente viene assegnato un piano per chiamate Microsoft o un numero Operator Connect ma vuole instradare alcune chiamate tramite SBC.

Uno degli scenari più comuni sono le chiamate a PBX di terze parti. Con questa configurazione, le chiamate ai telefoni connessi al PBX di terze parti vengono instradate tramite Direct Routing e quindi rimangono all'interno della rete aziendale, non attraverso il PSTN. Nel frattempo, tutte le altre chiamate vengono instradate al PSTN in base al metodo di connettività PSTN assegnato agli utenti: Piano per chiamate Microsoft o Operator Connect.

Per altre informazioni sulle licenze di Teams Phone, vedere Licenze per i componenti aggiuntivi di Microsoft Teams.

Endpoint supportati

Come punto finale, è possibile utilizzare quanto segue:

• Qualsiasi client di Teams.

• Telefoni ad area comune. Non è necessaria una licenza per il piano per chiamate durante la configurazione di un telefono dell'area comune con Routing diretto. Per altre informazioni, vedere Configurare i telefoni dell'area comune per Microsoft Teams.

Nomi di dominio SBC

Il nome di dominio SBC deve provenire da uno dei nomi registrati in Domini del tenant.

La tabella seguente mostra esempi di nomi DNS registrati per il tenant, se il nome può essere usato come FQDN per SBC ed esempi di nomi FQDN validi. Si noti che non è possibile usare il tenant *.onmicrosoft.com per il nome FQDN di SBC.

Si supponga di voler usare un nuovo nome di dominio. Ad esempio, il tenant ha contoso.com come nome di dominio registrato nel tenant e si vuole usare sbc1.sip.contoso.com.

Prima di associare un'associazione SBC al nome sbc1.sip.contoso.com, è necessario registrare il nome di dominio sip.contoso.com in Domini nel tenant. Se si prova ad associare un dominio SBC a sbc1.sip.contoso.com prima di registrare il nome di dominio, viene visualizzato l'errore seguente: "Non è possibile usare il dominio "sbc1.sip.contoso.com" perché non è stato configurato per il tenant.

Dopo aver aggiunto il nome di dominio, è necessario creare un utente con UPN user@sip.contoso.com e assegnare una licenza di Teams. Il provisioning completo del nome di dominio dopo l'aggiunta ai domini del tenant, la creazione di un utente con un nuovo nome e l'assegnazione di una licenza all'utente possono richiedere fino a 24 ore.

È possibile che una società abbia diversi spazi di indirizzi SIP in un tenant. Ad esempio, una società potrebbe avere contoso.com come spazio di indirizzi SIP e fabrikam.com come secondo spazio di indirizzi SIP. Alcuni utenti hanno un indirizzo user@contoso.com e altri hanno l'indirizzo user@fabrikam.com.

SBC richiede un solo FQDN e può richiedere assistenza agli utenti da qualsiasi spazio di indirizzi nel tenant associato. Ad esempio, una SBC con il nome sbc1.contoso.com può ricevere e inviare il traffico PSTN per gli utenti con indirizzi user@contoso.com e user@fabrikam.com purché questi spazi di indirizzi SIP siano registrati nello stesso tenant.

Certificato pubblico attendibile per SBC

Microsoft consiglia di richiedere il certificato per SBC generando una richiesta di firma di certificazione (CSR). Per istruzioni specifiche sulla generazione di una CSR per una SBC, vedere le istruzioni di interconnessione o la documentazione fornita dai fornitori di SBC.

Il certificato deve avere l'FQDN SBC come nome comune (CN) o il campo SAN (Subject Alternative Name).

In alternativa, Direct Routing supporta un carattere jolly in CN e/o SAN e il carattere jolly deve essere conforme allo standard RFC HTTP Over TLS.

Un esempio potrebbe essere l'uso di *.contoso.com, che corrisponde al sbc.contoso.com FQDN SBC, ma non a sbc.test.contoso.com.

L'interfaccia SIP per il routing diretto considera attendibili solo i certificati firmati da autorità di certificazione (CA) che fanno parte del programma Microsoft Trusted Root Certificate. Assicurarsi che una CA che fa parte del programma apporti la firma del certificato SBC. Assicurarsi anche che l'estensione Utilizzo chiave estesa (EKU) del certificato includa l'autenticazione server e l'autenticazione client.

Per altre informazioni, vedere Requisiti del programma - Microsoft Trusted Root Program e Elenco certificati CA inclusi.

Per il routing diretto negli ambienti GCCH e DoD di Office 365, una delle autorità di certificazione radice seguenti deve generare il certificato:

• Ca radice globale DigiCert
• Ca radice EV High Assurance DigiCert

Per verificare che la connessione MTLS provenga dall'infrastruttura di Teams, sbc deve essere configurato per implementare i seguenti controlli sul certificato lato server di Teams:

• Verificare che la catena di rilascio dei certificati provenga da una delle ca radice seguenti:

  • Baltimore CyberTrust Root
  • DigiCert Global Root G2

• Verificare che il certificato "Nome alternativo oggetto" includa "sip.pstnhub.microsoft.com".

Segnalazione SIP: FQDN, porte, meccanismo di failover

Direct Routing è disponibile nei seguenti ambienti:

• Microsoft 365 o Office 365
• Office 365 GCC
• Office 365 GCC High
• Office 365 DoD

Per altre informazioni sugli ambienti governativi, ad esempio GCC, GCC High e DoD, vedere Ambienti Office 365 e US Government.

Le sezioni seguenti descrivono informazioni sui nomi di dominio completi, sulle porte e sui meccanismi di failover.

Segnalazione SIP: FQDN

Le sezioni seguenti descrivono i punti di connessione FQDN per vari ambienti cloud Microsoft.

Ambienti Microsoft 365, Office 365 e Office 365 GCC

In questi ambienti, i punti di connessione per il routing diretto sono i tre FQDN seguenti:

• sip.pstnhub.microsoft.com , fqdn globale, deve essere prima provata. Quando SBC invia una richiesta di risoluzione di questo nome, i server DNS di Microsoft Azure restituiscono un indirizzo IP che punta al data center di Azure primario assegnato alla chiave SBC. L'assegnazione si basa sulle metriche delle prestazioni dei data center e sulla prossimità geografica all'SBC. L'indirizzo IP restituito corrisponde all'FQDN primario.

• sip2.pstnhub.microsoft.com , FQDN secondario, mappa geograficamente alla seconda area di priorità.

• sip3.pstnhub.microsoft.com – FQDN fqdn fqdn : corrisponde geograficamente alla terza area di priorità.

L'inserimento di questi tre FQDN è necessario per:

• Offrire un'esperienza ottimale (meno carico e più vicino al data center SBC assegnato eseguendo una query sul primo FQDN).

• Fornire il failover quando viene stabilita la connessione da un server SBC a un data center in cui si verifica un problema temporaneo. Per ulteriori informazioni, vedere Meccanismo di failover.

Gli FQDN sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com e sip3.pstnhub.microsoft.com vengono risolti in indirizzi IP dalle subnet seguenti:

• 52.112.0.0/14
• 52.122.0.0/15

È necessario aprire le porte per tutti questi intervalli di indirizzi IP nel firewall per consentire il traffico in ingresso e in uscita da e verso gli indirizzi per la segnalazione.

Nota: il traffico SIP in ingresso verso gli SBC dagli endpoint SIP di Teams può provenire da qualsiasi IP in queste subnet, non solo dagli IP che si risolveno dagli FQDN menzionati in precedenza. Per altre informazioni su come configurare il peering SIP, vedere la documentazione di SBC.

Ambiente DoD GCC di Office

Nell'ambiente DoD GCC di Office il punto di connessione per il routing diretto è il seguente:

sip.pstnhub.dod.teams.microsoft.us : FQDN globale. Poiché l'ambiente DoD di Office 365 esiste solo nei data center degli Stati Uniti, non esiste alcun FQDN secondario e terziario.

Il sip.pstnhub.dod.teams.microsoft.us FQDN viene risolto in un indirizzo IP dalla subnet seguente: 52.127.64.0/21

Per consentire il traffico in ingresso e in uscita da e verso gli indirizzi per il traffico di segnalazione, è necessario aprire le porte per tutti questi indirizzi IP nel firewall.

Ambiente Office 365 GCC High

Nell'ambiente Office 365 GCC High il punto di connessione per routing diretto è il seguente:

sip.pstnhub.gov.teams.microsoft.us - FQDN globale. Poiché l'ambiente GCC High esiste solo nei data center degli Stati Uniti, non esiste alcun FQDN secondario e accessorio.

Il sip.pstnhub.gov.teams.microsoft.us FQDN viene risolto in un indirizzo IP dalla subnet seguente: 52.127.88.0/21

Per consentire il traffico in ingresso e in uscita da e verso gli indirizzi per il traffico di segnalazione, è necessario aprire le porte per tutti questi indirizzi IP nel firewall.

Segnalazione SIP: porte

È necessario usare le porte seguenti per gli ambienti Microsoft 365 o Office 365 in cui è disponibile il routing diretto:

Segnalazione SIP: meccanismo di failover

Per risolvere sip.pstnhub.microsoft.com, SBC crea una query DNS. In base alla posizione SBC e alle metriche relative alle prestazioni del data center, viene selezionato il data center principale.

Se il data center principale riscontra un problema, SBC tenta di sip2.pstnhub.microsoft.com, che si risolve nel secondo data center assegnato. Nel raro caso in cui i data center di due aree geografiche non siano disponibili, SBC verifica l'ultimo FQDN (sip3.pstnhub.microsoft.com), che fornisce l'INDIRIZZO IP del data center secondario.

La tabella seguente riepiloga le relazioni tra data center primario, secondario e terziario:

Traffico multimediale: intervalli di porte, processori multimediali, CODEC

Traffico multimediale: intervalli di porte

Se si vuole distribuire direct routing senza bypass multimediale, si applicano i requisiti seguenti. Per i requisiti del firewall per il bypass multimediale, vedere Pianificare il bypass multimediale con routing diretto.

Il traffico multimediale scorre da e verso un servizio separato in Microsoft Cloud. Gli intervalli di indirizzi IP per il traffico multimediale sono i seguenti.

Ambienti Microsoft 365, Office 365 e Office 365 GCC

Negli ambienti Microsoft 365, Office 365 e GCC di Office 365, gli intervalli di indirizzi IP sono:

• 52.112.0.0/14 (indirizzi IP da 52.112.0.0 a 52.115.255.255)
• 52.120.0.0/14 (indirizzi IP da 52.120.0.0 a 52.123.255.255)

Ambiente DoD di Office 365

Nell'ambiente DoD di Office 365 gli intervalli di indirizzi IP sono:

• 52.127.64.0/21

Ambiente Office 365 GCC High

Nell'ambiente Office 365 GCC High gli intervalli di indirizzi IP sono:

• 52.127.88.0/21

Tutti gli ambienti

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

Traffico multimediale: area geografica dei processori

Il traffico multimediale passa attraverso componenti denominati processori multimediali. I processori multimediali vengono inseriti negli stessi data center dei proxy SIP come indicato di seguito:

• NOAM (Us South Central, due in data center us west e US East)
• Europa (paesi del Sud del Regno Unito, Francia centrale, Amsterdam e Dublino)
• Asia (data center Singapore)
• Giappone (data center JP Est e West)
• Australia (data center AU est e sudest)
• America Latina (Brasile Sud)

Traffico multimediale: codec

Le sezioni seguenti descrivono i codec per il traffico multimediale.

Gamba tra SBC e Cloud Media Processor o client Microsoft Teams

Si applica sia al caso di bypass multimediale che al caso di non bypass.

L'interfaccia Direct Routing sulla gamba tra session border controller e Cloud Media Processor (senza bypass multimediale) o tra il client Teams e SBC (se è abilitato il bypass multimediale) può utilizzare i codec seguenti:

• Bypass non multimediale (processore da SBC a cloud): SILK, G.711, G.722, G.729
• Bypass multimediale (client da SBC a Teams): SILK, G.711, G.722, G.729

È possibile forzare l'uso del codec specifico nel controller dei confini della sessione escludendo i codec indesiderati dall'offerta.

Parte tra il client Microsoft Teams e il processore multimediale cloud

Si applica solo al caso di bypass non multimediale. Con il bypass multimediale, i flussi multimediali passano direttamente tra il client di Teams e SBC.

Sulla gamba tra il processore cloud media e il client Teams, viene utilizzato SILK o G.722. La scelta del codec su questa gamba si basa sugli algoritmi Microsoft, che tengono in considerazione più parametri.

Controller dei confini della sessione supportati

Microsoft supporta solo gli SBC certificati da associare al routing diretto. Dato che VoIP aziendale è fondamentale per le aziende, Microsoft esegue test intensivi con le schede SBC selezionate e collabora con i fornitori di SBC per garantire che i due sistemi siano compatibili.

I dispositivi convalidati sono elencati come Certificati per Teams Direct Routing. I dispositivi certificati sono garantiti per funzionare in tutti gli scenari.

Per ulteriori informazioni sugli SBC supportati, vedi Session Border Controllers certified for Direct Routing.

Limiti del supporto

Microsoft supporta teams phone solo con routing diretto se usato con dispositivi certificati. In caso di problemi, è necessario contattare prima il supporto tecnico del fornitore di SBC. Se necessario, il fornitore di SBC inoltra il problema a Microsoft tramite canali interni. Microsoft si riserva il diritto di rifiutare i casi di supporto in cui un dispositivo non certificato è connesso a Teams Phone tramite direct routing. Se Microsoft determina che il problema relativo al routing diretto di un cliente riguarda il dispositivo SBC di un fornitore, il cliente deve coinvolgere nuovamente il fornitore di SBC per ottenere supporto.

Vedere anche

• Configurare Instradamento diretto
• Sessione video: Routing diretto in Microsoft Teams.