SIP

V současnosti existuje několik signalizačních protokolů. Kromě několika firemních řešení jsou používány protokoly MGCP (Media Gateway Control Protocol), H.323 a SIP (Session Initiation Protocol). Dvěma hlavními standartizovanými protokoly na scéně signalizace jsou protokoly H.323 a SIP.

Protokol H.323 vznikl a je podporován organizací ITU-T a proto je svým provedením bližší telefonním standardům. Jde o poměrně složitou a strukturu celé rodiny protokolů řešících jednotlivé signalizační úlohy. Protokoly používají binární zápis, což ztěžuje proces ladění. Rovněž rozšiřitelnost je poměrně složitá. Teprve ve třetí verzi byla implementována podpora transportního protokolu UDP. Donedávna byl protokol H.323 rozšířenější než protokol SIP, ale situace se, zdá se, obrací.

Protokol SIP vznikl pod křídly organizace IETF (Internet Engineering Task Force). Jde o textový protokol strukturou podobný například poštovnímu protokolu SMTP (Simple Mail Transfer Protocol) nebo protokolu HTTP (HyperText Transport Protocol). Tělo zprávy je tvořeno textovými položkami ve formě <název>:<hodnota>, které popisují předávané informace. Textová podstata protokolu napomáhá nejen jednoduchému ladění, ale především snadné rozšiřitelnosti.

Protokol SIP je typu klient-server, takže komunikace probíhá výměnou dvou typů zpráv, požadavků a odpovědí. Klient i server jsou logickou částí jednoho prvku. Pokud je dále v textu zmiňován termín klient, je tím míněn telefon nebo softwarová aplikace u uživatele a pojmem server jsou označovány aplikační servery služby, které poskytují klientům další služby jako registrace, lokalizace, zpoplatňování atd. Protokol SIP lze použít i pro další účely například síťové hry, instant messaging a další.

Příklad SIP zprávy INVITE

INVITE sip:mamut@iptel.org SIP/2.0.
Max-Forwards: 10.
Record-Route: <sip:195.113.222.3;ftag=5DAA94E7;lr=on>.
Via: SIP/2.0/UDP 195.113.222.3;branch=z9hG4bK0a5d.90580ee2.0.
Via: SIP/2.0/UDP 195.113.134.233:5062;branch=z9hG4bK2E1FD348.
CSeq: 262 INVITE.
To: <sip:mamut@iptel.org>.
Proxy-Authorization: Digest username="bbb", realm="ces.net", nonce="43788e90381194d66364fced4dc7097828391e81", uri="sip:mamut@iptel.org", cnonce="abcdefghi", nc=00000001, response="ed4adec8Content-Type: application/sdp.
From: "Franta Vomacka" <sip:bbb@ces.net>;tag=5DAA94E7.
Call-ID: 379332994@195.113.134.233.
Subject: sip:bbb@ces.net.
Content-Length: 234.
User-Agent: kphone/4.2.
Contact: "Franta Vomacka" <sip:bbb@195.113.134.233:5062;transport=udp>.
P-hint: outbound.
Remote-Party-ID: "Franta Vomacka" <sip:950070101@ces.net>;party=calling;id-type=subscriber;privacy=off; screen=yes.
.
v=0.
o=username 0 0 IN IP4 195.113.134.233.
s=The Funky Flow.
c=IN IP4 195.113.134.233.
t=0 0.
m=audio 33728 RTP/AVP 0 97 8 3.
a=rtpmap:0 PCMU/8000.
a=rtpmap:3 GSM/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:97 iLBC/8000.
a=fmtp:97 mode=30.

Typy požadavků

První položka požadavku obsahuje jeho typ, označovaný jako metoda, označení klienta nebo serveru, kterému je požadavek adresován (Request-URI) a verzi protokolu. Důležité jsou následující požadavky:

  • INVITE: Metoda INVITE slouží k přizvání uživatele nebo služby k podílení se na relaci. Tělo zprávy obsahuje popis relace (spojení).
  • ACK: Metoda ACK potvrzuje, že klient v pořádku přijal odpověď na INVITE dotaz.
  • BYE: Klient používá metodu BYE k oznámení protistraně, že hodlá ukončit hovor. Metoda BYE může být vyslána jak volaným tak volajícím.
  • CANCEL: Metoda CANCEL ukončuje nevyřízený požadavek se stejnou identifikací, tedy položkami Call-ID, To, From a pořadovým číslem požadavku Cseq. Vyřízené požadavky již metoda CANCEL neovlivní (požadavek je vyřízen pokud byla odeslána konečná odpověď, např. 200 OK).
  • REGISTER: Metoda REGISTER je používána k registraci současné adresy klienta u SIP serveru, který jí předá lokalizační službě.


Typy odpovědí

Odpovědi se dělí do uvedených kategorií podle kódu odpovědi na:

  • 1xx: Prozatímní odpovědi jako požadavek přijat, vyzvání
  • 2xx: Úspěch. Požadavek je přijat, pochopen a akceptován
  • 3xx: Přesměrování. Je třeba vytvořit nový upravený požadavek.
  • 4xx: Chyba klienta. Špatná syntaxe požadavku, nebo požadavek nemůže být proveden
  • 5xx: Chyba serveru. Server není schopen provést platný požadavek
  • 6xx: Globální chyba. Požadavek nelze provést na žádném serveru

Odpovědi s kódem 200 a výše jsou konečné, jejich přijetí ukončuje transakci.

Důležité hlavičky SIP

Níže uvedené položky jsou tím podstatným výběrem z mnoha možných hlaviček

  • To: Adresa volaného
  • From: Adresa volajícího klienta
  • Via: Adresa klienta, který vysílá požadavek nebo adresa serverů přes něž požadavek prošel a kudy se bude vracet odpověď
  • Call-Id: Unikátní identifikace volání
  • Contact: Aktuální skutečná adresa klienta
  • Record-Route: Seznam adres serverů, kteří chtějí dostávat veškerou komunikaci náležející k hovoru
  • Route Posloupnost adres serverů, přes které je požadavek směrován a

klienta, ke kterému má požadavek dorazit.

  • Request-URI: Aktuální adresát požadavku. Údaj se vyskytuje v první řádce požadavku za metodou (typem požadavku)

Pojmy a prvky architektury služby SIP

Následující odstavec Vás seznámí se základními pojmy a s prvky, se kterými se setkáme v prostředí SIP protokolu.


  • SIP adresa: Uživatel služeb SIP je identifikován pomocí adresy SIP, jinak také SIP URI (Uniform Resource Identifikator). SIP adresa funguje na stejném principu jako adresa e-mail a má nejčastěji následující formát: „sip:user@host“. Je obvyklé, aby až na předponu sip:, byla shodná s e-mail adresou. Část user může být kromě jména také telefonní číslo, pak však mívá adresa spíše předponu tel:. Část host je buď doménové jméno nebo adresa IP. Adresa může obsahovat množství dalších nepovinných parametrů jako číslo portu. Pokud není uvedeno, předpokládá se použití všeobecně známého portu 5060.
  • Transkace: Soubor požadavku a k němu příslušejících odpovědí. Například BYE a 200 OK.
  • User Agent: Sip prvky se mohou skládat se ze dvou logických části: User Agent Client (UAC) a User Agent Server (UAS). Logická část, která generuje dotaz, vystupuje po dobu transakce jako UAC. A UAS je logická část, která vytváří odpovědi. I tato role platí jen po dobu transakce.
  • SIP Server: SIP server je obvykle odpovědný za uživatele v doméně. Pracuje v proxy nebo redirect módu. V redirect módu sdělí informace o poloze volaného získané lokalizační službou zpět volajícímu a ten navazuje spojení přímo na novou adresu. V proxy módu pokračuje navazování spojení prostřednictvím serveru.
  • Location service: Lokalizační služba je služba poskytující informace o současné poloze uživatele, tedy o IP adrese. Služba může používat například Radius protokol nebo databázový stroj s tabulkou kontaktů.
  • Registrar: Registrační server zpracovává požadavek REGISTER a informace o poloze klienta předává lokalizační službě, která obsluhuje příslušnou oblast.
  • Transaction stateful proxy: Tato proxy udržuje stav transakce tj. od přijetí požadavku až do odeslání konečné odpovědi.
  • Call statefull proxy: Tato proxy udržuje stav dialogu od prvního požadavku INVITE až po ukončovací BYE požadavek.

SIP server, lokalizační služba a registrační server bývají často implementovány dohromady.

Registrace

Úspěšný registrační proces je tvořen požadavkem REGISTER a odpovědí 200 OK. Adresa SIP uvedená v položce To s příslušnou aktuální adresou v položce Contact vytvoří v registračním serveru časově omezený záznam, který je předán lokalizační službě. Tato informace umožňuje dosažení uživatele nezávisle na poloze použitého klienta.

Navázání a ukončení spojení

Spojení je navazováno pomocí procedury, která je označována jako „three-way handshake“. Klient A, jenž chce zavolat klientu B, vyšle požadavek INVITE (1). obsahující popis nabízeného spojení. Dorazila-li zpráva v pořádku a byla pochopena pošle, klient B prozatímní odpověď, kterou můžeme chápat jako vyzváněcí tón. Pokud se klient B rozhodl hovor přijmout, vysílá zpět odpověď OK (2) s návratovým kódem 200. Odpověď OK obsahuje kodeky, adresy IP a čísla portů, na kterých bude klient B očekávat data od protistrany. Závěrečnou fází je zaslání zprávy ACK (3) klientem A protistraně, která potvrzuje přijetí odpovědi od klienta B. Proces navazování spojení je kompletní a může začít vlastní rozhovor. Pokud chce některý z účastníků hovor ukončit, pošle protistraně požadavek BYE (4), který bude potvrzen odpovědí 200 OK (5).

Obvykle probíhá spojení za účasti SIP serverů, aby uživatel nemusel znát aktuální adresy volaného. Předpokládejme, že účastník je zaregistrován na serveru, který odpovídá za určitou oblast. Volající se tedy požadavkem INVITE (1) dotazuje serveru SIP, ke kterému podle adresy zadané uživatelem přísluší volaný. Server se snaží zjistit (2) aktuální polohu volaného. Polohu je možno zjistit například dotazem do databáze kontaktů, kterou může server spravovat. Po obdržení místa nebo míst (3), kde by se klient B mohl nacházet, zašle SIP server tuto informaci zpět klientovi A (server vystupuje v redirect módu) a je na klientovi samotném, aby spojení navázal. Nebo server zprávu INVITE upraví a posílá (4) směrem ke klientovi B sám (proxy mód). Přijetí hovoru 200 OK se vrací zpět na server a od něj pokračuje k volajícímu. Pokud není použit mechanismus Record-Route putuje potvrzení ACK (7) a všechny další zprávy mezi klienty A a B již přímo.

Směrování SIP zpráv a mechanismus Record-Route

Základní směrovací mechanismus probíhá pomocí adresy Request-URI a položek Via. Každý prvek vysílající požadavek zaznamená svou adresu do položky Via a umístí ji před ostatní položky Via , pokud existují. Příjemce žádosti, ať už server nebo klient (UAS), by měl zkontrolovat, zda položka Via doplněná předchozím prvkem obsahuje správnou adresu IP vysílače. Pokud položka obsahuje doménové jméno nebo se adresy IP neshodují, měl by příjemce přidat parametr recieved, jehož hodnotou bude adresa IP, ze které požadavek přišel. Neshoda adres IP může nastat v případě, že vysílač má více rozhraní nebo je zakryt překladačem. Do adresy Request-URI je zapsán další příjemce požadavku a požadavek je odeslán. Prvek, který na požadavek odpovídá, zkopíruje všechny položky Via do odpovědi a odešle ji na adresu uvedenou v první položce Via v pořadí. Příjemce odpovědi odstraní první položku Via (svou) a odesílá odpověď na další adresu v pořadí. Takto postupně projde odpověď všemi prvky, kterými prošel požadavek.

Příchodem odpovědi klientovi došlo k vzájemné výměně adres v položkách Contact a je možné všechny další požadavky zasílat přímo mezi klienty bez prostřednictví serverů. Některé servery ale potřebují zůstat informovány o dalším průběhu signalizace. Takovými servery jsou například zpoplatňovací servery nebo servery zajišťující průchod firewalem atd.. V tomto případě je třeba použít mechanismus Record-Route, který zaručí, že přes vybrané servery bude procházet veškerá signalizace hovoru. Vybraný server přidá na konec položky Record-Route požadavku INVITE svoji adresu. Pokud položka neexistuje, vytvoří ji. Volaný klient zkopíruje položku Record-Route do odpovědi. Mimo to přidá na konec seznamu adresu volajícího z položky Contact a tento seznam (cestu) si uloží. Volající po příchodu odpovědi obrátí pořadí adres uvedených v položce Record-Route, vloží na konec adresu volaného z položky Contact a cestu si také uloží. Příchodem odpovědi jsou tedy oba klienti informováni o cestě, po níž budou zasílány všechny další požadavky tohoto hovoru.

V okamžiku odesílání nového požadavku, kterýmkoliv z klientů, je vložena první adresa z cesty do adresy Request-URI a zbytek cesty do položky Route. Via položka je vytvořena také. Příjemce požadavku vyjme první adresu seznamu v položce Route a zapíše ji do adresy Request-URI. Doplní požadavek o svoji položku Via a pošle ho dál. Takto doputuje požadavek až k cíli. Odpověď je zasílána jako předtím podle položek Via.

Odkazy

cs/protokoly/sip.txt · Poslední úprava: 2012/03/11 22:14 autor: janru@cesnet.cz
Creative Commons License Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0