Czym jest SIP?

Session Initiation Protocol (SIP) rozpoczyna, modyfikuje i kończy połączenia, podczas gdy dźwięk przechodzi osobno.

Systemy telefoniczne różnych producentów potrzebują wspólnego sposobu na uzgodnienie połączenia.

SIP nie przenosi mediów i ta granica wyjaśnia, dlaczego nawiązane połączenie może nie mieć dźwięku.

Co właściwie robi SIP?

Doprowadza dwie strony do zgody, że sesja ma się odbyć i na jakich warunkach.

RFC 3261, specyfikacja z czerwca 2002 roku, która go definiuje, opisuje SIP jako "an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants". Pięć zadań to znalezienie drugiej strony, ustalenie czy przyjmie połączenie, uzgodnienie mediów, dzwonienie, a później rozłączenie lub przekierowanie. Specyfikacja wymienia je jako:

User location: determination of the end system to be used for
     communication;

User availability: determination of the willingness of the called
     party to engage in communications;

User capabilities: determination of the media and media parameters
     to be used;

Session setup: "ringing", establishment of session parameters at
     both called and calling party;

Session management: including transfer and termination of
     sessions, modifying session parameters, and invoking
     services.

Żadne z tych pięciu zadań nie obejmuje przesyłania dźwięku. To cały zakres odpowiedzialności.

Dlaczego moje połączenie jest nawiązane, ale nie ma dźwięku?

Ponieważ dźwięk nigdy nie był zadaniem SIP, a obie ścieżki mogą ulegać awariom niezależnie.

Specyfikacja jest jednoznaczna co do własnego zakresu:

SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture.

Media przechodzą przez RTP, negocjowany podczas zestawiania połączenia i dalej płynący samodzielnie, często między punktami końcowymi, których sygnalizacja nigdy nie dotknęła. Sygnalizacja może się zakończyć i obie strony mogą uznać, że sesja jest aktywna. Dźwięk i tak może nie dotrzeć, bo zapora sieciowa, translator adresów sieciowych albo reguła routingu między punktami końcowymi mediów go odrzuciła, nie naruszając sygnalizacji.

Dlatego dźwięk jednokierunkowy i brak dźwięku stanowią osobną kategorię diagnostyczną, a nie odmianę awarii połączenia. W logu połączeń zobaczysz nawiązane połączenie, bo nawiązane połączenie to dokładnie to, co sygnalizacja osiągnęła. Diagnostyka głosu omawia objawy krok po kroku. Narzędzie do połączeń testowych Bird wypisuje podsumowanie szczytowego poziomu dźwięku dla każdego kierunku, gdzie zero po jednej stronie to objaw dźwięku jednokierunkowego wyrażony liczbą.

Ten sam podział sprawia, że inne elementy dają się wpiąć bez problemów. RFC 3261 ujmuje to tak: "SIP does not provide services. Rather, SIP provides primitives that can be used to implement different services." Poczta głosowa, grupy przeszukiwania, nagrywanie rozmów i agent AI są zbudowane na prymitywach, a nie zdefiniowane przez protokół.

Czy muszę zarejestrować klienta, zanim będzie mógł dzwonić?

Nie. Trunki Bird uwierzytelniają połączenia bez rejestracji klienta.

SIP definiuje funkcję rejestracji, dzięki której agent użytkownika informuje sieć, pod jakim adresem jest aktualnie osiągalny. To ona sprawia, że telefon biurkowy da się odnaleźć, gdy ktoś wybiera numer wewnętrzny. Ale rejestracja i wykonywanie połączeń to oddzielne czynności, a system, który jedynie inicjuje połączenia, nie musi być osiągalny.

SIP INVITE to metoda żądająca połączenia. Bird uwierzytelnia każde z nich na podstawie listy dozwolonych IP trunka lub przez wyzwanie hasłem. Klienci nie rejestrują się w trunku. Skonfiguruj Bird jako trunk, a nie jako zarejestrowane konto: bez sekcji type=registration w Asterisku, register=false w bramce FreeSWITCH, rejestracja ustawiona na none w FreePBX lub 3CX. Jeśli softphone nie pozwala wyłączyć rejestracji, nieudana próba rejestracji jest kosmetyczna i wybieranie numeru nadal działa, bo platforma reaguje na zaproszenie, a nie na rejestrację. Konfiguracja klienta SIP zawiera gotowe konfiguracje.

Wniosek dotyczy tego, gdzie trafiają dane uwierzytelniające. Twój klient wysyła dwie różne tożsamości. Identyfikator dzwoniącego trafia do nagłówka From i musi być numerem, który zweryfikowałeś. Nazwa użytkownika digest to bird na każdym trunku. Umieszczenie identyfikatora dzwoniącego w polu uwierzytelniania powoduje błąd uwierzytelniania, a nie błąd wspominający o identyfikatorze dzwoniącego.

Dlaczego odpowiedzi wyglądają jak HTTP?

Bo protokół został tak zaprojektowany, łącznie z zakresami numerów.

SIP to tekstowy protokół żądanie-odpowiedź z metodami i nagłówkami. Jego odpowiedzi należą do tych samych sześciu klas ze znanymi numerami: 404 dla nieistniejącego celu i 486 dla zajętego systemu końcowego. Wspólna struktura pozwala czytać ślad SIP tak, jak czytasz ślad HTTP.

Są dwa wyjątki. Szósta klasa, 6xx, nie ma odpowiednika HTTP i oznacza, że żaden serwer nigdzie nie jest w stanie obsłużyć żądania, a nie tylko ten jeden. Jeden popularny kod niesie też znaczenie w Bird, którego standard nie opisuje. Co oznaczają kody odpowiedzi SIP omawia oba przypadki, w tym dlaczego 503 od Bird to zwykle odmowa, której platforma nie chce wyjaśniać w transmisji, a nie przeciążenie.

Gdzie spotykam SIP na Bird?

Na trunku, czyli adresie, na który wysyła twój sprzęt.

Każdy trunk ma stałą domenę SIP i przyjmuje UDP lub TCP na 5060 albo TLS na 5061, jeśli chcesz szyfrować sygnalizację w tranzycie. Co może na niego wysyłać, decydujesz ty, a nowy trunk nie akceptuje niczego, dopóki tak nie powiesz. Czym jest trunk SIP omawia tę decyzję i trzy mechanizmy za nią stojące. Czym jest API głosowy opisuje, jak część SIP i część HTTP dzielą pracę.

W skrócie

  1. SIP zestawia sesje, ale ich nie przenosi.

    Jego własna specyfikacja nazywa go komponentem, a nie kompletnym systemem. Dźwięk przechodzi przez osobny protokół i często osobną ścieżką.

  2. Ten podział jest powodem, dla którego połączenie może się nawiązać i nie przekazywać dźwięku.

    Sygnalizacja i media mogą ulegać awariom niezależnie, więc połączenie może się nawiązać poprawnie i nie przekazywać dźwięku, a żadna ze stron nie myli się co do tego, co zaobserwowała.

  3. Rejestracja i dzwonienie to oddzielne czynności.

    Klient rejestruje się, żeby poinformować, pod jakim adresem jest osiągalny. Wykonanie połączenia tego nie wymaga, a Bird uwierzytelnia każde zaproszenie, a nie rejestrację.

  4. Odpowiedzi wyglądają jak HTTP, bo tak zostały zaprojektowane.

    Sześć klas odpowiedzi ze znanymi numerami, plus jedna klasa, której HTTP nie ma odpowiednika, oznaczająca, że żaden serwer nigdzie nie jest w stanie obsłużyć żądania.

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.