Grzegorz Danilewicz Instytut Elektroniki i Telekomunikacji Politechnika Poznańska ul. Piotrowo 3a 60-965 Poznań 2005 Poznańskie Warsztaty Telekomunikacyjne Poznań 8-9 grudnia 2005 Damian Parniewicz Activis Polska sp. z o.o. Świerzawska 5 60-321 Poznań IMPLEMENTACJA PROTOKOŁU SIP Streszczenie: W artykule przedstawiono, przygotowane w ramach pracy dyplomowej magisterskiej realizowanej w Instytucie Elektroniki i Telekomunikacji Politechniki Poznańskiej, założenia projektowe do oprogramowania implementujacego protokół sygnalizacyjny SIP. Wnioski z pracy dyplomowej stanowiły punkt wyjścia dla zrealizowanego przez firmę Activis Polska sp. z o.o. z siedziba w Poznaniu, oprogramowania implementujacego protokół SIP w urza- dzeniach rodziny NETmaster produkowanych przez tę firmę. 1. WSTEP W Instytucie Elektroniki i Telekomunikacji Politechniki Poznańskiej prowadzone są prace dyplomowe inżynierskie i magisterskie, które mają charakter teoretyczny oraz praktyczny. Zakres tematyczny prac mających charakter praktyczny jest często ograniczony ze względu na ograniczone możliwości produkcyjne Instytutu. Stąd wynika duża ilość realizowanytch prac dyplomowych, które mają charakter teoretyczny. Jednakże prace teoretyczne prowadzone w Instytucie mogą być także użyteczne dla przemysłu teleinformatycznego. Przykładem takiej pracy magisterskiej jest praca mgr. inż. Damiana Parniewicza pt. Implementacja protokołu SIP w telefonie IP [1]. Zadaniem autora pracy było rozpoznanie możliwości samego protokołu SIP (ang. Session Initiation Protocol), a także wyciągnięcie wniosków z analizy założeń projektowych dotyczących implementacji protokołu SIP w urządzeniach sieciowych. Firma Activis Polska sp. z o.o. realizowała w latach 2004-2005 projekt celowy Komitetu Badań Naukowych nr 6.T11.2003C/06264, którego zadaniem było opracowanie nowego urządzenia multimedialnego. Składową urządzenia jest oprogramowanie sygnalizacyjne protokołu SIP. Doświadczenie mgr. inż. Damiana Parniewicza, zdobyte podczas realizacji pracy dyplomowej, zostało wykorzystane w ramach zespołu programistów zatrudnionych w firmie Activis Polska sp. z o.o. tworzących oprogramowanie urządzenia multimedialnego rodziny NETmaster. Urządzenia rodziny NETmaster umożliwiają realizację połączeń między liniami analogowymi oraz kanałami cyfrowymi z techniką TDM (ang. Time Division Multiplexing) zorganizowanymi w trakty PCM a siecią Ethernet. Dzięki implementacji protokołu SIP w urządzeniach NETmaster mogą one realizować połączenia multimedialne (w tym głosowe) między urządzeniami lokalnych sieci komputerowych a urządzeniami sieci telekomunikacyjnej (w tym telefonami analogowymi). Dalsza część artykułu zawiera w rozdziale 2 charakterystykę sieci pakietowych i techniki przesyłania głosu w sieciach korzystających z protokołu IP. Dodatkowo w rozdziale drugim przedstawiono funkcje protokołu sygnalizacyjnego SIP. W rozdziale 3 omówiono warstwową strukturę protokołu SIP oraz zasady implementowania funkcji poszczególnych warstw w realizowanym projekcie. W następnym rozdziale przedstawiono rezultaty testowania implementacji protokołu SIP w urządzeniach rodziny NETmaster a także zobrazowano wyniki działania oprogramowania. Na końcu artykułu umieszczono wnioski. 2. ŚRODOWISKO PRACY PROTOKOŁU SIP 2.1. TECHNIKA VoIP W ostatnim dziesięcioleciu XX wieku można było zaobserwować duże przeobrażenia w sieciach telekomunikacyjnych. Sieć telefoniczna, która pierwotnie była siecią analogową z komutacją łączy stała się siecią cyfrową z komutacją kanałów. W takiej sieci głos jest przesyłany przez synchroniczne kanały cyfrowe. W kanałach cyfrowych strumienie bitów są transmitowane ze stałą szybkością. Synchroniczne kanały cyfrowe zapewniają realizację usług izochronicznych (ang. isochronous services) z bardzo dobrą jakością obsługi. Dzięki temu można je wykorzystywać do transmisji w czasie rzeczywistym sygnałów mowy i obrazów ruchomych. W 1996 roku izraelska firma VocalTec po raz pierwszy uruchomiła system telefonii IP (ang. Internet Protocol). Od tego momentu można mówić o wykorzystaniu również sieci pakietowych (w tym sieci Internet) do obsługi usług izochronicznych. Sieci pakietowe są elastyczne, gdyż mogą być wykorzystywane w ekonomiczny sposób do przesyłania dowolnych danych, w tym także kodowanych cyfrowo sygnałów mowy i video. PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005 1/6
Stąd też, tradycyjni operatorzy rynku telekomunikacyjnego coraz chętniej korzystają z techniki VoIP (ang. Voice over Internet Protocol). W sieci korzystającej z techniki VoIP sygnał mowy jest w pierwszej kolejności kodowany do postaci cyfrowej i kompresowany, a następnie tworzone są niewielkie pakiety, które służą do przesyłania zakodowanych cyfrowo próbek sygnału mowy. Pakiety te są transmitowane przez sieć pakietową. Technika Vo- IP ma szereg zalet, takich jak niższe koszty użytkowania pakietowej sieci telefonicznej, dostępność infrastruktury sieciowej, łatwa możliwość integracji z innymi technikami transmisji danych oraz zwiększenie mobilności i dostępności pod tym samym numerem katalogowym. Równocześnie należy zwrócić uwagę na pewne wady techniki VoIP wynikające z zastosowania sieci pakietowej do obsługi usług izochronicznych. Jednym z głównych problemów techniki VoIP jest zapewnienie odpowiedniej jakości obsługi transmisji głosu. W sieci pakietowej należy obecnie realizować zadania, które nie były w niej wykonywane, gdy nie służyła ona do obsługi usług izochronicznych. Zadania te mają na celu zmniejszanie wrażliwości systemu na opóźnienia lub utratę pakietów z próbkami sygnału mowy oraz wykorzystanie kodeków zapewniających dobrą kompresję przy zachowaniu jak najwyższej jakości sygnału mowy. Innym ważnym problemem jest praca w środowiskach sieciowych, w których wykorzystuje się technikę translacji adresów NAT (ang. Network Address Translation). Problem z translacją adresów wynika z potrzeby określenia i przekazania między użytkownikami końcowymi adresów docelowych dla pakietów z próbkami sygnału mowy. Adresy te pozwalają na przesyłanie pakietów przez serwery NAT. Innym istotnym zagadnieniem, które pojawia się przy omawianiu wykorzystania techniki VoIP w sieci Internet jest bezpieczeństwo sieciowe. 2.2. PROTOKÓŁ SIP W technice VoIP można wyróżnić szereg interesujących, podstawowych zagadnień, które są ciągle rozważane i rozwijane. Są to kompresja sygnałów, transport, sygnalizacja oraz mechanizmy zapewniania jakości obsługi QoS (ang. Quality of Service). Zagadnienia sygnalizacji nie były rozważane w sieciach pakietowych dopóki nie pojawiła się koncepcja wykorzystania tego typu sieci do obsługi usług izochronicznych. Protokół inicjowania sesji SIP jest jednym z kilku protokołów sygnalizacyjnych rozważanych w technice VoIP. Służy on do tworzenia, modyfikacji i kończenia sesji multimedialnych. SIP ma w zamierzeniu realizować zestaw funkcji obsługi połączenia takich jakie są wykonywane w publicznej sieci telefonicznej. Stąd, wśród procedur protokołu SIP można odnaleźć funkcje, które realizują operacje znane z telefonii stacjonarnej, takie jak wybieranie numeru, przesyłanie sygnału dzwonienia, sygnałów tonowych itp. Jednakże implementacja funkcji i używana terminologia jest odmienna. SIP to protokół typu peer-to-peer. Wymaga on jedynie prostej (a przez to wysoce skalowalnej) sieci szkieletowej. Inteligencja sieci SIP jest rozproszona i jest realizowana w węzłach końcowych. Na rysunku 1 przedstawiono infra- Agent użytkownika rejestrujący pośredniczący przekierowań lokalizacji aplikacji lokalizacji Rysunek 1: Struktura sieciowa SIP pośredniczący Agent użytkownika rejestrujący strukturę sieciową SIP, która składa się z agentów użytkowników końcowych oraz różnego rodzaju serwerów. SIP podlega międzynarodowej normalizacji. Twórcą tego protokołu sygnalizacyjnego jest społeczność sieci Internet IETF (ang. Internet Engineering Task Force). Pierwsza zaproponowana wersja standardu (SIP 2.0) została zdefiniowana w zaleceniu RFC 2543 [2]. Protokół następnie uszczegółowiono w zaleceniu RFC 3261 [3]. Duża ilość implementacji bazuje także na wskazówkach z tymczasowych wersji próbnych (ang. draft). Mimo wielu zaleceń próbnych oficjalny numer ostatniej wersji protokołu SIP nadal jest równy 2.0. SIP jest podobny do protokołu HTTP (ang. HyperText Tranfer Protocol) i dzieli z nim wiele zasad konstrukcyjnych. Na przykład wiadomość protokołu SIP ma postać tekstową co umożliwia łatwość czytania i analizy wiadomości bezpośrednio przez człowieka. Wiadomość protokołu SIP jest zbudowana z różnego rodzaju nagłówków a do wymiany wiadomości używany jest prosty mechanizm żądanie-odpowiedź. Identyfikacja terminali końcowych odbywa się z wykorzystaniem adresów podobnych do adresów poczty elektronicznej e-mail: uzytkownik@domena:port, gdzie domyślnym numerem portu jest 5060. Na rysunku 2 przedstawiono w sposób schematyczny budowę zarówno wiadomości żądania jak i odpowiedzi protokołu SIP. Pole zawartości wypełnione jest informacją o żądanej charakterystyce połączenia zapisaną z wykorzystaniem protokołu SDP (ang. Session Description Protocol). Protokół SIP jest stosowany nie tylko w telefonii IP, ale również w konferencjach multimedialnych, komunikatorach internetowych i multimedialnych sesjach rozsiewczych. Pierwotna koncepcja protokołu SIP zakładała jego dużą prostotę. Obecnie złożoność tego rozwiązania jest porównywalna z innym, konkurencyjnym systemem sygnalizacji H.323. Mimo tego protokół SIP jest obecnie liderem wśród protokołów sygnalizacyjnych wykorzystywanych w technice VoIP. PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005 2/6
Żądanie Odpowiedź metoda url_żądania SIP/2.0 SIP/2.0 kod_statusu przyczyna Via: SIP/2.0 protokół host:port From: opis <sip:użytkownik@źródło> To: opis <sip:użytkownik@przeznaczenie> Call-ID: identyfikator@host Cseq: numer_sekwencji metoda Content-Length: długość_pola_zawartości Content-Type: application/sdp Linia startowa Nagłówki wiadomości CRLF v=0 o=użytkownik znacznik_czasu znacznik_czasu IN IP 4 host c=in IP 4 adres_przeznaczenia_dla_multimediów t=0 0 m=typ_medium port RTP/AVP typy_fomatów_mediów Pole zawartości Rysunek 2: Schematyczne przedstawienie żądania i odpowiedzi protokołu SIP 3. IMPLEMENTACJA PROTOKOŁU SIP Implementacja protokołu SIP odbywała się zgodnie z zaleceniami standaryzacyjnymi umieszczonymi w dokumentach RFC (ang. Request for Comments) organizacji IETF, a w szczególności w dokumentach [3], [4] i [5]. Budowa protokołu SIP jest opisana w [3] jako złożona z kilku warstw, z których każda warstwa opisuje niezależny etap przetwarzania wiadomości SIP. Najniższa warstwą protokołu jest warstwa składni i kodowania. Warstwa ta zawiera reguły składni nagłówków wiadomości SIP. Pojedynczy nagłówek ma często złożoną budowę i może zawierać wiele informacji. Warstwa ta wykonuje dwa rodzaje czynności: składa wiadomość tekstową SIP na podstawie dostarczonego zbioru informacji, które ma przenieść składana wiadomość lub odczytuje te informacje z przychodzącej z sieci wiadomości SIP. Drugą warstwą protokołu SIP jest warstwa transportu, która jest odpowiedzialna za wszystkie aspekty transportu wiadomości SIP przez sieć, a w szczególności decyduje o protokole transportowym i numerach portów komunikacyjnych, dba o dołączanie do wiadomości informacji o przebytych węzłach w sieci oraz znajduje obiekt warstwy wyższej, do którego należy przesłać odebraną wiadomość lub informację zwrotną o niepowodzeniu transportu wiadomości. Wszystkie zależności czasowe wymian wiadomości pomiędzy dwoma elementami SIP są opisane w warstwie transakcji, która jest odpowiedzialna z jednej strony za generowanie retransmisji wiadomości a z drugiej za filtrowanie docierających a zbędnych retransmisji. Warstwa transakcji zawiera obiekty transakcji. Każdy taki obiekt jest odpowiedzialny za pewną sekwencję wymian wiadomości i kontroluje on prawidłowość tej sekwencji. Najważniejszą i najwyższą warstwą protokołu SIP jest warstwa użytkownika transakcji. Jest to warstwa, która zawiera główną logikę działania protokołu. Tworzy ona nowe żądania lub też odpowiedzi na przychodzące żądania. Poszczególne elementy sieci SIP (agenci i serwery) są rozróżniane przez uruchomione oprogramowanie warstwy użytkownika transakcji. Wyżej wymienione warstwy często są zaimplementowane jako osobne procesy a styki między warstwami protokołu są odzwierciedlone w komunikacji między procesami. Procesy i komunikację między procesami zapewniają mechanizmy systemu operacyjnego. Komunikacja między procesami polega na umieszczaniu obiektu w kanale asynchronicznym przez jeden proces i oczekiwaniem na ten obiekt przez drugi proces. Ponieważ w protokole SIP informacje wymieniane między warstwami są bogate w treść, to obiekty reprezentujące te informacje posiadają duże rozmiary. Dodatkowo te same informacje są współdzielone przez kilka warstw. Powoduje to, że w komunikatach między procesami bardziej ekonomiczne jest operowanie wskaźnikami do tych obiektów. Taka implementacja wymiany obiektów wprowadza konieczność opracowania zarządzania tymi obiektami a zwłaszcza zajmowania i zwalniania pamięci przez te obiekty. Zarządzanie obiektami zrealizowane jest na zasadzie zliczania referencji do obiektu. Implementacja warstwy składni i kodowania składa się z implementacji elementarnych funkcji operujących na łańcuchach tekstowych oraz funkcji składających lub czytających nagłówki wiadomości. Praca tej warstwy wygląda następująco: wiadomość tekstowa przychodząca z sieci jest rozbijana na nagłówki składowe, które następnie są analizowane przez tą warstwę zgodnie z regułami składni danego nagłówka i wydobywane są z tego nagłówka interesujące informacje. Informacje te maja postać liczb lub ciągów znakowych. Ciągi znakowe nie są jednak przepisywane do obiektu z informacjami na temat wiadomości SIP a jedynie obiekt ten zawiera wskaźniki do miejsca położenia informacji w buforze z wiadomością tekstową. Bufor staje się składową obiektu informacji o wiadomości SIP i zostaje wyczyszczony, gdy wiadomość jest już przetworzona. Warstwa składni i kodowania dostaje zlecenie stworzenia nowej wiadomości tekstowej od warstwy PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005 3/6
transportu. Zlecenie to zawiera obiekt informacji wiadomości SIP, który jest przetwarzany przez tą warstwę do postaci tekstowej. Wiadomość w postaci tekstowej jest następnie wysyłana w sieć. Implementacja warstwy transportu jest w miarę prosta, gdyż warstwa analizuje tylko kilka podstawowych nagłówków wiadomości SIP i modyfikuje jeden typ nagłówka (nagłówek Via). Najbardziej skomplikowaną czynnością wykonywaną przez tą warstwę jest odnalezienie odpowiedniego obiektu warstwy transakcji, do którego należy przesłać odebraną z sieci wiadomość. Warstwa transakcji jest zaimplementowana jako zbiór automatów stanów, z których każdy ma 4 możliwe stany. Zmiany stanów są powodowane przychodzącymi wiadomościami lub zdarzeniami generowanymi przez zegary temporyzacji. Użycie odpowiedniego automatu jest uzależnione od rodzaju żądania tworzącego obiekt transakcji. W warstwie transakcji może naraz działać wiele obiektów transakcji, mogą się one dynamicznie pojawiać i znikać. Wszystkie obiekty transakcji muszą być jednak obsługiwane przez jeden proces, gdyż w systemie operacyjnym nie ma możliwości dynamicznego tworzenia procesów (ani wątków). Multipleksacja wielu obiektów transakcji w jednym procesie jest uzyskana przez umieszczenie wszystkich zdarzeń dla obiektów transakcji w jednym kanale asynchronicznym, odczycie jednego zdarzenia naraz i uaktywnianiu obiektu transakcji, dla którego przeznaczone jest zdarzenie. Implementacja warstwy użytkownika transakcji jest najbardziej złożoną częścią całego projektu. W tej warstwie występuje najwięcej różnorodnych i rozbudowanych funkcji. Funkcje te można podzielić na operacje warstwy użytkownika transakcji, funkcje związane z obiektami składowymi tej warstwy oraz funkcje generalnego zachowania się elementu SIP. Operacje związane są z analizą przychodzących wiadomości lub generowaniem nowych wiadomości. W czasie wykonywania operacji powstają, są modyfikowane lub są niszczone obiekty dialogu i sesji, które odzwierciedlają dialog czyli nawiązanie połączenia i sesję jako nawiązanie sesji multimedialnej. Każdy z tych obiektów ma swój własny zbiór funkcji. Funkcje opisujące generalne zachowanie się elementu SIP (w przypadku tej implementacji agenta użytkownika) mają zwykle na celu tworzenie zrębów żądań i odpowiedzi oraz reakcje na niepoprawne wiadomości lub sytuacje szczególne. Wszystkie te funkcje są tak projektowane, żeby zapewnić wielokrotne używanie kodu oprogramowania. W realizowanym przez firmę Activis Polska sp. z o.o. oprogramowaniu opisane powyżej procesy i komunikacja pomiędzy procesami była zapewniona przez system BOSS dedykowany system operacyjny urządzeń ZTA. System BOSS jest systemem czasu rzeczywistego, który umożliwia statyczne tworzenie procesów o różnych priorytetach. Każdy proces ma ustalony limit czasu przydziału procesora. Zwolnienie procesora przez proces w dużej mierze należy do odpowiedzialności programisty piszącego dany proces. Proces, który zbyt długo jest aktywny, jest uznawany przez system za działający niepoprawnie i jest zawieszany. Asynchroniczne kanały komunikacyjne pomiędzy procesami są zaimplementowane w systemie BOSS jako mechanizm skrzynek. Wyróżniane są dwa rodzaje skrzynek: skrzynki domowe i skrzynki zleceniowe. Proces wysyłający komunikat pobiera obiekt komunikatu ze skrzynki domowej, odpowiednio ustawia pola pobranego obiektu i wysyła go do skrzynki zleceniowej. Przy skrzynce zleceniowej proces obierający komunikat zatrzymuje się i oczekuje na pojawienie się obiektu wiadomości w skrzynce. Jeżeli obiekt zostanie odebrany ze skrzynki zleceniowej, to proces odbierający musi po zakończeniu analizy komunikatu odesłać go z powrotem do skrzynki domowej tego obiektu komunikatu. System BOSS nie udostępnia mechanizmów dynamicznej alokacji pamięci, co często powoduje konieczność pisania własnych zarządców pamięci. Programista przy tym musi bardzo uważać, gdyż ma dostęp do całej pamięci, więc istnieje zawsze groźba, że przy używaniu wskaźników nastąpi nadpisanie danych innych procesów. Niestety system BOSS nie posiada bogatego oprogramowania bibliotecznego, takiego jak w przypadku systemów UNIX czy Windows. W przypadku implementacji protokołu SIP starano się przenosić standardowe biblioteki na system BOSS, ale często, w przypadku bardziej skomplikowanych narzędzi, z powodu braku dynamicznie alokowanej pamięci, było to niemożliwe i należało samemu zaimplementować analogiczną bibliotekę. Z tego samego powodu nie można było wykorzystać narzędzi takich jak Bison i Flex, służących do łatwego generowania parserów. Obecnie stworzona funkcjonalność stosu SIP obejmuje nawiązywanie połączeń, rezygnację z nawiązywanego połączenia, uzgadnianie mediów, zmianę mediów w czasie trwania połączenia, zmianę urządzeń końcowych w czasie połączenia, kończenie połączenia, obsługę wielu użytkowników, tryb połączeń bezpośrednich, tryb połączeń z wykorzystaniem serwerów pośredniczących, rejestrację w serwerze rejestracji oraz wykonywanie połączeń przez NAT. W najbliższym czasie projekt ma wejść w fazę produkcyjną. 4. TESTOWANIE IMPLEMENTACJI Testowanie jest jedną z najważniejszych czynności w projekcie implementacyjnym, dlatego też starano się wykonywać testy po każdym etapie prac. Zaliczenie testów pozwalało na skupienie się na nowych rzeczach w kolejnych stadiach projektu. Testowanie odbywało się w sposób przyrostowy. Każdy nowo ukończony moduł oprogramowania, jeżeli było to możliwe, był testowany z resztą już przetestowanego oprogramowania. Pozwalało to wykrywać błędy nie tylko w nowych fragmentach oprogramowania, ale także we wcześniej napisanych i przetestowanych modułach. Wynikało to zarówno z niepełnych, wcześniej realizowanych testów jak też z poszerzania się wiedzy programistów na temat protokołu SIP. W takiej sytuacji występowała konieczność modyfikacji lub uzupełniania istniejącego już oprogramowania i jego ponownego testowania. Testowanie warstwy składni i kodowania polegało głównie na oddzielnym testowaniu funkcji parsujących i składających każdy z używanych typów nagłówków. PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005 4/6
Testowanie funkcji parsujących polegało na dostarczaniu przykładowych postaci tych nagłówków i sprawdzaniu czy wszystkie informacje umieszczone w nagłówku wiadomości SIP znajdują się w strukturze informacyjnej zwracanej przez funkcję. Testowanie funkcji składających nagłówek przebiegało odwrotnie. Z tego powodu najczęstszym i najprostszym testem było dostarczenie do funkcji parsującej tekstu nagłówka a następnie zwróceniu struktury informacyjnej przez funkcję parsującą, która to struktura była następnie parametrem wejściowym funkcji generującej nagłówek. Jeżeli wejście takiego testu było różne od wyjścia testu, to rozpoczynało się szczegółowe poszukiwanie błędu przy użyciu debuggera. Faza testowania kończyła się testowaniem parsowania i generowania całych wiadomości SIP. Testowanie warstwy transakcji polegało na testowaniu każdego automatu stanów z osobna przez symulację nadchodzenia kolejnych zdarzeń do automatu i sprawdzaniu reakcji automatu na zdarzenia. Sprawdzana była poprawność przejścia do nowego stanu i odpowiednia praca zegarów temporyzacji. Testy te należały do trudniejszych w realizacji niż testy funkcji parsowania i składania wiadomości. Testy warstwy transakcji zostały uzupełnione w czasie pisania następnej warstwy oprogramowania, kiedy łatwiej było obserwować błędne działanie tej warstwy. Testy warstwy użytkownika transakcji były najbardziej złożonymi testami w całym projekcie. Zwykle testy te przebiegały jako testy działania całej stworzonej implementacji. Na początku testowano funkcje generujące żądania i obserwowano czy urządzenie wysyła w sieć odpowiednio zbudowaną ramkę. Później użyto specjalnego testera ruchu komunikatów SIPp [6]. Oprogramowanie SIPp symulowało działanie agenta użytkownika i wymieniało określone sekwencje komunikatów ze stworzoną implementacją protokołu SIP sprawdzając jednocześnie poprawność komunikacji. Oprogramowanie SIPp pozwalało na prowadzenie testów obciążenia i w konsekwencji usunięcie z projektu błędów prowadzących do wyczerpania zasobów. Następnym etapem testów było użycie aplikacji, będących prawdziwymi agentami protokołu SIP. Programami tymi były przede wszystkim X-Lite firmy Xten [7] oraz firefly firmy Freshtel [7]. Po testach zgodności z aplikacjami typu softphone w dalszym działaniu była rozwijana i następnie testowana współpraca stworzonego agenta użytkownika z aplikacjami serwerów SIP, w tym przypadku SIP Express Router (SER) [9] a później Asterisk PBX [10]. Implementacja była także testowana na współpracę z telefonami IP takimi jak Avaya 4602 IP Telephone czy Cisco IP 7905G. Najbardziej wymagające pod względem poprawności implementacji protokołu okazały się telefony firmy Cisco. Postępy prac były sprawdzane dwukrotnie w ramach projektu KBN w Instytucie Łączności w Warszawie. Sprawdzenie to pozwoliło przetestować implementację w większych, bardziej złożonych sieciach i sprawdzić poprawność komunikacji z nowymi urządzeniami. Wyniki testów wskazywały niepoprawność działania implementacji w niektórych sytuacjach. Dzięki temu możliwe było wyeliminowanie błędów oraz zaplanowanie następnych ZTA INVITE 100 Trying SER 180 Ringing 200 OK ACK INVITE 100 Trying 180 Ringing 200 OK Sesja multimedialna BYE 200 OK Telefon Cisco Rysunek 3: Wymiana wiadomości pomiędzy urządzeniami ZTA, SER i Cisco etapów prac nad oprogramowaniem. 5. PRZYKŁAD DZIAŁANIA IMPLEMENTACJI Na rysunku 3 przedstawiono przykład wymiany wiadomości sygnalizacyjnych SIP przy współpracy omawianej implementacji z telefonem IP firmy Cisco przez serwer SER. Na wykresie przedstawiono wymianę wiadomości w fazie zestawiania i rozłączania połączenia. Kodowanie i testowanie implemetacji doprowadziły do powstania w pełni funkcjonalnego urządzenia, które zapewnia obsługę połączeń i współpracę z urządzeniami innych producentów. Na rysunku 4 umieszczono przykład wiadomości sygnalizacji SIP INVITE, która jest obsługiwana przez omawianą w artykule implementację SIP. 6. PODSUMOWANIE Implementacja protokołu SIP zrealizowana w ramach pracy dyplomowej magisterskiej stanowi przykład udanej współpracy między Instytutem Elektroniki i Telekomunikacji Politechniki Poznańskiej a przemysłem teleinformatycznym obecnym w Poznaniu. Prace projektowe i wykonawcze były realizowane z wykorzystaniem wiedzy przekazywanej w czasie studiów, w tym głównie w ramach przedmiotu Oprogramowanie dla telekomunikacji. Funkcje realizowane przez przedstawione oprogramowanie są dalej rozszerzane tak aby spełniać wymagania coraz to nowych zaleceń dotyczących sygnalizacji SIP. Jednakże warto zaznaczyć, że przedstawiona implementacja jest w pełni funkcjonalna i może obsługiwać podstawowe i najczęściej realizowane zadania w czasie zestawiania, rozłączania i nadzoru nad połączeniami multimedialnymi. Dzięki temu oprogramowaniu urządzenia produkowane przez firmę Activis Polska sp. z o.o. mogą sprawnie współpracować z urządzeniami innych producentów. Autorzy wyrażają nadzieję, że prezentowana w artykule, zakończona powodzeniem, implementacja protokołu SIP będzie stanowić zachętę dla innych firm teleinformatycznych do współpracy z pracownikami Instytutu i studentami kierunku Elektronika i Telekomunikacja Politechniki Poznańskiej. PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005 5/6
Żądanie INVITE od urządzenia ZTA do serwera SER INVITE sip:5000@192.168.0.81 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.197:5060; branch=z9hg4bkdnud22zrpk From: <sip:12345@192.168.0.81>; tag=gum1qritt3 To: <sip:5000@192.168.0.81> Call-ID: lp3vk0hmhgcby8g@192.168.0.197 CSeq: 218029 INVITE User-Agent: NETmaster ZTA SIP v1.0 Contact: <sip:12345@192.168.0.197:5060> Max-Forwards: 70 Content-Type: application/sdp Content-Length: 133 Allow: INVITE,ACK,BYE,CANCEL,INFO v=0 o=omeen 230078 230078 IN IP4 192.168.0.197 s=c=in IP4 192.168.0.197 t=0 0 m=audio 7000 RTP/AVP 18 a=rtpmap:18 G729/8000 Rysunek 4: Postać wiadomości INVITE protokołu SIP obsługiwanej przez implementację SPIS LITERATURY [1] Parniewicz D. Implementacja protokołu SIP w telefonie IP. Praca dyplomowa magisterska, Instytut Elektoniki i Telekomunikacji, Politechnika Poznańska, 2005. [2] Handley M., Schulzrinne H., Schooler E., Rosenberg J. SIP: Session Initiation Protocol. RFC 2543, Marzec 1999. [3] Rosenberg J., Schulzrinne H., Camarillo G., Johnston A., Peterson J., Sparks R., Handley M., Schooler E. SIP: Session Initiation Protocol. RFC 3261, Kwiecień 2002. [4] Handley M., Jacobson. V. SDP: Session Description Protocol. RFC 2327, Kwiecień 1998. [5] Rosenberg J., Schulzrinne H. An Extension to the Session Initiation Protocol for Symmetric Response Routing. RFC 3581, Listopad 2003. [6] Strona WWW projektu SIPp. http://sipp.sourceforge.net [7] Strona WWW firmy Xten Networks. http://www.xten.com [8] Strona WWW firmy Freshtel. http://www.freshtel.net [9] Strona WWW projektu SER. http://www.iptel.org/ser [10] Strona WWW projektu Asterisk. http://www.asterisk.org PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005 6/6