Topologie toku volání

Tento článek popisuje topologie toku volání služby Azure Communication Services. V tomto článku se dozvíte podrobnosti o konceptech sítě pro Azure Communication Services, o tom, jak se volání provozu šifruje, a úvod do toků volání komunikačních služeb najdete v koncepční dokumentaci k tokům volání.

Pozadí

Koncepty sítě

Před kontrolou topologií toku volání definujeme některé termíny, na které se odkazuje v celém dokumentu.

Síť zákazníka obsahuje všechny segmenty sítě, které spravujete. Může se jednat o drátové a bezdrátové sítě v kanceláři nebo mezi pobočkami, datovými centry a poskytovateli internetových služeb.

Síť zákazníka má obvykle několik hraničních sítí s branami firewall nebo proxy servery, které vynucují zásady zabezpečení vaší organizace. Doporučujeme provést komplexní posouzení sítě, abyste zajistili optimální výkon a kvalitu komunikačního řešení.

Síť Communication Services je síť , která podporuje službu Azure Communication Services. Tuto síť spravuje Microsoft a distribuuje se po celém světě s datovými centry vlastněnými Microsoftem, která jsou nejblíže koncovým zákazníkům. Tato síť zodpovídá za přenosovou službu, zpracování médií pro volání skupin a další komponenty, které podporují bohatou komunikaci médií v reálném čase.

Typy provozu

Komunikační služby jsou postaveny především na dvou typech provozu: média v reálném čase a signalizace.

Médium v reálném čase se přenáší pomocí protokolu RTP (Real-Time Transport Protocol). Tento protokol podporuje přenos dat zvuku, videa a obrazovky. Tato data jsou citlivá na problémy s latencí sítě. I když je možné přenášet média v reálném čase pomocí protokolu TCP nebo HTTP, doporučujeme používat udp jako protokol přenosové vrstvy pro podporu vysoce výkonných prostředí koncových uživatelů. Datové části médií přenášené přes PROTOKOL RTP jsou zabezpečené pomocí protokolu SRTP.

Uživatelé vašeho řešení Komunikační služby se připojují k vašim službám ze svých klientských zařízení. Komunikace mezi těmito zařízeními a vašimi servery se zpracovává pomocí signalizace. Například: Inicializace volání a chat v reálném čase jsou podporovány signalizací mezi zařízeními a vaší službou. Většina signalizačních přenosů ale v některých scénářích používá PROTOKOL SIP jako signalizační protokol provozu. I když je tento typ provozu méně citlivý na latenci, signalizace s nízkou latencí poskytuje uživatelům vašeho řešení příjemné prostředí pro koncové uživatele.

Šifrování médií

Toky volání ve službě Azure Communication Services volají klienti SADY SDK a Teams založené na modelu nabídek a odpovědí rfc 8866 (Session Description Protocol) přes PROTOKOL HTTPS. Jakmile volaný přijme příchozí hovor, volající a volaný souhlasí s parametry relace.

Přenosy médií jsou šifrované a volající a volaný pomocí protokolu SRTP (Secure RTP), profilu protokolu RTP (Real-Time Transport Protocol), který poskytuje důvěrnost, ověřování a přehrání ochrany proti útokům na provoz RTP. Ve většině případů se přenosy mezi klienty a multimédii vyjednávají prostřednictvím signalizačního připojení klienta k serveru a šifrují se pomocí srTP při přímém přechodu z klienta do klienta.

Volání sady SDK služby Azure Communication Services používá K odvození šifrovacího klíče DTLS. Po dokončení metody handshake DTLS začne médium tokovat pomocí tohoto šifrovacího klíče DTLS-negotiated přes SRTP.

Klienti Azure Communication Services volané sadou SDK a Teams používají token založený na přihlašovacích údajích pro zabezpečený přístup k přenosům médií přes turn. Média vyměňují token přes kanál zabezpečený protokolem TLS.

Mediální provoz služby Azure Communication Services mezi dvěma koncovými body, které se účastní zvukového přenosu, videa a sdílení videa ve službě Azure Communication Services, využívá rozhraní SRTP k šifrování datového proudu médií. Kryptografické klíče se vyjednávají mezi těmito dvěma koncovými body přes signalizační protokol, který používá protokol TLS 1.2 a AES-256 (v režimu GCM) šifrovaný kanál UDP/TCP.

Principy toku volání

Existují čtyři obecné principy, které podporují toky volání služeb Azure Communication Services:

• První účastník volání skupiny Komunikační služby určuje oblast, ve které je hovor hostovaný. V některých topologiích existují výjimky, které jsou popsány níže.
• Koncový bod média používaný k podpoře volání komunikační služby je vybraný na základě potřeb zpracování médií a není ovlivněn počtem účastníků hovoru. Volání typu point-to-point může například použít koncový bod média v cloudu ke zpracování média pro přepis nebo záznam, zatímco hovor se dvěma účastníky nemusí používat žádné koncové body médií. Skupinové volání používají koncový bod média pro účely kombinování a směrování. Tento koncový bod je vybraný v závislosti na oblasti, ve které je hovor hostovaný. Přenos médií odesílaný z klienta do koncového bodu média se může směrovat přímo nebo může použít přenosovou přenosovou službu v Azure, pokud to vyžadují omezení brány firewall sítě zákazníka.
• Přenosy médií pro volání mezi dvěma účastníky přebírají nejsměrnější dostupnou trasu za předpokladu, že volání nepotřebuje koncový bod média v cloudu. Upřednostňovaná trasa je přímo ke vzdálenému partnerskému uzlu (klientovi). Pokud přímá trasa není dostupná, jedna nebo více přenosů přesměruje provoz. Provoz médií by neměl přecházet servery, které fungují jako tvarátory paketů, servery VPN nebo jiné funkce, které by mohly zpozdit zpracování a snížit výkon koncového uživatele.
• Signalizace provozu vždy přejde na jakýkoli server, který je uživateli nejblíže.

Další informace o zvolené cestě k médiím najdete v koncepční dokumentaci k tokům volání.

Volání toků v různých topologiích

Komunikační služby (internet)

Tuto topologii používají zákazníci, kteří používají Komunikační služby z cloudu bez jakéhokoli místního nasazení, jako je přímé směrování Azure. V této topologii provoz do a z komunikačních služeb prochází přes internet.

Obrázek 1 – topologie komunikačních služeb

Směr šipek na výše uvedeném diagramu odráží směr zahájení komunikace, která má vliv na připojení v hraničních sítích podniku. V případě UDP pro média mohou první pakety proudit opačným směrem, ale tyto pakety mohou být blokovány, dokud pakety v opačném směru nejdou tok.

Popisy toku:

• Flow 2 – představuje tok iniciovaný uživatelem v síti zákazníka do internetu jako součást prostředí komunikačních služeb uživatele. Mezi příklady těchto toků patří DNS a přenos médií mezi dvěma účastníky.
• Flow 2' – Představuje tok iniciovaný vzdáleným uživatelem mobilní komunikační služby s vpn sítí zákazníka.
• Flow 3 – představuje tok iniciovaný vzdáleným uživatelem mobilní komunikační služby do koncových bodů komunikačních služeb.
• Flow 4 – Představuje tok iniciovaný uživatelem v síti zákazníka do komunikačních služeb.
• Flow 5 – představuje tok médií mezi dvěma účastníky mezi jedním uživatelem komunikačních služeb a druhým v rámci sítě zákazníka.
• Flow 6 – představuje tok médií mezi vzdáleným mobilním komunikačním službám a jiným uživatelem vzdálené mobilní komunikační služby přes internet.

Případ použití: Volání 1:1

Volání 1:1 znamená, že jeden uživatel přímo volá jiného uživatele. Aby bylo možné inicializovat volání volající sady SDK, získá sadu kandidátů sestávajících z IP adres a portů, včetně místních, předávaných a reflexních (veřejné IP adresy klienta, jak je vidět v kandidátech pro předávání). Sada SDK volajícího odešle tyto kandidáty na volanou stranu; volaná strana rovněž získá podobnou sadu kandidátů a pošle je volajícímu. Kontrolou připojení STUN se používají zprávy, které volající nebo označované jako cesty médií stran fungují, a je vybrána nejlepší pracovní cesta. Po navázání cesty připojení se přes toto připojení provede metodu handshake DTLS, aby se zajistilo zabezpečení. Po použití metody handshake DTLS se klíče SRTP odvozují z procesu handshake DTLS. Média (tj. pakety RTP/RTCP zabezpečené pomocí SRTP) se pak posílají pomocí vybrané dvojice kandidátů. Přenosová přenosová služba je dostupná jako součást služeb Azure Communication Services.

Pokud mají kandidáti na místní IP adresu a port nebo reflexní kandidáti připojení, je pro média vybraná přímá cesta mezi klienty (nebo pomocí překladu adres (NAT). Pokud jsou klienti v síti zákazníka oba, měli byste vybrat přímou cestu. To vyžaduje přímé připojení UDP v rámci sítě zákazníka. Pokud jsou klienti oba nomadioví cloudoví uživatelé, pak v závislosti na překladu adres (NAT) nebo bráně firewall můžou média používat přímé připojení.

Pokud je jeden klient interní v síti zákazníka a jeden klient je externí (například mobilní cloudový uživatel), není pravděpodobné, že by bylo povolené přímé připojení mezi místními nebo reflexními kandidáty. V tomto případě je možné použít jednoho z kandidátů přenosu z jednoho klienta (například interní klient získal kandidáta na přenos z přenosového přenosu v Azure; externí klient musí být schopný odesílat pakety STUN/RTP/RTCP do přenosového přenosu). Další možností je, že interní klient odešle kandidátovi přenosu získanému mobilním cloudovým klientem. I když se připojení UDP pro média důrazně doporučuje, podporuje se protokol TCP.

Základní kroky:

1. Uživatel komunikační služby A přeloží název domény ADRESY URL (DNS) pomocí flow 2.
2. Uživatel A přidělí přenosový port médií na přenosové službě Teams pomocí flow 4.
3. Uživatel komunikačních služeb A odešle pozvánku s kandidáty ICE pomocí flow 4 do komunikačních služeb.
4. Komunikační služby upozorní uživatele B pomocí flow 4.
5. Uživatel B přiděluje přenosový port pro přenos médií v Teams pomocí Flow 4.
6. Uživatel B pošle "odpověď" s kandidáty ICE pomocí Flow 4, který se přepošle zpět uživateli A pomocí Flow 4.
7. Uživatel A a Uživatel B vyvolávají testy připojení ICE a je vybrána nejlepší dostupná cesta k médiím (viz diagramy níže pro různé případy použití).
8. Oba uživatelé odesílají telemetrii do komunikačních služeb pomocí flow 4.

Síť zákazníka (intranet)

Obrázek 2 – V rámci sítě zákazníků

V kroku 7 je vybraný tok médií peer-to-peer 5.

Tento přenos médií je obousměrný. Směr toku 5 označuje, že jedna strana zahájí komunikaci z pohledu připojení. V tomto případě nezáleží na tom, který směr se používá, protože oba koncové body jsou v síti zákazníka.

Síť zákazníka s externím uživatelem (média předávaná službou Teams Transport Relay)

Obrázek 3 – Síť zákazníka externímu uživateli (média předávaná službou Azure Transport Relay)

V kroku 7 je vybraný Tok 4 (ze sítě zákazníka do komunikačních služeb) a Flow 3 (ze vzdáleného mobilního uživatele Communication Services do Azure Communication Services).

Tyto toky jsou předávané službou Teams Transport Relay v rámci Azure.

Tento přenos médií je obousměrný. Směr označuje, která strana zahájí komunikaci z pohledu připojení. V tomto případě se tyto toky používají pro signalizaci a média pomocí různých přenosových protokolů a adres.

Síť zákazníka s externím uživatelem (přímé médium)

Obrázek 4 – Síť zákazníka s externím uživatelem (přímé médium)

V kroku 7 je vybraný tok 2 (ze sítě zákazníka po partnerský vztah klienta přes internet).

Přímé médium se vzdáleným mobilním uživatelem (nepředaná prostřednictvím Azure) je volitelné. Jinými slovy, tuto cestu můžete zablokovat a vynutit cestu k médiu prostřednictvím přenosového přenosu v Azure.

Tento přenos médií je obousměrný. Směr toku 2 ke vzdálenému mobilnímu uživateli označuje, že jedna strana zahájí komunikaci z pohledu připojení.

Uživatel VPN s interním uživatelem (média předávaná službou Teams Transport Relay)

Obrázek 5 – Uživatel VPN s interním uživatelem (média předávaná službou Azure Relay)

Signaling between the VPN to the customer network uses Flow 2*. Signaling between the customer network and Azure uses Flow 4. Média však předávají síť VPN a směrují se pomocí toků 3 a 4 přes Azure Media Relay.

Uživatel VPN s interním uživatelem (přímé médium)

Obrázek 6 – uživatel VPN s interním uživatelem (přímé médium)

Signaling between the VPN to the customer network uses Flow 2'. Signaling between the customer network and Azure is using flow 4. Média však obcházejí síť VPN a směrují se pomocí toku 2 ze sítě zákazníka do internetu.

Tento přenos médií je obousměrný. Směr toku 2 ke vzdálenému mobilnímu uživateli označuje, že jedna strana zahájí komunikaci z pohledu připojení.

Uživatel VPN pro externího uživatele (přímé médium)

Obrázek 7 – Uživatel VPN pro externího uživatele (přímé médium)

Signaling between the VPN user to the customer network uses Flow 2* and Flow 4 to Azure. Média ale obcházejí síť VPN a směrují se pomocí Flow 6.

Tento přenos médií je obousměrný. Směr toku 6 ke vzdálenému mobilnímu uživateli označuje, že jedna strana zahájí komunikaci z pohledu připojení.

Případ použití: Klient komunikačních služeb do veřejné telefonní sítě prostřednictvím kmene komunikačních služeb

Komunikační služby umožňují umísťování a přijímání hovorů z veřejné telefonní sítě (PSTN). Pokud je kufr veřejné telefonní sítě připojený pomocí telefonních čísel poskytovaných komunikačními službami, nejsou pro tento případ použití žádné zvláštní požadavky na připojení. Pokud chcete připojit svůj vlastní místní kmen veřejné telefonní sítě ke službám Azure Communication Services, můžete použít přímé směrování Azure (dostupné v CY2021).

Obrázek 8 – Uživatel komunikačních služeb do veřejné telefonní sítě přes Azure Trunk

V tomto případě signalizují a média ze sítě zákazníka do Azure používají Flow 4.

Případ použití: Volání skupiny komunikačních služeb

Služba sdílení zvuku/videa/obrazovky (VBSS) je součástí služby Azure Communication Services. Má veřejnou IP adresu, která musí být dostupná ze sítě zákazníka a musí být dostupná z klienta Nomadic Cloud. Každý klient nebo koncový bod musí být schopný se připojit ke službě.

Interní klienti získávají místní, reflexní a předávací kandidáty stejným způsobem, jak je popsáno pro volání 1:1. Klienti posílají tyto kandidáty do služby v pozvánce. Služba nepoužívá přenos, protože má veřejně dosažitelnou IP adresu, takže odpoví svým kandidátem na místní IP adresu. Klient a služba kontrolují připojení stejným způsobem jako u volání 1:1.

Obrázek 9 – Volání skupin komunikačních služeb

Omezení interoperability

Mediální tok přes Azure Communication Services je omezený následujícím způsobem:

Řadič SBC (Session Border Controller) relace třetí strany na hranici s veřejnou telefonní sadou by měl ukončit stream RTP/RTCP zabezpečený pomocí srTP a nepřevést ho do dalšího segmentu směrování. Pokud tok předáte dalšímu segmentu směrování, nemusí být srozumitelný.

Proxy servery PROTOKOLU SIP třetích stran. Dialogové okno sip pro signalizaci komunikačních služeb s externím SBC nebo bránou může procházet nativní proxy servery SIP microsoftu (stejně jako Teams). Interoperabilita s proxy servery SIP třetích stran se nepodporuje.

B2BUA (nebo SBC) třetích stran Tok médií služby Communication Services do veřejné telefonní sítě a z této veřejné telefonní sítě je ukončen třetí stranou SBC. Interoperabilita s SBC třetí strany v síti komunikačních služeb (kde externí SBC medituje dva koncové body komunikačních služeb) není podporovaná.

Nepodporované technologie

Síť VPN. Komunikační služby nepodporují přenos médií přes sítě VPN. Pokud vaši uživatelé používají klienty VPN, měl by klient rozdělit a směrovat provoz médií přes jiné připojení než VPN, jak je uvedeno v části Povolení obejití tunelu VPN v Lyncu.

Poznámka:

I když název označuje Lync, platí pro Azure Communication Services a Teams.*

Tvarovače paketů. Výstřižky paketů, kontrola paketů nebo zařízení pro tvarování paketů nejsou podporovány a mohou výrazně snížit kvalitu.

Další kroky

Začínáme s voláním

Pro vás můžou být zajímavé následující dokumenty:

• Další informace o typech volání
• Další informace o architektuře klient-server