Topologie del flusso di chiamata

Questo articolo descrive Servizi di comunicazione di Azure topologie del flusso di chiamata. In questo articolo vengono fornite informazioni dettagliate sui concetti di rete per Servizi di comunicazione di Azure, sul modo in cui il traffico chiamante viene crittografato e per un'introduzione ai flussi di chiamata di Servizi di comunicazione, visitare la documentazione concettuale sui flussi di chiamata.

Background

Concetti di rete

Prima di esaminare le topologie del flusso delle chiamate, vengono definiti alcuni termini a cui viene fatto riferimento in tutto il documento.

Una rete dei clienti contiene tutti i segmenti di rete gestiti. Ciò può includere reti cablate e wireless all'interno dell'ufficio o tra uffici, data center e provider di servizi Internet.

Una rete dei clienti ha in genere diversi perimetri di rete con firewall e/o server proxy che applicano i criteri di sicurezza dell'organizzazione. È consigliabile eseguire una valutazione completa della rete per garantire prestazioni ottimali e qualità della soluzione di comunicazione.

La rete di Servizi di comunicazione è la rete che supporta Servizi di comunicazione di Azure. Questa rete è gestita da Microsoft ed è distribuita in tutto il mondo con data center di proprietà Microsoft più vicini ai clienti finali. Questa rete è responsabile dell'inoltro del trasporto, dell'elaborazione dei supporti per le chiamate di gruppo e di altri componenti che supportano comunicazioni multimediali avanzate in tempo reale.

Tipi di traffico

Servizi di comunicazione si basa principalmente su due tipi di traffico: supporti in tempo reale e segnalazione.

I supporti in tempo reale vengono trasmessi tramite il protocollo RTP (Real-Time Transport Protocol). Questo protocollo supporta la trasmissione di dati audio, video e condivisione dello schermo. Questi dati sono sensibili ai problemi di latenza di rete. Sebbene sia possibile trasmettere supporti in tempo reale tramite TCP o HTTP, è consigliabile usare UDP come protocollo del livello di trasporto per supportare esperienze utente finali ad alte prestazioni. I payload multimediali trasmessi tramite RTP sono protetti tramite SRTP.

Gli utenti della soluzione Servizi di comunicazione si connettono ai servizi dai dispositivi client. La comunicazione tra questi dispositivi e i server viene gestita con la segnalazione. Ad esempio: l'avvio delle chiamate e la chat in tempo reale sono supportati dalla segnalazione tra i dispositivi e il servizio. La maggior parte del traffico di segnalazione usa REST HTTPS, anche se in alcuni scenari, SIP può essere usato come protocollo di traffico di segnalazione. Anche se questo tipo di traffico è meno sensibile alla latenza, la segnalazione a bassa latenza dà agli utenti della soluzione un'esperienza utente finale piacevole.

Crittografia dei supporti

I flussi di chiamata in Servizi di comunicazione di Azure i client SDK per chiamate e Teams si basano sull'offerta RFC 8866 RFC (SDP) RFC 8866 su HTTPS. Dopo che il chiamato accetta una chiamata in ingresso, il chiamante e il chiamato accettano i parametri della sessione.

Il traffico multimediale viene crittografato e passa tra il chiamante e il chiamato tramite SECURE RTP (SRTP), un profilo di RTP (Real-Time Transport Protocol) che fornisce riservatezza, autenticazione e protezione dagli attacchi di riproduzione al traffico RTP. Nella maggior parte dei casi, il traffico da client a supporto client viene negoziato tramite la segnalazione della connessione da client a server e viene crittografato tramite SRTP quando passa direttamente dal client al client.

Servizi di comunicazione di Azure chiamare SDK usare DTLS per derivare una chiave di crittografia. Al termine dell'handshake DTLS, il supporto inizia a fluire usando questa chiave di crittografia negoziata da DTLS su SRTP.

Servizi di comunicazione di Azure chiamare i client SDK e Teams usa un token basato su credenziali per l'accesso sicuro agli inoltri multimediali tramite TURN. Gli inoltri multimediali scambiano il token tramite un canale protetto da TLS.

Servizi di comunicazione di Azure traffico multimediale tra due endpoint che partecipano alla condivisione audio, video e video Servizi di comunicazione di Azure utilizza SRTP per crittografare il flusso multimediale. Le chiavi crittografiche vengono negoziate tra i due endpoint tramite un protocollo di segnalazione, che usa TLS 1.2 e AES-256 (in modalità GCM) crittografati UDP/TCP.

Principi del flusso di chiamata

Esistono quattro principi generali alla base Servizi di comunicazione di Azure flussi di chiamata:

• Il primo partecipante di una chiamata di gruppo di Servizi di comunicazione determina l'area in cui è ospitata la chiamata. Esistono eccezioni a questa regola in alcune topologie, descritte di seguito.
• L'endpoint multimediale usato per supportare una chiamata di Servizi di comunicazione viene selezionato in base alle esigenze di elaborazione multimediale e non è interessato dal numero di partecipanti in una chiamata. Ad esempio, una chiamata da punto a punto può usare un endpoint multimediale nel cloud per elaborare supporti per la trascrizione o la registrazione, mentre una chiamata con due partecipanti potrebbe non usare endpoint multimediali. Le chiamate di gruppo usano un endpoint multimediale per scopi di combinazione e routing. Questo endpoint viene selezionato in base all'area in cui è ospitata la chiamata. Il traffico multimediale inviato da un client all'endpoint multimediale può essere indirizzato direttamente oppure può usare un inoltro di trasporto in Azure se sono necessarie restrizioni del firewall di rete del cliente.
• Il traffico multimediale per le chiamate peer-to-peer accetta la route più diretta disponibile, presupponendo che la chiamata non richieda un endpoint multimediale nel cloud. La route preferita è diretta al peer remoto (client). Se una route diretta non è disponibile, uno o più inoltri di trasporto inoltrano il traffico. Il traffico multimediale non deve comportare server trasverse che agiscono come shaper di pacchetti, server VPN o altre funzioni che potrebbero ritardare l'elaborazione e ridurre l'esperienza dell'utente finale.
• Il traffico di segnalazione passa sempre a qualsiasi server più vicino all'utente.

Per altre informazioni sui dettagli sul percorso multimediale scelto, vedere la documentazione concettuale sui flussi di chiamata.

Flussi di chiamata in varie topologie

Servizi di comunicazione (Internet)

Questa topologia viene usata dai clienti che usano Servizi di comunicazione dal cloud senza alcuna distribuzione locale, ad esempio il routing diretto di Azure. In questa topologia il traffico da e verso Servizi di comunicazione passa da e verso Internet.

Figura 1 - Topologia di Servizi di comunicazione

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, i primi pacchetti possono scorrere nella direzione inversa, ma questi pacchetti possono essere bloccati fino a quando i pacchetti nell'altra direzione non vengono trasmessi.

Descrizioni dei flussi:

• Flow 2: rappresenta un flusso avviato da un utente nella rete del cliente a Internet come parte dell'esperienza di Servizi di comunicazione dell'utente. Esempi di questi flussi includono la trasmissione di supporti DNS e peer-to-peer.
• Flow 2' : rappresenta un flusso avviato da un utente di Servizi di comunicazione mobile remoto, con VPN alla rete del cliente.
• Flow 3: rappresenta un flusso avviato da un utente di Servizi di comunicazione mobili remoto agli endpoint di Servizi di comunicazione.
• Flow 4: rappresenta un flusso avviato da un utente nella rete del cliente a Servizi di comunicazione.
• Flow 5: rappresenta un flusso multimediale peer-to-peer tra un utente di Servizi di comunicazione e un altro all'interno della rete del cliente.
• Flow 6: rappresenta un flusso multimediale peer-to-peer tra un utente di Servizi di comunicazione mobile remoto e un altro utente di Servizi di comunicazione mobile remoto su Internet.

Caso d'uso: chiamata uno-a-uno

Una chiamata uno-a-uno significa che un utente chiama direttamente un altro utente. Per inizializzare la chiamata all'SDK chiamante, ottenere un set di candidati costituiti da indirizzi IP e porte, inclusi i candidati locali, di inoltro e riflessivi (indirizzo IP pubblico del client, come illustrato dall'inoltro). L'SDK del chiamante invia questi candidati all'entità chiamata; la parte chiamata ottiene anche un set simile di candidati e li invia al chiamante. I messaggi di controllo della connettività STUN vengono usati per trovare il chiamante/chiamato percorsi multimediali di entità e il percorso di lavoro migliore è selezionato. Dopo aver stabilito il percorso di connessione, viene eseguito un handshake DTLS tramite questa connessione per garantire la sicurezza. Dopo l'handshake DTLS, le chiavi SRTP vengono derivate dal processo di handshake DTLS. I supporti (ovvero i pacchetti RTP/RTCP protetti con SRTP) vengono quindi inviati usando la coppia candidata selezionata. L'inoltro di trasporto è disponibile come parte di Servizi di comunicazione di Azure.

Se l'indirizzo IP locale e i candidati alla porta o i candidati riflessivi hanno connettività, il percorso diretto tra i client (o l'uso di nat) viene selezionato per i supporti. Se i client si trovano entrambi nella rete del cliente, è necessario selezionare il percorso diretto. Ciò richiede la connettività UDP diretta all'interno della rete del cliente. Se i client sono entrambi utenti cloud nomadi, a seconda del NAT/firewall, i supporti possono usare la connettività diretta.

Se un client è interno nella rete del cliente e un client è esterno (ad esempio, un utente cloud mobile), è improbabile che sia abilitata la connettività diretta tra i candidati locali o riflessivi. In questo caso, un'opzione consiste nell'usare uno dei candidati dell'inoltro di trasporto da entrambi i client( ad esempio, il client interno ha ottenuto un candidato di inoltro dall'inoltro di trasporto in Azure; il client esterno deve essere in grado di inviare pacchetti STUN/RTP/RTCP all'inoltro di trasporto). Un'altra opzione è che il client interno invia al candidato di inoltro ottenuto dal client cloud mobile. Anche se la connettività UDP per i supporti è altamente consigliata, è supportato TCP.

Passaggi generali:

1. L'utente di Servizi di comunicazione A risolve il nome di dominio URL (DNS) usando Flow 2.
2. L'utente A alloca una porta di inoltro multimediale nell'inoltro del trasporto di Teams usando Flow 4.
3. L'utente di Servizi di comunicazione A invia un "invito" con candidati ICE che usano Flow 4 a Servizi di comunicazione.
4. Servizi di comunicazione notifica all'utente B tramite Flow 4.
5. L'utente B alloca una porta di inoltro multimediale nell'inoltro del trasporto di Teams usando Flow 4.
6. L'utente B invia "risposta" con i candidati ICE usando Flow 4, che viene inoltrato all'utente A usando Flow 4.
7. L'utente A e l'utente B richiamano i test di connettività ICE e viene selezionato il percorso multimediale migliore disponibile (vedere i diagrammi di seguito per vari casi d'uso).
8. Entrambi gli utenti inviano dati di telemetria a Servizi di comunicazione usando Flow 4.

Rete del cliente (Intranet)

Figura 2 - All'interno della rete dei clienti

Nel passaggio 7 è selezionato il flusso multimediale peer-to-peer 5.

Questa trasmissione multimediale è bidirezionale. La direzione di Flow 5 indica che un lato avvia la comunicazione dal punto di vista della connettività. In questo caso, non importa quale direzione viene usata perché entrambi gli endpoint si trovano all'interno della rete del cliente.

Rete del cliente a un utente esterno (supporto inoltrato da Teams Transport Relay)

Figura 3 - Rete del cliente a un utente esterno (supporto inoltrato da Inoltro trasporto di Azure)

Nel passaggio 7 vengono selezionati Flow 4 (dalla rete del cliente a Servizi di comunicazione) e Flow 3 (da un utente di Servizi di comunicazione mobile remoto a Servizi di comunicazione di Azure).

Questi flussi vengono inoltrati dall'inoltro del trasporto di Teams all'interno di Azure.

Questa trasmissione multimediale è bidirezionale. La direzione indica il lato che avvia la comunicazione dal punto di vista della connettività. In questo caso, questi flussi vengono usati per la segnalazione e i supporti, usando protocolli e indirizzi di trasporto diversi.

Rete del cliente a utente esterno (supporto diretto)

Figura 4 - Rete del cliente a utente esterno (supporto diretto)

Nel passaggio 7 viene selezionato Flow 2 (dalla rete del cliente al peer del client tramite Internet).

I supporti diretti con un utente mobile remoto (non inoltrato tramite Azure) sono facoltativi. In altre parole, è possibile bloccare questo percorso per applicare un percorso multimediale tramite un inoltro di trasporto in Azure.

Questa trasmissione multimediale è bidirezionale. La direzione di Flow 2 per l'utente mobile remoto indica che un lato avvia la comunicazione dal punto di vista della connettività.

Utente VPN a utente interno (supporto inoltrato da Inoltro trasporto Teams)

Figura 5 - Utente VPN all'utente interno (supporto inoltrato da Inoltro di Azure)

La segnalazione tra la VPN e la rete del cliente usa Flow 2*. La segnalazione tra la rete del cliente e Azure usa Flow 4. Tuttavia, i supporti ignorano la VPN e vengono instradati usando Flussi 3 e 4 tramite Inoltro multimediale di Azure.

Utente VPN a utente interno (supporto diretto)

Figura 6 - Utente VPN all'utente interno (supporto diretto)

La segnalazione tra la VPN e la rete del cliente usa Flow 2'. La segnalazione tra la rete del cliente e Azure usa il flusso 4. Tuttavia, i supporti ignorano la VPN e vengono instradati usando il flusso 2 dalla rete del cliente a Internet.

Questa trasmissione multimediale è bidirezionale. La direzione di Flow 2 all'utente di dispositivi mobili remoti indica che un lato avvia la comunicazione dal punto di vista della connettività.

Utente VPN a utente esterno (supporto diretto)

Figura 7 - Utente VPN a utente esterno (supporto diretto)

La segnalazione tra l'utente VPN e la rete del cliente usa Flow 2* e Flow 4 in Azure. Tuttavia, i supporti ignorano la VPN e vengono instradati usando Flow 6.

Questa trasmissione multimediale è bidirezionale. La direzione di Flow 6 all'utente di dispositivi mobili remoti indica che un lato avvia la comunicazione dal punto di vista della connettività.

Caso d'uso: client di Servizi di comunicazione a PSTN tramite trunk di Servizi di comunicazione

Servizi di comunicazione consente di effettuare e ricevere chiamate dalla rete PSTN (Public Switched Telephone Network). Se il trunk PSTN è connesso tramite numeri di telefono forniti da Servizi di comunicazione, non sono previsti requisiti di connettività speciali per questo caso d'uso. Se si vuole connettere il proprio trunk PSTN locale a Servizi di comunicazione di Azure, è possibile usare il routing diretto di Azure (disponibile in CY2021).

Figura 8 : Utente di Servizi di comunicazione con PSTN tramite Trunk di Azure

In questo caso, la segnalazione e i supporti dalla rete del cliente ad Azure usano Flow 4.

Caso d'uso: chiamate di gruppo di Servizi di comunicazione

Il servizio di condivisione audio/video/schermo (VBSS) fa parte di Servizi di comunicazione di Azure. 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 servizio.

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

Figura 9 - Chiamate di gruppo di Servizi di comunicazione

Restrizioni di interoperabilità

Il flusso multimediale attraverso Servizi di comunicazione di Azure è limitato come indicato di seguito:

Il controller SBC (Session Border Controller) di terze parti sul limite con PSTN deve terminare il flusso RTP/RTCP, protetto con SRTP e non inoltrarlo all'hop successivo. Se si inoltra il flusso all'hop successivo, potrebbe non essere compreso.

Server proxy SIP di terze parti. Una finestra di dialogo SIP di segnalazione di Servizi di comunicazione con un SBC di terze parti e/o un gateway può attraversare proxy SIP nativi microsoft (proprio come Teams). L'interoperabilità con proxy SIP di terze parti non è supportata.

B2BUA (o SBC) di terze parti. Il flusso multimediale di Servizi di comunicazione da e verso la rete PSTN viene terminato da un SBC di terze parti. L'interoperabilità con un SBC di terze parti all'interno della rete di Servizi di comunicazione (in cui un SBC di terze parti media due endpoint di Servizi di comunicazione) non è supportato.

Tecnologie non supportate

Rete VPN. Servizi di comunicazione non supporta la trasmissione multimediale tramite VPN. Se gli utenti usano client VPN, il client deve suddividere e instradare il traffico multimediale su una connessione non VPN come specificato in Abilitazione dei supporti Lync per ignorare un tunnel VPN.

Shaper di pacchetti. I dispositivi di profilatura dei pacchetti, ispezione dei pacchetti o data shaping dei pacchetti non sono supportati e possono compromettere significativamente la qualità.

Passaggi successivi

I documenti seguenti possono essere interessanti:

• Altre informazioni sui tipi di chiamate
• Informazioni sull'architettura client-server