Wywoływanie wewnętrznych procedur sieciowych

W tym artykule opisano przepływy 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 połączeń obejmują połączenia jeden do jednego za pomocą VoIP, jeden do jednego w publicznej sieci telefonicznej (PSTN) oraz połączenia grupowe zawierające kombinację uczestników podłączonych za pomocą VoIP i PSTN. Aby uzyskać więcej informacji, zobacz Typy wywołań.

Protokoły sygnalizacyjne i medialne

Podczas ustanawiania połączenia równorzędnego lub grupowego dwa protokoły są używane w tle — HTTPS (REST) do sygnalizacji i bezpieczny protokół transportowy czasu rzeczywistego (SRTP) dla mediów.

Sygnalizowanie między zestawami SDK lub między zestawami SDK a kontrolerami sygnalizowania 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) zalecamy użycie protokołu datagramu użytkownika (UDP). Jeśli zapora uniemożliwia korzystanie z protokołu UDP, zestaw SDK używa 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 z bezpośrednim połączeniem 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 SDK mogą się wzajemnie dosięgnąć, nawiązują bezpośrednie połączenie. Ścieżka bezpośrednia jest możliwa, gdy dwa zestawy SDK znajdują się w tej samej podsieci (na przykład w podsieci 192.168.1.0/24) lub gdy urządzenia znajdują się w podsieciach, które mogą się wzajemnie widzieć (zestawy SDK w podsieciach 10.10.0.0/16 i 192.168.1.0/24 mogą się ze sobą komunikować).

Przypadek 2: VoIP, w którym bezpośrednie połączenie między urządzeniami nie jest możliwe, ale 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ć, ale połączenie między urządzeniami translatora adresów sieciowych (NAT) jest możliwe, zestawy SDK po stronie klienta ustanawiają łączność za pośrednictwem urządzeń NAT. Jeśli na przykład Alice pracuje z kawiarni, a Bob pracuje z domu.

Dla Alicji jest to NAT kawiarni, a dla Boba NAT biura domowego. Urządzenie Alice wysyła zewnętrzny adres translatora adresów sieciowych, a Bob robi to samo. Pakiety SDK uczą się adresów zewnętrznych za pomocą narzędzi obsługi sesji dla NAT (STUN) udzielaną bezpłatnie przez Azure Communication Services. 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 dodanej konfiguracji.

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

Jeśli jedno lub oba urządzenia klienckie znajdują się za symetrycznym NAT, oddzielna usługa chmurowa jest wymagana do przesyłania mediów między dwoma zestawami SDK. Ta usługa nazywana jest przechodzeniem przy użyciu przekaźników wokół NAT (TURN) i jest również udostępniana przez Azure Communication Services. SDK do wykonywania połączeń w ramach Communication Services automatycznie używa usług TURN na podstawie zidentyfikowanych warunków sieciowych. Opłaty za usługę TURN są uwzględniane w cenie połączenia.

Przypadek 4. Wywołania grupowe z PSTN

Zarówno sygnalizacja, jak i media dla połączeń PSTN korzystają z zasobów telefonicznych usług Azure Communication Services. Ten zasób jest połączony z innymi przewoźnikami.

Ruch multimedialny PSTN przepływa przez składnik procesora multimediów.

W przypadku wywołań grupowych, multimedia i sygnały zawsze przepływają za pośrednictwem zaplecza Azure Communication Services. Dźwięk i/lub wideo ze wszystkich uczestników są mieszane w procesorze multimediów. Wszyscy członkowie połączenia grupowego wysyłają strumienie audio i wideo do procesora multimediów, który zwraca złożone strumienie multimediów.

Domyślnym protokołem czasu rzeczywistego (RTP) dla wywołań grupowych jest protokół datagramu użytkownika (UDP).

Jeśli zestaw SDK nie może używać protokołu UDP dla nośnika z powodu ograniczeń zapory, próbuje użyć protokołu TCP (Transmission Control Protocol). Składnik procesora multimediów wymaga protokołu UDP, więc w takim przypadku usługa TURN z komunikacyjnych usług jest dodawana do połączenia grupowego w celu przetłumaczenia protokołu TCP na UDP. Opłaty za usługę TURN są uwzględniane w cenie połączenia.

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

Sygnalizowanie przepływa przez kontroler sygnalizacyjny. Media przepływa przez procesor mediów. Kontroler sygnału 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 nośników wymienianych, takich jak audio i wideo, zanim odbiorca zaakceptuje sesję. W przypadku wczesnego przepływu multimediów kontroler granic sesji (SBC) musi zablokować się do pierwszego węzła końcowego, który zaczyna strumieniować media; przepływ multimediów może rozpocząć się przed nominacją kandydatów. W tej fazie SBC musi obsługiwać wysyłanie dwóch tonów z wieloma częstotliwościami (DTMF), aby umożliwić obsługę scenariuszy IVR/poczty głosowej. SBC powinien używać ścieżki o najwyższym priorytcie, na której otrzymuje kontrole, jeśli nominacje nie zostaną ukończone.

Dalsze kroki

Powiązane artykuły

• 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ń