Marcin Szczukiewicz

7. Protokoły umożliwiające realizację telefonii internetowej

7.1. Protokoły RTP (Real Time Protocol) i RTCP (Real Time Control Protocol)

Transmisja z wykorzystaniem protokołu IP nie jest pozbawiona wad. Nie ma na przykład mechanizmów gwarantujących, że kolejne pakiety dotrą do adresata w określonym czasie, co prowadzi do powstawania opóźnień. Protokoły operujące w warstwie transportowej to TCP (Transmision Control Protocol) oraz UDP (User Datagram Protocol). Ten pierwszy jest protokołem połączeniowym umożliwiającym wykrywanie błędów na obu końcach połączenia i odzyskiwanie pakietów po wystąpieniu błędów. Niestety generuje on przy tym opóźnienia. Drugi protokół jest protokołem bezpołączeniowym, nie posiadającym mechanizmów kontroli poprawności dostarczenia danych do miejsca przeznaczenia. Jest on stosowany do przesyłania głosu, ponieważ eliminuje powtarzanie zagubionych pakietów. Nie stosuje jednak znaczników czasu, nie można zatem kontrolować opóźnień. Aby umożliwić transmisję danych od aplikacji pracujących w czasie rzeczywistym przez sieć Internet, zastosowano nowe protokoły RTP (Real Time Protocol) i RTCP (Real Time Control Protocol).

RTP pozwala skorygować większość wad transportu aplikacji czasu rzeczywistego w sieciach z protokołem internetowym. Spełnia funkcje odpowiednie dla aplikacji czasu rzeczywistego transmitujących dane audio, wideo albo dane symulacyjne. Nagłówek protokołu RTP zawiera w sobie między innymi poniższe informacje [14]:

• Payload type - typ przenoszonej informacji. Identyfikuje format ładunku RTP i określa sposób jego interpretacji przez aplikację. Wyszczególnia typ i sposób kodowania informacji.

• Sequence number - numeracja pakietów sesji. Każdy kolejno wysyłany pakiet danych jest numerowany. W ten sposób można u odbiorcy obserwować utratę pakietów i ustalać ich kolejność.

• Timestamp - znacznik czasu. Wprowadza próbki zegara dla pierwszego oktetu pakietu RTP. Zegar musi być liniowy, by pozwalał synchronizować i obliczać wahania przybywających pakietów. Musi być także wystarczająco dokładny by było można mierzyć wahania przybycia paczek (np. jeden takt na ramkę wideo nie jest wystarczający).

Pomimo ulepszenia transportu pakietów w czasie rzeczywistym przez sieć IP, RTP nie ma mechanizmów rezerwujących zasoby sieci, zatem nie gwarantuje jakości usług. Sytuację tę zmienia omówiony wcześniej protokół RSVP, który może rezerwować zasoby dla strumienia RTP. Protokół RSVP tworzy coś w rodzaju "rury", przez którą może przepływać strumień RTP (rys. 7.1).

Rys. 7.1. Wspomaganie strumienia RTP przez protokół rezerwacji zasobów RSVP

Pracę protokołu RTP wspiera protokół kontroli RTCP dostarczający mechanizmów kontroli i informacji zwrotnych dla sesji czasu rzeczywistego. Są to między innymi informacje monitorujące przepływ danych. RTCP bazuje na okresowej transmisji pakietów kontrolnych do wszystkich uczestników sesji, przy użyciu tych samych mechanizmów dystrybucji, jakie istnieją dla pakietów przenoszących dane.

7.2. Protokoły sygnalizacyjne

Do realizacji telefonii internetowej niezbędne jest wykorzystywanie protokołów umożliwiających sterowanie przebiegiem transmisji w bezpołączeniowym środowisku sieci pakietowej IP. Ten właśnie element, czyli sygnalizacja umożliwiająca ustanawianie i sterowanie przebiegiem sesji wyróżnia w znacznym stopniu telefonię internetową od przekazu innych strumieni w sieci IP [3]. W systemach tradycyjnej telefonii podstawowym protokołem sygnalizacyjnym jest SS7 (Signalling System 7), który realizuje większość funkcji związanych z obsługą połączeń. Są to między innymi kierowanie ruchem, rezerwacja zasobów sieci, zestawianie i rozłączanie połączeń, zarządzanie połączeniem. Aby w środowisku sieci IP, można było realizować usługi telekomunikacyjne znane dotychczas tylko z tradycyjnych sieci telekomunikacyjnych, muszą istnieć mechanizmy umożliwiające stworzenie systemu sygnalizacji realizującego funkcje podobne do tych jakie istnieją w SS7. Istnieją takie mechanizmy, opierające się o całe zestawy współpracujących ze sobą protokołów. Protokoły sygnalizacyjne stanowią serce telefonii internetowej i są niezbędne do realizacji zaawansowanych usług, oraz do zapewnienia współdziałania z tradycyjnymi sieciami telefonicznymi.
Protokół sygnalizacyjny w telefonii internetowej powinien realizować takie funkcje, jak:

• translacja adresów i lokalizacja użytkownika wywoływanego,

• otwieranie i zamykanie sesji,

• negocjacja parametrów sesji (np. sposobu kompresji strumieni informacji) oraz ich zmiana w trakcie połączenia,

• zarządzanie grupą uczestników sesji,

• zarządzanie przebiegiem połączenia.

Obecnie nie ma ogólnie przyjętego standardu sygnalizacyjnego dla telefonii IP, jednak istnieją dwa najbardziej liczące się rozwiązania. Są to Zalecenie ITU-T H.323 oraz zdefiniowany przez IETF (Internet Engineering Task Force) protokół SIP (Session Initiation Protocol). W rywalizacji między rozwiązaniami opartymi na H.323 i SIP trudno typować zwycięzcę, chociaż dominującym do tej pory był ten pierwszy. Możliwe jest także powstanie zupełnie innego rozwiązania, ponieważ prowadzone są prace nad alternatywnymi standardami.

7.3. Zalecenie H.323

Zalecenie H.323 opisuje techniczne wymagania dla usług łączności audio i wideo w czasie rzeczywistym poprzez sieci transmisji pakietowej, które nie dostarczają gwarantowanej jakości usług QoS (Quality of Service). Taką siecią jest między innymi Internet. Zakres H.323 nie definiuje sieci pakietowej do przesyłania danych oraz warstw transportowych używanych do łączenia różnych sieci [14]. Zalecenia H.323 definiują architekturę, która umożliwia między innymi realizację połączeń telefonicznych w sieciach pakietowych. Do najważniejszych elementów tej architektury należą [3]:

• Terminale (terminals) wraz z kodekami - są to systemy końcowe (telefony internetowe lub odpowiednie oprogramowanie komunikacyjne), które realizują algorytmy kompresji i dekompresji danych oraz inne funkcje umożliwiające porozumiewanie się użytkowników.

• Bramki (gateways) - urządzenia pośredniczące w komunikacji systemów końcowych H.323 z innymi systemami końcowymi. Bramki pełnią funkcje związane z translacją protokołów, formatu strumieni audio i wideo oraz realizują pewne funkcje związane ze sterowaniem połączeniami. Gatekeepery - serwery sterujące, które zarządzają połączeniem, zapewniają translację adresów, autoryzację i zarządzanie przepływnością. Mostki konferencyjne MCU (Multipoint Control Unit) - służące do sterowania transmisją multicast.

Wyżej wymienione elementy zostaną szerzej omówione w jednym z kolejnych rozdziałów.

7.3.1. Stos protokołów H.323

Protokoły wchodzące w skład H.323 stanowią kompleksowe rozwiązanie dla transmisji aplikacji czasu rzeczywistego przez sieci transmisji pakietowej. Najważniejsze z nich przedstawiono poniżej, wraz z ilustracją pokazującą ich rozmieszczenie, na tle modelu OSI i stosu protokołów TCP/IP (rys. 7.2).
Należy podkreślić, że standard H.323 jest niezależny od rodzaju sieci pakietowej, stąd też w jego ramach nie ma zdefiniowanych protokołów pracujących w warstwach trzeciej i niższych modelu OSI.

Najważniejsze protokoły wchodzące w skład modelu H.323 [14]:

• H.225.0Protokoły sygnalizacji wywołań i strumieni multimedialnych (w skład protokołu wchodzą między innymi Q.931 i RAS).

• H.245Protokół kontroli dla komunikacji multimedialnej.

• H.235Bezpieczeństwo i kodowanie danych dla terminali serii H.

• H.450.xUsługi dodatkowe dla multimediów.

• T.120 Seria protokołów dla realizacji konferencji multimedialnych.

Jeżeli standard H.323 korzysta z sieci IP to wykorzystuje oba protokoły warstwy czwartej, czyli TCP i UDP. Protokół TCP kontrolujący przepływ pakietów i odpowiadający za ich odzyskiwanie w przypadku ich utraty jest przeznaczony do transportu sygnalizacji i danych, ponieważ te sygnały nie mogą być tracone. Protokół UDP eliminujący powtarzanie zagubionych pakietów jest używany dla pakietów niosących sygnały audio i wideo, które są wrażliwe na opóźnienia. Opóźniane pakiety audio i wideo są wtedy gubione. W konsekwencji, TCP jest stosowany dla kanału sterującego H.245, kanału danych T.120 i kanału sygnalizacyjnego połączenia, podczas gdy UDP ma zastosowanie dla kanałów audio, wideo i RAS.

Rys. 7.2. Protokoły modelu H.323 i stosu TCP/IP na tle modelu OSI

7.3.1.1. Kanały sygnalizacyjne

Zalecenie H.323 definiuje trzy kanały sygnalizacyjne. Są to odpowiednio RAS (Registration, Admission, Status), Q.931 i H.245.

RAS (Registration, Admission, Status) - jest przeznaczony do obsługi sygnalizacji między gatekeeperem a innymi elementami systemu. Protokół ten jest używany do przenoszenia wiadomości wykorzystywanych w gatekeeperze do rozpoznawania i procesu rejestracji punktu końcowego. Kojarzy on tymczasowy adres punktu końcowego z adresem kanału sygnalizacyjnego dla danego wywołania. RAS jest protokołem dzięki któremu terminal, gatekeeper i brama dowiadują się o zamiarze zestawienia sesji. Poniżej przedstawiono główne wiadomości sygnalizacyjne protokołu RAS:

• RegistrationRequest (RRQ) - prośba od terminala albo bramy o rejestrację w gatekeeperze. Gatekeeper może zrealizować lub odrzucić prośbę (RCF albo RRJ).

• AdmissionRequest (ARQ) - prośba od terminala do gatekeepera o dostęp do sieci pakietowej. Gatekeeper może zrealizować lub odrzucić prośbę (ACF albo ARJ).

• BandwidthRequest (BRQ) - prośba od terminala do gatekeepera o zmianę szerokości przydzielonego pasma. Gatekeeper może zrealizować lub odrzucić prośbę (BCF albo BRJ).

• RAS timers and Request in Progress (RIP). Transmisja RAS odbywa się w trybie bezpołączeniowym. H.225.0 zaleca jednak określenie czasu granicznego po upłynięciu którego punkt końcowy albo gatekeeper, który nie może dać odpowiedzi może użyć wiadomości RIP by pokazać że jeszcze przetwarza dane. Punkt końcowy albo gatekeeper otrzymujące RIP, zerują liczniki i zaczynają odliczanie czasu od początku .

Q.931 Call Signalling - zawiera w sobie procedury niezbędne do zrealizowania połączenia między stroną inicjującą a stroną docelową. Poniżej opisano wiadomości sygnalizacyjne wymieniane między stronami.

• Alerting - użytkownik jest informowany o wywołaniu ("telefon dzwoni").

• Call Proceeding - zawiadomienie terminala użytkownika o przejściu do fazy zestawiania połączenia, z chwilą otrzymania wszystkich niezbędnych informacji.

• Connect - odpowiedź na wezwanie ("podniesienie mikrotelefonu"), przejście do fazy rozmowy.

• Release Complete - wysyłane przez terminal wskazuje zakończenie połączenia.

• Status - odpowiedź na nieznaną wiadomość sygnalizacyjną bądź na wiadomość Status Inquiry. Dostarcza informacji o stanie rozmowy.

• Status Inquiry - prośba o informację o stanie rozmowy. Może być posyłana przez terminal albo gatekeeper do innego terminala.

H.245 Call Control - służy do wymieniania między terminalami sygnałów kontrolnych dotyczących połączenia. Procedura ta ma zapewnić optymalne warunki dla komunikacji audiowizualnej i danych. Polega ona na wymianie następujących wiadomości:

• Master-Slave Determination - określa, który terminal ma status Master, a który Slave.

• Terminal Capability Set - zawiera informacje o zdolności terminala do wysyłania i otrzymywania strumieni multimedialnych.

• Open Logical Channel - otwiera wirtualny kanał logiczny do przesyłania danych audiowizualnych i innych.

• Close Logical Channel - zamyka logiczny kanał między dwoma terminalami.

• Request Mode - wiadomość używana do ustanowienia trybu przesyłania danych w terminalu odbierającym tę informację. Tryby są następujące: VideoMode, AudioMode , DataMode i EncryptionMode.

• End Session Command - wskazuje koniec sesji H.245. Po jej wysłaniu terminal nie będzie posyłać więcej wiadomości H.245.

7.3.1.2. H.235 - bezpieczeństwo i kodowanie danych

H.235 uzupełnia strukturę serii H.3xx włączając usługi związane z bezpieczeństwem, takie jak identyfikacja (authentication) i utajnianie danych (privacy). H.235 powinien pracować z innymi protokołami z serii H używającymi H.245 jako ich protokołu kontroli.

7.3.1.3. H.450.x - usługi dodatkowe

Seria H.450.x definiuje usługi dodatkowe dla H.323, związane z przekierowywaniem wywołań (Call Transfer) bądź też ich odbijaniem (Call Diversion).

H.450.1 - protokół wspólny dla wszystkich usług dodatkowych realizowanych w ramach H.323. Współpracuje z procedurami i protokołem sygnalizacyjnym między elementami H.323 i służy do kontroli usług dodatkowych. Pracuje zawsze razem z protokołem H.225. Wszystkie wiadomości są wiadomościami tekstowymi w formacie ASN.1.

H.450.2 i H.450.3 - protokoły definiujące usługi przekierowania. Są one świadczone abonentowi wywoływanemu i w żaden sposób nie wpływają na możliwość inicjowania przez niego połączeń. Podczas aktywowania usługi abonent może wskazać alternatywny numer lub numery, do których system powinien skierować wywołania przychodzące określonych typów. Poszczególne usługi tej rodziny, oferowane i realizowane niezależnie, różnią się głównie warunkiem (stanem lub czynnością wywoływanego Ab. B) powodującym rzeczywiste przekierowanie połączenia. Są to usługi:
CFU(Call Forwarding Unconditional) - bezwarunkowe przekierowanie wywołania przychodzącego niezależnie od stanu Ab. B.
CFB (Call Forwarding Busy) - przekierowanie w przypadku zajętości Ab. B.
CFNR(Call Forwarding No Reply) - przekierowanie w przypadku braku zgłoszenia Ab. B.
CD(Call Deflection) - odbicie wywołania. Przekierowanie następuje w wyniku jawnego żądania abonenta wywoływanego, przed dojściem połączenia do skutku.

7.3.1.4. T.120 - obsługa konferencji multimedialnych

Rodzina T.120 definiuje protokoły i usługi dla wielopunktowych konferencji, które w znaczący sposób wspomagają multimedia, układy kodująco-dekodujące oraz samą jednostkę MCU, pozwalając jak najlepiej je wykorzystać.

Rys. 7.3. Zbiór protokołów T.120

Zbiór protokołów T.120 ma strukturę dwuwarstwową (rys. 7.3). Warstwa górna składa się z protokołów T.126 i T.127, które zabezpieczają aplikacje obsługujące konferencje. Protokół T.126 pozwala na wymianę i korektę nieruchomych obrazów. Protokół T.127 zapewnia transport każdego zbioru binarnego podczas konferencji. Warstwa niższa zapewnia pewnego rodzaju "infrastrukturę". Protokół T.123 zawiera stosy protokołów dla transportu danych pomiędzy różnymi dostępnymi sieciami - od sieci PSTN do sieci ISDN i od cyfrowych obwodów do komutacji pakietów. Protokoły T.122 i T.125 zapewniają współdziałanie aplikacjom warstwy wyższej. Protokół T.124 zarządza sterowaniem konferencją, śledzeniem aplikacji i węzłów, wspomaganiem zabezpieczeń i prowadzącego konferencję.

7.3.2. Elementy sieci opartej na protokole H.323

Pełny standard H.323 stanowi kompleksowe rozwiązanie dla transmisji aplikacji czasu rzeczywistego przez sieci transmisji pakietowej. H.323 specyfikuje komponenty, protokoły i procedury umożliwiające taką komunikację. Standard ten jest niezależny od rodzaju sieci pakietowej, po której będziemy wysyłać konkretne dane, a także od protokołu transportowego używanego w danej sieci pakietowej. W modelu H.323 istnieją cztery główne elementy służące do komunikacji aplikacji czasu rzeczywistego z wykorzystaniem sieci pakietowych: terminal, bramka lub brama (gateway), gatekeeper, mostek konferencyjny MCU (Multipoint Control Unit) (rys.7.4) [3].

Rys. 7.4. Elementy systemu H.323

7.3.2.1. Terminale (Terminals)

Terminale to punkty końcowe sieci zapewniające dwukierunkową łączność w czasie rzeczywistym. Wszystkie terminale muszą obsługiwać łączność głosową, obsługa sygnałów wideo i danych jest opcjonalna (rys. 7.5). Należy tutaj zaznaczyć, że terminal może być zarówno fizycznym urządzeniem jak i programem wykonującym wymagane funkcje.

Wszystkie terminale zgodne z H.323 muszą obsługiwać:

• Protokół H.245, który jest używany do kontroli poprawności sesji. Służy on do wymieniania wiadomości dotyczących połączenia między użytkownikami końcowymi.

• Protokół obsługi wywołań i sygnalizacji Q.931 - RAS (Registration, Admission and Status), który jest protokołem używanym do komunikacji z gatekeeperem informującym między innymi o zamiarze zestawienia sesji.

• Pakiety RTP/RTCP (Real Time Transport Protocol / Real Time Control Protocol) zawierających próbki zakodowanych danych audio i wideo.

Rys. 7.5. Terminal H.323

7.3.2.2. Bramki (Gateways)

Bramka, nazywana także bramą, jest opcjonalnym elementem w H.323. Bramka dostarcza wiele usług, w tym tłumaczenie między różnymi formatami transmisyjnymi oraz między różnymi procedurami komunikacyjnymi. Ponadto, obsługuje różne układy kodująco-dekodujące audio i wideo oraz odpowiada za zestawianie i rozłączanie połączeń na obu stronach obsługiwanych sieci. Bramki mogą zatem łączyć sieć H.323 z sieciami PSTN i ISDN. Terminale komunikują się z bramami używając protokołów H.245 i Q.931. Bramy nie są wymagane jeżeli połączenia do innych sieci nie występują, ponieważ terminale mogą się komunikować między sobą bezpośrednio w swojej sieci.

Stosując transkodery, bramy H.323 mogą obsługiwać terminale zgodne z protokołami H.310, H.321, H.322 i V.70. Wiele funkcji bram zależy od projektanta. Na przykład, liczba terminali H.323, które mogą jednocześnie komunikować się przez bramę nie podlega normalizacji. Podobnie, funkcje konwersji audio, wideo i danych oraz dołączanie funkcji połączeń wielopunktowych są zależne od producenta. Wykorzystanie bramy H.323 pociąga za sobą wykorzystanie kolejnego urządzenia - gatekeepera.

7.3.2.3. Gatekeepery

Gatekeeper jest centralnym punktem dla wszystkich wywołań w granicach obsługiwanej strefy H.323 (H.323 Zone), którą tworzy zespół wszystkich terminali, bram i MCU zarządzanych przez pojedynczy gatekeeper. Element ten dostarcza usług kontroli wywołań do zarejestrowanych punktów końcowych. Przy czym działa on najczęściej jako wirtualny przełącznik.

Gatekeeper wykonuje dwie ważne funkcje kontroli wywołań.

• Tłumaczenie tymczasowych adresów terminali i bram jakie występują w sieci LAN na adresy IP albo IPX, w sposób zdefiniowany w RAS.

• Zarządzanie szerokością pasma, określane także w granicach protokołu RAS. Szerokość pasma jest rozdzielana dla połączeń audio, wideo, poczty elektronicznej, transferu plików i innych protokołów występujących w danej sieci.

Opcjonalną, ale wartościową cechą gatekeepera jest zdolność do rutowania połączeń. Poprzez wyznaczanie tras dla wywołań wzrasta skuteczność kontroli nad nimi. Dostawcom usług ta funkcja umożliwia rozliczanie rozmów i połączeń wykonywanych poprzez ich sieć. Ta usługa może być także używana do ponownego łączenia rozmów inną drogą, jeżeli dana droga jest niedostępna. W dodatku, gatekeeper zdolny do wyznaczania tras wywołań H.323 może pomagać równoważyć ruch pośród wielu bram opierając się na własnej logice wyznaczania tras.

Gatekeeper jest logicznie oddzielną jednostką funkcjonalną ale producenci mogą fizycznie łączyć funkcje gatekeepera z bramami i mostkami MCU w jednej obudowie. Nie jest on wymagany w systemie H.323. Jakkolwiek, jeżeli jest obecny, terminale muszą robić użytek z usług przez niego oferowanych.

Wymagane funkcje gatekeepera:

• tłumaczenie adresów tymczasowych na transportowe,

• kontrola dostępu,

• kontrola pasma,

• zarządzanie strefą.

Opcjonalne funkcje gatekeepera:

• obsługa sygnalizacji,

• zarządzanie pasmem,

• autoryzacja wywołań,

• zarządzanie wywołaniami.

7.3.2.4. Mostek konferencyjny MCU (Multipoint Control Unit)

Mostek konferencyjny MCU jest niezbędny jedynie wtedy, gdy w sieci korzysta się z telekonferencji. Jednostka MCU zapewnia jednoczesną łączność między trzema albo więcej punktami końcowymi. Służy do rozdzielania strumieni i przekazywania ich do odpowiednich terminali. MCU składa się z: jednego MC (Multipoint Controller), od zera do kilku MP (Multipoint Processor).

MC odpowiada za wymianę informacji. Posługuje się H.245 do negocjacji między wszystkimi zakończeniami, określając wspólne możliwości dla przetwarzania audio i wideo. MC kontroluje też zasoby połączenia przez decydowanie, który, jeżeli jakikolwiek, strumień audio i/lub wideo będzie podzielony. MC nie ma do czynienia bezpośrednio z jakimkolwiek z przesyłanych strumieni. Funkcja obsługi strumieni danych jest pozostawiona MP, który miesza, przełącza i przetwarza strumienie audio, wideo i/lub danych. MC i MP mogą istnieć jako oddzielne układy lub mogą wchodzić w skład innych urządzeń.

7.3.2.5. Zestawianie połączeń przy wykorzystaniu sieci zgodnej z H.323

Stos H.323 definiuje kilka protokołów koniecznych przy zestawianiu połączeń. Przede wszystkim są to sposoby kodowania audio i wideo (przykładowym sposobem kodowania audio jest standard G.729A, umożliwiający kompresję sesji głosowych do 8 kb/s). Zakodowane dane muszą zostać przesłane do adresata końcowego. W tym celu musi zostać uruchomiona sesja pomiędzy użytkownikami zdalnymi.
Zanim nastąpi proces zestawienia połączenia, wszystkie urządzenia w sieci H.323 (terminal, bramka, gatekeeper) muszą być poinformowane o zamiarze zestawienia takiej sesji i umożliwić komunikację między sobą (rys. 7.6). Do tego celu służy protokół RAS. Do zestawienia sesji jest używany protokół Q.931 Call Signalling.

Rys. 7.6. Pierwsza faza zestawiania połączenia

Ostatnim elementem zestawiania połączenia jest kontrola poprawności sesji (rys. 7.7). Do tego celu wykorzystywany jest protokół H.245 Call Control. Służy on do wymieniania pomiędzy terminalami końcowymi wiadomości kontrolnych dotyczących połączenia.

Rys. 7.7. Druga faza zestawiania połączenia

W chwili kiedy sesja jest już zestawiona, pomiędzy użytkownikami końcowymi zaczynają być transportowane pakiety RTP (RTCP), zawierające próbki konkretnych danych zakodowanych w standardowy sposób.

7.4. Protokół SIP (Session Initiation Protocol)

Protokół SIP jest alternatywnym rozwiązaniem w stosunku do protokołów zdefiniowanych w ramach Zalecenia H.323. Opracowany został przez grupę roboczą IETF MMUSIC (IETF Multiparty Multimedia Session Control). Zasadnicze założenia protokołu zostały sformułowane w 1996 roku, kiedy to pierwowzór SIP wykorzystano jako jeden z elementów architektury eksperymentalnej sieci szkieletowej Mbone, która stanowiła nakładkę na publiczny Internet umożliwiającą komunikację w trybie grupowym. Środowisko internetowe, dla którego został stworzony protokół SIP, wpłynęło w zasadniczy sposób na jego charakterystykę. Został on zaprojektowany w sposób uwzględniający uwarunkowania Internetu, to znaczy z wykorzystaniem wcześniej znormalizowanych przez IETF koncepcji i protokołów. Spełnia wymagania szerokiego zakresu skalowalności, dzięki czemu użytkownicy mogą być zlokalizowani w dowolnym miejscu Internetu i mogą być zapraszani do uczestnictwa w wielu sesjach [11].

7.4.1. Charakterystyka protokołu SIP

SIP jest protokołem sterującym warstwy aplikacji, mogącym zestawiać, modyfikować i kończyć sesje, w których uczestniczy dwóch lub więcej użytkowników. Przez sesję rozumie się w tym przypadku telefonię internetową, konferencję multimedialną lub multimedialną sesję rozsiewczą. Uczestnicy sesji mogą się komunikować za pośrednictwem transmisji w trybie multicast, siatki połączeń punkt-punkt czyli w trybie unicast lub kombinacji powyższych rozwiązań. W trakcie trwania sesji można dołączać kolejnych uczestników oraz zmieniać wykorzystywane media. Protokół SIP w sposób przezroczysty obsługuje odwzorowanie nazw i przeadresowywanie usług pozwalając na wprowadzanie w sieciach pakietowych IP usług znanych z ISDN i sieci inteligentnej IN, w tym pewnych aspektów mobilności użytkownika. Mobilność ta w terminologii sieci IN jest rozumiana jako możliwość inicjowania i odbierania połączeń oraz dostępu do własnego profilu usług, w każdym miejscu i za pomocą dowolnego terminala, a także zdolność sieci do identyfikacji użytkowników zmieniających swoje położenie. SIP pozwala także na wprowadzanie nowych usług łączących funkcjonalność PSTN/IN, sieci IP i Internetu.
Protokół SIP został zaprojektowany jako część ogólnej architektury danych multimedialnych i ich sterowania, która obejmuje:

• RSVP - służący do rezerwacji zasobów sieciowych,

• RTP - służący do przenoszenia danych w trybie czasu rzeczywistego,

• SDP (Session Description Protocol) - służący do opisu sesji multimedialnych,

• SAP (Session Announcement Protocol) - służący do ogłaszania sesji multimedialnych za pomocą trybu multicast,

• RTSP (Real Time Streaming Protocol) - służący do sterowania dostarczaniem strumienia multimedialnego.

Protokół SIP nie zależy jednak od żadnego z tych protokołów i może być użyty łącznie z innym wywołaniem i innymi protokołami sygnalizacji. W tym przypadku system końcowy używa protokołu SIP do określenia właściwego adresu systemu docelowego i odpowiedniego protokołu z danego adresu. Można zatem użyć protokołu SIP do ustalenia, czy abonent może być osiągnięty przez H.323 i czy jest dostępna brama zgodna z H.245 oraz adres użytkownika, a następnie użyć protokołów RAS i Q.931 do ustanowienia sesji.

7.4.2. Architektura funkcjonalna sieci IP wykorzystującej protokół SIP

Na architekturę sieci IP obsługiwaną przez protokół SIP składają się dwa elementy [3]:

• agent użytkownika UA (User Agent),

• serwery o różnym przeznaczeniu i sposobach działania.

7.4.2.1. Agent użytkownika

Agent jest systemem końcowym, zazwyczaj odpowiednio "inteligentnym oprogramowaniem", działającym w imieniu użytkownika i jest elementem pośredniczącym w komunikacji między użytkownikiem a siecią. Agent składa się z dwóch części - klienta UAC (User Agent Client) i serwera UAS (User Agent Server). Dzięki temu, każdy terminal sieci SIP jest węzłem typu "host". Umożliwia to wysyłanie przez użytkownika żądań protokołu SIP (np. inicjowanie sesji) i odbieranie takich żądań, przesyłanych do niego przez innych agentów oraz wysyłanie odpowiedzi w imieniu użytkownika (np. przyjęcie zaproszenia do sesji).

7.4.2.2. Serwery siecioweSerwery sieciowe w odróżnieniu od serwerów wchodzących w skład UA, nie potrafią bezpośrednio obsłużyć przesyłanych do nich żądań. Podstawową ich funkcją jest translacja adresów i pośredniczenie w procesie odnajdywania użytkownika UA, do którego jest skierowane wywołanie. Użytkownik inicjujący połączenie może znać tylko numer telefonu. Jego agent musi wówczas ustalić, który adres sieciowy może dokonać translacji tego adresu na adres IP.

Serwery sieciowe dzielą się na:

• serwery pośredniczące (Proxy Server),

• serwery przekierowujące (Redirect Server),

• serwery lokalizacji (Location Server),

• serwery rejestrowe (Registrar),

• serwery aplikacji (Application Server).

Serwer pośredniczący przyjmuje żądanie od UAC i jeśli nie jest w stanie go obsłużyć to przekazuje je do następnego serwera, który postępuje w analogiczny sposób. Serwer ten może rozwidlić żądanie wysyłając je jednocześnie do wielu serwerów, poszerzając w ten sposób zasięg przeszukiwania. Odpowiedzi wracają tą samą drogą jaką zostały wysłane żądania, tylko że w odwrotnym kierunku.
Serwer przekierowujący po odebraniu żądania od UAC nie przesyła go dalej ale odpowiada na nie, zwracając adres kolejnego serwera, z którym należy się skontaktować w celu poszukiwania właściwego serwera użytkownika końcowego. UA wysyła ponownie zaproszenie dosesji wykorzystując w ten sposób uzyskany adres. Znaleziony w ten sposób serwer może być znów serwerem Redirect i procedura powtarzać się będzie aż do znalezienia właściwego serwera końcowego.
Serwer lokalizacji przechowuje informacje dotyczące bieżącego położenia UA. Serwery rejestrowe przyjmują zgłoszenia rejestrowe UA, a serwery aplikacji realizują funkcje związane z konkretnymi usługami.

7.4.3. Adresacja

Format adresacji z której korzysta protokół SIP jest bardzo podobny do formatu stosowanego w poczcie elektronicznej e-mail. Adres składa się z nazwy użytkownika, którą może zastąpić numer telefoniczny z sieci PSTN, oraz z węzła sieci lub bramki, pełniących rolę serwera SIP. Przykładowe adresy użytkowników wyglądają następująco:

Adres wykorzystujący nazwę użytkownika:
sip:marcin.szczukiewicz@nazwa_hosta.pl

Adres uwzględniający plan numeracji E.164:
sip:[phone]@nazwa_hosta.pl

7.4.4. Żądania protokołu SIP

Żądania wysyłane przez klienta wywołują w serwerze określone funkcje. Żądania i odpowiedzi są tekstowe i zawierają nagłówki, przenoszące między innymi informacje dotyczące połączenia i usługi, na przykład identyfikatory nadawcy i odbiorcy. Zasada działania protokołu SIP jest podobna do zasady działania używanego powszechnie w Internecie protokołu HTTP (HyperText Transfer Protocol). W nagłówkach protokołu SIP istnieją takie same pola jak w protokole HTTP co ułatwia integrację protokołu SIP z serwerami WWW. Przykładowe żądania protokołu SIP oraz ich znaczenie przedstawiono poniżej.

• INVITE - służy do inicjacji połączenia i stanowi zaproszenie określonego użytkownika do sesji. W nagłówkach wiadomości zawarte są informacje o adresach użytkowników, temacie połączenia, priorytetach itp. Treść wiadomości zawiera opis sesji tzn. rodzaj mediów, które terminal wywołujący może obsłużyć, typy kodeków, zaimplementowane metody kompresji, protokoły itp. Za pośrednictwem tej wiadomości można także zmieniać parametry sesji w trakcie trwania połączenia.

• ACK - potwierdza, że agent użytkownika otrzymał odpowiedź na zaproszenie INVITE.

• OPTIONS - służy do uzyskiwania informacji o stanie użytkownika. Gdy jest on w stanie gotowości może odpowiedzieć wiadomością zawierającą obsługiwane przez niego media, protokoły itp. Gdy jest zajęty może odesłać odpowiedź zawierającą adres poczty elektronicznej lub głosowej.

• BYE - jest wysyłana przez agenta w celu opuszczenia, bądź likwidacji sesji. Adresat powinien zaprzestać wysyłania danych wyłącznie do użytkownika, który przysłał tę wiadomość, co pozwala rezygnować z uczestnictwa w sesji grupowej bez zrywania jej.

• REGISTER - informuje serwer o obecnej lokalizacji użytkownika.

Po otrzymaniu i zinterpretowaniu żądania agent wysyła odpowiedź, która oznajmia sukces lub niepowodzenie danej operacji albo wskazuje postęp w realizacji zadania.

7.4.5. Inicjowanie i przebieg sesji

Inicjowanie sesji wymaga określenia, gdzie i w jaki sposób adresat połączenia jest w danej chwili osiągalny. Niezbędna jest zatem realizacja funkcji dynamicznej lokalizacji użytkowników, którzy w danym momencie mogą korzystać z domowego lub biurowego komputera PC albo być osiągalnymi przez telefon IP.

Gdy adresat zostanie zlokalizowany, następuje faza przekazywania parametrów charakteryzujących ustanawianą sesję. SIP przekazuje informacje o protokole, który został wykorzystany do opisu sesji.
Po zlokalizowania adresata i przesłaniu informacji opisujących sesję, zwracana jest odpowiedź na zaproszenie. Może to być odpowiedź pozytywna lub negatywna. Pozytywna odpowiedź powoduje aktywację sesji. Trwająca sesja może być modyfikowana, poprzez dodawanie lub usuwanie strumieni audio i/lub wideo, zmianę sposobu kodowania, zawieszenie połączenia, itp. W celu zmiany parametrów należy ponownie zainicjować sesję za pomocą tej samej wiadomości SIP lecz z nowym opisem.
Wiadomość INVITE służąca do inicjowania sesji przekazuje także opis mediów, co pozwala na ich negocjowanie uwzględniające możliwości funkcjonalne terminali. SIP implementuje także mobilność użytkowników dzięki mechanizmom wyszukiwania i przekierowywania wiadomości, do bieżącej, wskazanej przez rejestrację (np. przez dołączenie się do sieci w danym miejscu), lokalizacji użytkownika.
Protokół SIP wspiera zatem następujące aspekty przy inicjowaniu i kończeniu sesji:

• Lokalizację użytkownika - ustalenie systemu końcowego użytego do komunikacji.

• Możliwości użytkownika - ustalenie użytego medium i jego parametrów.

• Osiągalność użytkownika - ustalenie gotowości wywoływanej strony do zaangażowania się w komunikację.

• Zestawienie wywołania ("dzwonienie") i ustalenie parametrów wywołania po stronie wywołującej i wywoływanej.

• Utrzymanie wywołania obejmujące przenoszenie i zakończenie wywołania.

7.4.6. Realizowanie sesji SIP przez Internet

Protokół SIP może współpracować prawie z każdym protokołem transportowym, zorientowanym połączeniowo lub datagramowym. Jedynym ograniczeniem jest konieczność dostarczania wiadomości SIP w całości. Jeśli sesja SIP jest realizowana przez Internet to można wysyłać wiadomości SIP korzystając z TCP a pakiety zawierające dane wrażliwe na opóźnienia korzystając z UDP.
Protokół SIP ma obiecującą możliwość dodawania uzupełnień, które mogą się okazać potrzebne wraz z rozwojem telefonii internetowej. Cecha ta jest bardzo przydatna w globalnym Internecie, gdzie brakuje kontroli nad procesem wprowadzania nowych rozwiązań.

Strona 10 z 12

---