Oproepstroomtopologieën

In dit artikel worden oproeptopologieën van Azure Communication Services beschreven. In dit artikel vindt u meer informatie over netwerkconcepten voor Azure Communication Services, hoe het aanroepen van verkeer wordt versleuteld en voor een inleiding tot Communication Services-oproepstromen raadpleegt u de conceptuele documentatie over oproepstromen.

Achtergrond

Netwerkconcepten

Voordat u gespreksstroomtopologieën bekijkt, definiëren we enkele termen waarnaar in het hele document wordt verwezen.

Een klantnetwerk bevat netwerksegmenten die u beheert. Dit kan onder andere bekabelde en draadloze netwerken zijn binnen uw kantoor of tussen kantoren, datacenters en internetproviders.

Een klantnetwerk heeft meestal verschillende netwerkperimeters met firewalls en/of proxyservers die het beveiligingsbeleid van uw organisatie afdwingen. We raden u aan een uitgebreide netwerkevaluatie uit te voeren om optimale prestaties en kwaliteit van uw communicatieoplossing te garanderen.

Het Communication Services-netwerk is het netwerk dat Ondersteuning biedt voor Azure Communication Services. Dit netwerk wordt beheerd door Microsoft en wordt wereldwijd gedistribueerd met datacenters die eigendom zijn van Microsoft het dichtst bij eindgebruikers. Dit netwerk is verantwoordelijk voor transportrelais, mediaverwerking voor groepsgesprekken en andere onderdelen die ondersteuning bieden voor uitgebreide realtime mediacommunicatie.

Soorten verkeer

Communication Services is voornamelijk gebaseerd op twee soorten verkeer: realtime media en signalering.

Realtime media worden verzonden met behulp van het Realtime Transport Protocol (RTP). Dit protocol ondersteunt gegevensoverdracht via audio, video en scherm delen. Deze gegevens zijn gevoelig voor netwerklatentieproblemen. Hoewel het mogelijk is om realtime media te verzenden met TCP of HTTP, raden we u aan UDP te gebruiken als het transportlaagprotocol ter ondersteuning van hoogwaardige eindgebruikerservaringen. Nettoladingen van media die via RTP worden verzonden, worden beveiligd met SRTP.

Gebruikers van uw Communication Services-oplossing maken verbinding met uw services vanaf hun clientapparaten. Communicatie tussen deze apparaten en uw servers wordt verwerkt met signalering. Bijvoorbeeld: het starten van oproepen en realtime chatten wordt ondersteund door signalering tussen apparaten en uw service. Het meeste signaleringsverkeer maakt gebruik van HTTPS REST, maar in sommige scenario's kan SIP worden gebruikt als een signaleringsverkeersprotocol. Hoewel dit type verkeer minder gevoelig is voor latentie, geeft signalering met lage latentie de gebruikers van uw oplossing een aangename ervaring voor eindgebruikers.

Mediaversleuteling

Oproepstromen in Azure Communication Services die SDK- en Teams-clients aanroepen, zijn gebaseerd op het RFC 8866-aanbiedings - en antwoordmodel van Session Description Protocol (SDP) via HTTPS. Zodra de gebruiker een inkomende oproep accepteert, gaan de beller en de beller akkoord met de sessieparameters.

Mediaverkeer wordt versleuteld en stromen tussen de beller en de aanroeper met behulp van Secure RTP (SRTP), een profiel van Real-Time Transport Protocol (RTP) dat vertrouwelijkheid, verificatie en aanvalsbeveiliging voor RTP-verkeer biedt. In de meeste gevallen wordt onderhandeld over client-naar-clientmediaverkeer via client-naar-serververbindingssignalering en wordt versleuteld met BEHULP van SRTP wanneer deze rechtstreeks van client naar client gaat.

Azure Communication Services die SDK aanroept, gebruikt DTLS om een versleutelingssleutel af te leiden. Zodra de DTLS-handshake is voltooid, begint de media te stromen met behulp van deze DTLS-versleutelingssleutel via SRTP.

Azure Communication Services die SDK- en Teams-clients aanroepen, maakt gebruik van een token op basis van referenties voor beveiligde toegang tot mediarelais via TURN. Mediarelais wisselen het token uit via een met TLS beveiligd kanaal.

Mediaverkeer van Azure Communication Services tussen twee eindpunten die deelnemen aan audio, video en video delen van Azure Communication Services maakt gebruik van SRTP om de mediastroom te versleutelen. Cryptografische sleutels worden onderhandeld tussen de twee eindpunten via een signaleringsprotocol, dat gebruikmaakt van TLS 1.2 en AES-256 (in de GCM-modus) versleuteldE UDP/TCP-kanaal.

Principes voor oproepstroom

Er zijn vier algemene principes die azure Communication Services-oproepstromen ondersteunen:

• De eerste deelnemer van een Communication Services-groepsoproep bepaalt de regio waarin de oproep wordt gehost. Er zijn uitzonderingen op deze regel in sommige topologieën, die hieronder worden beschreven.
• Het media-eindpunt dat wordt gebruikt om een Communication Services-oproep te ondersteunen, wordt geselecteerd op basis van de mediaverwerkingsbehoeften en wordt niet beïnvloed door het aantal deelnemers aan een gesprek. Een punt-naar-punt-oproep kan bijvoorbeeld een media-eindpunt in de cloud gebruiken om media te verwerken voor transcriptie of opname, terwijl een gesprek met twee deelnemers mogelijk geen media-eindpunten gebruikt. Groepsoproepen maken gebruik van een media-eindpunt voor meng- en routeringsdoeleinden. Dit eindpunt wordt geselecteerd op basis van de regio waarin de aanroep wordt gehost. Mediaverkeer dat van een client naar het media-eindpunt wordt verzonden, kan rechtstreeks worden gerouteerd of het kan een transportrelay in Azure gebruiken als de firewallbeperkingen van de klant dit vereisen.
• Mediaverkeer voor peer-to-peer-aanroepen neemt de meest directe route die beschikbaar is, ervan uitgaande dat de oproep geen media-eindpunt in de cloud nodig heeft. De voorkeursroute is rechtstreeks naar de externe peer (client). Als er geen directe route beschikbaar is, stuurt een of meer transportrelais het verkeer door. Mediaverkeer mag geen transversale servers zijn die fungeren als pakketshapers, VPN-servers of andere functies die de verwerking kunnen vertragen en de eindgebruikerservaring kunnen verminderen.
• Signaleringsverkeer gaat altijd naar de server die zich het dichtst bij de gebruiker bevindt.

Raadpleeg de conceptuele documentatie voor oproepstromen voor meer informatie over het gekozen mediapad.

Oproepstromen in verschillende topologieën

Communication Services (internet)

Deze topologie wordt gebruikt door klanten die Communication Services uit de cloud gebruiken zonder on-premises implementatie, zoals directe routering van Azure. In deze topologie stromen verkeer van en naar Communication Services via internet.

Afbeelding 1: Communication Services-topologie

De richting van de pijlen in het bovenstaande diagram weerspiegelt de beginrichting van de communicatie die van invloed is op de connectiviteit op de bedrijfsperimeter. In het geval van UDP voor media kunnen de eerste pakketten in omgekeerde richting stromen, maar deze pakketten kunnen worden geblokkeerd totdat pakketten in de andere richting stromen.

Stroombeschrijvingen:

• Flow 2: vertegenwoordigt een stroom die is geïnitieerd door een gebruiker in het klantnetwerk naar internet als onderdeel van de Communication Services-ervaring van de gebruiker. Voorbeelden van deze stromen zijn DNS- en peer-to-peermediaoverdracht.
• Flow 2': vertegenwoordigt een stroom die is geïnitieerd door een externe mobile Communication Services-gebruiker, met VPN naar het klantnetwerk.
• Flow 3: vertegenwoordigt een stroom die is geïnitieerd door een externe mobile Communication Services-gebruiker naar Communication Services-eindpunten.
• Flow 4: vertegenwoordigt een stroom die is geïnitieerd door een gebruiker in het klantnetwerk naar Communication Services.
• Flow 5: vertegenwoordigt een peer-to-peermediastroom tussen de ene Communication Services-gebruiker en een andere binnen het klantnetwerk.
• Flow 6: vertegenwoordigt een peer-to-peermediastroom tussen een externe mobile Communication Services-gebruiker en een andere externe mobile Communication Services-gebruiker via internet.

Use case: Een-op-een-bellen

Een een-op-een-oproep betekent dat een gebruiker rechtstreeks een andere gebruiker aanroept. Om de aanroep te initialiseren, verkrijgt de aanroepende SDK een reeks kandidaten die bestaan uit IP-adressen en poorten, waaronder lokale, relay en reflexieve (openbare IP-adressen van client zoals gezien door de relay) kandidaten. De aanroeper-SDK stuurt deze kandidaten naar de aangeroepen partij; de gebelde partij krijgt ook een vergelijkbare set kandidaten en stuurt deze naar de beller. STUN-connectiviteitscontroleberichten worden gebruikt om te vinden welke beller/gebelde mediapaden werken en het beste werkpad is geselecteerd. Zodra het verbindingspad tot stand is gebracht, wordt er via deze verbinding een DTLS-handshake uitgevoerd om de beveiliging te garanderen. Na de DTLS-handshake worden de SRTP-sleutels afgeleid van het DTLS-handshakeproces. Media (dat wil gezegd, RTP/RTCP-pakketten die zijn beveiligd met SRTP) worden vervolgens verzonden met behulp van het geselecteerde kandidaatpaar. De transportrelais is beschikbaar als onderdeel van Azure Communication Services.

Als het lokale IP-adres en de poortkandidaten of de reflexieve kandidaten verbinding hebben, wordt het directe pad tussen de clients (of het gebruik van een NAT) geselecteerd voor media. Als de clients beide zich in het netwerk van de klant bevinden, moet het directe pad worden geselecteerd. Hiervoor is directe UDP-connectiviteit in het klantnetwerk vereist. Als de clients beide nomadische cloudgebruikers zijn, kunnen media, afhankelijk van de NAT/firewall, directe connectiviteit gebruiken.

Als één client intern is op het klantnetwerk en één client extern is (bijvoorbeeld een mobiele cloudgebruiker), is het onwaarschijnlijk dat directe connectiviteit tussen de lokale of reflexieve kandidaten is ingeschakeld. In dit geval is een optie om een van de transportrelaiskandidaten van een van beide clients te gebruiken (de interne client heeft bijvoorbeeld een relaykandidaat verkregen van de transportrelais in Azure; de externe client moet STUN/RTP/RTCP-pakketten kunnen verzenden naar de transportrelais). Een andere optie is dat de interne client verzendt naar de relay-kandidaat die is verkregen door de mobiele cloudclient. Hoewel UDP-connectiviteit voor media sterk wordt aanbevolen, wordt TCP ondersteund.

Stappen op hoog niveau:

1. Communication Services-gebruiker A zet DE URL-domeinnaam (DNS) om met behulp van Flow 2.
2. Gebruiker A wijst een mediarelaispoort toe aan de Teams-transportrelais met behulp van Flow 4.
3. Communication Services-gebruiker A verzendt een 'uitnodiging' met ICE-kandidaten met behulp van Flow 4 naar Communication Services.
4. Communication Services meldt Gebruiker B met Flow 4.
5. Gebruiker B wijst een mediarelaispoort toe aan Teams-transportrelais met behulp van Flow 4.
6. Gebruiker B verzendt 'antwoord' met ICE-kandidaten met behulp van Flow 4, die wordt doorgestuurd naar Gebruiker A met behulp van Flow 4.
7. Gebruiker A en Gebruiker B roepen ICE-connectiviteitstests aan en het beste beschikbare mediapad is geselecteerd (zie de onderstaande diagrammen voor verschillende gebruiksscenario's).
8. Beide gebruikers verzenden telemetrie naar Communication Services met behulp van Flow 4.

Klantnetwerk (intranet)

Afbeelding 2: binnen het netwerk van de klant

In stap 7 is peer-to-peermedia Flow 5 geselecteerd.

Deze mediaoverdracht is bidirectioneel. De richting van Flow 5 geeft aan dat één kant de communicatie vanuit een connectiviteitsperspectief initieert. In dit geval maakt het niet uit welke richting wordt gebruikt, omdat beide eindpunten zich binnen het klantnetwerk bevinden.

Klantnetwerk naar externe gebruiker (media die worden doorgestuurd door Teams Transport Relay)

Afbeelding 3: Klantnetwerk naar externe gebruiker (media die worden doorgestuurd door Azure Transport Relay)

In stap 7 worden Flow 4 (van het klantnetwerk naar Communication Services) en Flow 3 (van een externe mobiele Communication Services-gebruiker naar Azure Communication Services) geselecteerd.

Deze stromen worden door Teams Transport Relay binnen Azure doorgestuurd.

Deze mediaoverdracht is bidirectioneel. De richting geeft aan welke kant de communicatie vanuit een connectiviteitsperspectief initieert. In dit geval worden deze stromen gebruikt voor signalering en media, met behulp van verschillende transportprotocollen en adressen.

Klantnetwerk naar externe gebruiker (directe media)

Afbeelding 4: Klantnetwerk naar externe gebruiker (directe media)

In stap 7 is Flow 2 (van klantnetwerk naar de peer van de client via internet) geselecteerd.

Directe media met een externe mobiele gebruiker (niet doorgegeven via Azure) is optioneel. Met andere woorden, u kunt dit pad blokkeren om een mediapad af te dwingen via een transportrelay in Azure.

Deze mediaoverdracht is bidirectioneel. De richting van Flow 2 naar een externe mobiele gebruiker geeft aan dat één kant de communicatie vanuit een connectiviteitsperspectief initieert.

VPN-gebruiker naar interne gebruiker (media die door Teams Transport Relay worden doorgestuurd)

Afbeelding 5: VPN-gebruiker naar interne gebruiker (media die door Azure Relay worden doorgestuurd)

Signalering tussen het VPN en het klantnetwerk maakt gebruik van Flow 2*. Signalering tussen het klantnetwerk en Azure maakt gebruik van Flow 4. Media omzeilen echter de VPN en worden gerouteerd met stromen 3 en 4 via Azure Media Relay.

VPN-gebruiker naar interne gebruiker (directe media)

Afbeelding 6: VPN-gebruiker naar interne gebruiker (directe media)

Signalering tussen het VPN en het klantnetwerk maakt gebruik van Flow 2.' Signalering tussen het klantnetwerk en Azure maakt gebruik van stroom 4. Media omzeilen echter de VPN en worden gerouteerd met behulp van stroom 2 van het netwerk van de klant naar internet.

Deze mediaoverdracht is bidirectioneel. De richting van Flow 2 naar de externe mobiele gebruiker geeft aan dat één kant de communicatie vanuit een connectiviteitsperspectief initieert.

VPN-gebruiker naar externe gebruiker (directe media)

Afbeelding 7: VPN-gebruiker naar externe gebruiker (directe media)

Signalering tussen de VPN-gebruiker en het klantnetwerk maakt gebruik van Flow 2* en Flow 4 naar Azure. Media omzeilen ECHTER VPN en worden gerouteerd met Flow 6.

Deze mediaoverdracht is bidirectioneel. De richting van Flow 6 naar de externe mobiele gebruiker geeft aan dat één kant de communicatie vanuit een connectiviteitsperspectief initieert.

Use Case: Communication Services-client naar PSTN via Communication Services Trunk

Communication Services staat het plaatsen en ontvangen van oproepen van het Public Switched Telephone Network (PSTN) toe. Als de PSTN-trunk is verbonden met behulp van telefoonnummers van Communication Services, zijn er geen speciale connectiviteitsvereisten voor deze use-case. Als u uw eigen on-premises PSTN-trunk wilt verbinden met Azure Communication Services, kunt u directe routering van Azure gebruiken (beschikbaar in CY2021).

Afbeelding 8: Communication Services-gebruiker naar PSTN via Azure Trunk

In dit geval gebruiken signalering en media van het klantnetwerk naar Azure Flow 4.

Use case: Communication Services-groepsoproepen

De SERVICE voor audio/video/scherm delen (VBSS) maakt deel uit van Azure Communication Services. Het heeft een openbaar IP-adres dat bereikbaar moet zijn vanuit het klantnetwerk en moet bereikbaar zijn vanaf een Nomadic Cloud-client. Elke client/elk eindpunt moet verbinding kunnen maken met de service.

Interne klanten krijgen lokale, reflexieve en relay kandidaten op dezelfde manier als beschreven voor een-op-een-oproepen. De klanten sturen deze kandidaten naar de service in een uitnodiging. De service gebruikt geen relay omdat het een openbaar bereikbaar IP-adres heeft, zodat deze reageert met de kandidaat voor het lokale IP-adres. De client en de service controleren de connectiviteit op dezelfde manier die wordt beschreven voor een-op-een-aanroepen.

Afbeelding 9: Communicatieservices-groepsgesprekken

Beperkingen voor interoperabiliteit

Media die door Azure Communication Services stromen, worden als volgt beperkt:

SBC (Session Border Controller) van derden op de grens met PSTN moet de RTP-/RTCP-stream beëindigen, beveiligd met SRTP en deze niet doorsturen naar de volgende hop. Als u de stroom doorgeeft aan de volgende hop, wordt deze mogelijk niet begrepen.

SIP-proxyservers van derden. Een Communication Services-signalering sip-dialoogvenster met een externe SBC en/of gateway kan systeemeigen SIP-proxy's van Microsoft doorlopen (net als Teams). Interoperabiliteit met SIP-proxy's van derden wordt niet ondersteund.

B2BUA (of SBC) van derden. Communication Services-mediastroom van en naar het PSTN wordt beëindigd door een externe SBC. Interoperabiliteit met een externe SBC binnen het Communication Services-netwerk (waarbij een externe SBC twee Communication Services-eindpunten mediaeert) wordt niet ondersteund.

Niet-ondersteunde technologieën

VPN-netwerk. Communication Services biedt geen ondersteuning voor mediaoverdracht via VPN's. Als uw gebruikers VPN-clients gebruiken, moet de client mediaverkeer splitsen en routeren via een niet-VPN-verbinding zoals opgegeven in Lync-media om een VPN-tunnel te omzeilen.

Notitie

Hoewel de titel lync aangeeft, is deze van toepassing op Azure Communication Services en Teams.*

Pakketshapers. Pakketknipsels, pakketinspectie of apparaten voor het vormgeven van pakketten worden niet ondersteund en kunnen de kwaliteit aanzienlijk afnemen.

Volgende stappen

Aan de slag met oproepen

De volgende documenten zijn mogelijk interessant voor u:

• Meer informatie over oproeptypen
• Meer informatie over Client-serverarchitectuur