Topologie toku volání

Tento článek popisuje topologie toku volání služby Azure Communication Services. Tento článek obsahuje podrobnosti o konceptech sítě pro službu Azure Communication Services, o šifrování provozu volání a různých topologiích toku volání. Úvod do toků volání komunikačních služeb naleznete v tématu Interní volání sítě.

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. Síť zákazníka může zahrnovat drátové a bezdrátové sítě v rámci vaší kanceláře 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. Microsoft tuto síť spravuje a distribuuje ji po celém světě s datovými centry vlastněnými Microsoftem 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í přenosového protokolu v reálném čase (RTP). 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 protokol UDP (User Datagram Protocol) 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í zabezpečeného protokolu RTP (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ů používá PROTOKOL HTTPS REST. V některých scénářích můžete protokol SIP použít 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í v Azure Communication Services a klienti volací sady SDK a Teams jsou založeny 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ý se domluví na parametrech relace.

Mediální přenos je šifrován a proudí mezi volajícím a volaným pomocí zabezpečeného protokolu SRTP, což je profil přenosového protokolu reálného času (RTP), který poskytuje důvěrnost, autentizaci a ochranu proti přehrání útoků na RTP přenos. Ve většině případů je přenos mediálních dat mezi klienty sjednáván prostřednictvím signalizačního spojení mezi klientem a serverem a při přímém spojení z klienta na klienta se šifruje pomocí SRTP.

Volání sady SDK služby Azure Communication Services používá DTLS k odvození šifrovacího klíče. Po dokončení handshake DTLS se médium začne přenášet s využitím šifrovacího klíče vyjednaného pomocí DTLS přes SRTP.

Klienti Azure Communication Services a klienti Teams používají token založený na přihlašovacích údajích pro zabezpečený přístup k mediálním relé přes TURN. Mediální přepínače 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 dále v tomto článku.

• 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ý. Mediální provoz odesílaný z klienta do koncového bodu média může být směrován přímo. Nebo může použít 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á, jedno nebo více přenosových relé přesměrují provoz. Provoz médií by neměl přecházet servery, které fungují jako tvarátory paketů, servery virtuální privátní sítě (VPN) nebo jiné funkce, které by mohly zpozdit zpracování a snížit výkon koncových uživatelů.

• Signální provoz vždy směřuje na ten server, který je uživateli nejblíže.

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

Průběhy volání v různých topologiích

Internetové komunikační služby

Tento příklad topologie toku volání znázorňuje zákazníky, kteří používají komunikační služby z cloudu bez 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.

Směr šipek v předchozím diagramu odráží směr počáteční komunikace, která ovlivňuje připojení v hraničních sítích podniku. U médií UDP můžou první pakety proudit opačným směrem, ale tyto pakety můžou být blokované, dokud pakety nejdou do jiného směru.

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ý uživatelem vzdálené mobilní komunikační služby s VPN k síti 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 proces iniciovaný uživatelem v zákaznické síti směrem ke Komunikačním službám.
• Flow 5 – představuje peer-to-peer tok médií 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 peer-to-peer tok médií mezi vzdáleným uživatelem mobilních komunikačních služeb a jiným vzdáleným uživatelem mobilních komunikačních služeb 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. K inicializaci volání získá volající SDK sadu kandidátů skládající se z IP adres a portů, včetně místních, relé a reflexních kandidátů (veřejná IP adresa klienta, jak ji vidí relé). Volající sada SDK odešle tyto kandidáty na volanou stranu. Volaná strana obdrží podobnou sadu kandidátů a pošle je volajícímu.

Systém používá STUN zprávy ke kontrole připojení, aby zjistil, které cesty médií volajícího/volaného fungují, a pak vybere nejlepší funkční cestu. Jakmile systém vytvoří cestu připojení, provede metodu handshake datového diagramu transportní vrstvy (DTLS) přes připojení, aby se zajistilo zabezpečení. Po použití metody handshake DTLS systém odvozuje klíče SRTP 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á služba je dostupná jako součást služeb Azure Communication Services.

Pokud mají kandidáti na místní IP adresy a porty nebo reflexivní kandidáti připojení, je pro média vybrána přímá trasa mezi klienty (nebo použitím překladu adres (NAT)). Pokud jsou oba klienti v síti zákazníka, měla by být zvolena přímá cesta. To vyžaduje přímé připojení UDP v rámci sítě zákazníka. Pokud jsou klienti oba nomádští cloudoví uživatelé, pak v závislosti na NAT/firewallu 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řenosového relé z jednoho klienta (například interní klient získal kandidáta relé z přenosového relé v Azure; externí klient musí být schopný odesílat pakety STUN/RTP/RTCP do přenosového relé). Další možností je, že interní klient odešle relé kandidáta, kterého získal mobilní cloudový klient. 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řekládá název domény adresy URL (DNS) pomocí toku 2.
2. Uživatel A přidělí port pro přenos médií na transportním relé 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 provádějí testy připojení přes ICE a je vybrána nejlepší dostupná cesta pro média. Podívejte se na následující diagramy 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)

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 k externímu uživateli (média předávaná prostřednictvím Teams Transport Relay)

V kroku 7 jsou vybrány Tok 4 (ze sítě zákazníka do komunikačních služeb) a Tok 3 (ze vzdáleného mobilního uživatele komunikačních služeb do Azure komunikačních služeb).

Služba Teams Transport Relay tyto toky zpracovává 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)

V kroku 7 je vybrán Flow 2 (ze sítě zákazníka ke klientovu peeru přes Internet).

Přímé spojení médií s vzdáleným mobilním uživatelem (nepředané prostřednictvím Azure) je volitelné. Jinými slovy, můžete zablokovat tuto cestu a vynutit mediální cestu prostřednictvím transportního relé 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)

Signalizace mezi VPN a zákaznickou sítí používá tok 2*. Signálování mezi zákaznickou sítí a Azure používá Flow 4. Média však obcházejí síť VPN a jsou směrována pomocí Toků 3 a 4 přes Azure Media Relay.

Uživatel VPN k internímu uživateli (přímé spojení)

Signalizace mezi VPN a zákaznickou sítí využívá tok 2'. Signalizace mezi sítí zákazníka a Azure využívá tok 4. Média však obcházejí síť VPN a jsou směrována prostřednictvím 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 k externímu uživateli (přímé médium)

Signalizace mezi uživatelem VPN a zákaznickou sítí používá tok 2* a tok 4 do 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 PSTN trunk 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).

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

Případ použití: Skupinové hovory komunikační služby

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.

Omezení interoperability

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

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

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

Třetích stran B2BUA (nebo SBC) SBC třetí strany ukončí tyto toky médií komunikačních služeb do a z veřejné telefonní sítě. Interoperabilita s SBC třetí strany v rámci sítě komunikačních služeb (ve které externí SBC mediatuje dva koncové body komunikačních služeb) není podporována.

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.*

Formovače paketů. Zařízení s výstřižky paketů, kontrola paketů nebo tvarování paketů nejsou podporována a mohou výrazně snížit kvalitu.

Další kroky

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

Související články

• Přečtěte si další informace o typech volání.
• Přečtěte si o architektuře klient-server.