Topologie przepływu wywołań

W tym artykule opisano topologie przepływu wywołań usług Azure Communication Services. W tym artykule dowiesz się więcej na temat pojęć dotyczących sieci dla usług Azure Communication Services, sposobu szyfrowania ruchu wywołującego oraz Aby zapoznać się z wprowadzeniem do przepływów wywołań usług Communication Services, odwiedź dokumentację koncepcyjną przepływów połączeń.

Tło

Pojęcia dotyczące sieci

Przed przejrzeniem topologii przepływu wywołań definiujemy niektóre terminy, które są określane w całym dokumencie.

Sieć klienta zawiera wszystkie segmenty sieci, którymi zarządzasz. Może to obejmować sieci przewodowe i bezprzewodowe w biurze lub między biurami, centrami danych i dostawcami usług internetowych.

Sieć klienta zwykle ma kilka obwodów sieci z zaporami i/lub serwerami proxy, które wymuszają zasady zabezpieczeń organizacji. Zalecamy przeprowadzenie kompleksowej oceny sieci w celu zapewnienia optymalnej wydajności i jakości rozwiązania komunikacyjnego.

Sieć usług komunikacyjnych to sieć , która obsługuje usługi Azure Communication Services. Ta sieć jest zarządzana przez firmę Microsoft i jest dystrybuowana na całym świecie z centrami danych należącymi do firmy Microsoft najbliżej klientów końcowych. Ta sieć jest odpowiedzialna za przekaźnik transportu, przetwarzanie multimediów dla wywołań grupowych i inne składniki, które obsługują zaawansowaną komunikację multimediów w czasie rzeczywistym.

Typy ruchu

Usługi komunikacyjne są oparte głównie na dwóch typach ruchu: nośnikach w czasie rzeczywistym i sygnalizowaniu.

Nośniki w czasie rzeczywistym są przesyłane przy użyciu protokołu transportowego czasu rzeczywistego (RTP). Ten protokół obsługuje transmisję danych audio, wideo i ekranu. Te dane są wrażliwe na problemy z opóźnieniami sieci. Chociaż istnieje możliwość przesyłania multimediów w czasie rzeczywistym przy użyciu protokołu TCP lub HTTP, zalecamy użycie protokołu UDP jako protokołu warstwy transportu w celu obsługi środowisk użytkowników końcowych o wysokiej wydajności. Ładunki multimediów przesyłane za pośrednictwem protokołu RTP są zabezpieczone przy użyciu protokołu SRTP.

Użytkownicy rozwiązania Usług komunikacyjnych łączą się z usługami z urządzeń klienckich. Komunikacja między tymi urządzeniami a serwerami jest obsługiwana za pomocą sygnałów. Na przykład: inicjowanie połączeń i czat w czasie rzeczywistym są obsługiwane przez sygnalizowanie między urządzeniami a usługą. Większość ruchu sygnalizowego używa protokołu HTTPS REST, choć w niektórych scenariuszach protokół SIP może być używany jako protokół sygnalizujący ruch. Chociaż ten typ ruchu jest mniej wrażliwy na opóźnienia, sygnały o małych opóźnieniach zapewniają użytkownikom rozwiązania przyjemne środowisko użytkownika końcowego.

Szyfrowanie multimediów

Przepływy wywołań w usługach Azure Communication Services wywołujących zestaw SDK i klienci usługi Teams są oparte na ofercie protokołu RDP (SDP) RFC 8866 i modelu odpowiedzi za pośrednictwem protokołu HTTPS. Po zaakceptowaniu wywołania przychodzącego obiekt wywołujący i wywoływany zgadzają się na parametry sesji.

Ruch multimedialny jest szyfrowany, a przepływy między obiektem wywołującym i wywoływanym przy użyciu protokołu Secure RTP (SRTP), profilu protokołu transportu w czasie rzeczywistym (RTP), który zapewnia poufność, uwierzytelnianie i odtwarzanie ochrony przed atakami do ruchu RTP. W większości przypadków klient do ruchu multimediów klienta jest negocjowany za pośrednictwem klienta do sygnalizowania połączenia z serwerem i jest szyfrowany przy użyciu protokołu SRTP podczas przechodzenia bezpośrednio z klienta do klienta.

Usługi Azure Communication Services wywołujące zestaw SDK używają usługi DTLS do uzyskiwania klucza szyfrowania. Po zakończeniu uzgadniania usługi DTLS nośnik zaczyna przepływać przy użyciu tego klucza szyfrowania wynegocjowanego przez usługę DTLS za pośrednictwem protokołu SRTP.

Usługi Azure Communication Services wywołujące zestaw SDK i klienci usługi Teams używają tokenu opartego na poświadczeniach do bezpiecznego dostępu do przekaźników multimediów za pośrednictwem usługi TURN. Przekaźniki multimediów wymieniają token za pośrednictwem kanału zabezpieczonego protokołem TLS.

Ruch multimedialny usługi Azure Communication Services między dwoma punktami końcowymi uczestniczącymi w usługach Azure Communication Services audio, wideo i udostępnianie wideo korzysta z protokołu SRTP do szyfrowania strumienia multimediów. Klucze kryptograficzne są negocjowane między dwoma punktami końcowymi za pośrednictwem protokołu sygnalizowanego, który używa protokołu TLS 1.2 i AES-256 (w trybie GCM) szyfrowanego kanału UDP/TCP.

Reguły przepływu wywołań

Istnieją cztery ogólne zasady, które stanowią podstawę przepływów wywołań usług Azure Communication Services:

• Pierwszy uczestnik wywołania grupy usług komunikacyjnych określa region, w którym jest hostowane wywołanie. Istnieją wyjątki od tej reguły w niektórych topologiach, które zostały opisane poniżej.
• Punkt końcowy multimediów używany do obsługi wywołania usług komunikacyjnych jest wybierany na podstawie potrzeb przetwarzania multimediów i nie ma to wpływu na liczbę uczestników połączenia. Na przykład wywołanie typu punkt-punkt może używać punktu końcowego multimediów w chmurze do przetwarzania multimediów na potrzeby transkrypcji lub nagrywania, podczas gdy wywołanie z dwoma uczestnikami może nie używać żadnych punktów końcowych multimediów. Wywołania grup używają punktu końcowego multimediów do celów mieszania i routingu. Ten punkt końcowy jest wybierany na podstawie regionu, w którym jest hostowane wywołanie. Ruch multimedialny wysyłany z klienta do punktu końcowego nośnika może być kierowany bezpośrednio lub może używać przekaźnika transportowego na platformie Azure, jeśli wymagają tego ograniczenia zapory sieciowej klienta.
• Ruch multimedialny dla wywołań komunikacji równorzędnej pobiera najbardziej bezpośrednią trasę, która jest dostępna, przy założeniu, że wywołanie nie wymaga punktu końcowego multimediów w chmurze. Preferowana trasa jest bezpośrednia do zdalnej komunikacji równorzędnej (klienta). Jeśli trasa bezpośrednia nie jest dostępna, co najmniej jeden przekaźnik transportowy przekazuje ruch. Ruch multimedialny nie powinien być przekierowywany przez serwery, które działają jak kształtatory pakietów, serwery sieci VPN lub inne funkcje, które mogą opóźniać przetwarzanie i obniżać wydajność środowiska użytkownika końcowego.
• Sygnalizowanie ruchu zawsze przechodzi do dowolnego serwera znajdującego się najbliżej użytkownika.

Aby dowiedzieć się więcej na temat szczegółów wybranej ścieżki multimedialnej, zapoznaj się z dokumentacją koncepcyjną przepływów wywołań.

Wywoływanie przepływów w różnych topologiach

Communication Services (Internet)

Ta topologia jest używana przez klientów korzystających z usług Komunikacyjnych z chmury bez żadnego wdrożenia lokalnego, takiego jak routing bezpośredni na platformie Azure. W tej topologii ruch do i z usług Komunikacyjnych przepływa przez Internet.

Rysunek 1. Topologia usług komunikacyjnych

Kierunek strzałek na powyższym diagramie odzwierciedla kierunek inicjowania komunikacji, która wpływa na łączność w obwodach przedsiębiorstwa. W przypadku protokołu UDP dla nośnika pierwsze pakiety mogą przepływać w odwrotnym kierunku, ale te pakiety mogą być blokowane, dopóki pakiety w innym kierunku nie będą przepływać.

Opisy przepływów:

• Flow 2 — reprezentuje przepływ zainicjowany przez użytkownika w sieci klienta w Internecie w ramach środowiska usług komunikacyjnych użytkownika. Przykłady tych przepływów obejmują system DNS i transmisję multimediów równorzędnych.
• Flow 2' — reprezentuje przepływ zainicjowany przez zdalnego użytkownika usług komunikacji mobilnej z siecią klienta sieci VPN.
• Flow 3 — reprezentuje przepływ zainicjowany przez zdalnego użytkownika usług komunikacji mobilnej do punktów końcowych usług Komunikacyjnych.
• Flow 4 — reprezentuje przepływ zainicjowany przez użytkownika w sieci klienta do usług komunikacyjnych.
• Flow 5 — reprezentuje przepływ multimediów równorzędnych między jednym użytkownikiem usługi Communication Services a innym w sieci klienta.
• Flow 6 — reprezentuje przepływ multimediów równorzędnych między zdalnym użytkownikiem usług komunikacji mobilnej a innym użytkownikiem zdalnych usług komunikacji mobilnej przez Internet.

Przypadek użycia: wywołanie "jeden do jednego"

Wywołanie jeden do jednego oznacza, że jeden użytkownik bezpośrednio wywołuje innego użytkownika. Aby zainicjować wywołanie zestawu SDK wywołania, uzyskaj zestaw kandydatów składających się z adresów IP i portów, w tym lokalnego, przekaźnika i refleksyjnego (publicznego adresu IP klienta widocznego przez przekaźnik). Zestaw SDK rozmówcy wysyła tych kandydatów do wywoływanej partii; nazwana partia uzyskuje również podobny zestaw kandydatów i wysyła je do rozmówcy. Komunikaty sprawdzania łączności STUN są używane do znajdowania elementów wywołujących/nazywanych ścieżkami multimediów firmowych i wybraną najlepszą ścieżką roboczą. Po ustanowieniu ścieżki połączenia uzgadnianie usługi DTLS jest wykonywane za pośrednictwem tego połączenia w celu zapewnienia bezpieczeństwa. Po uzgadnianiu dtLS klucze SRTP pochodzą z procesu uzgadniania DTLS. Nośnik (czyli pakiety RTP/RTCP zabezpieczone przy użyciu srTP) są następnie wysyłane przy użyciu wybranej pary kandydatów. Przekaźnik transportowy jest dostępny w ramach usług Azure Communication Services.

Jeśli lokalny adres IP i kandydaci portów lub kandydaci refleksyjni mają łączność, wybrana jest bezpośrednia ścieżka między klientami (lub przy użyciu translatora adresów sieciowych) dla nośnika. Jeśli klienci znajdują się w sieci klienta, należy wybrać ścieżkę bezpośrednią. Wymaga to bezpośredniej łączności UDP w sieci klienta. Jeśli klienci są użytkownikami chmury koczowniczej, w zależności od translatora adresów sieciowych/zapory nośnik może używać bezpośredniej łączności.

Jeśli jeden klient jest wewnętrzny w sieci klienta, a jeden klient jest zewnętrzny (na przykład użytkownik chmury mobilnej), jest mało prawdopodobne, że zostanie włączona bezpośrednia łączność między kandydatami lokalnymi lub refleksyjnymi. W takim przypadku opcja polega na użyciu jednego z kandydatów przekaźnika transportu z dowolnego klienta (na przykład wewnętrzny klient uzyskał kandydata przekaźnika z przekaźnika transportu na platformie Azure; klient zewnętrzny musi mieć możliwość wysyłania pakietów STUN/RTP/RTCP do przekaźnika transportu). Inną opcją jest to, że wewnętrzny klient wysyła do kandydata do przekazywania uzyskanego przez klienta chmury mobilnej. Mimo że łączność UDP z nośnikami jest zdecydowanie zalecana, protokół TCP jest obsługiwany.

Ogólne kroki:

1. Użytkownik usług komunikacyjnych A rozpoznaje nazwę domeny adresu URL (DNS) przy użyciu usługi Flow 2.
2. Użytkownik A przydziela port przekazywania multimediów w przekaźniku transportu usługi Teams przy użyciu usługi Flow 4.
3. Użytkownik usług komunikacyjnych A wysyła "zaproszenie" z kandydatami ICE przy użyciu usługi Flow 4 do usług komunikacyjnych.
4. Usługi komunikacyjne powiadamiają użytkownika B przy użyciu usługi Flow 4.
5. Użytkownik B przydziela port przekazywania multimediów w przekaźniku transportu usługi Teams przy użyciu usługi Flow 4.
6. Użytkownik B wysyła "odpowiedź" z kandydatami ICE przy użyciu usługi Flow 4, która jest przesyłana z powrotem do użytkownika A przy użyciu usługi Flow 4.
7. Wybrano testy łączności ICE użytkownika A i użytkownika B. Wybrano najlepszą dostępną ścieżkę multimediów (zobacz diagramy poniżej dla różnych przypadków użycia).
8. Obaj użytkownicy wysyłają dane telemetryczne do usług komunikacyjnych przy użyciu usługi Flow 4.

Sieć klienta (intranet)

Rysunek 2. W sieci klienta

W kroku 7 wybrano przepływ 5 multimediów równorzędnych.

Ta transmisja multimediów jest dwukierunkowa. Kierunek usługi Flow 5 wskazuje, że jedna strona inicjuje komunikację z perspektywy łączności. W takim przypadku nie ma znaczenia, który kierunek jest używany, ponieważ oba punkty końcowe znajdują się w sieci klienta.

Sieć klienta dla użytkownika zewnętrznego (nośnik przekazywany przez usługę Teams Transport Relay)

Rysunek 3. Sieć klienta do użytkownika zewnętrznego (nośnik przekazywany przez usługę Azure Transport Relay)

W kroku 7 wybrano usługę Flow 4 (z sieci klienta do usług komunikacyjnych) i Flow 3 (od zdalnego użytkownika usług komunikacji mobilnej do usług Azure Communication Services).

Te przepływy są przekazywane przez usługę Teams Transport Relay na platformie Azure.

Ta transmisja multimediów jest dwukierunkowa. Kierunek wskazuje, która strona inicjuje komunikację z perspektywy łączności. W takim przypadku te przepływy są używane do sygnalizowania i nośników przy użyciu różnych protokołów transportu i adresów.

Sieć klienta dla użytkownika zewnętrznego (nośnik bezpośredni)

Rysunek 4. Sieć klienta do użytkownika zewnętrznego (nośnik bezpośredni)

W kroku 7 wybrano usługę Flow 2 (z sieci klienta do komunikacji równorzędnej klienta przez Internet).

Nośniki bezpośrednie z zdalnym użytkownikiem mobilnym (bez przekazywania za pośrednictwem platformy Azure) są opcjonalne. Innymi słowy, możesz zablokować tę ścieżkę, aby wymusić ścieżkę multimediów za pośrednictwem przekaźnika transportu na platformie Azure.

Ta transmisja multimediów jest dwukierunkowa. Kierunek przepływu 2 do zdalnego użytkownika mobilnego wskazuje, że jedna strona inicjuje komunikację z perspektywy łączności.

Użytkownik sieci VPN do użytkownika wewnętrznego (nośnik przekazywany przez usługę Teams Transport Relay)

Rysunek 5. Użytkownik sieci VPN do użytkownika wewnętrznego (nośnik przekazywany przez usługę Azure Relay)

Sygnalizowanie między siecią VPN a siecią klienta korzysta z usługi Flow 2*. Sygnalizowanie między siecią klienta a platformą Azure używa usługi Flow 4. Jednak nośnik pomija sieć VPN i jest kierowany przy użyciu przepływów 3 i 4 za pośrednictwem usługi Azure Media Relay.

Użytkownik sieci VPN do użytkownika wewnętrznego (nośnik bezpośredni)

Rysunek 6. Użytkownik sieci VPN do użytkownika wewnętrznego (nośnik bezpośredni)

Sygnalizowanie między siecią VPN a siecią klienta korzysta z usługi Flow 2". Sygnalizowanie między siecią klienta a platformą Azure korzysta z przepływu 4. Jednak nośnik pomija sieć VPN i jest kierowany przy użyciu przepływu 2 z sieci klienta do Internetu.

Ta transmisja multimediów jest dwukierunkowa. Kierunek przepływu 2 do zdalnego użytkownika mobilnego wskazuje, że jedna strona inicjuje komunikację z perspektywy łączności.

Użytkownik sieci VPN do użytkownika zewnętrznego (nośnik bezpośredni)

Rysunek 7. Użytkownik sieci VPN do użytkownika zewnętrznego (nośnik bezpośredni)

Sygnalizowanie między użytkownikiem sieci VPN a siecią klienta używa usług Flow 2* i Flow 4 do platformy Azure. Jednak nośnik pomija sieć VPN i jest kierowany przy użyciu usługi Flow 6.

Ta transmisja multimediów jest dwukierunkowa. Kierunek przepływu 6 do zdalnego użytkownika mobilnego wskazuje, że jedna strona inicjuje komunikację z perspektywy łączności.

Przypadek użycia: klient usług komunikacyjnych do sieci PSTN za pośrednictwem magistrali usług komunikacyjnych

Usługi komunikacyjne umożliwiają umieszczanie i odbieranie połączeń z publicznej sieci telefonicznej (PSTN). Jeśli magistrala PSTN jest połączona przy użyciu numerów telefonów dostarczonych przez usługi komunikacyjne, nie ma specjalnych wymagań dotyczących łączności dla tego przypadku użycia. Jeśli chcesz połączyć własną lokalną magistralę PSTN z usługami Azure Communication Services, możesz użyć routingu bezpośredniego platformy Azure (dostępnego w wersji CY2021).

Rysunek 8 . Użytkownik usług komunikacyjnych do sieci PSTN za pośrednictwem usługi Azure Trunk

W takim przypadku sygnały i nośniki z sieci klienta do platformy Azure używają usługi Flow 4.

Przypadek użycia: Wywołania grupy usług komunikacyjnych

Usługa udostępniania audio/wideo/ekranu (VBSS) jest częścią usług Azure Communication Services. Ma on publiczny adres IP, który musi być dostępny z sieci klienta i musi być dostępny z poziomu klienta Koczowniczego chmury. Każdy klient/punkt końcowy musi mieć możliwość nawiązania połączenia z usługą.

Klienci wewnętrzni uzyskują lokalnych, refleksyjnych i przekaźnikowych kandydatów w taki sam sposób, jak opisano w przypadku wywołań jeden do jednego. Klienci wysyłają tych kandydatów do usługi w zaproszeniu. Usługa nie używa przekaźnika, ponieważ ma publicznie dostępny adres IP, dlatego odpowiada za pomocą lokalnego kandydata adresu IP. Klient i usługa sprawdzają łączność w taki sam sposób, jak opisano w przypadku wywołań jeden do jednego.

Rysunek 9 . Wywołania grupy usług komunikacyjnych

Ograniczenia współdziałania

Multimedia przepływające za pośrednictwem usług Azure Communication Services są ograniczone w następujący sposób:

Kontroler granic sesji innej firmy (SBC) na granicy z PSTN powinien zakończyć strumień RTP/RTCP, zabezpieczony przy użyciu srTP, a nie przekazać go do następnego przeskoku. Jeśli przekażesz przepływ do następnego przeskoku, może to nie być zrozumiałe.

Serwery proxy SIP innej firmy. Usługa Communication Services sygnalizuje okno dialogowe SIP z usługą SBC innej firmy i/lub bramą może przejść przez natywne serwery proxy SIP firmy Microsoft (podobnie jak usługa Teams). Współdziałanie z serwerami proxy SIP innej firmy nie jest obsługiwane.

B2BUA (lub SBC) innej firmy. Przepływ multimediów usług Communication Services do i z pstN jest przerywany przez SBC innej firmy. Współdziałanie z usługą SBC innej firmy w sieci usług komunikacyjnych (gdzie pośredniczy dwa punkty końcowe usług komunikacyjnych SBC innej firmy) nie jest obsługiwane.

Nieobsługiwane technologie

Sieć VPN. Usługi komunikacyjne nie obsługują transmisji multimediów za pośrednictwem sieci VPN. Jeśli użytkownicy korzystają z klientów sieci VPN, klient powinien rozdzielić i kierować ruch multimedialny przez połączenie nienależące do sieci VPN, jak określono w temacie Włączanie nośników programu Lync w celu obejścia tunelu sieci VPN.

Uwaga

Chociaż tytuł wskazuje program Lync, ma zastosowanie do usług Azure Communication Services i Teams.*

Kształtatory pakietów. Snipping pakietów, inspekcja pakietów lub urządzenia kształtowania pakietów nie są obsługiwane i mogą znacznie obniżyć jakość.

Następne kroki

Rozpoczynanie pracy z nawiązywaniem połączenia

Poniższe dokumenty mogą cię zainteresować:

• Dowiedz się więcej o typach wywołań
• Dowiedz się więcej o architekturze klient-serwer