Nozioni di base sul flusso di chiamata

La sezione seguente offre una panoramica dei flussi di chiamate in Servizi di comunicazione di Azure. I flussi multimediali e di segnalazione dipendono dai tipi di chiamate effettuate dagli utenti. Esempi di tipi di chiamate sono le chiamate VoIP uno-a-uno, PSTN uno-a-uno e di gruppo che contengono una combinazione di partecipanti VoIP e connessi a PSTN. Esaminare i tipi di chiamate.

Informazioni sui protocolli multimediali e di segnalazione

Quando si stabilisce una chiamata peer-to-peer o di gruppo, vengono usati due protocolli in background: HTTPS (REST) per la segnalazione e SRTP per i supporti.

La segnalazione tra gli SDK o tra SDK e i controller di segnalazione di Servizi di comunicazione viene gestita con HTTPS REST (TLS). Servizi di comunicazione di Azure usa TLS 1.2. Per il traffico multimediale in tempo reale (RTP), è preferibile il protocollo UDP (User Datagram Protocol). Se l'uso di UDP viene impedito dal firewall, l'SDK userà il protocollo TCP (Transmission Control Protocol) per i supporti.

Di seguito vengono descritti i protocolli multimediali e di segnalazione in diversi scenari.

Casi di flussi di chiamate

Caso 1: VoIP in cui è possibile stabilire una connessione diretta tra due dispositivi

Nelle chiamate video o VoIP uno-a-uno, il traffico preferisce il percorso più diretto. "Percorso diretto" significa che se due SDK possono raggiungere l'uno dall'altro direttamente, stabiliranno una connessione diretta. Ciò è in genere possibile quando due SDK si trovano nella stessa subnet (ad esempio, in una subnet 192.168.1.0/24) o due quando i dispositivi si trovano in subnet che possono vedersi tra loro (SDK nella subnet 10.10.0.0/16 e 192.168.1.0/24 possono raggiungere l'uno dall'altro).

Caso 2: VoIP in cui non è possibile stabilire una connessione diretta tra i dispositivi, ma dove è possibile connettersi tra dispositivi NAT

Se due dispositivi si trovano in subnet che non possono raggiungere l'una dall'altra (ad esempio, Alice lavora da un bar e Bob lavora dalla sua sede), ma la connessione tra i dispositivi NAT è possibile, gli SDK lato client stabiliranno la connettività tramite dispositivi NAT.

Per Giorgia, sarà il NAT del bar e per Davide sarà il NAT dell'ufficio. Il dispositivo di Giorgia invierà l'indirizzo esterno del NAT e il dispositivo di Davide eseguirà la stessa operazione. Gli SDK apprendono gli indirizzi esterni da un servizio STUN (Session Traversal Utilities for NAT) che Servizi di comunicazione di Azure fornisce gratuitamente. La logica che gestisce l'handshake tra Alice e Bob è incorporata all'interno degli SDK forniti Servizi di comunicazione di Azure. Non è necessaria alcuna configurazione aggiuntiva.

Caso 3: VoIP in cui non è possibile né una connessione DIRETTA né NAT

Se uno o entrambi i dispositivi client si trovano dietro un NAT simmetrico, è necessario un servizio cloud separato per inoltrare i supporti tra i due SDK. Questo servizio viene chiamato TURN (Traversal Using Relays around NAT) e viene fornito da Servizi di comunicazione. Communication Services Calling SDK usa automaticamente i servizi TURN in base alle condizioni di rete rilevate. Gli addebiti TURN sono inclusi nel prezzo della chiamata.

Caso 4: Raggruppare le chiamate con PSTN

Sia la segnalazione che i file multimediali per le chiamate PSTN usano la risorsa di telefonia di Servizi di comunicazione di Azure. Questa risorsa è interconnessa con altri gestori telefonici.

Il traffico multimediale PSTN attraversa un componente denominato processore di contenuti multimediali.

Per le chiamate di gruppo, i file multimediali e le segnalazioni vengono sempre propagati tramite il back-end di Servizi di comunicazione di Azure. L'audio e/o il video di tutti i partecipanti risulta combinato nel componente del processore di contenuti multimediali. Tutti i membri di una chiamata di gruppo inviano i flussi audio e/o video al processore di contenuti multimediali, che restituisce flussi multimediali misti.

Il protocollo RTP (Real-Time Protocol) predefinito per le chiamate di gruppo è UDP (User Datagram Protocol).

Se l'SDK non può usare UDP per i supporti a causa di restrizioni del firewall, verrà effettuato un tentativo di usare il protocollo TCP (Transmission Control Protocol). Si noti che il componente del processore di contenuti multimediali richiede UDP, quindi, in questo caso, il servizio TURN di Servizi di comunicazione verrà aggiunto alla chiamata di gruppo per convertire TCP in UDP. Gli addebiti TURN sono inclusi nel prezzo della chiamata.

Caso 5: Communication Services SDK e Microsoft Teams in una riunione pianificata di Teams

La segnalazione passa attraverso il controller di segnalazione. I supporti passano attraverso il processore multimediale. Il controller di segnalazione e il processore di contenuti multimediali sono condivisi tra Servizi di comunicazione e Microsoft Teams.

Caso 6: Supporti iniziali

Fa riferimento ai supporti (ad esempio, audio e video) scambiati prima che una determinata sessione venga accettata dall'utente chiamato. Se è presente un flusso multimediale iniziale, il SBC deve eseguire il latch al primo endpoint che avvia lo streaming multimediale; il flusso multimediale può iniziare prima che i candidati vengano nominati. L'SBC deve avere il supporto per l'invio di DTMF durante questa fase per abilitare gli scenari di IVR/segreteria telefonica. Il SBC deve usare il percorso con priorità più alta in cui ha ricevuto controlli se le nomination non sono state completate.

Passaggi successivi

I documenti seguenti possono essere interessanti:

• Altre informazioni sui tipi di chiamate
• Informazioni sull'architettura client-server
• Informazioni sulle topologie del flusso di chiamata