Anropsflödestopologier

I den här artikeln beskrivs topologier för Azure Communication Services-anropsflöden. I den här artikeln får du lära dig mer om nätverksbegrepp för Azure Communication Services, hur samtalstrafik krypteras och En introduktion till Kommunikationstjänsters samtalsflöden finns i den konceptuella dokumentationen för samtalsflöden.

Bakgrund

Nätverksbegrepp

Innan vi granskar anropsflödestopologier definierar vi vissa termer som refereras till i hela dokumentet.

Ett kundnätverk innehåller alla nätverkssegment som du hanterar. Detta kan omfatta kabelanslutna och trådlösa nätverk på kontoret eller mellan kontor, datacenter och internetleverantörer.

Ett kundnätverk har vanligtvis flera nätverksperimeter med brandväggar och/eller proxyservrar som tillämpar organisationens säkerhetsprinciper. Vi rekommenderar att du utför en omfattande nätverksutvärdering för att säkerställa optimala prestanda och kvalitet för din kommunikationslösning.

Communication Services-nätverket är det nätverk som stöder Azure Communication Services. Det här nätverket hanteras av Microsoft och distribueras över hela världen med Microsoft-ägda datacenter närmast slutkunder. Det här nätverket ansvarar för transportrelä, mediebearbetning för gruppanrop och andra komponenter som stöder omfattande mediekommunikation i realtid.

Typer av trafik

Communication Services bygger främst på två typer av trafik: realtidsmedia och signalering.

Realtidsmedia överförs med hjälp av RTP (Real-time Transport Protocol). Det här protokollet stöder överföring av ljud-, video- och skärmdelningsdata. Dessa data är känsliga för problem med nätverksfördröjning. Även om det är möjligt att överföra realtidsmedier med TCP eller HTTP rekommenderar vi att du använder UDP som transportlagerprotokoll för att stödja slutanvändarupplevelser med höga prestanda. Medienyttolaster som överförs via RTP skyddas med hjälp av SRTP.

Användare av din Communication Services-lösning ansluter till dina tjänster från sina klientenheter. Kommunikationen mellan dessa enheter och dina servrar hanteras med signalering. Till exempel: samtalsinitiering och realtidschatt stöds genom signalering mellan enheter och din tjänst. De flesta signaltrafik använder HTTPS REST, men i vissa scenarier kan SIP användas som ett signaltrafikprotokoll. Även om den här typen av trafik är mindre känslig för svarstid, ger signaler med låg svarstid användarna av din lösning en trevlig slutanvändarupplevelse.

Mediekryptering

Samtalsflöden i Azure Communication Services som anropar SDK och Teams-klienter baseras på erbjudandet och svarsmodellen för Sessionsbeskrivningsprotokoll (SDP) RFC 8866 via HTTPS. När anroparen har accepterat ett inkommande samtal kommer anroparen och anroparen överens om sessionsparametrarna.

Medietrafiken krypteras och flödar mellan anroparen och anroparen med hjälp av Secure RTP (SRTP), en profil för RTP (Real-time Transport Protocol) som tillhandahåller konfidentialitet, autentisering och återspelningsattackskydd för RTP-trafik. I de flesta fall förhandlas klient-till-klientmedietrafik via klient-till-server-anslutningssignalering och krypteras med SRTP när den går direkt från klient till klient.

Azure Communication Services som anropar SDK använder DTLS för att härleda en krypteringsnyckel. När DTLS-handskakningen är klar börjar mediet flöda med den här DTLS-förhandlade krypteringsnyckeln över SRTP.

Azure Communication Services-anropande SDK- och Teams-klienter använder en autentiseringsbaserad token för säker åtkomst till mediereläer via TURN. Mediareläer utbyter token över en TLS-skyddad kanal.

Azure Communication Services-medietrafik mellan två slutpunkter som deltar i Ljud-, video- och videodelning i Azure Communication Services använder SRTP för att kryptera medieströmmen. Kryptografiska nycklar förhandlas mellan de två slutpunkterna över ett signalprotokoll, som använder TLS 1.2 och AES-256 (i GCM-läge) krypterad UDP/TCP-kanal.

Principer för samtalsflöde

Det finns fyra allmänna principer som ligger till grund för Azure Communication Services-samtalsflöden:

• Den första deltagaren i ett communication services-gruppanrop avgör i vilken region anropet finns. Det finns undantag till den här regeln i vissa topologier, som beskrivs nedan.
• Medieslutpunkten som används för att stödja ett Communication Services-anrop väljs baserat på mediebearbetningsbehov och påverkas inte av antalet deltagare i ett samtal. Ett punkt-till-punkt-samtal kan till exempel använda en medieslutpunkt i molnet för att bearbeta media för transkription eller inspelning, medan ett samtal med två deltagare kanske inte använder några medieslutpunkter. Gruppanrop använder en medieslutpunkt för blandning och routning. Den här slutpunkten väljs baserat på den region där anropet finns. Medietrafik som skickas från en klient till medieslutpunkten kan dirigeras direkt eller använda ett transportrelä i Azure om kundens nätverksbrandväggsbegränsningar kräver det.
• Medietrafik för peer-to-peer-anrop tar den mest direkta vägen som är tillgänglig, förutsatt att anropet inte behöver någon medieslutpunkt i molnet. Den föredragna vägen är direkt till fjärr-peer (klienten). Om en direktväg inte är tillgänglig vidarebefordrar en eller flera transportreläer trafiken. Medietrafik bör inte övergående servrar som fungerar som paketformare, VPN-servrar eller andra funktioner som kan fördröja bearbetningen och försämra slutanvändarupplevelsen.
• Signaltrafik går alltid till den server som är närmast användaren.

Mer information om den mediesökväg som väljs finns i den konceptuella dokumentationen för samtalsflöden.

Anropa flöden i olika topologier

Kommunikationstjänster (Internet)

Den här topologin används av kunder som använder Kommunikationstjänster från molnet utan någon lokal distribution, till exempel Azure-direktdirigering. I den här topologin flödar trafik till och från Communication Services via Internet.

Bild 1 – Kommunikationstjänsters topologi

Pilarnas riktning i diagrammet ovan visar initieringsriktningen för den kommunikation som påverkar anslutningen vid företagsperimetern. När det gäller UDP för media kan de första paketen flöda i omvänd riktning, men dessa paket kan blockeras tills paketen i den andra riktningen flödar.

Flödesbeskrivningar:

• Flow 2 – Representerar ett flöde som initierats av en användare i kundnätverket till Internet som en del av användarens kommunikationstjänstupplevelse. Exempel på dessa flöden är DNS- och peer-to-peer-medieöverföring.
• Flow 2' – Representerar ett flöde som initierats av en fjärransluten användare av kommunikationstjänster med VPN till kundnätverket.
• Flow 3 – Representerar ett flöde som initierats av en fjärransluten mobil Communication Services-användare till Communication Services-slutpunkter.
• Flow 4 – Representerar ett flöde som initierats av en användare i kundnätverket till Communication Services.
• Flöde 5 – Representerar ett peer-to-peer-medieflöde mellan en Communication Services-användare och en annan i kundnätverket.
• Flow 6 – Representerar ett peer-to-peer-medieflöde mellan en fjärransluten mobil Communication Services-användare och en annan fjärransluten mobil Communication Services-användare via Internet.

Användningsfall: 1-till-en-samtal

Ett 1-till-ett-anrop innebär att en användare anropar en annan användare direkt. För att initiera anropet får den anropande SDK:t en uppsättning kandidater som består av IP-adresser och portar, inklusive lokala kandidater, reläer och reflexiva (offentliga IP-adresser för klienten enligt reläets) kandidater. Anroparen SDK skickar dessa kandidater till den anropade parten; den anropade parten får också en liknande uppsättning kandidater och skickar dem till anroparen. STUN-anslutningskontrollmeddelanden används för att hitta vilka uppringare/anropade partmediesökvägar som fungerar och den bästa arbetssökvägen är markerad. När anslutningssökvägen har upprättats utförs en DTLS-handskakning över den här anslutningen för att säkerställa säkerheten. Efter DTLS-handskakningen härleds SRTP-nycklarna från DTLS-handskakningsprocessen. Media (dvs. RTP/RTCP-paket som skyddas med SRTP) skickas sedan med det valda kandidatparet. Transportreläet är tillgängligt som en del av Azure Communication Services.

Om den lokala IP-adressen och portkandidaterna eller de reflexiva kandidaterna har anslutning, väljs den direkta sökvägen mellan klienterna (eller använder en NAT) för media. Om klienterna båda finns i kundnätverket bör den direkta sökvägen väljas. Detta kräver direkt UDP-anslutning i kundnätverket. Om klienterna båda är nomadiska molnanvändare kan media, beroende på NAT/brandväggen, använda direktanslutning.

Om en klient är intern i kundnätverket och en klient är extern (till exempel en mobil molnanvändare) är det osannolikt att direkt anslutning mellan de lokala eller reflexiva kandidaterna skulle aktiveras. I det här fallet är ett alternativ att använda en av transportreläkandidaterna från någon av klienterna (till exempel fick den interna klienten en reläkandidat från transportreläet i Azure. Den externa klienten måste kunna skicka STUN/RTP/RTCP-paket till transportreläet). Ett annat alternativ är att den interna klienten skickar till den reläkandidat som hämtas av den mobila molnklienten. Udp-anslutning för media rekommenderas starkt, men TCP stöds.

Steg på hög nivå:

1. Communication Services-användare A löser URL-domännamn (DNS) med hjälp av Flow 2.
2. Användare A allokerar en mediareläport på Teams transportrelä med hjälp av Flow 4.
3. Communication Services-användare A skickar en "inbjudan" med ICE-kandidater med hjälp av Flow 4 till Communication Services.
4. Communication Services meddelar användare B med flow 4.
5. Användare B allokerar en mediareläport i Teams transportrelä med hjälp av Flow 4.
6. Användare B skickar "svar" med ICE-kandidater med hjälp av Flow 4, som vidarebefordras tillbaka till användare A med flow 4.
7. Användare A och användare B anropar ICE-anslutningstester och den bästa tillgängliga mediesökvägen har valts (se diagram nedan för olika användningsfall).
8. Båda användarna skickar telemetri till Kommunikationstjänster med hjälp av Flow 4.

Kundnätverk (intranät)

Bild 2 – Inom kundnätverket

I steg 7 väljs peer-to-peer-media Flow 5.

Den här medieöverföringen är dubbelriktad. Riktningen för Flow 5 anger att ena sidan initierar kommunikationen ur ett anslutningsperspektiv. I det här fallet spelar det ingen roll vilken riktning som används eftersom båda slutpunkterna finns i kundnätverket.

Kundnätverk till extern användare (media som vidarebefordras av Teams Transport Relay)

Bild 3 – Kundnätverk till extern användare (media som vidarebefordras av Azure Transport Relay)

I steg 7 väljs Flow 4 (från kundnätverket till Kommunikationstjänster) och Flow 3 (från en fjärransluten mobil Communication Services-användare till Azure Communication Services).

Dessa flöden vidarebefordras av Teams Transport Relay i Azure.

Den här medieöverföringen är dubbelriktad. Riktningen anger vilken sida som initierar kommunikationen ur ett anslutningsperspektiv. I det här fallet används dessa flöden för signalering och media, med olika transportprotokoll och adresser.

Kundnätverk till extern användare (direktmedia)

Bild 4 – Kundnätverk till extern användare (direktmedia)

I steg 7 väljs Flow 2 (från kundnätverk till klientens peer via Internet).

Direktmedia med en fjärransluten mobil användare (som inte vidarebefordras via Azure) är valfritt. Med andra ord kan du blockera den här sökvägen för att framtvinga en mediesökväg via ett transportrelä i Azure.

Den här medieöverföringen är dubbelriktad. Riktningen för Flow 2 till en fjärransluten mobil användare anger att ena sidan initierar kommunikationen ur ett anslutningsperspektiv.

VPN-användare till intern användare (media som vidarebefordras av Teams Transport Relay)

Bild 5 – VPN-användare till intern användare (medier som vidarebefordras av Azure Relay

Signalering mellan VPN till kundnätverket använder Flow 2*. Signalering mellan kundnätverket och Azure använder Flow 4. Media kringgår dock VPN och dirigeras med hjälp av flöden 3 och 4 via Azure Media Relay.

VPN-användare till intern användare (direktmedia)

Bild 6 – VPN-användare till intern användare (direktmedia)

Signalering mellan VPN till kundnätverket använder Flow 2". Signalering mellan kundnätverket och Azure använder flöde 4. Media kringgår dock VPN och dirigeras med flöde 2 från kundnätverket till Internet.

Den här medieöverföringen är dubbelriktad. Riktningen för Flow 2 till den fjärranslutna mobila användaren anger att ena sidan initierar kommunikationen ur ett anslutningsperspektiv.

VPN-användare till extern användare (direktmedia)

Bild 7 – VPN-användare till extern användare (direktmedia)

Signalering mellan VPN-användaren till kundnätverket använder Flow 2* och Flow 4 till Azure. Media kringgår dock VPN och dirigeras med flow 6.

Den här medieöverföringen är dubbelriktad. Riktningen för Flow 6 till den fjärranslutna mobila användaren anger att ena sidan initierar kommunikationen ur ett anslutningsperspektiv.

Användningsfall: Communication Services-klient till PSTN via Communication Services Trunk

Med Kommunikationstjänster kan du ringa och ta emot samtal från PSTN (Public Switched Telephone Network). Om PSTN-bagageutrymmet är anslutet med hjälp av telefonnummer som tillhandahålls av Kommunikationstjänster finns det inga särskilda anslutningskrav för det här användningsfallet. Om du vill ansluta din egen lokala PSTN-stam till Azure Communication Services kan du använda Azure-direktdirigering (tillgänglig i CY2021).

Bild 8 – Communication Services-användare till PSTN via Azure Trunk

I det här fallet använder signalering och media från kundnätverket till Azure Flow 4.

Användningsfall: Gruppanrop för Kommunikationstjänster

Tjänsten för ljud-/video-/skärmdelning (VBSS) är en del av Azure Communication Services. Den har en offentlig IP-adress som måste kunna nås från kundnätverket och som måste kunna nås från en Nomadic Cloud-klient. Varje klient/slutpunkt måste kunna ansluta till tjänsten.

Interna klienter hämtar lokala, reflexiva och reläkandidater på samma sätt som beskrivs för en-till-en-anrop. Klienterna skickar dessa kandidater till tjänsten i en inbjudan. Tjänsten använder inte ett relä eftersom den har en offentligt nåbar IP-adress, så den svarar med sin lokala IP-adresskandidat. Klienten och tjänsten kontrollerar anslutningen på samma sätt som beskrivs för en-till-en-anrop.

Bild 9 – Gruppanrop för kommunikationstjänster

Begränsningar för samverkan

Media som flödar via Azure Communication Services begränsas på följande sätt:

SBC (Session Border Controller) från tredje part på gränsen med PSTN bör avsluta RTP/RTCP-strömmen, skyddas med SRTP och inte vidarebefordra den till nästa hopp. Om du vidarebefordrar flödet till nästa hopp kanske det inte förstås.

SIP-proxyservrar från tredje part. En Dialogruta för kommunikationstjänster som signalerar SIP med en SBC och/eller gateway från tredje part kan passera Microsofts interna SIP-proxyservrar (precis som Teams). Samverkan med SIP-proxyservrar från tredje part stöds inte.

B2BUA från tredje part (eller SBC). Mediaflödet i Communication Services till och från PSTN avslutas av en SBC från tredje part. Samverkan med en SBC från tredje part i Communication Services-nätverket (där en SBC från tredje part förmedlar två Communication Services-slutpunkter) stöds inte.

Tekniker som inte stöds

VPN-nätverk. Communication Services stöder inte medieöverföring via VPN. Om dina användare använder VPN-klienter bör klienten dela upp och dirigera medietrafik över en icke-VPN-anslutning enligt beskrivningen i Aktivera Lync-media för att kringgå en VPN-tunnel.

Kommentar

Även om rubriken anger Lync gäller den för Azure Communication Services och Teams.*

Paketformare. Paketsnipping, paketinspektion eller paketformningsenheter stöds inte och kan försämra kvaliteten avsevärt.

Nästa steg

Kom igång med samtal

Följande dokument kan vara intressanta för dig:

• Läs mer om samtalstyper
• Lär dig mer om klientserverarkitektur