Pianificare Instradamento diretto

  • Articolo
  • Si applica a:
    Microsoft Teams

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

Diagramma che illustra la configurazione della connettività PSTN locale.

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 direct routing, quando gli utenti partecipano a una conferenza pianificata, il numero di accesso esterno viene fornito dal servizio 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 Requisiti e considerazioni per i servizi di 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:

Requisito dell'infrastruttura Sono necessari i seguenti
Session Border Controller (SBC) Un'estensione SBC supportata. Per altre informazioni, vedere Schede SBC supportate.
Trunk di telefonia collegati alla SBC Uno o più trunk di telefonia collegati all'SBC. Da un lato, SBC si connette a Teams Phone tramite direct routing. SBC può anche connettersi a entità di telefonia di terze parti, come PBX, Analog Telephony Adapter e così via. Qualsiasi opzione di connettività PSTN connessa a SBC funzionerà. Per la configurazione dei trunk PSTN a SBC, fare riferimento ai fornitori di servizi di protezione avanzata o ai provider di trunk.
Organizzazione di Microsoft 365 Un'organizzazione di Microsoft 365 che usi per la casa degli utenti di Microsoft Teams e la configurazione e la connessione alla scheda SBC.
Registrar utenti L'utente deve essere ospitato in Microsoft 365.
Se l'azienda ha un ambiente di Skype for Business locale con connettività ibrida a Microsoft 365, non è possibile abilitare la voce in Teams per un utente ospitato in locale.

Per controllare il registrar di un utente, usare il cmdlet PowerShell di Teams seguente:
Get-CsOnlineUser -Identity <user> | fl HostingProvider

L'output del cmdlet dovrebbe mostrare:
HostingProvider : sipfed.online.lync.com
Domini Uno o più domini aggiunti a Microsoft 365 o Office 365 organizzazioni.

Non è possibile usare il dominio predefinito *.onmicrosoft.com creato automaticamente per il tenant.

Per visualizzare i domini, è possibile usare il cmdlet di Teams PowerShell seguente:
Get-CsTenant | fl Domains

Per altre informazioni sui domini e microsoft 365 o Office 365 organizzazioni, vedere Domande frequenti sui domini.
Indirizzo IP pubblico per SBC Un indirizzo IP pubblico che può essere usato per connettersi a SBC. In base al tipo di SBC, SBC può usare NAT.
Nome di dominio completo (FQDN) per SBC FQDN per SBC, in cui la parte relativa al dominio dell'FQDN è uno dei domini registrati nell'organizzazione di Microsoft 365 o Office 365. Per altre informazioni, vedere Nomi di dominio SBC.
Voce DNS pubblica per SBC Una voce DNS pubblica che associa l'FQDN SBC all'indirizzo IP pubblico.
Certificato pubblico attendibile per SBC Un certificato per SBC da usare per tutte le comunicazioni con direct routing. Per altre informazioni, vedere Certificato attendibile pubblico per il certificato SBC.
Punti di connessione per l'instradamento diretto I punti di connessione per il routing diretto sono i seguenti tre FQDN:

sip.pstnhub.microsoft.com : è necessario provare prima l'FQDN globale.
sip2.pstnhub.microsoft.com – FQDN secondario, mappato geograficamente alla seconda area di priorità.
sip3.pstnhub.microsoft.com – FQDN fqdn fqdn, geograficamente mappa alla terza area di priorità.

Per informazioni sui requisiti di configurazione, vedere Segnalazione SIP: FQDN.
Porte e indirizzi IP firewall per i supporti di routing diretto SBC comunica ai servizi seguenti nel cloud:

Proxy SIP, che gestisce la segnalazione
Processore multimediale, che gestisce i supporti, tranne quando Media Bypass è attivato

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

Per altre informazioni, vedere la sezione Microsoft Teams in URL e intervalli di indirizzi IP.
Media Transport Profile TCP/RTP/SAVP
UDP/RTP/SAVP
Porte e indirizzi IP firewall per i supporti di Microsoft Teams Per altre informazioni, vedere URL e intervalli di indirizzi IP.

Licenze e altri requisiti

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

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.

Requisiti e considerazioni per i servizi di 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 hai completamente configurato il Routing diretto e hai aggiunto 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 fino a quando non hai completamente configurato l'instradamento diretto 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 ad hoc 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:

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.

Nome DNS Può essere usato per l'FQDN SBC Esempi di nomi FQDN
contoso.com Sì Nomi validi:
sbc1.contoso.com
ssbcs15.contoso.com
europe.contoso.com
contoso.onmicrosoft.com No L'uso dei domini *.onmicrosoft.com non è supportato per i nomi 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.

Nota

L'FQDN SBC in Servizi di comunicazione di Azure routing diretto deve essere diverso dall'FQDN SBC nel routing diretto di Teams.

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.

Nota

La maggior parte delle autorità di certificazione richiede che la dimensione della chiave privata sia almeno 2048. Tieni presente questo aspetto quando generi la CSR.

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.

Nota

Alla fine di agosto 2023, Microsoft 365 aggiornerà i servizi per l'utilizzo dei certificati TLS emessi dalla nuova CA "DigiCert Global Root G2". Per evitare errori che possono influire sul servizio, è necessario aggiornare l'archivio radice del certificato SBC per includere la nuova CA radice. Per altre informazioni, vedere Modifica dell'autorità di certificazione SIP da certificato a MSPKI.

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

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

Nota

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

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:

  • 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 ulteriori informazioni sugli ambienti governativi, ad esempio GCC, GCC High e DoD, vedi 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 per eseguire questa operazione, 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 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.

Office 365 ambiente GCC High

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

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 utilizzare le porte seguenti per Microsoft 365 o Office 365 ambienti in cui è disponibile il routing diretto:

Traffico Da A Porta di origine Porta di destinazione
SIP/TLS SIP Proxy SBC 1024 – 65535 Definito su SBC (per Office 365 porta GCC High/DoD deve essere usata solo la porta 5061)
SIP/TLS SBC SIP Proxy Definito in SBC 5061

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:

Se il data center principale è EMEA NOAM ASIA
Data center secondario (sip2.pstnhub.microsoft.com) NOI UE NOI
Data center terziario (sip3.pstnhub.microsoft.com) ASIA ASIA UE

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.

Nota

Gli intervalli IP presentati in questo documento sono specifici per direct routing e possono essere diversi da quelli consigliati per il client teams.

Ambienti Microsoft 365, Office 365 e Office 365 GCC

Negli ambienti Microsoft 365, Office 365 e GCC 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)

Office 365 ambiente DoD

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

  • 52.127.64.0/21

Office 365 ambiente 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 Da A Porta di origine Porta di destinazione
UDP/SRTP Media Processor SBC 3478-3481 e 49152 – 53247 Definito in SBC
UDP/SRTP SBC Media Processor Definito in SBC 3478-3481 e 49152 – 53247

Nota

Microsoft consiglia almeno due porte per chiamata simultanea in SBC.

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.

Nota

Il re-targeting dei supporti non è supportato. Durante una chiamata di routing diretto, se SBC invia un nuovo indirizzo IP multimediale al routing diretto, anche se è negoziato nel segnale SIP, il supporto non viene mai inviato al nuovo indirizzo IP dal routing diretto.

Controller dei confini della sessione supportati

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

I dispositivi che sono stati 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 eseguirà l'escalation del 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