Flussi di chiamata in Microsoft Teams

• Si applica a:

  Microsoft Teams

Mancia

Guardare questa sessione per scoprire come Teams sfrutta la rete e come pianificare una connettività di rete ottimale: Pianificazione della rete di Teams.

Panoramica

Questo articolo descrive in che modo Teams usa i flussi delle chiamate di Microsoft 365 in varie topologie. Vengono inoltre descritti flussi di Teams univoci usati per la comunicazione multimediale peer-to-peer. Il documento descrive questi flussi, il loro scopo e l'origine e la terminazione sulla rete. Ai fini del presente articolo, si supponga che:

• Flow X viene usato dal client locale per comunicare con il servizio Microsoft 365 nel cloud. Proviene dalla rete del cliente e termina come endpoint in Microsoft 365.

• Il flusso Y viene usato dal client locale per comunicare con un servizio su Internet da cui Microsoft 365 ha una dipendenza. Proviene dalla rete del cliente e termina come endpoint su Internet.

Questo articolo illustra le informazioni seguenti:

• Sfondo. Fornisce informazioni di base, ad esempio le reti che i flussi possono attraversare, tipi di traffico e indicazioni sulla connettività dalla rete del cliente agli endpoint del servizio Microsoft 365. Descrive anche l'interoperabilità con i componenti di terze parti e i principi che vengono utilizzati da Teams per selezionare i flussi multimediali.

• Le chiamate fluiscono in varie topologie. Illustra l'uso dei flussi delle chiamate in varie topologie. Per ogni topologia, la sezione enumera tutti i flussi supportati e ne illustra l'uso in diversi casi d'uso. Per ogni caso d'uso, descrive la sequenza e la selezione dei flussi usando un diagramma di flusso.

• Teams con ottimizzazione Express Route. Descrive come vengono usati questi flussi quando Express Route viene distribuito per l'ottimizzazione, illustrati con una topologia semplice.

Sfondo

Segmenti di rete

Rete del cliente. Il segmento di rete che si controlla e si gestisce. Questo segmento include tutte le connessioni dei clienti all'interno degli uffici dei clienti, sia cablate che wireless, le connessioni tra edifici degli uffici, le connessioni a data center locali e le connessioni a provider Internet, Express Route o qualsiasi altro peering privato.

In genere, una rete del cliente ha diversi perimetri di rete con firewall e/o server proxy, che applicano i criteri di sicurezza dell'organizzazione e che consentono solo determinati traffici di rete configurati e configurati. Poiché si gestisce questa rete, si ha un controllo diretto sulle prestazioni della rete. È consigliabile completare le valutazioni di rete per convalidare le prestazioni sia all'interno dei siti della rete che dalla rete a Microsoft 365.

Internet. Il segmento di rete che fa parte della rete complessiva utilizzato dagli utenti che si connettono a Microsoft 365 dall'esterno della rete del cliente. Questo segmento viene utilizzato anche da parte del traffico dalla rete del cliente a Microsoft 365.

Rete privata visitata o guest. Il segmento di rete al di fuori della rete del cliente, ma non in Internet pubblico, che gli utenti e i loro guest possono visitare. Ad esempio, una rete privata domestica o una rete privata aziendale, che non distribuisce Teams, in cui possono risiedere gli utenti e i clienti che interagiscono con i servizi di Teams.

Nota

La connettività a Microsoft 365 è applicabile anche a queste reti.

Microsoft 365. Il segmento di rete che supporta i servizi di Microsoft 365. È distribuito in tutto il mondo con bordi in prossimità della rete del cliente nella maggior parte delle località. Le funzioni includono Transport Relay, server conferenze e Media Processor.

Express Route (facoltativo). Il segmento di rete che fa parte della rete complessiva che offre una connessione privata dedicata alla rete di Microsoft 365.

Tipi di traffico

Elementi multimediali in tempo reale. Dati incapsulati all'interno del protocollo RTP (Real-Time Transport Protocol) che supporta i carichi di lavoro audio, video e di condivisione dello schermo. In generale, il traffico multimediale è altamente sensibile alla latenza. Si desidera che questo traffico prenda il percorso più diretto possibile e utilizzi UDP rispetto a TCP come protocollo transport layer, che è il miglior trasporto per i supporti interattivi in tempo reale da una prospettiva di qualità. Come ultima risorsa, i supporti possono usare TCP/IP e anche essere tunnelati all'interno del protocollo HTTP, ma non è consigliabile a causa di implicazioni di scarsa qualità. Il flusso RTP è protetto tramite SRTP, in cui viene crittografato solo il payload.

Segnalazione. Il collegamento di comunicazione tra il client e il server o altri client usati per controllare le attività (ad esempio, quando viene avviata una chiamata) e recapitare messaggi istantanei. La maggior parte del traffico di segnalazione utilizza le interfacce REST basate su HTTPS, anche se in alcuni scenari (ad esempio la connessione tra Microsoft 365 e un controller dei confini della sessione) utilizza il protocollo SIP. È importante tenere presente che questo traffico è molto meno sensibile alla latenza, ma può causare interruzioni del servizio o timeout delle chiamate se la latenza tra gli endpoint supera diversi secondi.

Connettività a Microsoft 365

Teams richiede connettività a Internet. Gli URL e gli intervalli di indirizzi IP degli endpoint di Teams sono elencati in OFFICE 365 URL e intervalli di indirizzi IP. Aprire la connettività alle porte TCP 80 e 443 e alle porte UDP 3478 (STUN), 3479 (Audio), 3480 (Video) e 3481 (condivisione/VBSS) sono necessarie.

La connettività dei flussi multimediali di Teams viene implementata con procedure standard IETF Interactive Connectivity Establishment (ICE).

Restrizioni di interoperabilità

Media Relay di terze parti. Un flusso multimediale di Teams (ovvero, uno degli endpoint multimediali è Teams) può attraversare solo Teams o Skype for Business media relay nativi. L'interoperabilità con un media relay di terze parti non è supportata. Una SBC di terze parti sul limite con PSTN deve terminare il flusso RTP/RTCP, protetto con SRTP, e non inoltrarlo all'hop successivo.

Server proxy SIP di terze parti. Una finestra di dialogo SIP di segnalazione di Teams con un gateway e/o SBC di terze parti può attraversare Teams o Skype for Business proxy SIP nativi. L'interoperabilità con un proxy SIP di terze parti non è supportata.

B2BUA (o SBC) di terze parti. Un flusso multimediale di Teams da e verso il pstn viene interrotto da un'interfaccia di posta elettronica di terze parti. Tuttavia, l'interoperabilità con una SBC di terze parti all'interno della rete di Teams (in cui una SBC di terze parti media due endpoint di Teams o Skype for Business) non è supportata.

Tecnologie non consigliate con Microsoft Teams

Rete VPN. Non è consigliabile per il traffico multimediale (o flusso 2'). Il client VPN deve usare il tunneling diviso e instradare il traffico multimediale di Teams come qualsiasi utente esterno non VPN, come specificato in Abilitazione dei supporti multimediali di Lync a bypassare un tunnel VPN.

Nota

Anche se il titolo indica Lync, è applicabile anche a Teams.

Packet shaper. Qualsiasi tipo di dispositivo di cattura pacchetti, ispezione pacchetti o packet shaper non è consigliato per il traffico multimediale di Teams e può ridurre significativamente la qualità.

Principi

Esistono quattro principi generali che aiutano a comprendere i flussi delle chiamate per Microsoft Teams:

• Una conferenza di Microsoft Teams è ospitata da Microsoft 365 nella stessa area geografica in cui è stato aggiunto il primo partecipante. Se in alcune topologie sono presenti eccezioni a questa regola, queste sono descritte in questo documento e illustrate da un flusso delle chiamate appropriato.

• Un endpoint multimediale di Teams in Microsoft 365 viene usato in base alle esigenze di elaborazione dei supporti e non al tipo di chiamata. Ad esempio, una chiamata point-to-point può usare un endpoint multimediale nel cloud per elaborare il supporto per la trascrizione o la registrazione, mentre una conferenza con due partecipanti potrebbe non usare alcun endpoint multimediale nel cloud. Tuttavia, la maggior parte delle conferenze utilizzerà un endpoint multimediale per la combinazione e il routing, allocato dove è ospitata la conferenza. Il traffico multimediale inviato da un client all'endpoint multimediale può essere instradato direttamente o utilizzare un Transport Relay in Microsoft 365, se necessario a causa di restrizioni del firewall di rete del cliente.

• Il traffico multimediale per le chiamate peer-to-peer prende il percorso più diretto disponibile, presupponendo che la chiamata non richieda un endpoint multimediale nel cloud (vedere il principio precedente). Il percorso preferito è diretto al peer (client) remoto, ma se tale percorso non è disponibile, uno o più Transport Relays inoltrino il traffico. È consigliabile che il traffico multimediale non trasverse i server come i packet shaper, i server VPN e così via, dal momento che questo influirà sulla qualità multimediale.

• Il traffico di segnalazione passa sempre al server più vicino all'utente.

Per altre informazioni sui dettagli sul percorso multimediale scelto, vedere Informazioni sui flussi multimediali in Microsoft Teams - BRK4016.

Flussi delle chiamate in varie topologie

Topologia di Teams

Questa topologia viene usata dai clienti che usano i servizi di Teams dal cloud senza alcuna distribuzione locale, ad esempio Skype for Business Server o Routing diretto sistema telefonico. Inoltre, l'interfaccia per Microsoft 365 viene eseguita tramite Internet senza Azure Express Route.

Figura 1 - Topologia di Teams

Tenere presente quanto segue:

• La direzione delle frecce nel diagramma riflette la direzione di avvio della comunicazione che influisce sulla connettività ai perimetro dell'organizzazione. Per UDP per i supporti, i primi pacchetti possono scorrere nella direzione inversa, ma questi pacchetti possono essere bloccati fino a quando i pacchetti nella direzione opposta non vengono fluiti.
• Teams viene distribuito affiancato con Skype for Business Online, quindi i client vengono visualizzati come "Utente di Teams/SFB".

Altre informazioni sulle topologie facoltative seguenti sono disponibili più avanti nell'articolo:

• Skype for Business distribuzione locale è descritta nella topologia ibrida di Teams.
• Il routing diretto del sistema telefonico (per la connettività PSTN) è descritto in Teams con topologia routing diretto.
• Express Route è descritto in Teams con ottimizzazione Express Route.

Descrizioni del flusso:

• Flusso 2 : rappresenta un flusso avviato da un utente sulla rete del cliente verso Internet nell'ambito dell'esperienza teams dell'utente. Esempi di questi flussi sono il DNS e i file multimediali peer-to-peer.
• Flusso 2' - Rappresenta un flusso avviato da un utente remoto di Teams mobile, con VPN per la rete del cliente.
• Flusso 3 : rappresenta un flusso avviato da un utente remoto di Teams mobile agli endpoint di Microsoft 365 Teams.
• Flusso 4 : rappresenta un flusso avviato da un utente nella rete del cliente agli endpoint di Microsoft 365 Teams.
• Flusso 5 : rappresenta un flusso multimediale peer-to-peer tra un utente di Teams e un altro utente di Teams o Skype for Business all'interno della rete del cliente.
• Flusso 6 : rappresenta un flusso multimediale peer-to-peer tra un utente di Teams per dispositivi mobili remoto e un altro utente di Teams per dispositivi mobili remoto o Skype for Business su Internet.

Maiuscole/minuscole: uno-a-uno

Le chiamate uno-a-uno usano un modello comune in cui il chiamante ottiene un set di candidati costituito da indirizzi IP/porte, inclusi i candidati locali, relay e riflessivi (indirizzo IP pubblico del client visto dall'inoltro). Il chiamante invia questi candidati al partito chiamato; il chiamato ottiene anche un set simile di candidati e li invia al chiamante. I messaggi di controllo della connettività STUN vengono usati per trovare i percorsi multimediali di tipo chiamante/chiamato del gruppo e il percorso di lavoro migliore è selezionato. I supporti, ovvero i pacchetti RTP/RTCP protetti con SRTP, vengono quindi inviati usando la coppia di candidati selezionata. Il transport relay viene distribuito come parte di Microsoft 365.

Se i candidati dell'indirizzo IP locale o della porta o i candidati riflessivi dispongono di connettività, il percorso diretto tra i client (o usando un NAT) è selezionato per gli elementi multimediali. Se i client si trovano entrambi nella rete del cliente, il percorso diretto deve essere selezionato. Ciò richiede la connettività UDP diretta all'interno della rete del cliente. Se i client sono entrambi utenti di cloud nomadi, a seconda del NAT/firewall, i supporti possono usare la connettività diretta.

Se un client è interno alla rete del cliente e un client è esterno (ad esempio, un utente di cloud mobile), è improbabile che funzioni la connettività diretta tra i candidati locali o riflessivi. In questo caso, un'opzione consiste nell'usare uno dei candidati Transport Relay da uno dei due client (ad esempio, il client interno ha ottenuto un candidato di inoltro dal transport relay in Microsoft 365; il client esterno deve essere in grado di inviare pacchetti STUN/RTP/RTCP all'inoltro di trasporto). Un'altra opzione è l'invio del client interno al candidato di inoltro ottenuto dal client cloud mobile. Anche se la connettività UDP per i supporti è altamente consigliata, TCP è supportato.

Passaggi di alto livello:

1. L'utente A di Teams risolve il nome di dominio URL (DNS) usando il flusso 2.
2. L'utente di Teams A alloca una porta Media Relay su Teams Transport Relay utilizzando il flusso 4.
3. L'utente A di Teams invia un "invito" con i candidati ICE che usano il flusso 4 a Microsoft 365.
4. Microsoft 365 invia una notifica all'utente B di Teams usando il flusso 4.
5. L'utente B di Teams alloca una porta Media Relay su Teams Transport Relay usando il flusso 4.
6. L'utente B di Teams invia una "risposta" con i candidati ICE usando il flusso 4, che viene inoltrato di nuovo all'utente di Teams A tramite Flow 4.
7. L'utente A di Teams e l'utente B di Teams richiamano i test di connettività ICE ed è selezionato il miglior percorso multimediale disponibile (vedere i diagrammi seguenti per i vari casi d'uso).
8. Gli utenti di Teams inviano la telemetria a Microsoft 365 usando il flusso 4.

All'interno della rete del cliente:

Figura 2 - All'interno della rete del cliente

Nel passaggio 7 è selezionato flusso di elementi multimediali peer-to-peer 5.

I supporti sono bidirezionali. La direzione del flusso 5 indica che un lato avvia la comunicazione da una prospettiva di connettività, coerente con tutti i flussi in questo documento. In questo caso, non importa quale direzione viene utilizzata perché entrambi gli endpoint sono all'interno della rete del cliente.

Rete del cliente a utente esterno (media inoltrati da Teams Transport Relay):

Figura 3 - Rete del cliente a utente esterno (media relayed by Teams Transport Relay)

Nel passaggio 7, il flusso 4, dalla rete del cliente a Microsoft 365, e il flusso 3, dall'utente remoto di Teams mobile a Microsoft 365, sono selezionati. Questi flussi vengono inoltrati da Teams Transport Relay all'interno di Microsoft 365.

Il supporto è bidirezionale, dove la direzione indica quale lato avvia la comunicazione da una prospettiva di connettività. In questo caso, questi flussi vengono utilizzati per la segnalazione e i supporti, utilizzando diversi protocolli e indirizzi di trasporto.

Rete del cliente verso un utente esterno (supporto diretto):

Figura 4 - Rete del cliente verso utenti esterni (supporti diretti)

Nel passaggio 7 è selezionato il flusso 2, dalla rete del cliente a Internet (peer del client).

• Il supporto diretto con un utente mobile remoto (non inoltrato tramite Microsoft 365) è facoltativo. In altre parole, il cliente può bloccare questo percorso per applicare un percorso multimediale tramite Transport Relay in Microsoft 365.

• I supporti sono bidirezionali. La direzione del flusso 2 per l'utente mobile remoto indica che un lato avvia la comunicazione da una prospettiva di connettività.

Utente VPN all'utente interno (media relayed da Teams Transport Relay)

Figura 5 - Utente VPN all'utente interno (media relayed by Teams Transport Relay)

Il traffico di segnalazione tra la VPN e la rete del cliente utilizza il flusso 2'. Il traffico di segnalazione tra la rete del cliente e Microsoft 365 usa il flusso 4. Tuttavia, i contenuti multimediali ignorano la VPN e vengono instradati con flussi 3 e 4 attraverso Teams Media Relay in Microsoft 365.

Da utente VPN a utente interno (file multimediali diretti)

Figura 6 - Da utente VPN a utente interno (file multimediali diretti)

Il traffico di segnalazione tra la VPN e la rete del cliente utilizza il flusso 2'. Il traffico di segnalazione tra la rete del cliente e Microsoft 365 usa il flusso 4. Tuttavia, i contenuti multimediali ignorano la VPN e vengono instradati usando il flusso 2 dalla rete del cliente a Internet.

I supporti sono bidirezionali. La direzione del flusso 2 per l'utente mobile remoto indica che un lato avvia la comunicazione da una prospettiva di connettività.

Utente VPN a utente esterno (file multimediali diretti)

Figura 7 - Utente VPN a utente esterno (file multimediali diretti)

Il traffico di segnalazione tra l'utente VPN e la rete del cliente utilizza il flusso 2' e il flusso 4 verso Microsoft 365. Tuttavia, i contenuti multimediali ignorano la VPN e vengono instradati con il flusso 6.

I supporti sono bidirezionali. La direzione del flusso 6 per l'utente mobile remoto indica che un lato avvia la comunicazione da una prospettiva di connettività.

Use Case: da Teams a PSTN tramite il trunk di Microsoft 365

Microsoft 365 dispone di un sistema telefonico che consente di effettuare e ricevere chiamate da PSTN (Public Switched Telephone Network). Se il trunk PSTN è connesso con il piano per le chiamate del sistema telefonico, non ci sono requisiti di connettività speciali per questo caso d'uso. Se si vuole connettere il proprio trunk PSTN locale a Microsoft 365, è possibile usare Il routing diretto del sistema telefonico.

Figura 8 - Da Teams a PSTN attraverso il trunk di Microsoft 365

Caso d'uso: riunione di Teams

Il server delle conferenze audio/video/condivisione schermo (VBSS) fa parte di Microsoft 365. Ha un indirizzo IP pubblico che deve essere raggiungibile dalla rete del cliente e deve essere raggiungibile da un client Nomadic Cloud. Ogni client/endpoint deve essere in grado di connettersi al server delle conferenze.

I client interni ottengono candidati locali, riflessivi e inoltrati nello stesso modo descritto per le chiamate uno-a-uno. I client inviano questi candidati al server delle conferenze in un invito. Il server delle conferenze non utilizza un inoltro perché dispone di un indirizzo IP raggiungibile pubblicamente, quindi risponde con il candidato per l'indirizzo IP locale. Il client e il server delle conferenze controllano la connettività nello stesso modo descritto per le chiamate uno-a-uno.

Tenere presente quanto segue:

• I client di Teams non possono partecipare alle riunioni Skype for Business e Skype for Business clienti non possono partecipare alle riunioni di Teams.

• Un utente PSTN facoltativamente "Accesso esterno" o "Chiamata in uscita", a seconda del provisioning delle chiamate PSTN e/o dei servizi di conferenza PSTN dell'organizzatore della riunione.

• Un utente guest o un cliente può partecipare da una rete privata guest, protetta tramite FW/NAT con regole rigorose.

Figura 9 - Riunione di Teams

Use case: Federazione con Skype for Business locale

Media relayed by Teams Transport Relay in Microsoft 365

Figura 10 - Media inoltrati da Teams Transport Relay in Microsoft 365

Tenere presente quanto segue:

• La federazione è, per definizione, una comunicazione tra due tenant. In questo caso, il tenant A, che usa Teams, è federato con il tenant B, che usa Skype for Business locale. Se anche il tenant B usa Microsoft 365, il client Skype for Business avrebbe usato il flusso 3 per connettersi a Microsoft 365.

• Il traffico di segnalazione e il supporto dal client Skype for Business federato a Skype for Business Server locale non rientra nell'ambito di questo documento. Tuttavia, è illustrato qui per chiarezza.

• Il traffico di segnalazione tra Teams e Skype for Business è collegato tramite un gateway.

• I supporti in questo caso vengono inoltrati da Teams Transport Relay alla rete del cliente e dal client di Skype for Business remoto utilizzando il flusso 4.

Media relayed by Skype for Business Media Relay in federated tenant

Figura 11 - Media relayed by Skype for Business Media Relay in federated tenant

Tieni presente che:

• Il traffico di segnalazione e il supporto multimediale dal client Skype for Business federato a un Skype for Business Server locale non rientra nell'ambito di questo documento. Tuttavia, è illustrato qui per chiarezza.

• Il traffico di segnalazione tra Teams e Skype for Business è collegato tramite un gateway.

• I supporti in questo caso vengono inoltrati da Skype for Business Media Relay locale alla rete del cliente usando il flusso 2. Si noti che il traffico dall'utente di Teams al Media Relay remoto nella rete del cliente federato verrà inizialmente bloccato dal Media Relay finché non inizia il flusso del traffico nella direzione inversa. Tuttavia, il flusso bidirezionale aprirà la connettività in entrambe le direzioni.

Diretto (peer-to-peer)

Figura 12 - Diretto (peer-to-peer)

Topologia ibrida di Teams

Questa topologia include Teams con una Skype for Business distribuzione locale.

Figura 13 - Topologia ibrida di Teams

• La direzione delle frecce nel diagramma precedente riflette la direzione di avvio della comunicazione che influisce sulla connettività nei perimetri aziendali. Nel caso di UDP per i file multimediali, il primo o i primi pacchetti possono scorrere nella direzione inversa, ma questi pacchetti possono essere bloccati fino a quando i pacchetti nella direzione opposta non vengono fluiti.

• Teams viene distribuito affiancato con Skype for Business Online, quindi i client vengono visualizzati come "Utente di Teams/SFB".

Flusso aggiuntivo (oltre alla topologia di Teams):

• Flusso 5A: rappresenta un flusso multimediale peer-to-peer tra un utente di Teams all'interno della rete del cliente e un Skype for Business media relay locale nell'edge della rete del cliente.

Use case: Teams to Skype for Business uno-a-uno

Ibrida all'interno della rete del cliente

Figura 14 - Ibrida all'interno della rete del cliente

Il traffico di segnalazione tra Teams e Skype for Business è collegato tramite un gateway. Tuttavia, i file multimediali sono indirizzati direttamente peer-to-peer all'interno della rete del cliente usando il flusso 5.

Rete del cliente ibrida con utente Skype for Business esterno - inoltrata da Microsoft 365

Figura 15 - Rete del cliente ibrido con utente Skype for Business esterno - inoltro da Microsoft 365

Tieni presente che:

• Il traffico di segnalazione e il supporto dal client Skype for Business a un Skype for Business Server locale non rientra nell'ambito di questo documento. Tuttavia, è illustrato qui per chiarezza.

• Il traffico di segnalazione tra Teams e Skype for Business è collegato tramite un gateway.

• I supporti sono inoltrati tramite Teams Transport Relay alla rete del cliente attraverso il flusso 4.

Rete del cliente ibrida con utente Skype for Business esterno , inoltrato da Edge locale

Figura 16 - Rete del cliente ibrida con utente Skype for Business esterno - inoltro da Edge locale

Tieni presente che:

• Il traffico di segnalazione e il supporto da Skype for Business client a un Skype for Business Server locale non rientra nell'ambito di questo documento. Tuttavia, è illustrato qui per chiarezza.

• Il traffico di segnalazione è collegato a un gateway.

• I contenuti multimediali sono inoltrati da Skype for Business Media Relay all'interno di Skype for Business edge locale all'utente di Teams all'interno della rete del cliente usando il flusso multimediale 5A.

Teams con topologia di routing diretto sistema telefonico

Questa topologia include Teams con routing diretto sistema telefonico.

Direct Routing consente di utilizzare un provider di servizi PSTN (Public Switched Telephone Network) di terze parti associando a Microsoft 365 un dispositivo hardware SBC (Session Border Controller) di proprietà del cliente supportato dal cliente e quindi collegando il trunk di telefonia a tale dispositivo.

Per supportare questo scenario, il cliente deve distribuire un certificato SBC per direct routing da uno dei partner certificati Microsoft. La scheda SBC deve essere configurata come consigliato dal fornitore ed essere instradabile da Microsoft 365 per il traffico UDP diretto. I supporti possono scorrere direttamente da Teams e/o dal client Skype for Business a SBC (bypassando il gateway di Teams) o attraversano il gateway di Teams. La connettività con SBC, quando il trunk è configurato per bypassare il gateway di Teams, si basa su ICE, dove SBC supporta ICE-Lite, mentre l'endpoint multimediale Teams/Skype for Business supporta ICE Full Form.

*Figura 17 - Teams con topologia di routing diretto del sistema telefonico

Tieni presente che:

• La direzione delle frecce nel diagramma precedente riflette la direzione di avvio della comunicazione che influisce sulla connettività nei perimetri aziendali. Nel caso di UDP per i supporti, il primo o i primi pacchetti possono scorrere nella direzione inversa, ma questi pacchetti possono essere bloccati fino a quando i pacchetti nella direzione opposta fluiranno.

• Teams viene distribuito affiancato con Skype for Business Online, quindi i client vengono visualizzati come "Utente di Teams/SFB".

Flussi aggiuntivi (oltre alla topologia online di Teams):

• Flusso 4' - Rappresenta un flusso da Microsoft 365 alla rete del cliente, usato per stabilire una connessione tra il server multimediale di Teams nel cloud e SBC in locale.
• Flusso 5B : rappresenta un flusso multimediale tra l'utente di Teams all'interno della rete del cliente con il routing diretto SBC in modalità bypass.
• Flusso 5C : rappresenta un flusso multimediale tra sbc routing diretto a un altro SBC routing diretto in una modalità di bypass chiamata PSTN hairpin.

Utente interno con Direct Routing (media relayed by Teams Transport Relay)

Figura 18 - Utente interno con routing diretto (media relayed by Teams Transport Relay)

Tieni presente che:

• L'SBC deve avere un indirizzo IP pubblico instradabile da Microsoft 365.

• La segnalazione e il supporto da SBC a Microsoft 365 e viceversa usano il flusso 4 e/o il flusso 4'.

• Segnalazione ed elementi multimediali dal client all'interno della rete del cliente a Microsoft 365 usano il flusso 4.

Utente remoto con routing diretto (il supporto viene instradato attraverso un server multimediale (MP))

Figura 19 - Utente remoto con routing diretto (il supporto viene instradato attraverso un server multimediale (MP))

Tieni presente che:

• L'SBC deve avere un indirizzo IP pubblico instradabile da Microsoft 365.

• La segnalazione e il supporto da SBC a Microsoft 365 e viceversa usano il flusso 4 e/o il flusso 4'.

• Segnalazione ed elementi multimediali dal client su Internet a Microsoft 365 usano il flusso 3.

Routing diretto utente interno (bypass multimediale)

Figura 20 - Routing diretto utente interno (bypass multimediale)

Tieni presente che:

• L'SBC deve avere un indirizzo IP pubblico instradabile da Microsoft 365.

• La segnalazione da SBC a Microsoft 365 e viceversa usa il flusso 4 e/o il flusso 4'.

• Il traffico di segnalazione dal client all'interno della rete del cliente a Microsoft 365 usa il flusso 4.

• Gli elementi multimediali dal client all'interno della rete del cliente a SBC all'interno della rete del cliente usano il flusso 5B.

Utente remoto con routing diretto (bypass multimediale inoltrato da Teams Transport Relay)

Figura 21 - Utente remoto con routing diretto (bypass multimediale inoltrato da Teams Transport Relay)

Tieni presente che:

• L'SBC deve avere un indirizzo IP pubblico instradabile da Microsoft 365 e Da Internet.

• La segnalazione da SBC a Microsoft 365 e viceversa utilizza il flusso 4 e/o il flusso 4'.

• La segnalazione dal client su Internet a Microsoft 365 usa il flusso 3.

• I supporti dal client su Internet all'SBC all'interno della rete del cliente utilizzano flussi 3 e 4, inoltrati da Teams Transport Relay.

Routing diretto utente remoto (bypass multimediale diretto)

Figura 22 - Routing diretto utente remoto (bypass multimediale diretto)

Tieni presente che:

• L'SBC deve avere un indirizzo IP pubblico instradabile da Microsoft 365 e Da Internet.

• La segnalazione da SBC a Microsoft 365 e viceversa utilizza il flusso 4 e/o il flusso 4'.

• La segnalazione dal client su Internet a Microsoft 365 usa il flusso 3.

• Gli elementi multimediali dal client su Internet all'SBC all'interno della rete del cliente usano il flusso 2.

Routing diretto (bypass multimediale) - Chiamata di hairpin pstn (a causa di trasferimento/inoltro di chiamata)

Figura 23 - Routing diretto (bypass multimediale) - Chiamata di hairpin pstn (a causa di trasferimento/inoltro di chiamata)

Tieni presente che:

• L'SBC deve avere un indirizzo IP pubblico instradabile da Microsoft 365.

• La segnalazione da SBC a Microsoft 365 e viceversa utilizza il flusso 4 e/o il flusso 4'.

• Il client è fuori dal ciclo di segnalazione e supporto dopo che la chiamata è stata rimossa da PSTN a PSTN.

• I supporti dall'istanza SBC A all'interno della rete del cliente all'istanza B di SBC all'interno della rete del cliente (dove A e B possono essere la stessa istanza) usano il flusso 5C.

Routing diretto (elementi multimediali tramite Microsoft 365) - Chiamata di hairpintura PSTN tra due tenant

Figura 24 - Direct Routing (media through Microsoft 365) - Hairpin call PSTN tra due tenant

Tieni presente che:

• L'SBC deve avere un indirizzo IP pubblico instradabile da Microsoft 365.

• La segnalazione da SBC a Microsoft 365 e viceversa utilizza il flusso 4 e/o il flusso 4'.

• Il client è fuori dal ciclo di segnalazione e supporto dopo che la chiamata è stata rimossa da PSTN a PSTN.

• I supporti dall'istanza SBC A all'interno della rete X del cliente all'istanza B di SBC devono essere inoltrati tramite Microsoft 365 Media Server e non possono usare la modalità bypass.

Teams con ottimizzazione Express Route

Figura 25 - Teams con ottimizzazione Express Route

Nel caso in cui Express Route sia giustificato e distribuito, i flussi di Teams potrebbero essere reindirizzati dal flusso 4 al flusso 1 e dal flusso 4' al flusso 1'. Tuttavia, l'applicazione Teams ha una difficile dipendenza da altri flussi di Microsoft 365 su Internet utilizzando flussi 4 e 4'; quindi questi flussi non devono essere bloccati.

Si noti che Skype for Business traffico perimetrale ibrido viene instradato a Internet e non a Express Route per comunicare con utenti esterni e federati con altri tenant.

Per evitare flussi asimmetrici, il re-routing deve essere in entrambe le direzioni. In altre parole, un indirizzo all'interno della rete del cliente è instradabile tramite Internet o Express Route, in base all'ottimizzazione, ma non attraverso entrambi.

Rete del cliente a utente esterno (media inoltrati da Teams Transport Relay):

Figura 26 - Rete del cliente a utente esterno (media inoltrati da Teams Transport Relay)

Passaggi di alto livello:

1. L'utente di Teams all'interno della rete del cliente risolve il nome di dominio URL (DNS) usando flow2.
2. L'utente di Teams all'interno della rete del cliente alloca una porta Media Relay su Teams Transport Relay utilizzando il flusso 1.
3. L'utente di Teams all'interno della rete del cliente invia un "invito" con i candidati ICE che usano il flusso 1 a Microsoft 365.
4. Microsoft 365 invia una notifica all'utente esterno di Teams usando il flusso 3.
5. L'utente esterno di Teams alloca una porta Media Relay su Teams Transport Relay utilizzando il flusso 3.
6. L'utente esterno di Teams invia una "risposta" con i candidati ICE usando il flusso 3, che viene inoltrato di nuovo all'utente di Teams A tramite Flow 1.
7. L'utente A e l'utente B di Teams richiamano i test di connettività ICE e seleziona i flussi 1 e 3, che vengono inoltrati da Teams Transport Relay.
8. Gli utenti di Teams inviano la telemetria a Microsoft 365 usando i flussi 1 e 3.

Nota

Flow 4 deve essere abilitato a supportare le dipendenze dell'applicazione Teams su altri micro-servizi che delegano il flusso 4.