Czym jest trunk SIP i czy go potrzebuję?

Trunk SIP to połączenie między sprzętem, który obsługujesz, a siecią operatora. Potrzebujesz go, ponieważ każde połączenie do lub z sieci telefonicznej przez niego przechodzi.

Trunk to granica, na której operator decyduje, które połączenia Twój sprzęt może wysyłać i odbierać. Jeśli masz PBX, czyli firmowy system telefoniczny kierujący Twoje połączenia, kontroler sesji brzegowej, platformę contact center lub dowolnego innego klienta SIP, trunk jest drogą, którą połączenia docierają do świata zewnętrznego i którą połączenia zewnętrzne docierają do niego. Kontroler sesji brzegowej to urządzenie chroniące brzeg sieci głosowej.

Pierwsze pytanie brzmi zwykle, czy w ogóle go potrzebujesz, a odpowiedź brzmi: tak. Różni się tylko to, co postawisz za nim.

Czy naprawdę potrzebuję trunka?

Tak. Między konfiguracjami różni się klient po Twojej stronie, a nie to, czy trunk istnieje.

Każde połączenie do lub z sieci telefonicznej przechodzi przez trunk, ponieważ to na nim platforma decyduje, czy w ogóle je przyjąć. Dwa warianty są typowe:

  • Masz system telefoniczny. PBX, softswitch lub platforma contact center, która już obsługuje połączenia i potrzebuje trasy do sieci publicznej. Łączy się jako peer, zwykle ze stałego adresu, a jej własny plan wybierania, czyli reguły kierujące połączenia, steruje nimi.
  • Masz kod aplikacji. Chcesz, żeby Twoje oprogramowanie nawiązywało i odbierało połączenia bez uruchamiania infrastruktury telekomunikacyjnej. Trunk nadal jest potrzebny, a to, co z nim rozmawia, może być niewielkie: softphone, przeglądarka, CLI lub środowisko uruchomieniowe agenta głosowego. Uwierzytelnia się krótkotrwałym poświadczeniem sesji, czyli tymczasową nazwą użytkownika i hasłem dla klienta SIP, zamiast ze sprzętu na znanym adresie.

Różnica dotyczy tego, gdzie żyje sterowanie połączeniami, a nie skali, i żaden wariant nie omija trunka. Lekki klient oszczędza Ci prowadzenia systemu telefonicznego, nie samego połączenia. Własne narzędzia Bird pokazują to podwójnie: telefon w dashboardzie i połączenie testowe CLI to klienci SIP wykonujący prawdziwe połączenia przez jeden z Twoich trunków.

Trunk nie jest też alternatywą dla API, ponieważ żaden endpoint nie nawiązuje połączenia do wybranego przez Ciebie celu. Czym jest głosowy API opisuje, jak część konfiguracyjna i część sygnalizacyjna dzielą między siebie pracę.

Co trunk właściwie robi?

Daje Twojemu sprzętowi adres, na który wysyła połączenia, i decyduje, które z nich przyjąć.

Bird przypisuje każdemu trunkowi stałą domenę SIP, którą wpisujesz w swoim systemie telefonicznym, żeby połączenia mogły być powiązane z trunkiem. Twój sprzęt wysyła na tę domenę jednym z trzech transportów: UDP lub TCP na 5060 albo TLS na 5061, gdy chcesz szyfrować sygnalizację w transmisji.

Nowy trunk odrzuca każde połączenie. Oba kierunki są wyłączone i żaden nadawca nie jest autoryzowany. To celowe ustawienie domyślne, a nie niekompletna konfiguracja. Trunk, który przyjmowałby połączenia od momentu powstania, byłby otwartym zaproszeniem, a toll fraud szybko czyni to kosztownym.

Dlaczego kierunek wychodzący i przychodzący konfiguruje się osobno?

Ponieważ to różne problemy z różnymi trybami awarii, a trunk obsługuje każdy kierunek niezależnie.

Wychodzący to Twój system telefoniczny wykonujący połączenia przez Bird. Dopóki go nie włączysz, trunk odrzuca każdą próbę połączenia wychodzącego niezależnie od poświadczeń, więc poprawnie uwierzytelnione połączenie i tak nie przejdzie, jeśli kierunek jest wyłączony.

Przychodzący to dostarczanie przez Bird połączeń do Twojego systemu telefonicznego na numery wskazujące na trunk. Samo włączenie nie wystarczy: trunk z włączonym kierunkiem przychodzącym, ale bez bramy dostarczania, odrzuca każde połączenie przychodzące na swoje numery. Przypisanie numeru do trunka wykonuje się na numerze, a nie na trunku. To druga połowa, o której ludzie zapominają.

Wyłączenie połączeń przychodzących przełącza każdy numer wskazujący na ten trunk z powrotem na odrzucanie, a ponowne włączenie ich nie przywraca. Usunięcie trunka daje ten sam efekt. Cofnięcie nie jest więc symetryczne: jeśli wyłączasz kierunek przychodzący w celu testu, zaplanuj ponowne przypisanie każdego numeru i sprawdź numery, zamiast zakładać, że przełącznik je przywrócił.

Jak trunk decyduje, kto może wysyłać mu połączenia?

Decydują o tym lista dozwolonych adresów IP, uwierzytelnianie kluczem API i poświadczenia sesji. Można je łączyć, a każdy mechanizm staje się aktywny, gdy tylko ma jeden wpis.

Lista dozwolonych adresów IP. Dodaj publiczne adresy, z których Twój sprzęt wysyła połączenia do SIP. Filtrowanie zaczyna działać, gdy lista ma choćby jeden wpis, i od tego momentu połączenia mogą wysyłać tylko wymienione zakresy. Dla sprzętu za NAT-em jest to publiczny adres routera, a nie prywatny adres systemu telefonicznego. Połączenia z adresów spoza listy są odrzucane na warstwie SIP i zwykle nigdy nie trafiają do logu połączeń. Pusty log jest więc objawem tego problemu, a nie dowodem, że nic nie próbowano.

Uwierzytelnianie kluczem API. Bird wysyła wyzwanie, a Twój system odpowiada skrótem hasła zamiast samym hasłem. Skrót jest weryfikowany względem klucza Bird API z uprawnieniem głosowym na poziomie zapisu. W Twoim PBX-ie nazwa użytkownika to zawsze bird, a hasło to sekret klucza. Tak jak lista IP, mechanizm staje się wyłączny, gdy tylko jeden klucz zostanie dopuszczony.

Z tego wynikają dwa szczegóły operacyjne. Odebranie kluczowi uprawnienia głosowego natychmiast blokuje jego uwierzytelnianie. Klucz pozostaje na liście dozwolonych trunka, oznaczony, więc lista nigdy nie wygląda na działającą, gdy nie działa. Przywrócenie uprawnienia przywraca klucz bez żadnych zmian. Unieważnienie lub usunięcie klucza jest natychmiastowe na każdym trunku, który go dopuszczał, i jest trwałe. Rotuj klucze, dodając nowy klucz do trunka jako pierwszy, przenosząc na niego sprzęt i unieważniając stary jako ostatni.

Poświadczenia sesji. Krótkotrwała nazwa użytkownika i hasło SIP odpowiadające na to samo wyzwanie bez ujawniania długotrwałego sekretu. Na nowym trunku są wyłączone i należą do obszaru roboczego, a nie do jednego trunka. Hasło jest zwracane tylko w momencie wystawienia.

Włączenie poświadczeń sesji nie zmienia sposobu łączenia się sprzętu z listy dozwolonych. Połączenie z adresu na liście na trunku bez dopuszczonych kluczy API nadal jest wpuszczane bez wyzwania hasła. Jeśli zamierzałeś, żeby poświadczenie było bramą, lista IP po cichu wciąż nią jest.

Dlaczego moja przeglądarka lub softphone nie mogą się uwierzytelnić?

Prawie zawsze chodzi o algorytm digest. To jedyne ustawienie, które zawodzi w sposób wyglądający jak problem z poświadczeniami.

Domyślnie Bird oferuje najpierw SHA-256, a potem MD5, a Twój sprzęt odpowiada pierwszym, który obsługuje. Trunk akceptuje tylko algorytmy, które oferuje, więc zawężenie oferty zawęża to, co może się połączyć.

Pułapką są przeglądarki: przeglądarka odpowiada MD5 i niczym innym. Trunk oferujący wyłącznie SHA-256 odrzuca każde połączenie z przeglądarki, łącznie z telefonem w dashboardzie. Zostaw więc MD5 w ofercie na każdym trunku, z którego zamierzasz dzwonić z przeglądarki, a po sam MD5 sięgaj wtedy, gdy PBX niepoprawnie obsługuje wyzwanie zaczynające się od SHA-256. Klucze API działają z obydwoma algorytmami i nigdy nie wymagają ponownego wystawienia przy zmianie oferty.

Co więc skonfigurować?

  1. Trunk, niezależnie od wariantu. Każde połączenie przez niego przechodzi, więc ten krok nie jest opcjonalny.
  2. Peer, jeśli masz system telefoniczny. Podłącz PBX lub platformę contact center ze stałego adresu i pozwól jej planowi wybierania sterować połączeniami.
  3. Lekki klient, jeśli masz kod aplikacji. Softphone, przeglądarka, CLI lub środowisko uruchomieniowe agenta, uwierzytelniające się krótkotrwałym poświadczeniem sesji zamiast znanego adresu.
  4. Jedna reguła nadawcy, bez względu na wybór. Lista dozwolonych adresów IP, dopuszczony klucz API lub poświadczenie sesji. Pamiętaj, że każdy mechanizm staje się wyłączny, gdy tylko ma jeden wpis.
  5. MD5 pozostawiony w ofercie digest na każdym trunku, z którego zamierzasz dzwonić z przeglądarki.

Trunki SIP opisuje każde ustawienie i gdzie je znaleźć. Klienci SIP opisuje podłączanie pojedynczego klienta zamiast systemu telefonicznego, a rozwiązywanie problemów z głosem pomaga w przypadku połączeń, które nie dochodzą.

W skrócie

  1. Każda droga do sieci telefonicznej prowadzi przez trunk.

    Różnica dotyczy klienta po Twojej stronie: system telefoniczny podłączony jako peer albo lżejszy klient SIP, na przykład przeglądarka lub CLI na krótkotrwałym poświadczeniu.

  2. Nowy trunk odrzuca wszystko.

    Oba kierunki są wyłączone i nie ma autoryzowanego nadawcy, dopóki go nie dodasz. To celowe zachowanie, a nie krok konfiguracji, który można pominąć.

  3. Każdy kierunek włączasz osobno, a przychodzący wymaga bramy dostarczania.

    Trunk z włączonym kierunkiem przychodzącym, ale bez bramy dostarczania, odrzuca każde połączenie przychodzące na swoje numery.

  4. Wyłączenie kierunku przychodzącego nie cofa się czysto.

    Każdy numer wskazujący na trunk wraca do stanu odrzucania, a ponowne włączenie kierunku przychodzącego ich nie przywraca. Przekieruj każdy numer samodzielnie.

Zastosuj w praktyce.

Przejdź do dokumentacji, przewodników i przykładów dotyczących tego tematu.

Uzyskaj brief wdrożeniowy

Buduj na tej samej sieci.

Testowy klucz API otrzymasz od razu. Dostęp produkcyjny odblokujesz po dodaniu metody płatności i zweryfikowaniu nadawcy.

Twój kolejny pomysł. Gotowy do połączenia.