Topologie przepływu połączeń

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

Kontekst

Pojęcia dotyczące sieci

Przed przejrzeniem topologii przepływu wywołań warto zapoznać się z terminami używanymi w tym artykule.

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 obwodów sieci z zaporami lub serwerami proxy, które wymuszają zasady zabezpieczeń organizacji. Zalecamy przeprowadzenie kompleksowej oceny sieci w celu uzyskania optymalnej wydajności i jakości rozwiązania komunikacyjnego.

Sieć usług Azure Communication Services to sieć, która obsługuje usługi Azure Communication Services. Firma Microsoft zarządza tą siecią i dystrybuuje ją na całym świecie za pomocą centrów danych należących do firmy Microsoft, które znajdują się 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 Azure Communication Services są oparte głównie na dwóch typach ruchu: nośnikach w czasie rzeczywistym i sygnalizowaniu.

Nośniki w czasie rzeczywistym są przesyłane za pośrednictwem protokołu Real-Time Transport Protocol (RTP). Ten protokół obsługuje transmisję danych audio, wideo i udostępniania 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 (User Datagram Protocol) jako protokołu warstwy transportu do 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 za pośrednictwem bezpiecznego protokołu RTP (SRTP).

Użytkownicy rozwiązania Azure Communication Services łączą się z usługami z urządzeń klienckich. Signaling obsługuje komunikację między tymi urządzeniami a serwerami. Na przykład sygnał między urządzeniami a usługą obsługuje inicjowanie połączeń i czat w czasie rzeczywistym. Większość ruchu sygnalizowego używa protokołu HTTPS REST. W niektórych scenariuszach można użyć protokołu inicjowania sesji (SIP) jako protokołu sygnalizującego ruch. Mimo że ten typ ruchu jest mniej wrażliwy na opóźnienia, sygnały o małych opóźnieniach zapewniają przyjemne środowisko użytkownika końcowego.

Szyfrowanie multimediów

Przepływy wywołań w usługach Azure Communication Services wywołujące zestaw SDK i klienci usługi Teams są oparte na ofercie protokołu RFC 8866 protokołu SDP (Session Description Protocol) i modelu odpowiedzi za pośrednictwem protokołu HTTPS. Gdy obiekt wywoływany akceptuje wywołanie przychodzące, obiekt wywołujący i wywoływany zgadza się na parametry sesji.

Ruch multimedialny jest szyfrowany i przepływa między obiektem wywołującym i wywoływanym przez funkcję SRTP, profilem protokołu RTP, który zapewnia poufność, uwierzytelnianie i odtwarzanie ochrony przed atakami na ruch RTP. W większości przypadków ruch multimedialny klient-klient jest negocjowany za pośrednictwem sygnału połączenia klient-serwer i jest szyfrowany za pośrednictwem protokołu SRTP podczas przechodzenia bezpośrednio z klienta do klienta.

Wystąpienia usług Azure Communication Services wywołujące klientów zestawu SDK używają usługi Datagram Transport Layer Security (DTLS) do uzyskiwania klucza szyfrowania. Po zakończeniu uzgadniania usługi DTLS nośnik zaczyna przepływać przez ten klucz szyfrowania wynegocjowany przez usługę DTLS za pośrednictwem protokołu SRTP.

Wystąpienia usług 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 funkcji TURN. Przekaźniki multimediów wymieniają token za pośrednictwem zabezpieczonego kanału Transport Layer Security (TLS).

Ruch multimedialny przechodzący między dwoma punktami końcowymi uczestniczącymi w usługach Azure Communication Services audio, wideo i udostępnianie wideo używa 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 szyfrowanego kanału UDP/TCP protokołu TLS 1.2 i AES-256 (w trybie GCM).

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 Azure Communication Services określa region, w którym jest hostowane wywołanie. Istnieją wyjątki od tej reguły w niektórych topologiach, które można znaleźć w dalszej części tego artykułu.

• Punkt końcowy multimediów używany do obsługi wywołania usług Azure Communication Services 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 nośnika w chmurze do przetwarzania multimediów na potrzeby transkrypcji lub nagrywania. 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 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 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 przechodzić przez serwery, które działają jak kształtatory pakietów lub serwery wirtualnej sieci prywatnej (VPN) ani wykonywać innych funkcji, 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 Wywoływanie przepływów koncepcyjnych dokumentacji.

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

Azure Communication Services (Internet)

Ten przykład topologii przepływu wywołań przedstawia klientów korzystających z usług Azure Communication Services z chmury bez żadnego wdrożenia lokalnego, takiego jak routing bezpośredni na platformie Azure. W tej topologii ruch do i z usług Azure Communication Services 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ływu

• Flow 2: reprezentuje przepływ zainicjowany przez użytkownika w sieci klienta do Internetu w ramach środowiska usług Azure Communication Services 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 usług Azure Communication Services z siecią klienta za pomocą sieci VPN.
• Flow 3: reprezentuje przepływ zainicjowany przez zdalnego użytkownika usług Azure Communication Services do punktów końcowych usług Azure Communication Services.
• Przepływ 4: reprezentuje przepływ zainicjowany przez użytkownika w sieci klienta do usług Azure Communication Services.
• Przepływ 5: reprezentuje przepływ multimediów równorzędnych między jednym użytkownikiem usług Azure Communication Services i innym w sieci klienta.
• Przepływ 6: reprezentuje przepływ multimediów równorzędnych między zdalnym użytkownikiem usług Azure Communication Services i innym zdalnym użytkownikiem usług Azure Communication Services za pośrednictwem Internetu.

Przypadek użycia: rozmowa jeden-na-jeden

Wywołanie jeden do jednego oznacza, że jeden użytkownik bezpośrednio wywołuje innego użytkownika. Aby zainicjować wywołanie, zestaw SDK wywołujący uzyskuje zestaw kandydatów, który składa się z adresów IP i portów. Ten zestaw obejmuje kandydatów lokalnego, przekaźnika i refleksyjnego (publicznego adresu IP klienta widocznego 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óry obiekt wywołujący/nazwany ścieżki multimediów firmy działa, a następnie wybiera najlepszą ścieżkę roboczą. Po ustanowieniu przez system ścieżki połączenia wykonuje uzgadnianie dtLS za pośrednictwem połączenia w celu zapewnienia bezpieczeństwa. Po uzgadnianiu usługi DTLS system uzyskuje klucze SRTP z procesu uzgadniania DTLS. Następnie nośniki (pakiety RTP/RTCP zabezpieczone za pośrednictwem srTP) są wysyłane za pośrednictwem 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 jeśli używasz translatora adresów sieciowych) dla nośnika. Jeśli obaj klienci znajdują się w sieci klientów, należy wybrać ścieżkę bezpośrednią. Wybór ten wymaga 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 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 można użyć jednego z kandydatów przekaźnika transportu z dowolnego klienta. Na przykład klient wewnętrzny uzyskał kandydata do przekazywania z przekaźnika transportowego na platformie Azure, a 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 przekaźnika uzyskanego przez klienta chmury mobilnej. Mimo że zdecydowanie zalecamy łączność UDP dla nośników, protokół TCP jest obsługiwany.

Kroki na wysokim poziomie

1. Użytkownik usług Azure Communication Services 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 A wysyła zaproszenie z kandydatami do interaktywnego ustanowienia łączności (ICE) przy użyciu usługi Flow 4 do usług Azure Communication Services.

4. Usługi Azure Communication Services 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. Użytkownik A i Użytkownik B wywołują testy łączności ICE i wybrano najlepszą dostępną ścieżkę multimediów. Zapoznaj się z poniższymi diagramami, aby zobaczyć różne przypadki użycia.

8. Obaj użytkownicy wysyłają dane telemetryczne do usług Azure Communication Services przy użyciu usługi Flow 4.

Sieć klienta (intranet)

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

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ć klienta dla użytkownika zewnętrznego (nośnik przekazywany przez przekaźnik transportu usługi Teams)

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

Przekaźnik transportu usługi Teams 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 nośników, a także używają różnych protokołów transportu i adresów.

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

W kroku 7 wybrano usługę Flow 2 (z sieci klienta do komunikacji równorzędnej 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 Flow 2 do zdalnego użytkownika mobilnego wskazuje, że jedna strona inicjuje komunikację z punktu widzenia łączności.

Użytkownik sieci VPN do użytkownika wewnętrznego (nośnik przekazywany przez przekaźnik transportu usługi Teams)

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 za pośrednictwem przepływów 3 i 4 za pośrednictwem usługi 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 używa usługi Flow 4. Jednak nośnik pomija sieć VPN i jest kierowany przez usługę Flow 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)

Sygnalizowanie między użytkownikiem sieci VPN a siecią klienta korzysta z usług Flow 2 i Flow 4 do platformy Azure. Jednak nośnik pomija sieć VPN i jest kierowany za pośrednictwem usługi 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 Azure Communication Services do sieci PSTN za pośrednictwem magistrali usług Azure Communication Services

Usługi Azure Communication Services umożliwiają umieszczanie i odbieranie połączeń z publicznej sieci telefonicznej przełączonej (PSTN). Jeśli magistrala PSTN jest połączona za pośrednictwem numerów telefonów dostarczonych przez usługi Azure Communication Services, 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.

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

Przypadek użycia: wywołania grup usług Azure Communication Services

Usługa udostępniająca udostępnianie dźwięku, wideo i ekranu jest częścią usług Azure Communication Services. Ma on publiczny adres IP, który musi być dostępny zarówno z sieci klienta, jak i klienta chmury koczowniczej. Każdy klient i punkt końcowy muszą 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 na lokalny adres 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

Nośnik przepływujący za pośrednictwem usług Azure Communication Services jest ograniczony w następujący sposób:

• Kontroler granic sesji innej firmy (SBC): SBC na granicy z PSTN powinien zakończyć strumień RTP/RTCP, zabezpieczony za pośrednictwem 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 innych firm: usługa Azure 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: SBC innej firmy kończy te przepływy multimediów usług Azure Communication Services do i z PSTN. Współdziałanie z usługą SBC innej firmy w sieci usług Azure Communication Services (w której pośredniczy dwa punkty końcowe usług Azure Communication Services innej firmy) nie jest obsługiwane.

Nieobsługiwane technologie

• Sieć VPN: usługi Azure Communication Services 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

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

• Kształtatory pakietów: Urządzenia kształtujące pakiety, inspekcja pakietów lub kształtowanie pakietów nie są obsługiwane i mogą znacznie obniżyć jakość.

Następny krok

Treści powiązane

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