Niełatwa droga do celu

SIP (Session Initiation Protocol) jest protokołem warstwy aplikacji, służącym do inicjowania, zrywania oraz zmiany sesji komunikacyjnych między terminalami (obecnie najczęściej -wykorzystywany do realizacji połączeń Voice over IP). Protokół został zaprojektowany przez Henninga Schulzrinne'a na Uniwersytecie Columbia, a jego standaryzacją zajęła się w sierpniu 1999 r. grupa MMUSIC (Multiparty Multimedia Session Control), działająca w ramach IETF. Pierwsza wersja zalecenia (o numerze 2.0) otrzymała nazwę RFC 2543. Dalsze rozszerzenia dotyczące samego protokołu zapisano w dokumencie RFC 3261, a w opracowaniu RFC3329 zawarto wytyczne odnośnie do sposobu negocjacji wyboru metod zabezpieczeń między punktami końcowymi terminali. Inżynierowie Internet Engineering Task Force wciąż rozwijają SIP, w czym chętnie pomagają wiodący dostawcy infrastruktury telekomunikacyjnej. Według prognoz ABI Research, w 2012 r. połowa klientów firm telekomunikacyjnych będzie korzystać przynajmniej z jednej usługi bazującej na protokole SIP.

Ci ostatni dostrzegli zalety SIP stosunkowo niedawno, zwiększona chęć wdrażania elementów sieci opartych na tym protokole zauważalna jest dopiero od dwóch, trzech lat. Dystans operatorów i firm w podchodzeniu do SIP miał swoje podłoże w silnej pozycji, jaką wypracował sobie jego główny konkurent - standard H.323. Pierwszą wersję H.323 przyjęto w 1996 r., protokół ten jest zatem obecny w telekomunikacji od 13 lat i zyskał opinię stabilnego, dopracowanego oraz wiarygodnego sposobu nawiązywania komunikacji sieciowej. Standard H.323 ma pewne atuty (np. dobra współpraca ze starszymi wersjami urządzeń klienckich, uproszczony i bardzo dokładny billing), ale z biegiem czasu zaczęto zauważać jego wady. Obecnie rynek telekomunikacji IP (VoIP, unified communications) obfituje w rozwiązania różnych producentów (bramki, telefony, terminale), co z jednej strony zwiększa konkurencyjność i pozwala obniżać ceny, ale z drugiej wnosi problem kompatybilności (z czym bardzo dobrze radzi sobie SIP, a czego nie można powiedzieć o H.323). W dobie szukania oszczędności w każdym obszarze nie bez znaczenia pozostaje fakt, że do obsługi H.323 (konwersja z innymi standardami, implementacja w firmie) potrzebni są doświadczeni programiści (stopień skomplikowania jest dość wysoki).

Zobacz również:

• Ruszyły testy satelitów Starlink działających w trybie „direct-to-cell”
• Z tych powodów wiadomości SMS powinny przejść na emeryturę

Wraz z wprowadzeniem SIP problemy z kompatybilnością i zarządzaniem samym protokołem zniwelowano w znacznym stopniu. Na tym nie kończą się jednak korzyści wynikające z jego wdrożenia. SIP został oparty na znanym protokole HTTP (HyperText Transfer Protocol), jest zatem łatwy w konfiguracji. Dzięki temu, iż jest to standard warstwy aplikacyjnej (połączenia, zdarzenia, sesje są zwykłymi aplikacjami) uproszczono architekturę komunikacji w całej firmie. Między innymi z tego powodu dodawanie kolejnych usług czy urządzeń również nie stanowi problemu.

Zaletą SIP jest także współpraca z innymi protokołami IETF w celu zestawienia np. większych sesji multimedialnych czy połączeń wideokonferencyjnych.

SIP może także współdziałać z kilkoma protokołami transportowymi, takimi jak TCP, UDP czy SCTP. Proste połączenia można z powodzeniem tworzyć za pomocą UDP, który jest szybki, wydajny i nie obciąża nadmiernie systemu. Aby zapewnić większą niezawodność i bezpieczeństwo, serwery powinny jednak wspierać również TCP. SCTP (Stream Control Transmission Protocol), zdefiniowany w 2000 r. przez IETF, jest bardzo podobny do protokołów TCP i UDP. Pozwala jednak dwóm stronom biorącym udział w połączeniu na wykorzystanie kilku adresów IP, dzięki czemu możliwy jest transport strumieni nawet wtedy, gdy jeden z adresów przestanie funkcjonować.

Krótkie know-how

Komunikacja w sieci SIP może odbywać się zarówno w najprostszym układzie peer-to-peer, jak i w architekturze klient-serwer. Ta ostatnia wymaga zdefiniowania kilku pojęć, które pomogą zrozumieć, w jaki sposób nawiązywane są sesje za pomocą SIP. Po stronie użytkownika wyróżniamy: agenta SIP (User Agent Client; UAC), czyli telefon IP lub aplikację na komputerze oraz urządzenie pośredniczące, które może działać jako klient i serwer (User Agent Server; UAS). Rolą UAS jest odpowiadanie na zapytania SIP wysyłane przez UAC.

Część typowo serwerowa jest nieco bardziej rozbudowana. Serwer przekierowań (redirect server) zwraca adres miejsca, do którego ma być przekazane połączenie (przekierowuje połączenia tych użytkowników, którzy zmienili swoje położenie geograficzne - dom, praca, podróż służbowa). Serwer Proxy kieruje połączeniami, odpowiada za ich routing, często występuje jako mediator między UAC i UAS, obsługując żądania i przekazując je dalej. Serwer rejestracji (registrar server) dokonuje odwzorowania nazw w domenie SIP na adresy sieciowe, aktualizuje je oraz przechowuje dane o użytkownikach.

Sposób komunikacji SIP między klientem a serwerem wprost wynika z architektury samego protokołu i jego podobieństwa do specyfiki żądań i odpowiedzi HTTP. Adresowanie zasobów sieciowych w SIP, co należy rozumieć, jako zidentyfikowanie np. użytkownika danej usługi, grupy użytkowników, konkretnej skrzynki pocztowej (e-mail), numeru telefonu w tradycyjnej sieci PSTN lub sieci IP, realizowane jest za pomocą identyfikatora URI (Uniform Resource Indicator). SIP URI jest ciągiem znaków ułożonych analogicznie do adresu e-mail (nazwa użytkownika@nazwa hosta).

Warto w tym miejscu zaznaczyć, że używany przez protokół HTTP identyfikator URL (Uniform Resource Locator) nie jest tożsamy z URI, mimo łudząco podobnych nazw. Oba terminy są obecnie używane wymiennie, co stanowi jednak duże uproszczenie. URL określa jedynie miejsce, w którym dany zasób jest dostępny, natomiast jego rodzaj określa URI. W pewnym sensie URI jest elementem nadrzędnym wobec URL - często jest tak, że URI jest tożsame z URL, ale nie musi być to regułą.

Aby zainicjować połączenie, agent UAC wysyła do najbliższego serwera SIP proxy komunikat "INVITE" z adresem odbiorcy połączenia. SIP proxy przeprowadza routing komunikatów SIP (lub SIP redirect od razu informuje klienta, żeby skontaktował się bezpośrednio z innym serwerem), by ustalić adres serwera obsługującego punkt docelowy. Poszukiwania adresata mogą być przeprowadzane zarówno poprzez serwery DNS, jak i ENUM, wiążące numery telefoniczne z adresami sieciowymi. W tym czasie informacje o próbie lokalizacji punktu docelowego połączenia, SIP proxy wysyła do agenta SIP, inicjującego żądanie (odpowiedzi z zakresu 1xx, np. 180 - "ringing", czy 181 - "call is being forwarded"). Docelowy SIP proxy po otrzymaniu zgłoszenia pobiera z serwera lokalizacji (registrar) dane użytkownika, a następnie kieruje do niego żądanie zestawienia sesji. Po pomyślnej wymianie komunikatów zestawiana jest sesja RTP bezpośrednio między dzwoniącym i adresatem.

Informacje o charakterze zestawianej sesji (głos, wideo, dane) są przekazywane za pomocą wspomnianego już protokołu SDP (Session Description Protocol) oraz SAP (Session Announcement Protocol). Wiadomości SDP określają, jakie możliwości muszą mieć terminale końcowe do poprawnego zrealizowania połączenia. Za pomocą SAP można natomiast poinformować większą liczbę użytkowników o otwieranej sesji (telekonferencje, wideokonferencje, telewizja internetowa itp.).

Druga część artykułu: SIP: bezpieczeństwo (2) - tutaj.

O SIP czytaj też tu.

SIP (cz. 2): bezpieczeństwo