Podstawy przepływu wywołań
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ć).
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)
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.
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.
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)
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.
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.
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
Poniższe dokumenty mogą cię zainteresować:
- Dowiedz się więcej o typach wywołań
- Dowiedz się więcej o architekturze klient-serwer
- Dowiedz się więcej o topologii przepływu wywołań