SIP - Szybki przewodnik

Session Initiation Protocol (SIP) jest jednym z najpowszechniejszych protokołów używanych w technologii VoIP. Jest to protokół warstwy aplikacji, który działa w połączeniu z innymi protokołami warstwy aplikacji w celu sterowania sesjami komunikacji multimedialnej przez Internet.

Technologia VoIP

Zanim przejdziemy dalej, najpierw zrozumiemy kilka punktów dotyczących VoIP.

  • VOIP to technologia umożliwiająca dostarczanie treści głosowych i multimedialnych (wideo, zdjęcia) przez Internet. Jest to jeden z najtańszych sposobów komunikowania się w dowolnym czasie i miejscu z dostępnością Internetu.

  • Niektóre zalety VOIP to:

    • Niska cena

    • Portability

    • Bez dodatkowych kabli

    • Flexibility

    • Wideokonferencje

  • Do połączenia VOIP potrzebujesz tylko komputera / laptopa / telefonu komórkowego z łączem internetowym. Poniższy rysunek przedstawia sposób prowadzenia rozmowy VoIP.

Mając tak fundamentalne znaczenie, wróćmy do SIP.

SIP - przegląd

Poniżej podano kilka punktów, na które należy zwrócić uwagę na temat SIP -

  • SIP to protokół sygnalizacyjny używany do tworzenia, modyfikowania i kończenia sesji multimedialnej za pośrednictwem protokołu internetowego. Sesja to nic innego jak zwykłe wywołanie między dwoma punktami końcowymi. Punktem końcowym może być smartfon, laptop lub dowolne urządzenie, które może odbierać i wysyłać treści multimedialne przez Internet.

  • SIP to protokół warstwy aplikacji zdefiniowany przez standard IETF (Internet Engineering Task Force). Jest zdefiniowany wRFC 3261.

  • SIP uosabia architekturę klient-serwer oraz wykorzystanie adresu URL i URI z HTTP oraz schemat kodowania tekstu i styl nagłówka z SMTP.

  • SIP korzysta z SDP (Session Description Protocol), który opisuje sesję i RTP (Real Time Transport Protocol), używanego do dostarczania głosu i wideo przez sieć IP.

  • SIP może być używany w sesjach dwustronnych (unicast) lub wielostronnych (multiemisja).

  • Inne aplikacje SIP obejmują przesyłanie plików, komunikatory, wideokonferencje, gry online i strumieniową dystrybucję multimediów.

Gdzie pasuje SIP?

Zasadniczo SIP jest protokołem warstwy aplikacji. Jest to prosty protokół sygnalizacji sieciowej służący do tworzenia i kończenia sesji z jednym lub większą liczbą uczestników. Protokół SIP został zaprojektowany tak, aby był niezależny od bazowego protokołu transportowego, więc aplikacje SIP mogą działać na TCP, UDP lub innych protokołach sieciowych niższej warstwy.

Poniższa ilustracja przedstawia, gdzie SIP pasuje do ogólnego schematu rzeczy -

Zwykle protokół SIP jest używany do telefonii internetowej i dystrybucji multimediów między dwoma lub większą liczbą punktów końcowych. Na przykład jedna osoba może zainicjować połączenie telefoniczne z inną osobą za pomocą SIP lub ktoś może utworzyć połączenie konferencyjne z wieloma uczestnikami.

Protokół SIP został zaprojektowany jako bardzo prosty, z ograniczonym zestawem poleceń. Jest również oparty na tekście, więc każdy może odczytać wiadomość SIP przekazaną między punktami końcowymi w sesji SIP.

Istnieje kilka podmiotów, które pomagają SIP w tworzeniu sieci. W SIP każdy element sieci jest identyfikowany przezSIP URI(Uniform Resource Identifier), który jest jak adres. Poniżej znajdują się elementy sieci -

  • Agent użytkownika
  • Serwer proxy
  • Serwer rejestracyjny
  • Serwer przekierowań
  • Serwer lokalizacji

Agent użytkownika

Jest to punkt końcowy i jeden z najważniejszych elementów sieci SIP. Punkt końcowy może inicjować, modyfikować lub kończyć sesję. Agenci użytkownika to najbardziej inteligentne urządzenie lub element sieciowy sieci SIP. Może to być telefon programowy, telefon komórkowy lub laptop.

Programy użytkownika są logicznie podzielone na dwie części -

  • User Agent Client (UAC) - Podmiot, który wysyła żądanie i otrzymuje odpowiedź.

  • User Agent Server (UAS) - Podmiot, który odbiera żądanie i wysyła odpowiedź.

Protokół SIP jest oparty na architekturze klient-serwer, w której telefon dzwoniącego działa jako klient inicjujący połączenie, a telefon odbiorcy działa jako serwer, który odpowiada na połączenie.

Serwer proxy

To element sieciowy przyjmuje żądanie od agenta użytkownika i przekazuje je innemu użytkownikowi.

  • Zasadniczo rola serwera proxy jest podobna do routera.

  • Ma pewną inteligencję, aby zrozumieć żądanie SIP i wysłać je dalej za pomocą URI.

  • Serwer proxy znajduje się pomiędzy dwoma agentami użytkownika.

  • Pomiędzy źródłem a miejscem docelowym może znajdować się maksymalnie 70 serwerów proxy.

Istnieją dwa typy serwerów proxy -

  • Stateless Proxy Server- Po prostu przekazuje otrzymaną wiadomość. Ten typ serwera nie przechowuje żadnych informacji o połączeniu ani transakcji.

  • Stateful Proxy Server- Ten typ serwera proxy śledzi każde otrzymane żądanie i odpowiedź i może w razie potrzeby użyć go w przyszłości. Może ponownie przesłać żądanie, jeśli na czas nie ma odpowiedzi z drugiej strony.

Serwer rejestracyjny

Serwer rejestracyjny przyjmuje żądania rejestracji od agentów użytkownika. Pomaga użytkownikom w uwierzytelnianiu się w sieci. Przechowuje identyfikator URI i lokalizację użytkowników w bazie danych, aby pomóc innym serwerom SIP w tej samej domenie.

Spójrz na poniższy przykład, który przedstawia proces rejestracji SIP.

Tutaj dzwoniący chce się zarejestrować w domenie TMC. Dlatego wysyła żądanie REJESTRACJI do serwera rejestracyjnego TMC, a serwer zwraca 200 OK, gdy autoryzował klienta.

Serwer przekierowań

Serwer przekierowujący odbiera żądania i wyszukuje zamierzonego adresata żądania w bazie danych lokalizacji utworzonej przez rejestratora.

Serwer przekierowań korzysta z bazy danych w celu uzyskania informacji o lokalizacji i odpowiada użytkownikowi 3xx (odpowiedź przekierowania). Kody odpowiedzi omówimy w dalszej części tego samouczka.

Serwer lokalizacji

Serwer lokalizacji dostarcza informacje o możliwych lokalizacjach dzwoniącego do serwerów przekierowujących i proxy.

Tylko serwer proxy lub serwer przekierowań może skontaktować się z serwerem lokalizacji.

Poniższy rysunek przedstawia role odgrywane przez każdy z elementów sieci podczas nawiązywania sesji.

SIP - Architektura systemu

Protokół SIP ma strukturę warstwowego protokołu, co oznacza, że ​​jego zachowanie jest opisane za pomocą zestawu dość niezależnych etapów przetwarzania z jedynie luźnym sprzężeniem między każdym etapem.

  • Najniższą warstwą SIP jest jego syntax and encoding. Jego kodowanie jest określane za pomocą rozszerzonegoBackus-Naur Form grammar (BNF).

  • Na drugim poziomie jest transport layer. Określa, w jaki sposób klient wysyła żądania i otrzymuje odpowiedzi oraz w jaki sposób serwer odbiera żądania i wysyła odpowiedzi przez sieć. Wszystkie elementy SIP zawierają warstwę transportową.

  • Dalej jest transaction layer. Transakcja to żądanie wysłane przez transakcję klienta (przy użyciu warstwy transportowej) do transakcji serwera, wraz ze wszystkimi odpowiedziami na to żądanie wysłane z transakcji serwera z powrotem do klienta. Każde zadanie wykonywane przez klienta użytkownika (UAC) odbywa się za pomocą serii transakcji.Stateless proxies nie zawierają warstwy transakcyjnej.

  • Warstwa powyżej transaction layernazywa się użytkownikiem transakcji. Każda z jednostek SIP, z wyjątkiemStateless proxies, jest użytkownikiem transakcji.

Poniższy obraz przedstawia podstawowy przepływ połączeń w sesji SIP.

Poniżej znajduje się wyjaśnienie krok po kroku powyższego przepływu połączeń -

  • Za zainicjowanie sesji odpowiada żądanie INVITE wysyłane do serwera proxy.

  • Serwer proxy sendsa 100 Trying natychmiastowa odpowiedź do dzwoniącego (Alicji), aby zatrzymać ponowne transmisje żądania INVITE.

  • Serwer proxy wyszukuje adres Roberta na serwerze lokalizacji. Po uzyskaniu adresu przekazuje dalej żądanie INVITE.

  • Odtąd, 180 Ringing (Tymczasowe odpowiedzi) wygenerowane przez Boba są zwracane Alicji.

  • ZA 200 OK odpowiedź jest generowana wkrótce po podniesieniu telefonu przez Roberta.

  • Bob otrzymuje ACK od Alice, kiedy już się pojawi 200 OK.

  • W tym samym czasie sesja zostaje nawiązana i pakiety RTP (konwersacje) zaczynają płynąć z obu końców.

  • Po rozmowie każdy uczestnik (Alicja lub Bob) może wysłać plik BYE żądanie zakończenia sesji.

  • BYE sięga bezpośrednio od Alicji do Boba z pominięciem serwera proxy.

  • Wreszcie Bob wysyła plik 200 OK odpowiedź potwierdzająca BYE i sesja zostaje zakończona.

  • W powyższym podstawowym przepływie połączeń trzy transactions są (oznaczone jako 1, 2, 3) dostępne.

Cała rozmowa (od INVITE do 200 OK) jest znana jako Dialog.

Trapez SIP

W jaki sposób proxy pomaga połączyć jednego użytkownika z innym? Dowiedzmy się za pomocą poniższego diagramu.

Topologia pokazana na schemacie jest znana jako trapez SIP. Proces przebiega w następujący sposób -

  • Gdy dzwoniący inicjuje połączenie, do serwera proxy wysyłana jest wiadomość INVITE. Po otrzymaniu INVITE serwer proxy podejmuje próbę ustalenia adresu odbiorcy za pomocą serwera DNS.

  • Po uzyskaniu następnej trasy serwer proxy dzwoniącego (Proxy 1, znany również jako wychodzący serwer proxy) przekazuje żądanie INVITE do serwera proxy wywołującego, który działa jako przychodzący serwer proxy (Proxy 2) dla odbiorcy.

  • Serwer proxy ruchu przychodzącego kontaktuje się z serwerem lokalizacji, aby uzyskać informacje o adresie odbiorcy, pod którym zarejestrował się użytkownik.

  • Po uzyskaniu informacji z serwera lokalizacji przekazuje połączenie do miejsca docelowego.

  • Gdy agenci użytkownika poznają swój adres, mogą ominąć połączenie, czyli rozmowę przechodzić bezpośrednio.

Wiadomości SIP są dwojakiego rodzaju - requests i responses.

  • Wiersz otwierający żądania zawiera metodę, która definiuje żądanie, oraz identyfikator URI żądania, który określa, gdzie żądanie ma zostać wysłane.

  • Podobnie, pierwszy wiersz odpowiedzi zawiera kod odpowiedzi.

Metody żądania

SIP requeststo kody używane do nawiązania komunikacji. Aby je uzupełnić, sąSIP responses które ogólnie wskazują, czy żądanie powiodło się, czy nie.

Te żądania SIP, które są znane jako METODY, sprawiają, że wiadomość SIP działa.

  • METODY można traktować jako żądania SIP, ponieważ żądają one podjęcia określonej akcji przez innego agenta użytkownika lub serwer.

  • METODY wyróżnia się na dwa typy -

    • Metody podstawowe

    • Metody rozszerzeń

Metody podstawowe

Istnieje sześć podstawowych metod omówionych poniżej.

ZAPRASZAM

INVITE służy do zainicjowania sesji z agentem użytkownika. Innymi słowy, metoda INVITE służy do ustanowienia sesji medialnej między agentami użytkownika.

  • INVITE może zawierać informacje o multimediach osoby dzwoniącej w treści wiadomości.

  • Sesja jest uważana za ustanowioną, jeśli INVITE otrzymało odpowiedź (2xx) lub ACK zostało wysłane.

  • Pomyślne żądanie INVITE powoduje utworzenie dialog między dwoma agentami użytkownika, która trwa do wysłania BYE w celu zakończenia sesji.

  • ZAPROSZENIE wysłane w ramach ustalonego okna dialogowego jest znane jako re-INVITE.

  • Ponownie INVITE służy do zmiany charakterystyki sesji lub odświeżenia stanu okna dialogowego.

ZAPROŚ Przykład

Poniższy kod ilustruje sposób użycia INVITE.

INVITE sips:Bob@TMC.com SIP/2.0 
   Via: SIP/2.0/TLS client.ANC.com:5061;branch = z9hG4bK74bf9 
   Max-Forwards: 70 
   From: Alice<sips:Alice@TTP.com>;tag = 1234567 
   To: Bob<sips:Bob@TMC.com>
   Call-ID: 12345601@192.168.2.1  
   CSeq: 1 INVITE 
   Contact: <sips:Alice@client.ANC.com> 
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
   Supported: replaces 
   Content-Type: application/sdp 
   Content-Length: ...  
   
   v = 0 
   o = Alice 2890844526 2890844526 IN IP4 client.ANC.com 
   s = Session SDP 
   c = IN IP4 client.ANC.com 
   t = 3034423619 0 
   m = audio 49170 RTP/AVP 0 
   a = rtpmap:0 PCMU/8000

PA

BYE to metoda używana do kończenia ustanowionej sesji. Jest to żądanie SIP, które może zostać wysłane przez dzwoniącego lub odbierającego w celu zakończenia sesji.

  • Nie można go wysłać przez serwer proxy.

  • Żądanie BYE zwykle kieruje od końca do końca, omijając serwer proxy.

  • BYE nie może zostać wysłane do oczekującej sesji INVITE lub nierozstrzygniętej sesji.

ZAREJESTROWAĆ

Żądanie REGISTER wykonuje rejestrację agenta użytkownika. To żądanie jest wysyłane przez agenta użytkownika do serwera rejestracyjnego.

  • Żądanie REJESTRACJI może zostać przekazane lub przekazane dalej, aż dotrze do autorytatywnego rejestratora określonej domeny.

  • Niesie AOR (adres rejestracji) w formacie To nagłówek rejestrowanego użytkownika.

  • Żądanie REGISTER zawiera okres (3600 sekund).

  • Jeden klient użytkownika może wysłać żądanie REGISTER w imieniu innego użytkownika. Jest to znane jakothird-party registration. TutajFrom tag zawiera identyfikator URI strony dokonującej rejestracji w imieniu strony określonej w To nagłówek.

ANULUJ

CANCEL służy do zakończenia sesji, która nie została nawiązana. Klienty użytkownika używają tego żądania, aby anulować oczekującą próbę połączenia zainicjowaną wcześniej.

  • Może zostać wysłany przez agenta użytkownika lub serwer proxy.

  • ANULUJ to plik hop by hop request, tj. przechodzi przez elementy między agentem użytkownika i otrzymuje odpowiedź wygenerowaną przez następny element stanowy.

ACK

ACK służy do potwierdzenia końcowych odpowiedzi na metodę INVITE. ACK zawsze idzie w kierunku INVITE.ACK może zawierać treść SDP (charakterystykę mediów), jeśli nie jest dostępna w INVITE.

  • ACK nie może być używane do modyfikowania opisu mediów, który został już wysłany w początkowym INVITE.

  • Pełnostanowy serwer proxy odbierający ACK musi określić, czy ACK powinien być przesłany dalej do innego proxy lub agenta użytkownika.

  • W przypadku odpowiedzi 2xx ACK działa od końca do końca, ale w przypadku wszystkich pozostałych odpowiedzi końcowych działa na zasadzie przeskok po przeskoku, gdy zaangażowane są stanowe proxy.

OPCJE

Metoda OPTIONS służy do wysyłania zapytań do agenta użytkownika lub serwera proxy o jego możliwości i wykrywania ich aktualnej dostępności. Odpowiedź na żądanie zawiera listę możliwości agenta użytkownika lub serwera. Serwer proxy nigdy nie generuje żądania OPTIONS.

Metody rozszerzeń

Subskrybuj

SUBSCRIBE jest używane przez agentów użytkownika do ustanowienia subskrypcji w celu otrzymywania powiadomień o określonym wydarzeniu.

  • Zawiera plik Expires pole nagłówka, które wskazuje czas trwania subskrypcji.

  • Po upływie tego czasu subskrypcja wygaśnie automatycznie.

  • Subskrypcja ustanawia dialog między agentami użytkownika.

  • Możesz ponownie zasubskrybować, wysyłając kolejną SUBSKRYPCJĘ w oknie dialogowym przed upływem czasu.

  • 200 OK zostanie otrzymane za subskrypcję od użytkownika.

  • Użytkownicy mogą zrezygnować z subskrypcji, wysyłając inną metodę SUBSCRIBE z wartością Expires 0 (zero).

NOTYFIKOWAĆ

NOTIFY jest używany przez programy użytkownika do uzyskania informacji o wystąpieniu określonego zdarzenia. Zwykle NOTIFY zostanie wywołane w oknie dialogowym, gdy istnieje subskrypcja między subskrybentem a powiadamiającym.

  • Każde powiadomienie NOTIFY otrzyma 200 odpowiedzi OK, jeśli zostanie odebrane przez zgłaszającego.

  • NOTIFY zawiera rozszerzenie Event pole nagłówka wskazujące na zdarzenie oraz a subscriptionstate pole nagłówka wskazujące aktualny stan subskrypcji.

  • POWIADOMIENIE jest zawsze wysyłane przy rozpoczęciu i zakończeniu subskrypcji.

PUBLIKOWAĆ

OPUBLIKUJ jest używane przez agenta użytkownika do wysyłania informacji o stanie zdarzenia do serwera.

  • OPUBLIKUJ jest szczególnie przydatne, gdy istnieje wiele źródeł informacji o wydarzeniach.

  • Żądanie OPUBLIKUJ jest podobne do POWIADOMIENIA, z tą różnicą, że nie jest wysyłane w oknie dialogowym.

  • Żądanie OPUBLIKUJ musi zawierać rozszerzenie Expires pole nagłówka i Min-Expires pole nagłówka.

ODNOSIĆ SIĘ

REFER jest używany przez agenta użytkownika w celu skierowania innego klienta użytkownika w celu uzyskania dostępu do identyfikatora URI dla okna dialogowego.

  • REFER musi zawierać Refer-Tonagłówek. To jest obowiązkowy nagłówek REFER.

  • REFER można wysłać w oknie dialogowym lub poza nim.

  • ZA 202 Accepted wywoła żądanie REFER, które wskazuje, że inny klient użytkownika zaakceptował odniesienie.

INFO

INFO jest używane przez agenta użytkownika do wysyłania informacji sygnalizujących wywołanie do innego agenta użytkownika, z którym nawiązał sesję medialną.

  • To jest kompleksowa prośba.

  • Proxy zawsze przekaże żądanie INFO.

AKTUALIZACJA

UPDATE służy do modyfikowania stanu sesji, jeśli sesja nie została ustanowiona. Użytkownik może zmienić kodek za pomocą UPDATE.

Jeśli sesja jest ustanowiona, ponowne zaproszenie jest używane do zmiany / aktualizacji sesji.

PRACK

PRACK służy do potwierdzenia otrzymania wiarygodnego przesłania tymczasowej odpowiedzi (1XX).

  • Generalnie PRACK jest generowany przez klienta, gdy otrzymuje tymczasową odpowiedź zawierającą plik RSeq niezawodny numer kolejny i a supported:100rel nagłówek.

  • PRACK zawiera (RSeq + CSeq) wartość w pliku rack nagłówek.

  • Metoda PRACK ma zastosowanie do wszystkich tymczasowych odpowiedzi z wyjątkiem odpowiedzi 100 Trying, która nigdy nie jest niezawodnie przekazywana.

  • PRACK może zawierać treść wiadomości; może służyć do wymiany ofert / odpowiedzi.

WIADOMOŚĆ

Służy do wysyłania wiadomości błyskawicznych przy użyciu protokołu SIP. Komunikator składa się zwykle z krótkich wiadomości wymienianych w czasie rzeczywistym przez uczestników biorących udział w rozmowie tekstowej.

  • WIADOMOŚĆ można wysłać w oknie dialogowym lub poza nim.

  • Treść MESSAGE jest przenoszona w treści wiadomości jako plik MIME Załącznik.

  • ZA 200 OK zwykle otrzymywana jest odpowiedź wskazująca, że ​​wiadomość została dostarczona do miejsca przeznaczenia.

Odpowiedź SIP to komunikat generowany przez serwer klienta użytkownika (UAS) lub serwer SIP w celu odpowiedzi na żądanie wygenerowane przez klienta. Może to być formalne potwierdzenie, aby zapobiec ponownej transmisji żądań przez UAC.

  • Odpowiedź może zawierać dodatkowe pola nagłówka zawierające informacje wymagane przez UAC.

  • SIP ma sześć odpowiedzi.

  • 1xx do 5xx został zapożyczony z HTTP i 6xx został wprowadzony w SIP.

  • 1xx jest uważany za plik provisional odpowiedź, a reszta to final odpowiedzi.

S.No. Opis funkcji
1 1xx: tymczasowe / informacyjne odpowiedzi

Odpowiedzi informacyjne służą do wskazania call progress. Zwykle odpowiedzi są od końca do końca (z wyjątkiem 100 prób).

2 2xx: Odpowiedzi na sukces

Ta klasa odpowiedzi ma na celu wskazanie, że żądanie zostało zaakceptowane.

3 3xx: Odpowiedzi na przekierowanie

Ogólnie te odpowiedzi klas są wysyłane przez serwery przekierowujące w odpowiedzi na INVITE. Są one również znane jako odpowiedzi klas przekierowań.

4 4xx: Odpowiedzi klienta na błędy

Odpowiedzi na błędy klienta wskazują, że żądanie nie może zostać spełnione, ponieważ niektóre błędy zostały zidentyfikowane po stronie UAC.

5 5xx: Odpowiedź na awarię serwera

Ta odpowiedź klasy służy do wskazania, że ​​żądanie nie może zostać przetworzone z powodu błędu serwera.

6 6xx: Globalna reakcja na awarię

Ta klasa odpowiedzi wskazuje, że serwer wie, że żądanie zakończy się niepowodzeniem przy każdej próbie. W rezultacie żądanie nie powinno być wysyłane do innych lokalizacji.

Nagłówek jest składnikiem wiadomości SIP, który przekazuje informacje o wiadomości. Ma strukturę sekwencji pól nagłówka.

Pola nagłówka SIP w większości przypadków podlegają tym samym regułom, co pola nagłówka HTTP. Pola nagłówka są zdefiniowane jakoHeader: field, gdzie Nagłówek jest używany do reprezentowania nazwy pola nagłówka, a pole to zestaw tokenów, który zawiera informacje. Każde pole składa się z nazwy pola, po której następuje dwukropek („:”) i wartość pola (tj.field-name: field-value).

Nagłówki SIP - Compact Form

Wiele typowych pól nagłówka SIP ma zwartą formę, w której nazwa pola nagłówka jest oznaczona pojedynczą małą literą. Poniżej podano kilka przykładów -

nagłówek Kompaktowa forma
Do T
Przez V
Call-ID ja
Kontakt M
Od fa
Przedmiot S
Długość treści ja

Format nagłówka SIP

Poniższy obraz przedstawia strukturę typowego nagłówka SIP.

Nagłówki są podzielone na następujące kategorie w zależności od ich wykorzystania w SIP -

  • Wniosek i odpowiedź
  • Tylko żądanie
  • Tylko odpowiedź
  • Treść wiadomości

SDP oznacza protokół opisu sesji. Służy do opisu sesji multimedialnych w formacie zrozumiałym dla uczestników w sieci. W zależności od tego opisu strona decyduje, czy dołączyć do konferencji, czy też kiedy lub jak dołączyć do konferencji.

  • Właściciel konferencji rozgłasza ją w sieci, wysyłając wiadomości multicastowe, które zawierają opis sesji, np. Nazwisko właściciela, nazwę sesji, kodowanie, czas itp. W zależności od tych informacji, odbiorcy ogłoszenia podjąć decyzję o udziale w sesji.

  • SDP jest generalnie zawarte w części głównej protokołu inicjowania sesji, popularnie zwanej SIP.

  • SDP jest zdefiniowane w RFC 2327. Komunikat SDP składa się z szeregu linii, zwanych polami, których nazwy są skracane jedną małą literą i są ułożone w wymaganej kolejności, aby uprościć analizę.

Cel SDP

Celem SDP jest przekazywanie informacji o strumieniach mediów w sesjach multimedialnych, aby pomóc uczestnikom dołączyć lub zebrać informacje o określonej sesji.

  • SDP to krótki ustrukturyzowany opis tekstowy.

  • Zawiera nazwę i cel sesji, media, protokoły, formaty kodeków, informacje o czasie i transporcie.

  • Wstępny uczestnik sprawdza te informacje i decyduje, czy dołączyć do sesji oraz jak i kiedy dołączyć do sesji, jeśli zdecyduje się to zrobić.

  • Format ma wpisy w postaci <typ> = <wartość>, gdzie <typ> definiuje unikalny parametr sesji, a <wartość> podaje określoną wartość dla tego parametru.

  • Ogólna forma wiadomości SDP to -

    x = parameter1 parameter2 ... parameterN

  • Linia zaczyna się od jednej małej litery, na przykład x. Nigdy nie ma spacji między literą a znakiem =, a między każdym parametrem jest dokładnie jedna spacja. Każde pole ma określoną liczbę parametrów.

Parametry opisu sesji

Opis sesji (* oznacza opcjonalne)

  • v = (wersja protokołu)
  • o = (właściciel / twórca i identyfikator sesji)
  • s = (nazwa sesji)
  • i = * (informacje o sesji)
  • u = * (URI opisu)
  • e = * (adres e-mail)
  • p = * (numer telefonu)
  • c = * (informacje o połączeniu - niewymagane, jeśli są zawarte we wszystkich mediach)
  • b = * (informacje o przepustowości)
  • z = * (korekty strefy czasowej)
  • k = * (klucz szyfrowania)
  • a = * (zero lub więcej linii atrybutów sesji)

Wersja protokołu

Pole v = zawiera numer wersji SDP. Ponieważ aktualna wersja SDP to 0, prawidłowy komunikat SDP będzie zawsze zaczynał się od v = 0.

Pochodzenie

Pole o = zawiera informacje o inicjatorze sesji i identyfikatorach sesji. To pole służy do jednoznacznej identyfikacji sesji.

  • Pole zawiera -

    o = <nazwa użytkownika> <id sesji> <wersja> <typ-sieci> <typ-adresu>

  • Plik username parametr zawiera login lub host twórcy.

  • Plik session-id parametr jest sygnaturą czasową protokołu NTP (Network Time Protocol) lub liczbą losową używaną w celu zapewnienia niepowtarzalności.

  • Plik version to pole numeryczne, które jest zwiększane przy każdej zmianie w sesji, zalecane również jako znacznik czasu NTP.

  • Plik network-typejest zawsze w Internecie. Parametr typu adresu to IP4 lub IP6 dla adresu IPv4 lub IPv6 w postaci dziesiętnej z kropkami lub w pełni kwalifikowanej nazwy hosta.

Nazwa sesji i informacje

Pole s = zawiera nazwę sesji. Może zawierać dowolną niezerową liczbę znaków. Opcjonalne pole i = zawiera informacje o sesji. Może zawierać dowolną liczbę znaków.

URI

Opcjonalne pole u = zawiera jednolity wskaźnik zasobów (URI) z dodatkowymi informacjami o sesji

Adres e-mail i numer telefonu

Opcjonalne pole e = zawiera adres e-mail hosta sesji. Opcjonalne pole p = zawiera numer telefonu.

Dane połączenia

Pole c = zawiera informacje o połączeniu mediów.

  • Pole zawiera -

    c = <typ-sieci> <typ-adresu> <adres-połączenia>

  • Plik network-type parametr jest zdefiniowany jako IN dla Internetu.

  • Plik address-type jest zdefiniowany jako IP4 dla adresów IPv4 i IP6 dla adresów IPv6.

  • Plik connection-address to adres IP lub host, który będzie wysyłał pakiety multimediów, które mogą być przesyłane grupowo lub pojedynczo.

  • W przypadku multiemisji pole adresu połączenia zawiera -

    adres-połączenia = podstawowy-adres-multiemisji / ttl / liczba-adresów

  • gdzie ttl to wartość czasu wygaśnięcia, a liczba adresów wskazuje, ile ciągłych adresów multiemisji jest zawartych, zaczynając od podstawowego adresu multiemisji.

Pasmo

Opcjonalne pole b = zawiera informacje o wymaganej przepustowości. Ma postać -

b = modyfikator: przepustowość - wartość

Czas, czasy powtórzeń i strefy czasowe

Pole t = zawiera godzinę rozpoczęcia i zakończenia sesji.

t = czas rozpoczęcia, czas zakończenia

Opcjonalne pole r = zawiera informacje o czasach powtarzania, które można określić w NTP lub w dniach ( d ), godzinach ( h ) lub minutach ( m ).

Opcjonalne pole z = zawiera informacje o przesunięciach stref czasowych. To pole jest używane, jeśli sesja obejmuje zmianę z czasu letniego na standardowy lub odwrotnie.

Ogłoszenia w mediach

Opcjonalne pole m = zawiera informacje o typie sesji medialnej. Pole zawiera -

m = lista formatów transportu portu mediów

  • Parametrem multimediów jest dźwięk, wideo, tekst, aplikacja, wiadomość, obraz lub element sterujący. Parametr portu zawiera numer portu.

  • Parametr transport zawiera używany protokół transportowy lub profil RTP.

  • Lista formatów zawiera więcej informacji o mediach. Zwykle zawiera typy ładunku multimediów zdefiniowane w profilach audio-wideo RTP.

Example:
m = audio 49430 RTP/AVP 0 6 8 99

Jeden z tych trzech kodeków może być użyty w sesji multimediów audio. Jeśli intencją jest ustanowienie trzech kanałów audio, zostaną użyte trzy oddzielne pola medialne.

Atrybuty

Opcjonalne pole a = zawiera atrybuty poprzedniej sesji multimedialnej. To pole może służyć doextend SDP to provide more information about the media. Jeśli użytkownik SDP nie zrozumie go w pełni, pole atrybutu można zignorować. Może istnieć jedno lub więcej pól atrybutów dla każdego typu ładunku nośnika wymienionego w polu nośnika.

Atrybuty w SDP mogą być dowolne

  • poziom sesji lub
  • poziom mediów.

Poziom sesji oznacza, że ​​atrybut jest wymieniony przed pierwszą linią mediów w SDP. W takim przypadku atrybut ma zastosowanie do wszystkich linii multimediów poniżej.

Poziom mediów oznacza, że ​​jest wymieniony po linii mediów. W tym przypadku atrybut dotyczy tylko tego konkretnego strumienia multimediów.

SDP może zawierać atrybuty na poziomie sesji i na poziomie nośnika. Jeśli ten sam atrybut pojawia się jako oba, atrybut poziomu mediów zastępuje atrybut poziomu sesji dla tego konkretnego strumienia mediów. Należy zauważyć, że pole danych połączenia może również wskazywać poziom sesji lub poziom mediów.

Przykład SDP

Poniżej podano przykładowy opis sesji, zaczerpnięty z RFC 2327 -

v = 0
o = mhandley2890844526 2890842807 IN IP4 126.16.64.4
s = SDP Seminar
i = A Seminar on the session description protocol
u = http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e = mjh@isi.edu(Mark Handley)
c = IN IP4 224.2.17.12/127
t = 2873397496 2873404696
a = recvonly
m = audio 49170 RTP/AVP 0
m = video 51372 RTP/AVP 31
m = application 32416udp wb
a = orient:portrait

Użycie SDP z SIP jest podane w odpowiedzi na ofertę SDP RFC 3264. Domyślny typ treści wiadomości w SIP to application/sdp.

  • Strona wywołująca wymienia możliwości multimedialne, które chce otrzymać w SDP, zazwyczaj w INVITE lub ACK.

  • Wzywana strona wymienia swoje możliwości multimedialne w odpowiedzi 200 OK na INVITE.

Typowe użycie SIP SDP obejmuje następujące pola: wersja, pochodzenie, temat, czas, połączenie oraz jeden lub więcej nośników i atrybut.

  • Pola tematu i czasu nie są używane przez SIP, ale zostały uwzględnione w celu zapewnienia zgodności.

  • W standardzie SDP pole tematu jest polem wymaganym i musi zawierać co najmniej jeden znak, sugerowany s = - jeśli nie ma tematu.

  • Pole czasu jest zwykle ustawione na t = 00. SIP używa pól połączenia, mediów i atrybutów do konfigurowania sesji między UA.

  • Pole pochodzenia ma ograniczone zastosowanie w przypadku protokołu SIP.

  • Identyfikator sesji jest zwykle utrzymywany na stałym poziomie przez całą sesję SIP.

  • Wersja jest zwiększana za każdym razem, gdy zmienia się SDP. Jeśli wysyłane SDP jest takie samo, jak wysłane wcześniej, wersja pozostaje taka sama.

  • Ponieważ typ sesji multimedialnej i kodek, który ma być użyty, są częścią negocjacji połączenia, SIP może używać SDP do określania wielu alternatywnych typów mediów i do selektywnego akceptowania lub odrzucania tych typów mediów.

Specyfikacja oferty / odpowiedzi, RFC 3264, zaleca użycie atrybutu zawierającego a = rtpmap: dla każdego pola mediów. Strumień mediów jest odrzucany przez ustawienie numeru portu na zero dla odpowiedniego pola mediów w odpowiedzi SDP.

Przykład

W poniższym przykładzie dzwoniący Tesla chce skonfigurować połączenie audio i wideo z dwoma możliwymi kodekami audio i kodekiem wideo w SDP przenoszonym w początkowym INVITE -

v = 0 
o = John 0844526 2890844526 IN IP4 172.22.1.102  
s = - 
c = IN IP4 172.22.1.102 
t = 0 0 
m = audio 6000 RTP/AVP 97 98 
a = rtpmap:97 AMR/16000/1 
a = rtpmap:98 AMR-WB/8000/1 
m = video 49172 RTP/AVP 32 
a = rtpmap:32 MPV/90000

Kodeki są oznaczone numerami profili RTP / AVP 97, 98.

Wzywana strona Marry odbiera połączenie, wybiera drugi kodek dla pierwszego pola multimediów i odrzuca drugie pole multimedialne, chcąc tylko sesji AMR.

v = 0 
o = Marry 2890844526 2890844526 IN IP4 172.22.1.110 
s = - 
c = IN IP4 200.201.202.203 
t = 0 0 
m = audio 60000 RTP/AVP 8 
a = rtpmap:97 AMR/16000 
m = video 0 RTP/AVP 32

Jeśli to połączenie audio jest nie do przyjęcia, Tom wyśle ​​ACK, a następnie BYE, aby anulować połączenie. W przeciwnym razie sesja audio zostałaby ustanowiona i pakiety RTP wymieniane.

Jak ilustruje ten przykład, o ile nie zostanie zachowana liczba i kolejność pól multimediów, strona dzwoniąca nie będzie wiedziała na pewno, które sesje multimedialne zostały zaakceptowane i odrzucone przez stronę wywołującą.

Zasady oferty / odpowiedzi zostały podsumowane w kolejnych sekcjach.

Zasady generowania oferty

Oferta SDP musi zawierać wszystkie wymagane pola SDP (w tym v =, o =, s =, c = i t =). To są obowiązkowe pola w SDP.

Zwykle zawiera pole multimedialne ( m = ), ale nie musi. Wiersze multimediów zawierają wszystkie kodeki wymienione w preferowanej kolejności. Jedynym wyjątkiem jest sytuacja, gdy punkt końcowy obsługuje ogromną liczbę kodeków, na liście należy wymienić te, które są najczęściej akceptowane lub preferowane. Różne typy mediów obejmują audio, wideo, tekst, MSRP, BFCP i tak dalej.

Zasady generowania odpowiedzi

Odpowiedź SDP na ofertę musi być skonstruowana zgodnie z następującymi zasadami -

  • Odpowiedź musi mieć taką samą liczbę m = wierszy w tej samej kolejności, co odpowiedź.

  • Poszczególne strumienie multimediów można odrzucić, ustawiając numer portu na 0.

  • Strumienie są akceptowane przez wysłanie niezerowego numeru portu.

  • Wymienione ładunki dla każdego typu nośnika muszą być podzbiorem ładunków wymienionych w ofercie.

  • W przypadku dynamicznych ładunków ten sam numer dynamicznego ładunku nie musi być używany w każdym kierunku. Zwykle wybierany jest tylko jeden ładunek.

Zasady modyfikowania sesji

Każda ze stron może zainicjować kolejną wymianę ofert / odpowiedzi, aby zmodyfikować sesję. Kiedy sesja jest modyfikowana, należy przestrzegać następujących zasad -

  • Numer wersji linii źródłowej ( o = ) musi być taki sam, jak ostatnio wysłany, co wskazuje, że ten pakiet SDP jest identyczny z poprzednią wymianą, lub może być zwiększany o jeden, co wskazuje na nowe SDP, które należy przeanalizować.

  • Oferta musi zawierać wszystkie istniejące linie medialne i należy je przesłać w tej samej kolejności.

  • Dodatkowe strumienie multimediów można dodać na końcu listy m = line.

  • Istniejący strumień multimediów można usunąć, ustawiając numer portu na 0. Ta linia multimediów musi pozostać w SDP i we wszystkich przyszłych wymianach ofert / odpowiedzi dla tej sesji.

Zawieś połączenie

Jedna osoba w rozmowie może tymczasowo zawiesić drugą. Odbywa się to poprzez wysłanie INVITE z identycznym SDP do oryginalnego INVITE, ale za = sendonly atrybut obecny.

Połączenie jest ponownie aktywowane przez wysłanie kolejnego ZAPROSZENIA z a = sendrecvatrybut obecny. Poniższa ilustracja przedstawia przebieg zawieszonego połączenia.

Personal mobilityto możliwość posiadania stałego identyfikatora na wielu urządzeniach. SIP obsługuje podstawową mobilność osobistą przy użyciu metody REJESTRACJA, która umożliwia urządzeniu mobilnemu zmianę adresu IP i punktu połączenia z Internetem i nadal może odbierać połączenia przychodzące.

SIP może również obsługiwać service mobility - zdolność użytkownika do utrzymania tych samych usług podczas korzystania z telefonu komórkowego

Mobilność SIP podczas przekazywania (połączenie wstępne)

Urządzenie wiąże swój kontaktowy identyfikator URI z adresem rekordu przez prostą rejestrację przez łyk. Zgodnie z adresem IP urządzenia, rejestracja upoważnia do automatycznej aktualizacji tych informacji w sieci SIP.

Podczas przekazywania agent użytkownika przekazuje połączenia między różnymi operatorami, gdzie musi ponownie zarejestrować się u Kontakt jako AOR u innego usługodawcy.

Na przykład weźmy przykład następującego przepływu wywołań. UA, który tymczasowo otrzymał nowy identyfikator URI SIP od nowego dostawcy usług. Następnie UA dokonuje podwójnej rejestracji -

  • Pierwsza rejestracja odbywa się u nowego operatora usługi, który wiąże identyfikator URI kontaktu urządzenia z identyfikatorem URI nowego dostawcy usług.

  • Drugie żądanie REGISTER jest kierowane z powrotem do pierwotnego dostawcy usług i dostarcza AOR nowego usługodawcy jako identyfikator URI kontaktu.

Jak pokazano później w przebiegu połączenia, gdy żądanie przychodzi do sieci pierwotnego usługodawcy, INVITE jest przekierowywane do nowego usługodawcy, który następnie kieruje połączenie do użytkownika.

Podczas pierwszej rejestracji wiadomość zawierająca identyfikator URI urządzenia wyglądałaby następująco:

REGISTER sip:visited.registrar1.com SIP/2.0 
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK97a7ea349ce0fca 
Max-Forwards: 70 
To: Tom <sip:UA1@registrar1.in> 
From: Tom <sip:UA1@registrar1.in>;tag = 72d65a24 
Call-ID: 4e719d1c1fc9000803630373300@172.22.1.102 
CSeq: 1 REGISTER 
Contact: <sip:Tom@172.22.1.102:5060> 
Expires: 600000 
Content-Length: 0

Drugi komunikat rejestracyjny z identyfikatorem URI w roamingu to -

REGISTER sip:home.registrar2.in SIP/2.0 
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bKah4vn2u 
Max-Forwards: 70 
To: Tom <sip:UA1@registrar2.in> 
From: Tom <sip:UA1@registrar2.in>;tag = 45375 
Call-ID:87nr43i@172.22.1.102 
CSeq: 6421 REGISTER 
Contact: <sip:UA1@registrar2.in> 
Content-Length: 0

Pierwsze ZAPROSZENIE przedstawione na powyższym rysunku zostanie wysłane na adres sip: registrar2.in; drugie ZAPROSZENIE zostanie wysłane na adres sip: sip: Tom@registrar2.in, które zostanie przekazane na adressip:Tom@172.22.1.102. Dociera do Toma i umożliwia rozpoczęcie sesji. Okresowo trzeba będzie odświeżać obie rejestracje.

Mobilność podczas rozmowy (ponowne zaproszenie)

Agent użytkownika może zmienić swój adres IP podczas sesji, gdy przechodzi z jednej sieci do drugiej. Podstawowy protokół SIP obsługuje ten scenariusz, ponieważ ponowne zaproszenie w oknie dialogowym może służyć do aktualizacji identyfikatora URI kontaktu i zmiany informacji o mediach w SDP.

Przyjrzyj się przepływowi połączeń wymienionemu na poniższym rysunku.

  • Tutaj Tom wykrywa nową sieć,

  • Używa protokołu DHCP do uzyskania nowego adresu IP, a

  • Wykonuje ponowne ZAPROSZENIE, aby umożliwić sygnalizację i przepływ mediów do nowego adresu IP.

Jeśli UA może odbierać multimedia z obu sieci, przerwa jest pomijalna. Jeśli tak nie jest, kilka pakietów multimedialnych może zostać utraconych, powodując niewielkie przerwanie połączenia.

Ponowne ZAPROSZENIE wyglądałoby następująco -

INVITE sip:Jerry@TTP.com SIP/2.0  
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK918f5a84fe6bf7a 
Max-Forwards: 70 

To: <sip:Harry@TTP.com> 

From: sip:Tom@PPT.com;tag = 70133df4 
Call-ID: 76d4861c19c 
CSeq: 1 INVITE 
Accept: application/sdp 
Accept-Language: en 

Allow: INVITE,ACK,CANCEL,BYE,INFO,OPTIONS,REFER,NOTIFY,SUBSCRIBE 
Contact: <sip:172.22.1.102:5060>; 
Content-Type: application/sdp 
Content-Length: 168 

v = 0
o = PPT 40467 40468 IN IP4 192.168.2.1 
s = - 
c = IN IP4 192.168.2.1 
b = AS:49 
t = 0 0 
b = RR:0 
b = RS:0 
a = rtpmap:97 AMR/8000/1 
m = audio 6000 RTP/AVP 96 
a = fmtp:102 0-15 
a = ptime:20 
a = maxptime:240

Ponowne zaproszenie zawiera nowy adres IP Bowditcha w polach nagłówka Via i Kontakt oraz informacje o mediach SDP.

Mobilność w Midcall (z wymianą nagłówka)

W mobilności w trakcie połączenia, rzeczywisty zestaw tras (zestaw serwerów proxy SIP, które muszą pokonać komunikaty SIP) musi ulec zmianie. Nie możemy użyć ponownego ZAPROSZENIA w mobilności w trakcie rozmowy

Na przykład, jeśli do przechodzenia przez NAT potrzebny jest serwer proxy, należy zmienić identyfikator URI kontaktu - należy utworzyć nowe okno dialogowe. Dlatego musi wysłać nowe INVITE z nagłówkiem Replaces, który identyfikuje istniejącą sesję.

Note - Załóżmy, że A i B są w trakcie połączenia i jeśli A otrzyma kolejne ZAPROSZENIE (powiedzmy od C) z nagłówkiem zastępującym (powinno pasować do istniejącego okna dialogowego), to A musi zaakceptować ZAPROSZENIE i zakończyć sesję z B i przenieść wszystkie zasoby do nowo utworzone okno dialogowe.

Przebieg połączenia pokazano na poniższym rysunku. Jest podobny do poprzedniego przepływu wywołań przy użyciu re-INVITE, z tym wyjątkiem, że BYE jest generowane automatycznie w celu zakończenia istniejącego okna dialogowego po zaakceptowaniu INVITE z Zastąpieniami.

Poniżej podano punkty, na które należy zwrócić uwagę w tym scenariuszu -

  • Istniejące okno dialogowe między Tomem i Jerrym obejmuje stary odwiedzany serwer proxy.

  • Nowe okno dialogowe korzystające z nowej sieci bezprzewodowej wymaga włączenia nowego odwiedzanego serwera proxy.

  • W rezultacie Tom wysyła ZAPROSZENIE z zamianami, co tworzy nowe okno dialogowe zawierające nowy odwiedzany serwer proxy, ale nie stary odwiedzany serwer proxy.

  • Kiedy Jerry akceptuje INVITE, automatycznie wysyłane jest BYE, aby zakończyć stare okno dialogowe, które kieruje przez stary odwiedzany serwer proxy, który nie jest już zaangażowany w sesję.

  • Wynikowa sesja medialna jest ustanawiana przy użyciu nowego adresu IP Toma z SDP w INVITE.

Mobilność usług

Usługi w SIP mogą być świadczone na serwerach proxy lub w UA. Zapewnienie mobilności usług wraz z mobilnością osobistą może być trudne, chyba że urządzenia użytkownika są identycznie skonfigurowane z tymi samymi usługami.

SIP może z łatwością wspierać mobilność usług przez Internet. Po podłączeniu do Internetu UA skonfigurowany do korzystania z zestawu serwerów proxy w Indiach może nadal korzystać z tych serwerów proxy podczas roamingu w Europie. Nie ma to żadnego wpływu na jakość sesji medialnej, ponieważ media zawsze przepływają bezpośrednio między dwoma UA i nie przechodzą przez serwery proxy SIP.

Usługi rezydentne punktu końcowego są dostępne tylko wtedy, gdy punkt końcowy jest połączony z Internetem. Usługa kończąca, taka jak usługa przekazywania połączeń zaimplementowana w punkcie końcowym, zakończy się niepowodzeniem, jeśli punkt końcowy tymczasowo utracił połączenie internetowe. Dlatego niektóre usługi są realizowane w sieci przy użyciu serwerów proxy SIP.

Czasami serwer proxy przekazuje pojedyncze wywołanie SIP do wielu punktów końcowych SIP. Ten proces jest znany jako rozwidlanie. Tutaj jedno połączenie może dzwonić do wielu punktów końcowych w tym samym czasie.

Dzięki rozwidleniu SIP telefon stacjonarny może dzwonić w tym samym czasie, co telefon programowy lub telefon SIP w telefonie komórkowym, umożliwiając łatwe odbieranie połączenia z dowolnego urządzenia.

Ogólnie rzecz biorąc, w biurze, zakładając, że szef nie może odebrać połączenia lub odejść, rozwidlenie SIP pozwala sekretarce odbierać połączenia z jego numeru wewnętrznego.

Rozwidlenie będzie możliwe, jeśli dostępny jest stanowy serwer proxy, który musi wykonać i odpowiedzieć z wielu otrzymanych.

Mamy dwa rodzaje rozwidlenia -

  • Rozwidlenie równoległe
  • Sekwencyjne rozwidlenie

Rozwidlenie równoległe

W tym scenariuszu serwer proxy rozwidli INVITE do, powiedzmy, dwóch urządzeń (UA2, UA3) jednocześnie. Oba urządzenia wygenerują 180 dzwonków, a ktokolwiek odbierze połączenie, wygeneruje 200 OK. Odpowiedź (załóżmy, że UA2), która jako pierwsza dotrze do Zleceniodawcy, ustanowi sesję z UA2. W przypadku drugiej odpowiedzi zostanie wywołane ANULOWANIE.

Jeśli twórca otrzyma obie odpowiedzi jednocześnie, to w oparciu o wartość q, prześle odpowiedź.

Sekwencyjne rozwidlenie

W tym scenariuszu serwer proxy rozwidli INVITE do jednego urządzenia (UA2). Jeśli UA2 jest w tym czasie niedostępny lub zajęty, serwer proxy rozwidli go na inne urządzenie (UA3).

Oddział - identyfikator i tag

Identyfikatory oddziałów pomagają serwerom proxy dopasować odpowiedzi do żądań rozwidlonych. Bez identyfikatorów gałęzi serwer proxy nie byłby w stanie zrozumieć odpowiedzi rozwidlonej. Branch-id będzie dostępny w nagłówku Via.

Tagi są używane przez UAC do rozróżniania wielu odpowiedzi końcowych z różnych UAS. UAS nie może rozstrzygnąć, czy żądanie zostało rozgałęzione, czy nie. Dlatego musi dodać tag.

Serwery proxy mogą również dodawać tagi, jeśli generują ostateczną odpowiedź, nigdy nie wstawiają tagów do żądań lub odpowiedzi, które przekazują.

Może się zdarzyć, że pojedyncze żądanie może być również rozwidlone przez wiele serwerów proxy. Tak więc proxy, które utworzyłoby fork, powinno dodać własne unikalne identyfikatory do utworzonych gałęzi.

Zadzwoń do nogi i Call ID

Noga połączenia odnosi się do relacji sygnalizacyjnej jeden do jednego między dwoma agentami użytkownika. Call ID to unikalny identyfikator przenoszony w wiadomości SIP, który odnosi się do połączenia. Połączenie to zbiór odnóg połączenia.

UAC rozpoczyna się od wysłania ZAPROSZENIA. Ze względu na rozwidlenie może otrzymać wiele 200 OK od różnych UA. Każdy odpowiada innemu etapowi rozmowy w ramach tego samego połączenia.

Zatem wywołanie jest grupą odnóg połączenia. Etap wywołania odnosi się do połączenia typu koniec-koniec między UA.

Przestrzenie CSeq w dwóch kierunkach odgałęzienia wywołania są niezależne. W jednym kierunku numer kolejny jest zwiększany dla każdej transakcji.

Poczta głosowa

Poczta głosowa jest obecnie bardzo popularna wśród użytkowników korporacyjnych. To aplikacja telefoniczna. Pojawia się obraz, gdy rozmówca jest niedostępny lub nie może odebrać połączenia, centrala poinformuje dzwoniącego o pozostawieniu wiadomości głosowej.

Agent użytkownika otrzyma odpowiedź 3xx lub przekieruje do serwera poczty głosowej, jeśli numer abonenta wywoływanego jest nieosiągalny. Potrzebne jest jednak jakieś rozszerzenie SIP, aby wskazać systemowi poczty głosowej, której skrzynki pocztowej użyć - to znaczy, które powitanie odtworzyć i gdzie przechowywać nagraną wiadomość. Można to osiągnąć na dwa sposoby -

  • Używając rozszerzenia pola nagłówka SIP

  • Wykorzystując Request-URI do sygnalizowania tych informacji

Załóżmy dla użytkownika sip:Tom@tutorialspoint.com ma system poczty głosowej pod adresem sip: voicemail.tutorialspoint.com, który zapewnia pocztę głosową, identyfikator URI żądania INVITE, gdy jest przekazywany do serwera poczty głosowej, mógłby wyglądać następująco -

sip:voicemail.tutorialspoint.com;target = sip:Tom@tutorialspoint.com;cause = 486

Na poniższej ilustracji pokazano, w jaki sposób identyfikator żądania-URI przenosi identyfikator skrzynki pocztowej i przyczynę (tutaj 486).

Jak wiemy, serwer proxy może być bezstanowy lub stanowy. W tym rozdziale omówimy więcej na temat serwerów proxy i routingu SIP.

Bezstanowy serwer proxy

Bezstanowy serwer proxy po prostu przekazuje otrzymaną wiadomość. Ten rodzaj serwera nie przechowuje żadnych informacji o połączeniu lub transakcji.

  • Bezstanowe serwery proxy zapominają o żądaniu SIP po jego przekazaniu.
  • Transakcja będzie szybka za pośrednictwem bezpaństwowych serwerów proxy.

Stanowy serwer proxy

Stanowy serwer proxy śledzi każde otrzymane żądanie i odpowiedź. W razie potrzeby może korzystać z przechowywanych informacji w przyszłości. Może ponownie przesłać żądanie, jeśli nie otrzyma odpowiedzi z drugiej strony.

  • Pełnostanowe serwery proxy zapamiętują żądanie po jego przekazaniu, więc mogą używać go do kierowania z wyprzedzeniem. Stanowe serwery proxy utrzymują stan transakcji . Transakcja implikuje stan transakcji,notstan połączenia .

  • Transakcja nie jest tak szybka z serwerami proxy stanowymi, jak bezpaństwowe.

  • Stanowe serwery proxy mogą w razie potrzeby rozwidlać i retransmitować (np. Przekierowywanie połączeń zajęte).

Via i Record-route

Record-Route

Nagłówek Record-Route jest wstawiany do żądań przez serwery proxy, które chciały być na ścieżce kolejnych żądań dla tego samego identyfikatora wywołania. Następnie jest używany przez agenta użytkownika do kierowania kolejnych żądań.

Przez

Nagłówki są wstawiane przez serwery do żądań w celu wykrycia pętli i pomocy odpowiedziom w znalezieniu drogi powrotnej do klienta. Jest to przydatne tylko wtedy, gdy odpowiedzi docierają do celu.

  • UA sam generuje i dodaje własny adres w polu nagłówka Via podczas wysyłania żądania.

  • Proxy przekazujące żądanie dodaje pole nagłówka Via zawierające własny adres na górze listy pól nagłówka Via.

  • Proxy lub UA generujące odpowiedź na żądanie kopiuje wszystkie pola nagłówka Via z żądania w kolejności do odpowiedzi, a następnie wysyła odpowiedź na adres podany w górnym polu nagłówka Via.

  • Serwer proxy otrzymujący odpowiedź sprawdza górne pole nagłówka Via i dopasowuje swój adres. Jeśli nie pasuje, odpowiedź została odrzucona.

  • Górne pole nagłówka Via jest następnie usuwane, a odpowiedź jest przekazywana na adres podany w następnym polu nagłówka Via.

Przez pola nagłówka zawierają nazwę protokołu, numer wersji i transport (SIP / 2.0 / UDP, SIP / 2.0 / TCP itp.) Oraz numery portów i parametry, takie jak odbiór, rport, rozgałęzienie.

  • Odebrany znacznik jest dodawany do pola nagłówka Via, jeśli UA lub proxy otrzyma żądanie z innego adresu niż podany w górnym polu nagłówka Via.

  • Parametr rozgałęzienia jest dodawany do pól nagłówka Via przez UA i proxy, który jest obliczany jako funkcja skrótu identyfikatora URI żądania oraz numeru To, From, Call-ID i CSeq.

SIP (telefon programowy) i PSTN (stary telefon) są różnymi sieciami i mówią różnymi językami. Potrzebujemy więc tłumacza (tutaj Gateway) do komunikacji między tymi dwoma sieciami.

Weźmy przykład, aby pokazać, jak telefon SIP kieruje połączenie telefoniczne do sieci PSTN za pośrednictwem bramki PSTN.

W tym przykładzie Tom (sip:tom@tutorialspoint.com) to telefon typu SIP, a Jerry używa globalnego numeru telefonu +91401234567.

SIP do PSTN przez bramy

Poniższa ilustracja przedstawia przepływ połączeń z SIP do PSTN przez bramy.

Poniżej znajduje się wyjaśnienie krok po kroku całego procesu, który ma miejsce podczas nawiązywania połączenia z telefonu SIP do PSTN.

  • Po pierwsze, (Tom) telefon SIP wybiera globalny numer +91401234567, aby skontaktować się z Jerry. Agent użytkownika SIP rozumie go jako liczbę globalną i konwertuje go na identyfikator-uri żądania przy użyciu DNS i wyzwala żądanie.

  • Telefon SIP wysyła INVITE bezpośrednio do bramki.

  • Bramka inicjuje połączenie z siecią PSTN, wybierając łącze ISUP SS7 do następnej centrali telefonicznej w sieci PSTN.

  • Wybrane cyfry z INVITE są mapowane do ISUP IAM. Komunikat o kompletnym adresie ISUP (ACM) jest odsyłany przez sieć PSTN w celu wskazania, że ​​łącze trunk zostało utworzone.

  • Telefon generuje dzwonek i przechodzi do centrali telefonicznej. Brama odwzorowuje ACM na odpowiedź 183 Session Progress zawierającą SDP wskazujący port RTP, którego będzie używać bramka do mostkowania dźwięku z sieci PSTN.

  • Po odebraniu 183 UAC dzwoniącego rozpoczyna odbieranie pakietów RTP wysłanych z bramki i przedstawia dźwięk dzwoniącemu, aby wiedzieli, że wywoływany postępuje w PSTN.

  • Połączenie jest zakończone, gdy strona wywoływana odbiera telefon, co powoduje, że centrala telefoniczna wysyła wiadomość zwrotną (ANM) do bramki.

  • Bramka następnie przerywa połączenie audio PSTN w obu kierunkach i wysyła odpowiedź 200 OK do dzwoniącego. Ponieważ ścieżka mediów RTP jest już ustanowiona, brama odpowiada na SDP w 183, ale nie powoduje żadnych zmian w połączeniu RTP.

  • UAC wysyła ACK, aby zakończyć wymianę sygnalizacji SIP. Ponieważ nie ma równoważnego komunikatu w ISUP, brama absorbuje ACK.

  • Wzywający wysyła BYE do bramki, aby zakończyć. Bramka mapuje BYE na komunikat o zwolnieniu ISUP (REL).

  • Bramka wysyła 200OK do BYE i odbiera RLC z PSTN.

Kodek, skrót od coder-decoder, wykonuje dwie podstawowe operacje -

  • Po pierwsze, konwertuje analogowy sygnał głosowy na jego równoważną postać cyfrową, dzięki czemu można go łatwo przesłać.

  • Następnie konwertuje skompresowany sygnał cyfrowy z powrotem do oryginalnej postaci analogowej, aby można go było odtworzyć.

Na rynku dostępnych jest wiele kodeków - niektóre są bezpłatne, a inne wymagają licencji. Kodeki różnią się jakością dźwięku i odpowiednio różnią się szerokością pasma.

Urządzenia sprzętowe, takie jak telefony i bramy, obsługują kilka różnych kodeków. Rozmawiając ze sobą, negocjują, jakiego kodeka będą używać.

Tutaj, w tym rozdziale, omówimy kilka popularnych powszechnie używanych kodeków audio SIP.

G.711

G.711 to kodek, który został wprowadzony przez ITU w 1972 roku do użytku w telefonii cyfrowej. Kodek ma dwa warianty:A-Law jest używany w Europie i w międzynarodowych łączach telefonicznych, uLaw jest używany w USA i Japonii.

  • G.711 wykorzystuje kompresję logarytmiczną. Zciska każdą 16-bitową próbkę do 8 bitów, dzięki czemu osiąga współczynnik kompresji 1: 2.

  • Szybkość transmisji wynosi 64 kbit / s w jednym kierunku, więc połączenie zużywa 128 kbit / s.

  • G.711 to ten sam kodek, który jest używany w sieci PSTN, dzięki czemu zapewnia najlepszą jakość głosu. Jednak zużywa więcej przepustowości niż inne kodeki.

  • Najlepiej działa w sieciach lokalnych, w których mamy dużo dostępnej przepustowości.

G.729

G.729 to kodek o niewielkich wymaganiach dotyczących przepustowości; zapewnia dobrą jakość dźwięku.

  • Kodek koduje dźwięk w ramkach o długości 10 ms. Biorąc pod uwagę częstotliwość próbkowania 8 kHz, ramka 10 ms zawiera 80 próbek audio.

  • Algorytm kodeka koduje każdą ramkę do 10 bajtów, więc wynikowa szybkość transmisji wynosi 8 kbit / sw jednym kierunku.

  • G.729 to licencjonowany kodek. Użytkownicy końcowi, którzy chcą używać tego kodeka, powinni kupić sprzęt, który go implementuje (czy to telefon VoIP, czy brama).

  • Często stosowanym wariantem G.729 jest G.729a. Jest zgodny przewodowo z oryginalnym kodekiem, ale ma mniejsze wymagania dotyczące procesora.

G.723.1

G.723.1 jest wynikiem konkursu ogłoszonego przez ITU w celu zaprojektowania kodeka, który umożliwiałby połączenia przez łącza modemowe 28,8 i 33 kbit / s.

  • Mamy dwa warianty G.723.1. Oba działają na ramkach audio o długości 30 ms (tj. 240 próbek), ale algorytmy się różnią.

  • Przepływność pierwszego wariantu wynosi 6,4 kbit / s, natomiast drugiego wariantu 5,3 kbit / s.

  • Zakodowane ramki dla dwóch wariantów mają odpowiednio 24 i 20 bajtów.

GSM 06.10

GSM 06.10 to kodek przeznaczony dla sieci komórkowych GSM. Jest również znany jako pełna szybkość GSM.

  • Ten wariant kodeka GSM może być swobodnie używany, więc często można go znaleźć w aplikacjach VoIP typu open source.

  • Kodek działa na ramkach audio o długości 20 ms (tj. 160 próbek) i kompresuje każdą ramkę do 33 bajtów, więc wynikowa przepływność wynosi 13 kbit /.

Agent użytkownika typu back-to-back (B2BUA) to logiczny element sieci w aplikacjach SIP. Jest to typ SIP UA, który odbiera żądanie SIP, a następnie przeformułowuje żądanie i wysyła jako nowe żądanie.

W przeciwieństwie do serwera proxy utrzymuje stan dialogu i musi uczestniczyć we wszystkich żądaniach wysyłanych w ustanowionych przez siebie dialogach. B2BUA przełamuje kompleksowy charakter SIP.

B2BUA - jak to działa?

Agent B2BUA działa między dwoma punktami końcowymi rozmowy telefonicznej i dzieli kanał komunikacyjny na dwa call legs. B2BUA to połączenie UAC i UAS. Uczestniczy we wszystkich sygnalizacjach SIP między oboma końcami połączenia, które ustalił. Ponieważ B2BUA dostępne w oknie dialogowym, dostawca usług może zaimplementować pewne dodatkowe funkcje.

W początkowej fazie połączenia B2BUA działa jako serwer agenta użytkownika (UAS) i przetwarza żądanie jako klient klienta użytkownika (UAC) do końca docelowego, obsługując sygnalizację między punktami końcowymi.

B2BUA utrzymuje pełny stan dla obsługiwanych wywołań. Każda strona B2BUA działa jako standardowy element sieci SIP, jak określono w dokumencie RFC 3261.

Funkcje B2BUA

B2BUA zapewnia następujące funkcje -

  • Zarządzanie połączeniami (fakturowanie, automatyczne rozłączanie połączeń, przekazywanie połączeń itp.)

  • Współpraca sieciowa (być może z adaptacją protokołu)

  • Ukrywanie wewnętrznych elementów sieci (adresy prywatne, topologia sieci itp.)

Często B2BUA są również implementowane w bramach medialnych w celu mostkowania strumieni mediów w celu uzyskania pełnej kontroli nad sesją.

Przykład B2BUA

Wiele korporacyjnych systemów telefonicznych central abonenckich (PBX) wykorzystuje logikę B2BUA.

Niektóre zapory mają wbudowaną funkcjonalność ALG (Application Layer Gateway), która umożliwia zaporze ogniowej autoryzację SIP i ruchu medialnego przy zachowaniu wysokiego poziomu bezpieczeństwa.

Inny popularny typ B2BUA jest znany jako Session Border Controller (SBC).