Topologie przepływu połączeń

W tym artykule opisano topologie przepływu wywołań usług Azure Communication Services. Ten artykuł zawiera szczegółowe informacje na temat pojęć dotyczących sieci dla usług Azure Communication Services, sposobu szyfrowania ruchu wywołującego i różnych topologii przepływu wywołań. Aby zapoznać się z wprowadzeniem do przepływów wywołań usług Communication Services, zobacz Call networking internals (Wywoływanie wewnętrznych sieci).

Kontekst

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. Sieć klienta może obejmować sieci przewodowe i bezprzewodowe w biurze lub między biurami, centrami danych i dostawcami usług internetowych.

Sieć klienta zwykle ma kilka granic sieciowych z zaporami i/lub serwerami proxy, które wymuszają zasady zabezpieczeń organizacji klienta. 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. Firma Microsoft zarządza tą siecią i dystrybuuje ją 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ą bogatą komunikację multimedialną w czasie rzeczywistym.

Typy ruchu

Usługi komunikacyjne są oparte głównie na dwóch typach ruchu: mediach w czasie rzeczywistym i sygnalizacji.

Media w czasie rzeczywistym są przesyłane za pomocą protokołu transportowego w czasie rzeczywistym (RTP). Ten protokół obsługuje przesyłanie danych audio, wideo oraz współdzielenie 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 datagramu użytkownika (UDP) jako protokołu warstwy transportu w celu obsługi środowisk użytkownika końcowego o wysokiej wydajności. Ładunki multimediów przesyłane za pośrednictwem protokołu RTP są zabezpieczone przy użyciu bezpiecznego protokołu RTP (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 sygnalizację pomiędzy urządzeniami a twoją usługą. Większość ruchu sygnalizowego używa protokołu HTTPS REST. W niektórych scenariuszach można użyć sip jako protokołu sygnalizacyjnego ruchu. Chociaż ten typ ruchu jest mniej wrażliwy na opóźnienia, sygnalizacja o małych opóźnieniach zapewnia użytkownikom rozwiązania przyjemne doświadczenie użytkownika.

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. Gdy odbiorca zaakceptuje przychodzące połączenie, dzwoniący i odbiorca uzgadniają parametry sesji.

Ruch medialny jest szyfrowany i przepływa między nadawcą a odbiorcą za pomocą bezpiecznego protokołu RTP (SRTP), stanowiącego profil protokołu transportu w czasie rzeczywistym (RTP), który zapewnia poufność, uwierzytelnianie oraz ochronę przed atakami opartymi na powtórzeniach dla ruchu RTP. W większości przypadków ruch multimedialny między klientami jest negocjowany za pośrednictwem sygnalizacji połączenia klient-serwer i szyfrowany przy użyciu SRTP, kiedy połączenie odbywa się bezpośrednio między klientami.

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 multimediów w usłudze Azure Communication Services między dwoma punktami końcowymi, które uczestniczą w usługach audio, wideo i dzielenia wideo, wykorzystuje protokół 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 grupowego połączenia komunikacyjnych usług dokonuje wyboru regionu, w którym jest hostowane połączenie. Istnieją wyjątki od tej reguły w niektórych topologiach, które zostały opisane w dalszej części tego artykułu.

• 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. Połączenia grupowe używają punktu końcowego mediów do celów miksowania i routingu.

  Ten punkt końcowy jest wybierany na podstawie regionu, w którym jest hostowane wywołanie. Ruch multimediów wysyłany z klienta do punktu końcowego nośnika może być kierowany bezpośrednio. Może też używać przekaźnika transportowego na platformie Azure, jeśli wymagają tego ograniczenia zapory sieciowej klienta.

• Ruch multimedialny dla połączeń peer-to-peer wybiera najkrótszą dostępną trasę, jeśli połączenie nie wymaga punktu końcowego transmisji medialnej w chmurze.

  Preferowana trasa jest bezpośrednia do zdalnego równorzędnego węzła (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 wirtualnej sieci prywatnej (VPN) ani 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 uzyskać więcej informacji na temat ścieżek multimedialnych, zobacz dokumentację koncepcyjną przepływów połączeń.

Przepływy połączeń w różnych topologiach

Usługi komunikacyjne (Internet)

Ten przykład topologii przepływu wywołań przedstawia 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.

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

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ą DNS i transmisję multimediów peer-to-peer.
• Flow 2' — reprezentuje przepływ zainicjowany przez zdalnego użytkownika mobilnych usług komunikacyjnych z siecią klienta przy użyciu 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 typu peer-to-peer między jednym użytkownikiem usługi Communication Services a innym w ramach sieci klienta.
• Flow 6 — reprezentuje przepływ mediów typu peer-to-peer między zdalnym użytkownikiem usług komunikacyjnych mobilnych a innym zdalnym użytkownikiem usług komunikacyjnych mobilnych przez Internet.

Przypadek użycia: rozmowa jeden-na-jeden

Bezpośrednie połączenie między użytkownikami oznacza, że jeden użytkownik dzwoni do innego użytkownika. Aby zainicjować połączenie, SDK uzyskuje zestaw kandydatów składających się z adresów IP i portów, w tym lokalnych, przekaźnikowych i refleksyjnych (publiczny adres IP klienta widoczny przez przekaźnik). Zestaw SDK wywołujący wysyła tych kandydatów do wywoływanej partii. Wywołana partia otrzymuje podobny zestaw kandydatów i wysyła je do rozmówcy.

System używa komunikatów sprawdzania łączności STUN, aby znaleźć, które drogi multimedialne użytkownika inicjującego/odbierającego połączenie działają, a następnie wybiera najlepiej działającą drogę. Po ustanowieniu ścieżki połączenia system wykonuje uzgadnianie warstwy zabezpieczeń transportu datagramów (DTLS) w celu zapewnienia bezpieczeństwa. Po uzgadnianiu usługi DTLS system uzyskuje klucze SRTP z procesu uzgadniania DTLS. Nośnik (czyli pakiety RTP/RTCP zabezpieczone przy użyciu SRTP) są następnie wysyłane za pomocą 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ść, zostanie wybrana bezpośrednia ścieżka między klientami (lub przy użyciu translatora adresów sieciowych) dla nośnika. Jeśli obaj klienci znajdują się w sieci klientów, należy wybrać ścieżkę bezpośrednią. Wymaga to bezpośredniej łączności UDP w sieci klienta. Jeśli klienci są oboje mobilnymi użytkownikami chmury, to w zależności od NAT/zapory ogniowej, przekaz może używać bezpośredniego połączenia.

Jeśli jeden klient znajduje się w wewnętrznej sieci klienta, a drugi klient jest zewnętrzny (na przykład użytkownik chmury mobilnej), jest mało prawdopodobne, że zostanie umożliwione bezpośrednie połączenie między kandydatami lokalnymi lub odbiciowymi. 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.

Wysokopoziomowe 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 Teams za pomocą 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 Teams przy użyciu 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. Użytkownik A i użytkownik B wywołują testy łączności ICE, a wybrana jest najlepsza dostępna ścieżka multimediów Zobacz poniższe diagramy 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)

W kroku 7 wybrano multimedialny przepływ równorzędny 5.

Ta transmisja multimediów jest dwukierunkowa. Kierunek 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ć dla klientów do użytkownika zewnętrznego (media przekazywane przez Teams 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).

Usługa Teams Transport Relay obsługuje te przepływy 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 multimediów, za pomocą różnych protokołów transportu i adresów.

Sieć klienta do użytkownika zewnętrznego (bezpośrednia transmisja)

W kroku 7 wybrano Flow 2 (od sieci klienta do punktu równorzędnego klienta przez Internet).

Bezpośrednie media z zdalnym użytkownikiem mobilnym (bez przekazywania za pośrednictwem Azure) są opcjonalne. Innymi słowy, możesz zablokować tę trasę, aby wymusić drogę przesyłu danych multimedialnych przez przekaźnik transportowy w Azure.

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

Użytkownik VPN do użytkownika wewnętrznego (media przekazywane przez Teams Transport 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 media omijają sieć VPN i są kierowane za pomocą przepływów 3 i 4 przez usługę Azure Media Relay.

Użytkownik VPN do użytkownika wewnętrznego (bezpośrednie połączenie)

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 transmisja multimediów pomija sieć VPN i jest kierowana przy użyciu procesu 2 z sieci klienta do Internetu.

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

Użytkownik VPN do użytkownika zewnętrznego (bezpośredni przekaz)

Sygnalizacja między użytkownikiem sieci VPN a siecią klienta wykorzystuje Flow 2* i Flow 4 do Azure. Jednak strumień danych pomija sieć VPN i jest kierowany przy użyciu metody Flow 6.

Ta transmisja multimediów jest dwukierunkowa. Kierunek przepływu Flow 6 do zdalnego użytkownika mobilnego wskazuje, że jedna ze stron inicjuje komunikację z punktu widzenia połączenia.

Przypadek użycia: klient usług komunikacyjnych do sieci PSTN za pośrednictwem trunku 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).

W takim przypadku sygnalizacja i dane multimedialne z sieci klienta do platformy Azure używają Flow 4.

Wywołania grupowe w usłudze komunikacyjnej - przypadek użycia

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 dla nomadycznego klienta chmury. Każdy klient/punkt końcowy musi mieć możliwość nawiązania połączenia z usługą.

Klienci wewnętrzni uzyskują kandydatów lokalnych, refleksyjnych i przekaźnikowych w taki sam sposób, jak opisano w przypadku połączeń jeden do jednego. Klienci przekazują tych kandydatów do usługi poprzez zaproszenie. 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.

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 węzła. Jeśli przekażesz przepływ do następnego przeskoku, może to nie być zrozumiałe.

Serwery proxy SIP podmiotów trzecich. Usługa Communication Services sygnalizuje okno dialogowe SIP z innym dostawcą SBC i/lub bramą może przechodzić 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 od innych firm. Zewnętrzny SBC kończy przepływy mediów usług komunikacyjnych do i z PSTN. Interoperacyjność z SBC innej firmy w ramach sieci usług komunikacyjnych (gdzie SBC innej firmy pośredniczy pomiędzy dwoma punktami końcowymi usług komunikacyjnych) nie jest obsługiwana.

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 / Notatka

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

Kształtatory pakietów. Obcinanie pakietów, inspekcja pakietów lub urządzenia do kształtowania pakietów nie są obsługiwane i mogą znacznie pogorszyć jakość.

Dalsze kroki

Rozpocznij rozmowy telefoniczne

Powiązane artykuły

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