Podstawy przepływu wywołań

  • Artykuł

Poniższa sekcja zawiera omówienie przepływów wywołań w usługach Azure Communication Services. Sygnały i przepływy multimediów zależą od typów wywołań, które robią użytkownicy. Przykłady typów wywołań obejmują jeden do jednego VoIP, jeden do jednego PSTN i wywołania grup zawierające kombinację uczestników voIP i PSTN połączonych. Przejrzyj typy wywołań.

Informacje o protokołach sygnalizujących i multimedialnych

Podczas ustanawiania połączenia równorzędnego lub grupowego dwa protokoły są używane w tle — HTTPS (REST) do sygnalizowania i SRTP dla multimediów.

Sygnalizowanie między zestawami SDK lub między zestawami SDK a kontrolerami signaling usług komunikacyjnych jest obsługiwane za pomocą protokołu HTTPS REST (TLS). Usługi Azure Communication Services używają protokołu TLS 1.2. W przypadku ruchu multimediów w czasie rzeczywistym (RTP) preferowany jest protokół UDP (User Datagram Protocol). Jeśli użycie protokołu UDP jest blokowane przez zaporę, zestaw SDK użyje protokołu TCP (Transmission Control Protocol) dla nośnika.

Przejrzyjmy protokoły sygnalizacyjne i medialne w różnych scenariuszach.

Przypadki przepływu wywołań

Przypadek 1: VoIP, w którym możliwe jest bezpośrednie połączenie między dwoma urządzeniami

W przypadku połączeń voIP typu jeden do jednego lub połączeń wideo ruch preferuje najbardziej bezpośrednią ścieżkę. "Ścieżka bezpośrednia" oznacza, że jeśli dwa zestawy SDK mogą się połączyć bezpośrednio, ustanowią bezpośrednie połączenie. Zwykle jest to możliwe, gdy dwa zestawy SDK znajdują się w tej samej podsieci (na przykład w podsieci 192.168.1.0/24) lub dwóch, gdy urządzenia znajdują się w podsieciach, które będą widzieć siebie nawzajem (zestawy SDK w podsieci 10.10.0.0/162.168.1.0/24 mogą się ze sobą połączyć).

Diagram showing a Direct VOIP call between users and Communication Services.

Przypadek 2: VoIP, w którym bezpośrednie połączenie między urządzeniami nie jest możliwe, ale jeśli możliwe jest połączenie między urządzeniami NAT

Jeśli dwa urządzenia znajdują się w podsieciach, które nie mogą się ze sobą połączyć (na przykład Alice działa z kawiarni, a Bob działa ze swojego domu), ale połączenie między urządzeniami NAT jest możliwe, zestawy SDK po stronie klienta ustanowią łączność za pośrednictwem urządzeń NAT.

Dla Alice będzie to NAT kawiarni i dla Bob będzie NAT domu. Urządzenie Alice wyśle zewnętrzny adres translatora adresów sieciowych, a Bob zrobi to samo. Zestawy SDK poznają adresy zewnętrzne z usługi STUN (Session Traversal Utilities for NAT), którą usługi Azure Communication Services udostępniają bezpłatnie. Logika, która obsługuje uzgadnianie między Alice i Bob, jest osadzona w udostępnionych zestawach SDK usług Azure Communication Services. (Nie potrzebujesz żadnej dodatkowej konfiguracji)

Diagram showing a VOIP call which utilizes a STUN connection.

Przypadek 3: VoIP, w którym nie jest możliwe ani bezpośrednie połączenie NAT

Jeśli jeden lub oba urządzenia klienckie znajdują się za symetrycznym translatorem adresów sieciowych, wymagana jest oddzielna usługa w chmurze do przekazywania multimediów między dwoma zestawami SDK. Ta usługa jest nazywana TURN (przechodzenie przy użyciu przekaźników wokół translatora adresów sieciowych) i jest również zapewniana przez usługi komunikacyjne. Zestaw SDK wywołujący usługi Communication Services automatycznie używa usług TURN na podstawie wykrytych warunków sieciowych. Opłaty za usługę TURN są uwzględniane w cenie połączenia.

Diagram showing a VOIP call which utilizes a TURN connection.

Przypadek 4. Wywołania grupowe przy użyciu nazwy PSTN

Zarówno sygnał, jak i nośnik dla połączeń PSTN używają zasobu telefonii usług Azure Communication Services. Ten zasób jest połączony z innymi przewoźnikami.

Ruch multimedialny PSTN przepływa przez składnik o nazwie Procesor multimediów.

Diagram showing a PSTN Group Call with Communication Services.

Uwaga

W przypadku osób zaznajomionych z przetwarzaniem multimediów procesor multimediów jest również agentem powrót do zaplecza użytkownika, zgodnie z definicją w dokumencie RFC 3261 SIP: Protokół inicjowania sesji, co oznacza, że może tłumaczyć koderów podczas obsługi wywołań między sieciami firmy Microsoft i operatora. Kontroler sygnalizacyjny usług Azure Communication Services to implementacja serwera proxy SIP firmy Microsoft dla tego samego RFC.

W przypadku wywołań grupowych, multimediów i sygnałów zawsze przepływa za pośrednictwem zaplecza usług Azure Communication Services. Dźwięk i/lub wideo ze wszystkich uczestników są mieszane w składniku Procesora multimediów. Wszyscy członkowie wywołania grupy wysyłają strumienie audio i/lub wideo do procesora multimediów, który zwraca mieszane strumienie multimediów.

Domyślny protokół czasu rzeczywistego (RTP) dla wywołań grup to User Datagram Protocol (UDP).

Uwaga

Procesor multimediów może pełnić rolę jednostki sterowania Multipoint (MCU) lub selektywnej jednostki przekazywania (SFU)

Diagram showing UDP media process flow within Communication Services.

Jeśli zestaw SDK nie może używać protokołu UDP dla multimediów z powodu ograniczeń zapory, zostanie podjęta próba użycia protokołu TCP (Transmission Control Protocol). Należy pamiętać, że składnik procesora multimediów wymaga protokołu UDP, więc w takim przypadku usługa Communication Services TURN zostanie dodana do wywołania grupy w celu przetłumaczenia protokołu TCP na UDP. Opłaty za usługę TURN są uwzględniane w cenie połączenia.

Diagram showing TCP media process flow within Communication Services.

Przypadek 5: Zestaw SDK usług komunikacyjnych i usługa Microsoft Teams w zaplanowanym spotkaniu usługi Teams

Sygnalizowanie przepływa przez kontroler sygnalizacyjny. Nośnik przepływa przez procesor multimediów. Kontroler sygnalizacyjny i procesor multimediów są współużytkowane między usługami Communication Services i Microsoft Teams.

Diagram showing Communication Services SDK and Teams Client in a scheduled Teams meeting.

Przypadek 6. Wczesne nośniki

Odnosi się do multimediów (np. audio i wideo), które są wymieniane przed zaakceptowaniem określonej sesji przez wywołanego użytkownika. Jeśli istnieje wczesny przepływ multimediów, protokół SBC musi zatrzasać się do pierwszego punktu końcowego, który uruchamia nośniki strumieniowe; przepływ mediów może rozpocząć się przed nominacją kandydatów. Protokół SBC powinien mieć obsługę wysyłania dtMF w tej fazie w celu włączenia scenariuszy IVR/poczty głosowej. SBC powinien użyć ścieżki o najwyższym priorytcie, na której otrzymał kontrole, czy nominacje nie zostały ukończone.

Następne kroki

Rozpoczynanie pracy z nawiązywaniem połączenia

Poniższe dokumenty mogą cię zainteresować: