4. ročník 25. 5. 2006 ČVUT FEL Semestrální práce 37MK Session Initiation Protocol
OBSAH 1.... 2 1.1. Historie a vývoj... 2 1.2. Charakteristika protokolu... 2 1.3. Prvky SIP architektury... 2 1.4. SIP Zprávy... 3 1.4.1. Metody (requests)... 3 1.4.2. Odpovědi (responses)... 3 2. Vertical Handover... 4 3. Závěrečné zhodnocení... 6 4. Seznam použité literatury...7-1-
1. 1.1. Historie a vývoj (Session Initiation Protocol) vyvíjela od roku 1996 pracovní skupina MMUSIC (Multiparty Multimedia Sesion Control) v rámci IETF (Internet Engineering Task Force). V roce 1999 byl předložen jako navrhovaný standard v RFC 2543. Ve stejném roce vznikla pracovní skupina s názvem SIP, která další vývoj převzala. V červnu r. 2002 byl vydán nový standard pro SIP: RFC 3261, který rozšířil původní protokol a zlepšil jeho rozšiřitelnost a bezpečnost. Tento dokument RFC 3261 obsahuje pouze jádro protokolu SIP. Další doporučení týkající se protokolu SIP: RFC 3261 - SIP: Session Initiation Protocol RFC 3262 - Reliability of Provisional Responses in Session Initiation Protocol (SIP) RFC 3263 - Session Initiation Protocol (SIP): Locating SIP Servers RFC 3264 - An Offer/Answer Model with Session Description Protocol (SDP) RFC 3265 - Session Initiation Protocol (SIP)-Specific Event Notification V roce 2000, 3GPP (3rd Generation Partnership Project) zvolil protokol SIP jako základ pro další vývoj v mobilní telefonii, což považuji za velmi významný krok pro následující rozvoj tohoto protokolu. 1.2. Charakteristika protokolu SIP je textově orientovaný signalizační protokol a svojí filozofií je velmi podobný protokolu HTTP (HyperText Transport Protocol), který slouží k sestavení, modifikaci a ukončení spojení s jedním nebo více účastníky. Umí pracovat jak nad UDP tak i TCP protokolem a nejčastěji je využíván pro IP telefonii, třebaže je zaměřen obecně a lze ho použít i např. pro videokonferenci nebo zasílání zpráv (Instant Messaging). Neprovádí však management spojení po jejich navázání a neumí zajistit požadovanou QoS (Quality of Service), protože neumí upřednostňovat nějaký určitý provoz ani rezervovat potřebné síťové prostředky. Spolupracuje však s protokoly, které se o zajištění potřebné QoS dokáží postarat. SIP také využívá protokol SDP pro popis vlastností účastníků spojení, který je pak použit k vyjednání parametrů spojení mezi účastníky (např. vyjednání kodeků). O tomto pro SIP velice důležitém protokolu se ještě zmíním později. 1.3. Prvky SIP architektury SIP architektura se skládá z pěti základních součástí. Každá entita má své specifické funkce a podílí se na SIP komunikaci jako client (tvoří a posílá požadavky - requests) nebo jako server (zasílá odpovědi responses na požadavky). Jedno fyzické zařízení může plnit více funkcí. Základní prvky SIP: User Agents - UA jsou koncovými zařízeními SIP sítě. Starají se o navazování spojení s ostatními UA. Nejčastěji jsou to SIP telefony (na HW nebo SW platformě) a brány do jiných sítí. Proxy server přijme žádost o spojení od UA nebo od jiného proxy serveru a předá ji dalšímu proxy serveru (pokud volanou stanici nemá ve své správě) nebo přímo volanému UA, pokud je tento v rámci spravované domény. Jeho funkcí je tedy jakési směrování požadavků do dalších sítí. -2-
Redirect server - stejně jako proxy přijímá žádosti o spojení od UA nebo proxy serverů, ale nepřeposílá je dále ve směru volaného. Posílá zpět informaci v odpovědi zařazené do třídy 3xx, komu má UA žádost poslat, aby se dostala k požadovanému cíli. Back to Back User Agent (B2BUA). Ta může plnit funkci UAS i UAC. Back to Back User Agent má za úkol zpřístupnit uživatelům služby, jako např. přepojování hovorů. B2BUA plní funkci proxy serveru a zároveň představuje koncový bod pro signalizaci. Na rozdíl od proxy může B2BUA vytvářet spojení a zasahovat do zasílaných zpráv a při komunikaci mezi koncovými účastníky. 1.4. SIP Zprávy Jak jsem již zmínil v úvodu, SIP je textově orientovaný protokol a využívá znakovou sadu UTF-8 (RFC 2279). SIP rozlišuje dva druhy zpráv: požadavek (request) od klienta serveru, který je posílány pomocí tzv. metod odpověď (response), kterou server reaguje na požadavek 1.4.1. Metody (requests) Mezi základních šest metod patří: INVITE slouží k žádosti o sestavení spojení nebo ke změně parametrů spojení ACK zpráva potvrzuje přijetí odpovědi na žádost INVITE Sestavení relace používá 3-way hand-shaking, kdy volaný periodicky opakuje odpověď (OK), dokud nepřijme ACK BYE je užívána pro ukončení spojení některou z komunikujících stran CANCEL slouží ke zrušení sestavovaného spojení, když volající ještě nepotvrdil žádost INVITE a volající chce zrušit sestavení REGISTER je žádost sdělující aktuální polohu uživatele. V této zprávě je přenášena informace o aktuální IP adrese a portu, na kterém může být uživatel zastižen. Tyto registrace jsou časově limitovány a potřebují periodicky obnovovat OPTIONS dotaz na možnosti a schopnosti serveru Další rozšiřující metody jsou pak předmětem samostatných RFC. 1.4.2. Odpovědi (responses) Každá žádost musí být zodpovězena, kromě žádosti ACK. Odpovědi na SIP metody jsou uvedené číselným kódem. To je celé číslo z rozsahu 100 až 699 a označuje typ odpovědi. Systém kódů je převzat z HTTP protokolu. Rozlišujeme šest tříd odpovědí. třídy: 1xx jsou informativní odpovědi, které jsou odeslány na žádosti, které již byly přijaty, ale výsledek zpracování není ještě znám.informační zprávy 2xx jsou pozitivní finální odpovědi. Je to poslední odpověď, kterou odesílatel na svou žádost dostává. Vyjadřují výsledek zpracování konkrétní 3xx přesměrování tyto odpovědi dávají informaci o nové poloze uživatele nebo alternativní službě, která má být konečná. Odpovědi 3xx jsou konečné. -3-
4xx chyba. Odpovědi řady 4xx jsou negativní konečné odpovědi a znamenají problém na straně odesílatele. Žádost nemohla být zpracována, protože obsahuje chybnou syntaxi 5xx chyba na straně serveru. Žádost je v pořádku, ale server selhal při zpracování a klient by měl požadavek zkusit znovu 6xx tento kód je vysílán, pokud žádost nemůže být splněna na žádném serveru příklady kódů odpovědí: číslo význam 100 Trying zkouší navázat spojení obvykle vysílají proxy servery, když zpracovávají požadavek INVITE 180 Ringing většinou odesílají UA, které oznamují vyzvánění volaného 200 OK úspěšné ukončení žádosti 300 Multiple choices vícenásobný výběr 301 Moved permanently 302 Moved temporarily dotaz je třeba směrovat jinam 400 Bad request špatný požadavek 401 Unauthorized - neautorizovaný 403 Forbidden zakázaný 408 Request time-out vypršel čas požadavku 480 Temporarily unavailable dočasně nedostupný 481 Call/Transaction does not exist hovor/spojení neexistuje 500 Server Internal Error interní chyba serveru 501 Not Implemented neimplementováno 600 Busy everywhere všude obsazen 603 Decline UA vysílá tuto odpověď, když odmítá žádost o sestavení spojení 604 Does not exist anywhere dotazovaný nikde neexistuje 606 Not acceptable nepřijatelný požadavek 2. Vertical Handover Jako handover se označuje předání hovoru. Je to proces, který probíhá, když si pohybující se mobilní telefon předávají dvě základnové stanice mezi sebou, tedy při přechodu z jedné buňky do druhé. Vertikální handover spočívá v handoveru mezi různými technologiemi používaných v mobilních komunikacích. Jedná se např. o handover mezi sítěmi UMTS a GPRS nebo GSM (generacemi sítí proto název vertikální ). Nabízí se mnoho způsobů, které mohou vyvolat vertikální handover. V ideálním případě by měl uživatel zůstat připojen k jeho současné síti. Nutný handover může být způsoben např. nízkou kvalitou signálu z důvodů pohybu uživatele mimo pokrytí signálu buňkou nebo zahlcením buňky velkým počtem uživatelů. Při pohybu mobilní stanice je stále monitorována přijímaná úroveň signálu a při poklesu na uživatelem definovanou úroveň je tato informace postoupena vyšším vrstvám OSI modelu a je vyvolán požadovaný handover. Plánovaný handover u tohoto typu handoveru je předem dáno, že dojde k handoveru a použitím určitých postupů nemusí dojít k velké ztrátě přenášených paketů a tedy komunikace je téměř bez přerušení. Plánovaný handover může být vyvolán uživatelem nebo terminálem. V prvním případě -4-
uživatel požaduje změnu dosavadní relace, protože současné možnosti sítě jsou nevyhovující. Např. pokud je uživatel součástí audio konference a chtěl by přepnout na video konferenci a je připojen do sítě GPRS s nízkou datovou propustností. Může tedy vyžádat přepojení do jiné dostupné a vyhovující síti. Neplánovaný handover může nastat např. již zmíněným zahlcením buňky větším počtem uživatelů nebo náhlým výpadkem signálu. Postup obnovení spojení zobrazuje následující obrázek a jeho popis. Uživatel A je ve spojení s uživatelem B na vyšší přenosové rychlosti. Ztráta signálu uživatele A je detekována na fyzické a následně předána spojové vrstvě terminálu. SIP User Agent (SUA) je informován o novém stavu sítě a spustí proces, kde dojde k detekci nových sítí na dostupných rozhraních terminálu. Nové připojení je vybráno z dostupných sítí dle potřeb a preferencí uživatele. Následně je poslán požadavek na registraci entitě Home Agent a uživatel A dostane přiřazenu tzv. dočasnou adresu (COA Care of address). Po úspěšné registraci je pomocí SIP sestaveno nové spojení se stejným call-id. Oba uživatelé pak sestaví novou relaci, spustí příslušné aplikace a zahájí přenos s nově dohodnutými parametry (kodeky,.) -5-
3. Závěrečné zhodnocení Session Initiation Protocol (SIP) se od svého vzniku v r. 1996 neustále vyvíjí. Řada vývojářů při implementaci toho protokolu do svých projektů nejen že respektují pravidla dána RFC 3261-3265, ale vytvářejí stále nové funkce. SIP je velice oblíbený pro svoji textovou povahu, vysokou flexibilitu, mobilitu a především jednoduchost. Potřebuje jen malý počet zpráv a navíc díky tomu, že umožňuje aplikacím nezávislost na síťové vrstvě, může pracovat nad různými typy sítí. Uživatele lze v síti lokalizovat a komunikovat s nimi bez ohledu na konkrétní koncová zařízení, která právě používají. Neumí však zajistit požadovanou kvalitu služby (QoS), protože neumí upřednostňovat nějaký provoz ani rezervovat potřebné síťové prostředky, ale může spolupracovat s protokoly, které se o zajištění QoS mohou postarat (např. RSVP - ReSerVation Protocol). Není také určený k přenosu velkého objemu dat. V současnosti je tento protokol především využíván pro IP telefonii, lze ho ale stejně tak použít pro videokonferenci nebo službu zasílání zpráv (instant messaging). -6-
4. Seznam použité literatury [1] RFC 3261 - SIP: Session Initiation Protocol [2] Sinnreich, H.: Internet communications using SIP : delivering VoIP and multimedia services with session initiation protocol. New York:Wiley, 2001 [3] Jian-Gou Ma:Third Generation Communication Systems. Berlin, 2005 [4] www.sipcenter.com [5] www.sipforum.org -7-