Publikování nebo šíření obsahu serveru bez předchozího písemného souhlasu je zakázáno!
Pro odfiltrování reklamních bannerů, použijte například "ABP".
Pro vyhledání použijte "Ctr F".
   
 
  Signalizace SIP


Abstrakt: Session Initiation Protocol (SIP)

Odorik peering server


Rychlý přechod na:

SIP odpovědi


(rozděleny do šesti skupin):

Signalizace - odpovědi


  1. Informační (nebo též "Přechodné") = 1xx .
  2. Úspěšné provedení = 200 ok.
  3. Přesměrování = 3xx.
  4. Chyba na straně klienta = 4xx.
  5. Chyba na straně serveru = 5xx
  6. Obecné chyby = 6xx.

 


První řešení telefonování přes internet

Roku 1995,uvedla firma "VocalTec" na trh
(
jako první) své řešení telefonování přes Internet.
Posléze do této oblasti rozšířily aktivity dalších firem.
Zavedení služeb majících původ v sítích
se spojováním okruhů do datových sítí,
je podmíněno existencí vhodné sady protokolů,
zprostředkovávajících činnosti potřebné pro přenos hlasu.
Signalizační protokol "SIP" představuje jeden z protokolů,
používaných na přelomu 21.století.
při přenosu hlasu přes datové a celulární sítě.
Jeho obliba stoupá nejen díky textové struktuře,
čímž se zjednodušuje ladění implementací SIP.

Následuje popis vlastností a základních síťových komponent
využívaných u SIP protokolu v IP sítích.


Obsah:

1 Úvod


4 Identifikace uživatelů
5 Závěr
Literatura

Úvod


SIP byl vyvíjen od roku 1996 pracovní skupinou MMUSIC (Multiparty Multimedia Session Control) v rámci IETF (Internet Engineering Task Force). V roce 1999 byl předložen ve formě navrhovaného standardu (Proposed Standard) v RFC 2543. Téhož roku na popud IETF vznikla nová pracovní skupina, nazvaná příznačně SIP, která převzala vývoj hlavního jádra protokolu. Její práce vyústila v nový Proposed Standard - RFC 3261 [1]. Na poli přenosu hlasu přes datové sítě si tedy v současné době konkurují (mimojiné) dvě řešení - jedno založené na rodině protokolů obalujících doporučení ITU-T H.323, a druhé, jímž jsou aktivity IETF ohledně SIPu. Není účelem tohoto článku porovnávat obě řešení, uvedu tedy jen nejmarkantnější rozdíl, kterým je použitá reprezentace dat. U H.323 zvolili autoři binární formát založený na ASN.1, což představuje problém při potřebě sledování a ladění provozu aplikací. SIP je naopak orientován textově, hlavní myšlenkou při návrhu byla jednoduchost a pružnost.

Koncepce protokolu je podobná jako u HTTP (Hypertext Transfer Protocol), používanému službou WWW (World Wide Web), nebo u SMTP (Simple Mail Transfer Protocol), který je prostředkem pro přenos elektronické pošty. Slouží pro řízení navázání, průběhu a ukončení spojení s jedním nebo více účastníky v síti IP (Internet Protocol). Mezi relace mohu zařadit multimediální konference, hovory přes IP síť, sdílení multimediálních dat. Účastníci ve spojení spolu komunikují skrze skupinové vysílání, tzv. multicast (speciální forma všesměrového vysílání, kdy kopie paketu jsou doručeny vymezené skupině koncových uzlů), nebo více spojení typu bod-bod, tzv. unicast. Je možná i kombinace obou uvedených možností.


Na obr. 1 uvádím možnosti komunikace protokolem SIP [2].






Obr. 1: Prvky a možnosti komunikace protokolu SIP

Jak vidno, protokolem SIP je možno komunikovat mezi běžnými telefony přes IP síť i mezi IP telefony s implementovaným SIP či H.323 protokolovým zásobníkem. Ať už telefony jako takovými, nebo jejich programovými ekvivalenty spuštěnými na PC.

SIP představuje aplikační protokol, jeho činnost tedy závisí na protokolech nižších vrstev. Jedná se zejména o protokol RTP (Real-time Protocol), signalizační protokoly pro komunikaci s telefonní sítí, garanci kvality řečového signálu prostřednictvím RSVP (Resource Reservation Protocol), adresářové služby spojené s LDAP (Lightweight Directory Access Protocol), autentizaci uživatelů apod. Mluvím-li o spolupráci, musím se zmínit o faktu, že SIP přesně nespecifikuje užité protokoly. Příkladem je třebas výše uvedený RTP; ten může pracovat jako spojově orientovaný (nad TCP) nebo jako nespojovaný (nad UDP), podle použitého typu protokolu transportní vrstvy (TCP - Transmission Control Protocol nebo UDP - User Datagram Protocol). Díky značné volnosti specifikace SIP co se týče použitých protokolů máme možnost výběru. Ve většině případů se používá protokol UDP, který má výhodu jednoduché implementace. Další důvod je nasnadě, u přenosu časově kritických dat nezáleží příliš na spolehlivosti přenosu, jako spíše na rychlosti doručení. Stejně tak není SIP pevně svázán s žádnými konkrétními protokoly pro přenos multimediálních dat. Uvnitř zprávy protokolu SIP při navázání spojení je proto zapouzdřena zpráva jiného protokolu, který specifikuje použitá kódování pro multimediální data, jejich parametry a čísla portů, na kterých mají být data vysílána nebo přijímána. Obvykle se pro tento účel používá SDP (Session Description Protocol), který je rovněž textový. SDP je popsán v RFC 2327.

Jednotlivé zprávy sestávají z posloupnosti textových hlaviček. Vytváření a rozpoznávání těchto zpráv na straně odesílatele resp. příjemce je jednodušší než u binárních zpráv. Odpadá zde problém složitého způsobu ladění s použitím analyzátoru např. ASN.1 notace. Stačí kopírovat odesílané a přijímané zprávy na obrazovku popřípadě použít sniffer (program, nebo u profesionálních nasazení specializované zařízení, pro monitorování provozu v síti), který vypisuje obsah paketů. Dekódování a vůbec práce s textovou hlavičkou je značně ulehčena využitím některého z vyšších programovacích jazyků (Java, Perl, Python, Ruby atp.). Protokol může být snadno rozšiřován přidáváním nových hlaviček, specifikovaných jako samostatné dokumenty RFC.

Následuje ukázka zprávy navázání spojení, pro předběžnou představu o "čitelné" podobě SIPu.
INVITE sip:sekretarka@firma.cz SIP/2.0
Via: SIP/2.0/UDP 212.80.76.18:1912
Date: Tue, 23 Oct 2002 02:11:31 CET
From: <sip:ty@tam.cz>
To: Josefina Novakova <sip:sekretarka@firma.cz>
Subject: Telefonie po Internetu
Priority: normal
Expires: 3600
CSeq: 1572096531 INVITE
Call-ID: 645663627@212.80.76.18
Contact: <sip:ja@212.80.76.18:5060>
Content-Type: application/sdp
Content-Length: 143

v=0
o=ja 795835924 795835924 IN IP4 212.80.76.18
s=Telefonie po Internetu
c=IN IP4 212.80.76.18
t=2186594793 2186597493
m=audio 10000 RTP/AVP 0

Konkrétně jde o zprávu sloužící k navázání spojení od volaného účastníka k volajícímu. Tato zpráva nemusí projít sítí přímo, většinou totiž není volajícímu dopředu známa adresa/číslo volaného. Tudíž je potřeba zapojit do procesu navazování spojení (a nejen sem) ještě další zařízení.

2 Struktura

V základě SIP pracuje s následujícími síťovými komponentami:
Uživatelský agent
Redirect server
Proxy server
Lokalizační server
Registrační server

2.1 Uživatelský agent


je program, který je zabudován v koncovém zařízení. Přesněji řečeno, UA (Usesr Agent) je souhrnný název používaný pro koncové zařízení obsahující klientského i serverového UA. Klient zabudovaný v koncovém zařízení má anglickou zkratku UAC (User Agent Client), podobně server zabudovaný v koncovém zařízení se nazývá UAS (User Agent Server). Z toho je zřejmé, že oba mohou být v koncovém zařízení implementovány společně. Jejich funkce jsou rozděleny následovně - klient žádá o spojení se serverem, server přijímá požadavky o spojení od klientů. Přitom oba jsou rovnocenní co se týče možnosti ukončit relaci. Jedno zařízení může pracovat současně jako klient i server. Například telefon pracuje jako klient pro odchozí volání a jako server pro příchozí volání.

2.2 Redirect server


se uplatní v případě, kdy klient nezná IP-adresu serveru, u kterého se nachází volaný uživatel. Tehdy redirect server prostřednictvím lokalizační služby zjistí žádanou adresu a předá ji zpět klientskému UA. V případě neúspěšné lokalizace se nepředá adresa žádná, ale je pamatováno i na situaci, kdy existuje pro jednoho uživatele více adres. Na rozdíl od proxy serveru se zde negeneruje žádost o spojení s volaným uživatelem, protože redirect server nepřijímá ani neukončuje volání. Klient potom musí sám navázat spojení přímo se serverem volaného uživatele. Je-li k dispozici více adres (získaných z redirect, potažmo lokalizačního serveru), může kontaktovat více serverů.

2.3 Proxy server

se chová podobným způsobem jako redirect server. Ovšem po obdržení adres(y) z lokalizačního serveru sám naváže spojení se serverem volaného uživatele a potvrdí navázání spojení volajícímu klientovi. Může zkoušet kontaktovat jednotlivé adresy buď postupně nebo paralelně, dokud některý server neodpoví. Proxy server tedy slouží jako prostředník v komunikaci. Navíc klient nemusí mít v této konfiguraci přímý přístup k internetu, například je umístěn ve vnitřní síti. Zde proxy, jako program patřící do aplikační vrstvy, přijímá z LAN požadavky na zprostředkování spojení do internetu. V té podobě, v jaké ho potřebujeme, pracuje nad dvěmi IP rozhraními - tím registrovaným se dívá ven do internetu a tím druhým do privátní LAN. Všechna spojení do internetu tedy otvírá jediná aplikace - proxy server. Závažné omezení provozu přes proxy spočívá v tom, že klientské aplikační programy běžící v LAN schované za proxy serverem musí proxy podporovat, tedy musí s ní umět pracovat (pokud nejde o transparentní proxy). Zrovna tak musí proxy server umět pro daný protokol službu zprostředkovat. Samozřejmě poslední věty jsou míněny spíše obecně, jelikož pojem proxy se neomezuje pouze na SIP. V případě SIP protokolu je zmíněná podpora aplikací a samotné proxy zajištěna.

Právě "maskování" pravého uživatele se nazývá "proxy" funkce. Kromě využití ve spojení s cache servery se proxy-cache servery často využívají pro zabezpečení firemních sítí, řešení nedostatku IP adres atd.

V obr. 2 jsem se pokusil nastínit obecně funkci proxy serveru. Znázorněny jsou dvě spojení směrem do Internetu, které přicházejí na proxy a z ní zprostředkovaně na servery umístěné v Internetu. Odpovědi na zpáteční cestě jsou cílovány pouze na proxy, která je pak propustí ("přeloží") na koncové stanice.









Obr. 2: Zapojení proxy serveru na rozhraní dvou sítí

2.4 Lokalizační server


slouží jako zdroj informace o možném umístění volaného klienta pro redirect a proxy servery. Pod pojmem umístění je lépe si představit adresu/číslo volaného, blíže vysvětlím v dalších odstavcích o identifikaci uživatelů a směrování hovorů. Komunikace mezi lokalizačním serverem a ostatními, kteří využívají jeho služeb, je zprostředkována jiným protokolem než SIP - nejčastěji LDAP. Lokalizační server je vlastně jen jiné jméno pro adresářový server. Pracovníci michiganské univerzity navrhli protokol LDAP (Lightweight Directory Access Protocol, protokol pro přístup k adresářovým službám v komunikacích online), který je definován ve specifikaci RFC 1777 (2. verze protokolu) a později i ve specifikaci RFC 2252 (3. verze protokolu). Jeho použití není samozřejmě omezeno jen na protokol SIP, byl pouze brán jako existující řešení.

2.5 Registrační server

Uživatelé mohou svůj telefon zaregistrovat u tohoto serveru. Pokusím se nastínit situaci, kdy není k dispozici informace o umístění volaného. Tento případ se často vyskytuje u modemových připojení k síti, kdy se IP adresa získaná od poskytovatele připojení k Internetu - ISP (Internet Service Provider) - přiděluje dynamicky, tedy při každém připojení je jiná. Pokud si chtějí dva lidé připojení k Internetu přes modem zavolat, musí provést následující kroky:
Domluvit se přibližně na hodině, kdy se hovor uskuteční
Jeden z nich se připojí modemem k Internetu a zjistí svou přidělenou IP adresu.
Následně zašle elektronickou poštou svoji IP adresu druhému účastníkovi. Z toho důvodu jsem zařadil původně poněkud nelogický bod 1. Aby totiž druhý uživatel věděl, kdy si má svou schránku prohlédnout.
Druhá strana použije obdrženou adresu k požadavku o zahájení spojení.

Jde samozřejmě jen o příklad, ovšem reálného scénáře u programových implementací VoIP na platformě PC.

Díky registračnímu serveru si může každý uživatel vytvořit záznam, svou "logickou" adresu, která se nemění s každým jeho připojením k síti (IP adresu stroje kde se volaný nachází pak mohu nazvat "fyzickým" umístěním). Postup registrace je následující: uživatelský agent vyšle registrační zprávu do registračního serveru. Ten uloží získanou informaci v lokalizační službě (komunikace mezi nimi není součástí SIPu a probíhá jiným protokolem). Jakmile je informace uložena, registrační server vyšle příslušnou odpověď do UA.

Závěrem k stručnému přehledu komponent se sluší ujasnit stav, který je vidět například hned v obr. 1. Proxy, redirect a registrační server bývají totiž často kombinovány v jednotném zařízení, kterému se potom říká SIP-server.

Nahoru

3 Signalizace



Zprávy protokolu SIP jsou dvojího druhu:

- žádosti, říká se jim též metody,
-  odpovědi.

  Nejprve k výčtu podporovaných metod:

  • INVITE - žádost o navázání spojení nebo o změnu parametrů již existujícího spojení.
  • BYE - žádost o ukončení spojení
  • ACK - žádost, kterou klient potvrzuje, že obdržel odpověď na žádost INVITE
  • REGISTER - žádost o registraci klienta u registračního serveru
  • CANCEL - žádost o zrušení probíhající žádosti INVITE
  • OPTIONS - žádost o zaslání přehledu funkcí podporovaných serverem
  • INFO - znamená přenos informací během hovoru
  • UPDATE - dovoluje klientovi aktualizovat parametry spojení
  • PRACK - dočasné potvrzení
  • SUBSCRIBE - znamená přijímání/odběr událostí (textové zprávy)
  • NOTIFY - informuj (uvědom) účastníky
  • MESSAGE - zpráva

Při bližším popisu metod se nevyhnu použití i některých odpovědí (návratových kódů), proto jejich výčet se stručnou charakteristikou zařazuji již zde. Návratový kód je třímístné číslo označující výsledek žádosti obdobně, jak je tomu například v protokolu HTTP.

Lze je rozdělit do šesti skupin podle první číslice:

  • 1xx - žádost přijata, pokračuji ve zpracování žádosti
  • 2xx - znamená úspěšné provedení žádosti
  • 3xx - označuje přesměrování (odpověď od redirectserveru)
  • 4xx - chyba způsobená klientem (chybný formát žádosti)
  • 5xx - chyba způsobená serverem
  • 6xx - obecná chyba, žádost nemůže být akceptována ani jiným serverem

Nejběžnější odpovědi jsou:

  • "200 OK" (úspěšné provedení žádosti),
  • "302 Moved Temporarily" (běžné přesměrování) a
  • "404 Not Found" (volaný uživatel se nenachází na daném serveru).
Nahoru

3.1 Metody

INVITE

Volající klient může kontaktovat volaný server přímo nebo prostřednictvím proxy/redirect serverů. Již jsem popisoval situaci kolem adres, tedy rozdíl je zřejmý.

Uvedu malou ukázku, která by měla osvětlit průběh typické SIP signalizace. Postup navazování spojení je nastíněn v obr. 3.





Obr. 3: Navazování spojení prostřednictvím mezilehlých SIP serverů

Volající strana vyšle volanému uživateli, kupříkladu sip:pepa@firma.cz, žádost INVITE. Prvotní cesta žádosti končí u lokálního proxy serveru (1). Z obr.3 je vidět jeho umístění na rozhraní vnitřní sítě a sítě Internet. Proxy hledá doménu firma.cz v DNS (Domain Name Service) a pokud je doména registrována, získá IP adresu serveru, který má v cílové síti na starosti zpracování SIP žádostí. Proxy tedy pošle žádost o spojení takto zjištěnému serveru (2). Ten zná uživatele pepa, ale ví že je právě přihlášen pod uživatelským jménem pepa.novak na jiném serveru jako pepa.novak@melouch.cz. O lokaci uživatele se dozvídá dynamicky díky mechanismu registrace (žádost REGISTER), nebo staticky, kdy je jeho adresa v databázi pevně nastavena. Tedy SIP server v doméně firma.cz přesměruje (chová se teď jako redirect server) požadavek zpět, tzn. vrátí adresu pepa.novak@melouch.cz zpět lokálnímu proxy serveru (3). Opět se provede DNS dotaz na IP adresu SIP serveru melouch.cz a pošle znovu žádost INVITE (4). Doména melouch.cz obsahuje několik podsítí. Její server zjistí dotazem na lokalizační server (5), že uživatelpepa.novak@melouch.cz je zde znám jako p.novak@tech.melouch.cz (6). Takže iniciuje další z řady INVITE žádostí na server techniků (7). Zde již server zná IP adresu přihlášeného uživatele p.novak a tak na ni pošle poslední INVITE (8). Volaný přijme po nějaké době volání a skrze řetěz proxy serverů pošle návratový kód (9), (10), (11), (12). Klient vždy potvrdí žádostí typu ACK (13), že obdržel konečnou odpověď na předchozí žádost INVITE.


BYE

Ukončení spojení je u SIP signalizace provedeno prostřednictvím žádosti BYE. Klient pošle serveru žádost, kterou server potvrdí odpovědí OK. Jak jsem se již zmínil na začátku, koncová zařízení obvykle obsahují klientskou i serverovou část UA, proto jak volající, tak volané KZ mohou poslat žádost o ukončení spojení BYE.

ACK

U žádosti ACK není mnoho co popisovat. Klient vždy potvrdí žádostí ACK, že obdržel konečnou odpověď na předchozí žádost INVITE. Uvedu další z obrázků ze kterého bude vyplývat význam slov "konečnou odpověď" z předchozí věty (viz obr. 4). Jedná se o jednodušší příklad než jaký jsem nastínil v sekci INVITE, tentokrát prezentovaný ve formě časového diagramu.





Obr. 4: Časový diagram signalizace

Mezi účastníky leží dva proxy servery, které uvedeným způsobem předají příchozí požadavek INVITE dál. Naznačil jsem i odpovědi "100 Trying" - "zkouším to dál" a "180 Ringing" - vyzvánění volaného účastníka. V okamžiku, kdy volaný zvedne sluchátko, jeho SIP telefon vyšle odpověď "200 OK". A konečně přichází na řadu ono finální potvrzení přijetí odpovědi - ACK od volajíciho k volanému.

Od tohoto okamžiku je sestaveno spojení a oba účastníci si vyměňují pakety obsahující kódovaný řečový signál, zapouzdřený v RTP protokolu. Spojení je ukončeno v případě uvedeném na obrázku volaným. Za zmínku stojí, že veškerá komunikace po sestavení spojení již jde mimo proxy servery.

REGISTER

Uživatel si může registrovat svou adresu sám, nebo to může za něj provést někdo jiný. Lze specifikovat dobu, po kterou má být adresa registrována. Pokud klient tuto dobu neuvede, platí standardní doba - 1 hodina. Klient může zrušit existující registraci specifikováním doby registrace 0 v hlavičce " Expires:".

Průběh registrace popsán dříve (registrační server), takže jen komentář k obr. 5:




Obr. 5: Průběh registrace UA

Z důvodu lepší přehlednosti jsem nezakreslil odpovědi, které se netýkají procesu registrace. Registrační server se chová jako služba předřazená lokalizačnímu serveru. Musí mít práva čtení a zápisu do/z lokalizační služby (stejnětak proxy a redirect server musí být schopni ta samá data přečíst). To mimochodem znamená, že registrační server nesmí generovat odpovědi typu "6xx". Je dobré si dále uvědomit, že registrační a proxy server mohou být realizovány v jediném zařízení. V obrázku jsou odděleny jen z důvodu lepší názornosti. V hlavičce "To:" je uvedena adresa uživatele, která má být registrována. V hlavičce "From:"je uvedena adresa uživatele, který posílá žádost o registraci. Klient může specifikovat dobu, po níž má být adresa registrována v hlavičce "Expires:". Server může provést registraci buď na požadovanou nebo na kratší dobu. Pokud klient dobu registrace nespecifikuje, server ji zvolí sám. Skutečnou dobu registrace server buď vrátí v hlavičce "Expires:" v odpovědi, nebo platí standardní doba. Klient může zrušit existující registraci specifikováním nulové doby registrace.

Šipkami (viz obr. 5) jsou rozlišeny zprávy SIP a zprávy (například) LDAP.

Nahoru

3.2 Odpovědi


Odpovědi SIP jsou rozděleny do šesti skupin:


Informační (nebo též "Přechodné") 1xx .

100    Zkouším to dál (Trying). Oznamuje, že žádost byla přijata serverem
a byly provedeny kroky k jejímu splnění.


180    Vyzvánění (Ringing). Uživatelský agent přijal žádost INVITE a nyní se snaží upozornit uživatele na příchozí hovor.


181    Volání je přesměrováno (Call Is Being Forwarded). Server může použít tento typ odpovědi, když oznamuje přesměrování hovoru na některý jiný server.


182    Zařazen ve frontě (Queued). Volaná strana je dočasně nedostupná, ale server se rozhodl místo zamítnutí volání zařadit žádost do fronty.
V okamžiku, kdy je volaný opět dostupný, vyšle se vhodná finální odpověď dle situace (odmítnout/přijmout).


183    Zpráva o činnosti (Session Progress). Používá se pro přenášení informace o průběhu zpracování volání. A to buď v hlavičce nebo v těle odpovědi.

 
Žádost byla zdárně zpracována.
Informace přenesená v odpovědi závisí na typu žádosti, která tuto odpověď vyvolala.

 
300    Více možností (Multiple Choices). SIP adresa uvedená v žádosti byla analyzována a rozložena na několik možných lokací volaného. Volající uživatel (potažmo UA) může upřednostnit jednu z lokací (koncových bodů) a pak přesměrovat svůj požadavek na zvolený koncový bod.
V těle odpovědi by samozřejmě měl být uveden seznam, podle kterého se volající rozhodne.

301    Trvale přesunut (Moved Permanently). Volaný uživatel už není na cílové adrese k nalezení. Volající by měl zopakovat svou žádost na adresu získanou z odpovědi v hlavičce "Contact:". Stejně tak by měl nahradit záznam v adresáři ("seznam kontaktů") aktualizovanou informací.


302    Běžné přesměrování redirect serverem (Moved Temporarily). Je možné specifikovat dobu, po kterou je adresa, na kterou se přesměrování provede, platná.


305    Použít proxy server (Use Proxy). Požadovaný zdroj je možné kontaktovat pouze přes proxy. Adresa proxy serveru je obsažena v odpovědi (hlavička "Contact:"). Zde plyne jednoznačně, že odpověď "Use Proxy" může generovat pouze serverová část UA (UAS).


380    Poskytnutí náhradní služby (Alternative Service). Volání nebylo úspěšné, ale server nabízí možnost náhradní služby. Typ služby je popsán v těle odpovědi.


400     Poškozená metoda (Bad Request). Žádost nemůže být zpracována díky zjevným syntaktickým chybám. Například chybí hlavička "Call-ID:"

401     Pokus o neautorizovaný přístup (Unauthorized). Žádost si vynucuje autentizaci uživatele. Tato odpověď je generována UAS a registračními servery. Proxy servery používají odpověď 407 (viz níže).


403     Zakázaná žádost (Forbidden). Server rozuměl žádosti, ale odmítá jí vyhovět/zpracovat. V RFC se uvádí, že by neměla být opakována.


404     Volaný uživatel se nenachází na daném serveru (Not Found). Server má konečnou informaci, že volaný uživatel v zadané doméně neexistuje. Stejně tak se tato odpověď zašle po žádosti obsahující doménu odlišnou od těch, které daný SIP server spravuje.


405     Žádost není povolena (Method Not Allowed). Server správně rozpoznal žádost, ale její zpracování je pro adresu ze které žádost přišla zakázáno. Aby klient věděl, které žádosti má povoleny, server je zašle v těle odpovědi (toto chování je u všech serverů povinné).


406     Nelze přijmout (Not Acceptable). V žádosti je uveden seznam charakteristik očekávaného datového toku, které kolidují s možnostmi serveru.


407     Nutná autentizace u proxy (Proxy Authentication Required). Klient se musí nejprve autentizovat u proxy serveru. Odpověď je podobná s "Unauthorized" výše.


408     Překročení doba odezvy (Request Timeout). Server není schopen reagovat v rozumném čase, například nestihne lokalizovat uživatele. Klient může zopakovat svou žádost beze změn.


410     (Gone). Žádaný zdroj není dále k dispozice a navíc není známa jeho stávající adresa pro přesun žádosti. Zde se předpokládá trvalý stav. Avšak, pokud server sám o sobě nemá možnost zjistit, je-li situace opravdu trvalá, potom by se se místo "Gone" měla generovat odpověď 404 - "Not Found".


413     Překročení délky zprávy (Request Entity Too Large). Tělo zprávy je delší než je server schopen (nebo ochoten) zpracovat.


414     Dlouhá adresa cíle (Request-URI Too Large). Server odmítl poskytnout službu z důvodu příliš dlouhé hlavičky "Request-URI".


415     Neznámý formát zprávy (Unsupported Media Type). Zde server opět odmítá žádost, nyní však z důvodu nemožnosti analýzy těla zprávy. Jednoduše - formát zprávy není na serveru podporován. Server musí naoplátku vrátit účastníkovi seznam podporovaných formátů.


416     Neznámý formát URI (Unsupported URI Scheme). Podobný případ jako předchozí.


423     Krátký interval (Interval Too Brief). Požadavek nelze splnit v žádané době. Použití této odpovědi spadá do oblasti registračního serveru. Žádost je zamítnuta.


480     Dočasně nedostupný (Temporarily not available). Bylo úspěšně navázáno spojení s koncovým bodem, ten však v té chvíli není dostupný. To znamená například, že není nalogován v systému, má nastaveno "nerušit", nebo je nalogován ale zrovna není ve stavu přijmout hovor. Odpověď by měla specifikovat čas pro další pokus o volání. Jiné použití je u proxy a redirect serverů, které touto odpovědí dávají najevo situaci, kdy volaný uživatel nemá v dané chvíli definovánu doménu kam hovor přesměrovat.


484 Chybné telefonní číslo (nesouhlasí počet číslic telefonního čísla).


486 Volané číslo je obsazené.
500 Vnitřní chyba serveru (Internal Server Error)

501 Požadovaná funkce není implementována (Not Implemented)


503 Služba není dostupná (Service Unavailable)


504 Vypršel čas pro odpověď (Server Time-out)


505 Použitá verze SIP není podporována (SIP Version not supported)


513 Příliš dlouhá zpráva (Message Too Large)


 


600 Zaneprázdněný, obsazený (Busy Everywhere)

603 Obecné odmítnutí (Decline) - Volaný odmítl volání.


604 Neexistující číslo (Does not exist anywhere) - Volaná URI neexistuje.


606 Nepřípustné číslo (Not Acceptable-komunikační nastavení nejsou akceptovatelná.
.


701 Volaný zavěsil.

702 VoIP Socket chybný.


703 Spojení přerušeno kvůli překročení časového limitu.


704 Spojení přerušeno kvůli chybě SIP.


705 Chyba paměti SIP.


706 Chyba paměti transakce SIP.


751 Obsazovací signál-nesouhlasí kodek volajícího a volaného účastníka.
 
 
Seznam (v kostce) některých SIP kódů

1xx Provisional

100 --- Trying
180 --- Ringing
181 --- Call is being forwarded
182 --- Queued
183 --- Session progress


2xx Successful

200 --- OK


3xx Redirection

300 --- Multiple choices
301 --- Moved permanently
302 --- Moved Temporarily
305 --- Use Proxy
380 --- Alternative service


4xx Request Failure

400 --- Bad request
401 --- Unauthorized
402 --- Payment request
403 --- Forbidden
404 --- Not found
405 --- Method not allowed
406 --- Not acceptable
407 --- Proxy authentication required
408 --- Request time out
410 --- Gone
413 --- Request entity too large
414 --- Request-URI too long
415 --- Unsupported media type
416 --- Unsupported URI scheme
420 --- Bad extension
421 --- Extension required
423 --- Interval too brief
480 --- Temporarily unavailable
481 --- Call/Transaction does not exist
482 --- Loop detected
483 --- Too many hops
484 --- Address incomplete
485 --- Ambiguous
486 --- Busy here
487 --- Request terminated
488 --- Not acceptable here
491 --- Request pending
493 --- Undecipherable


5xx Service Failure

500 --- Server internal Error
501 --- Not implemented
502 --- Bad Gateway
503 --- Service unavailable
504 --- Server time-out
505 --- Version not supported
513 --- Message too large


6xx Global Failures

600 --- Busy everywhere
603 --- Decline
604 --- Does not exist anywhere
606 --- Not acceptable


(Upozornění: Výčet není kompletní !)



4 Identifikace uživatelů

Základní adresa uživatele má tvar e-mailové adresy, nazývá se URI (Uniform Resource Identifier). Existují dvě podoby, SIP URI a SIPS URI. Forma zápisu je stejná, ovšem druhá verze (uvozená "sips:") je určena pro zabezpečenou formu komunikace. Z [3] vyplývá, že běžně používaný pojem URL (Uniform Resource Locator) je specifickou podtřídou URI.

Příkladem SIP URI je zápis ve tvaru:

sip:p.novak@tech.melouch.cz

Toto je adresa/jméno, kterou normálně použije volající, když chce navázat spojení s druhou stranou. Adresa však může obsahovat i další údaje popisující způsob kontaktu uživatele. Úplný tvar adresy je následující:

sip:[uživatel[:heslo]@]hostname[:port][;parametry][?hlavičky]

Hranaté závorky označují nepovinné části. Jediným povinným údajem je ve skutečnosti jméno počítače/telefonu, místo něhož může být uvedena přímo IP-adresa zařízení. Před jméno zařízení lze volitelně uvést jméno uživatele případně heslo na tomto zařízení. Pracuje-li zařízení jako brána do klasické telefonní sítě, ve které se uživatelé označují telefonními čísly, uvádí se místo jména uživatele jeho telefonní číslo. Za jménem zařízení může následovat seznam parametrů a hlaviček. Parametry určují, jaký protokol má být použit v transportní vrstvě (UDP nebo TCP), zda je uvedeno jméno nebo telefonní číslo uživatele a další údaje. Hlavičky se potom stávají přímo součástí signalizační zprávy.


Příklad:
sip:p.novak:tajne@tech.melouch.cz
;transport=UDP;maddr=224.2.0.1


Uživatel

Položka uživatel představuje identifikátor konkrétního zdroje v cílovém zařízení. Výraz "cílové zařízení" často zastupuje jméno síťové domény. Dvojice uživatel:heslo tvoří volitelnou část SIP URI a nemusí se uvádět v případě, kdy vzdálený server nemá co do činění s rozlišením uživatelů nebo tehdy, když vzdálený server sám o sobě představuje zdroj (službu), kterou chceme kontaktovat.


Heslo

Je spojeno s konkrétním uživatelem. Zároveň je však třeba říci, že použití této položky SIP URI není doporučováno. Skrze uzly sítě totiž prochází ve formě otevřeného textu, takže zasláním hesla jako součásti SIP URI podstupuje účastník bezpečnostní riziko.


Hostname

Hostitelský systém (vzdálený server), poskytující SIP služby (v textu RFC se mluví o "zdrojích"). Jak jsem již uvedl, může zde být buď úplné doménové jméno, nebo číselná podobu - IPv4/IPv6 adresa. Doporučeno je uvádět doménové jméno vždy když je to možné.


Port


Touto položkou se specifikuje číslo portu, na který se má požadavek zaslat. Pokud není zadáno, implicitně se předpokládá port 5060 pro přenos skrze protokoly TCP, UDP a SCTP (Stream Control Transmission Protocol), nebo port 5061 pro "sips:" přenášený přes TCP (SIPS musí být přenášen spolehlivou službou) a TLS (Transport Layer Security) přenos přes TCP. Čísla portů se přidělují prostřednictvím centrální autority IANA (Internet Assigned Numbers Authority).


Závěr

Protokol SIP (vyvíjí se již od roku 1996 nic nevypovídá o jeho relativním mládí).
Otevřenost protokolu je možno pokládat za značnou výhodu oproti přístupům ostatních standardizačních institucí. Proto se objevují volně šiřitelné zdrojové kódy k jednotlivým SIP komponentám - (tzv. "SIP stacks"), ať už programované v Javě, C, nebo C++. Seznam některých SIP zařízení je dostupný na stránkách SIP fóra.

Nahoru

Literatura

[1]    Schulzrinne, H., Rosenberg, J. et al.: SIP: Session Initiation Protocol. Request for Comments 3261. Internet Engineering Task Force, červen 2002. Proposed Standard

[2]    Ubik, S.: IP telefonie se signalizací SIP. Sdělovací technika, 9:3-5, září 2001.

[3]    Berners-Lee, T., Fielding, R., Irvine, U., C., Masinter, L.:
        Uniform Resource Identifiers (URI):
        Generic Syntax. Request for Comments 2396.
         Internet Engineering Task Force, srpen 1998.

[4]    Soumar, M.: Hlasové služby v datových sítích. Diplomová práce, s. 47-56. FEKT VUT, Brno 2002.

DALŚÍ INFORMACE O PROTOKOLU SIP

 
 
Signalizační protokol "SIP" je užíván k řízení multimediálních relací v IP sítích,
obsahuje zprávy pro sestavení, udržení a ukončení spojení.
Jádro protokolu je definováno v RFC 3261,
jeho oblíbenosti prospělo textově-orientované kódování,
poměrně snadná rozšiřitelnost a dynamický vývoj charakteristický pro normy vznikající v rámci IETF.

Příspěvek je zaměřen na popis prvků VoIP řešení s protokolem SIP,
popis zpráv (metody a odpovědi) s doplněním o příklady autentizace při registraci,
rozdílů chování na stavové a bezestavové SIP Proxy.


Budou vysvětlena i důležitá rozšíření pro SIP a jejich využití
(Presence, Instant Messaging).
Závěr příspěvku bude patřit otevřeným řešením s podporou SIP protokolu,
zejména SIP Express Router a Asterisk, které jsou využívány v akademickém prostředí.


ÚVOD


 
IP telefonie je jednou z nejvýznamnějších změn v dějinách telefonie.
V první etapě prosazování IP telefonie se používal nejčastěji termín konverze hlasových
a datových sítí, tak dnes už nehovoříme o konverzi,
ale rovnou o změně anebo náhradě.


Veřejná telefonní síť se téměř 100 let vyvíjela na analogovém principu, koncové telefonní přístroje i ústředny byly analogové a také všechny přenosy byly prováděny analogovou formou. Od poloviny minulého století byly učiněny první kroky k digitalizaci a standardizace PCM (pulzní kódové modulace, ITUT G.711) v roce 1972 změnila oblast telekomunikací a otevřela brány digitálního světa, viz. [1], [2]. V něm je charakteristický kanál 64 kbit/s a spojovací pole propojovacích  prvků je založeno na propojování toků 64 kbit/s. Dnes jsme v další etapě vývoje telefonie, telefonování je aplikací v sítích s Internet protokolem.

Za počátek IP telefonie je považován únor 1995, kdy izraelská společnost Vocaltec přišla s komerčním produktem Internet Phone. Nové techniky zpracování hlasu, především kodeky s lineární predikcí, umožnily redukovat hovorové pásmo při zachování kvality a jejich nasazení se uplatnilo právě v IP telefonii. Dominantní se stalo kódování dle ITU- T G.729 a G.723.1., přičemž povinné pro všechny zařízení je schopnost dorozumět se na ITU- T G.711. Využití Internetu jako páteřní infra-struktury pro telefonii snižuje náklady na telefonování, s rozšiřováním IP telefonie klesají provozní režie a zvyšuje se konkurenceschopnost služby, což stimuluje její rozšiřování a snižuje ceny, jedná se tak o efekt spirály. Jsou zde ovšem nové otázky
bezpečnosti (zneužití VoIP systémů, podvržení cizí identity, spam, zajištění utajení a integrity hovoru).


Výhody, které přináší IP telefonie vidíme ve dvou rovinách:
  • efektivnější řešení, využití jedné přenosové infrastruktury,
  • nové možnosti, větší mobilita, ENUM, (mapování tel.č. a URI adres přes DNS), snadnější integrace aplikací (např. tel. seznam v telefonu na bázi LDAP), nové služby typu Instant Messaging, prezence (zobrazení stavu konkrétního úč. – odhlášen, přihlášen).

Nevýhody, které opět můžeme rozdělit
do dvou oblastí:
  • IP telefonie přináší ve srovnání s PSTN snížení spolehlivosti a dostupnosti služby (nižší o 0,5 %),
  • Zmiňovaná bezpečnostní rizika.Voice over IP prochází evolucí, stejně jako jakákoliv rozvíjející se technologie.
 
IP telefonie se v počátcích orientovala striktně na oblast Internetu, kdy se používaly samostatné IP telefony především ve formě aplikací pro PC a nebylo realizováno propojení s PSTN, jednalo se o pionýrské začátky IP telefonie.

Dnes je nabízena IP telefonie jako plnohodnotná náhrada telefonních přípojek a klasických pobočkových ústředen. V sítích s protokolem IP se hlas přenáší v paketech RTP (Real Time Protocol), které na transportní vrstvě používají protokol UDP. Formát tohoto paketu je dán doporučením IETF z roku 1996 s označením RFC1889/1890 pro RTP/RTCP, přičemž RTP řeší vlastní přenos hlasové informace a RTCP kontrolní mechanizmus v doručování RTP (Real Time Control Protocol). Novější implementace používají FC3550 z roku 2003 nebo ještě novější SRTP (Secure RTP) dle RFC3711 z roku 2004. Během přenosu RTP dostáváme informace o počtu ztracených paketů a proměnném zpoždění pomocí kontrolního protokolu RTCP. Jeho zajímavým rozšířením je RTCP XR (Control Protocol Extended Reports), který definuje soubor metrik pro hodnocení VoIP kvality volání, určování problémů, viz. [3], [4]. RTCP XR jednak umožňuje zobrazení hodnoty MOS či R-faktoru přímo na koncových zařízeních, ale mnohem užitečnější je sledování těchto kvalitativních parametrů a vyhodnocení aktuální dostupné kvality pro konkrétní destinace, což může vést například ke změně směrování volání v síti (používá se kupříkladu v síti AARNET). Z pohledu signalizačních protokolů máme následující možnosti. Nejstarším doporučením je ITU-T H.323 pro multimediální komunikaci v paketových sítích, H.323 zastřešuje řadu standardů, první verze je z roku 1996, poslední verze H.323v6 je z roku 2006. Pracovní skupina ITU-T SG16, která odvedla podstatnou část práce na H.323 se dnes zabývá tvorbou nového standardu ITU-T H.325, což svědčí i o tom, že o osudu dalšího vývoje H.323 je rozhodnuto, viz. [5]. Vyvíjený H.325 bude zcela novým standardem pro IP telefonii a jeho uvolnění v R.2009.

Nahoru

Protokol SIP

Poprvé byl SIP uvolněn v roce 1999 a dnes je dostupný ve dvou verzích RFC, k SIPu se váže ale dalších zhruba sedmdesát RFC, které rozšiřují jeho možnosti. Ve veřejných sítích se používá softswitch architektura, která vyžaduje oddělit média, řídící a  signalizační funkce a k tomu účelu byl vyvinut master-slave protokol MGCP (Media Gateway Control Protocol) a Megaco. MGCP byl poprvé uvolněn IETF v roce 1999.

Další vývoj pokračoval společně s ITU-T pod označením Megaco/H.248 specifikovaným o rok později než MGCP (H.248 a Megaco jsou ekvivalentní jména pro stejný protokol). Rok byla ovšem dostatečně dlouhá doba k tomu, aby někteří výrobci implementovali MGCP a tím umožnili jeho další vývoj. Veškerá RFC pro MGCP jsou jako informativní, zatímco pro Megaco mají statut standardu. Řada lidí v oboru používá stejné označení pro MGCP a Megaco/H.248 či navzájem je zaměňuje, což je chyba, jelikož jsou to dva různé protokoly, ačkoliv v mnoha částech podobné.

Vlastnosti SIPu

SIP byl vyvíjen od roku 1996 pracovní skupinou MMUSIC (Multiparty Multimedia Session Control) v rámci IETF (Internet Engineering Task Force). V roce 1999 byl předložen ve formě navrhovaného standardu (Proposed Standard) v RFC 2543. Téhož roku na popud IETF vznikla nová pracovní skupina, nazvaná příznačně SIP, která převzala vývoj hlavního jádra protokolu. Její práce v květnu roku 2002 vyústila v nový standard RFC 3261. SIP je signalizační protokol pracující na aplikační vrstvě, tento protokol byl navržen tak, aby byl snadno implementovatelný, rozšiřitelný a dostatečně flexibilní. Specifikace je dostupná ve formě několika doporučení RFC, nejdůležitější je RFC3261 jež obsahuje jádro protokolu. Protokol je užíván pro sestavení, modifikaci a ukončení spojení s jedním nebo více účastníky. SIP není jediný protokol, který je potřebný pro komunikující zařízení. Ve spojení se SIPem jsou nejčastěji používány ještě dva další protokoly, RTP a SDP. RTP protokol je užíván k přenosu multimédií v reálném čase (real-time), tento protokol umožňuje přenášet hlas nebo video v paketech pomocí IP. Dalším důležitým protokolem je SDP, který je užíván k popisu vlastností účastníků spojení. Tento popis je pak použit k vyjednání parametrů spojení všech zařízení účastnících se spojení (vyjednání kodeků transportního protokolu), uvažuje se však o nahrazení novým protokolem založeným na XML. SIP byl navržen v souladu s modelem Internetu. Jde tedy o end-to-end orientovaný signalizační protokol, což znamená, že veškerá logika je uložená v koncových zařízeních (vyjma směrování SIP zpráv), koncové zařízení zná i jednotlivé stavy komunikace, tím je zvýšena odolnost komunikace proti chybám. Cena, která se musí zaplatit za decentralizaci a dostupnost služby, je vyšší režie v hlavičkách zpráv (zprávy jsou posílány end-to-end). Nepochybně stojí za zmínku, že end-to-end koncept SIPu je významná odlišnost od klasického řešení PSTN (Public Switched Telephone Network), kde logika je uložena v síti a koncová zařízení jsou podstatně jednodušší. Cílem SIPu je zajistit stejnou funkcionalitu jakou mají klasické PSTN, ale end-to-end návrh umožní SIP sítím vyšší výkonnost a otevře implementaci nových služeb, které mohou být jen ztěží nasazeny v klasických PSTN. Komunikace v SIPu probíhá výměnou dvou typů zpráv, požadavků a odpovědí. Klient i server jsou logickou částí jednoho prvku. SIP je založen na HTTP protokolu. HTTP protokol má formát hlaviček zpráv dle RFC822. HTTP je nepochybně nejúspěšnějším a nejpoužívanějším protokolem v Internetu. HTTP může být taky chápán jako signalizační protokol, protože UA (user agents) jej používají, aby sdělili HTTP serveru, o který dokument se zajímají. SIP je užíván k přenosu popisu parametrů relace, popis je zakódován dovnitř dokumentů používajících SDP. Oba protokoly (HTTP a SIP) zdědili kódování hlaviček zpráv z RFC822. Volba osvědčeného formátu zaručuje robustnost
a nadčasovost.

Nahoru

Adresace

SIP je vázán k doméně, což respektuje adresace. Uživatel existuje v konkrétní doméně, kterou obsluhuje SIP server. SIP entity jsou identifikovány použitím SIP URI (Uniform Resource Identifier). SIP URI má formát; sip:user@host:porturi-parameters .

Jak můžeme vidět, SIP URI se skládá z části user a z části host , obě části jsou oddělené znakem @. SIP URI je podobná e-mailové adrese, je doporučeno používat stejnou adresu pro e-mail i SIP, takže URI může být snadné si zapamatovat. Část user identifikuje uživatele v doméně prezentované v části host, která může být zadána pomocí jména nebo IP adresy. Pokud není uvedeno číslo portu, tak se předpokládá použití všeobecně známého portu 5060.Parametry mohou nést další volitelné informace. Doménová část URI je adresována s využitím DNS, což dává adresaci vysokou flexibilitu.

V následující tabulce 1 jsou uvedeny příklady URI.
 
URI Použití  adresy Doporučení
sip: nebo sips: SIP a Secure SIP adresa RFC 3261
tel: Telefonní čísla RFC 3999
pres: Prezence RFC 3861
im: Instant Message RFC 3861
http: Web RFC 2616
h322 H.323 URL RFC 3508

Tab. 1: URI a odkazy na doporučení


Prvky SIP řešení

Ačkoliv v nejjednodušší konfiguraci je možné použít dva UA posílající si navzájem SIP zprávy, typická SIP síť bude obsahovat více než jeden typ prvků.

Základními SIP prvky jsou:
  • • user agents,
  • • proxies, registrars, and redirect servers.
 
Jednotlivé servery jsou většinou prezentovány jako logické části SIP serveru, jelikož je často efektivní je provozovat společně na jednom HW. Koncové body sítě Internet, které užívají SIP ke vzájemnému spojení jsou nazývány jako user agents (UA). UA obvykle jsou představovány koncovými terminály ve formě HW SIP telefonu nebo aplikace, SIP UA mohou být i mobilní telefony, PSTN brány (GW), PDA, IVR systémy atd. UA jsou vztaženi k částem User Agent Server (UAS) a User Agent Client (UAC). UAS a UAC jsou pouze logické entity, každý UA obsahuje UAC a UAS:
 
  • • UAC je část vysílající požadavky a přijímající odpovědi,
  • • UAS je část přijímající požadavky a odesílající odpovědi.
URI použití adresy doporučení sip: nebo sips:
SIP a Secure SIP adresa RFC 3261
tel:
Telefonní čísla RFC 3999
pres:
Prezence RFC 3861
im:
Instant Message RFC 3861
http:
Web RFC 2616
h323 H.323 URL RFC 3508

Požadavek a odpověď jsou dva základní typy SIP zpráv. Protože koncové
zařízení téměř vždy obsahuje UAC a UAS, tak používáme pouze označení UA namísto UAC a UAS. Například, volající UA funguje jako UAC, když odesílá zprávu INVITE (požadavek na sestavení spojení) a přijímá odpověď na požadavek. Volaný UA se chová jako UAS, když obdrží zprávu INVITE a odesílá odpověď. Ale tato situace se mění, když volaný se rozhodne zavěsit a odesílá se zpráva BYE a ukončuje spojení. V tomto případě se volající chová jako UAC a volaný jako UAS.

Na obrázku 1 jsou tři UA a SIP proxy. Každý UA obsahuje UAC a UAS.

Část SIP proxy, která přijímá INVITE od volajícího, funguje jako UAS.
V případě větvení SIP proxy přeposílá požadavek na dvě místa zároveň
a vytváří dva UAC, každý odpovídající jednomu větvení na obrázku.
V našem příkladě volaný UAS B vyzvedl a později zavěsil, tím vyslal požadavek BYE a zachoval se jako UAC.

Obr. 1: Interakce mezi UAC a UAS

Volající SIP Proxy s funkcí forking
Volaný A
Volaný B
 
SIP SERVER
SIP umožňuje vytvořit infrastrukturu sítě hostitelů nazývaných jako proxy servers. Koncové terminály UA mohou odesílat zprávy na proxy server. Proxy servery jsou důležité entity v SIP infrastruktuře, zajišťující směrování žádostí o spojení dle aktuálního umístění adresáta, autentizaci, účtování a spoustu dalších důležitých funkcí. Nejdůležitější úloha proxy serveru je směrovat žádosti o sestavení spojení blíž k volanému. Při inicializaci sestavení spojení bude obvykle prohledávat řadu proxy serverů, dokud nenajde nějaký, který zná aktuální umístění volaného. Takže proxy bude přesměrovávat žádost o spojení přímo k volanému a volaný akceptuje
nebo odmítne žádost o spojení.

Máme dva základní typy SIP proxy serverů:
 
  • stateless (bezesetavový),
  • stateful (a s informací o stavech).

Stavová a bezestavová SIP Proxy

Stateless Servery servery jsou poměrně jednoduché a pouze přeposílají zprávy nezávisle na jejich vzájemné vazby. Zprávy jsou většinou v pořádku z hlediska souslednosti a významu v signalizaci, stateless proxy servery neumí kontrolovat jejich výměnu z hlediska smysluplnosti, takže může vyjímečně docházet k nekorektním stavům, které musí být ošetřeny na úrovni koncového zařízení. Stateless proxy servery jsou jednoduché, ale rychlejší než stateful proxy servery. Využití mají např. pro snížení zátěže, pro jednoduché překládání zpráv a směrování. Jedna z nevýhod stateless proxy serverů je, že nejsou schopné zachytit opakování zpráv a provádět dokonalejší směrování, např. větvení nebo předání. Ze zachycené
signalizace poznáme, že se jedná o stateless server, pokud budeme sledovat, zda zprávy pouze přeposílá. Stateful Servery jsou Proxy servery s informací o stavech jsou mnohem komplexnější. Po přijetí požadavku, server si vytvoří záznam stavu a tento stav drží, dokud nedojde k ukončení transakce. Některé transkace, zejména vytvořené zprávou INVITE, mohou trvat poměrně dlouho (dokud volaný nevyzvedne nebo se neukončí volání). Protože proxy servery s informací o stavech musí udržovat stav po celou dobu dané transakce, je jejich výkon limitován. Schopnost přiřazovat SIP zprávy do transakcí dává serveru některé zajímavé vlastnosti, například může provádět větvení, na přijetí jedné zprávy, může být odesláno více zpráv. Stateful proxy server může zachytit opakování zpráv, protože ze
stavu transakce lze určit, jestli byla stejná zpráva už přijata (stateless proxy nemůže ověřovat, protože nedrží stav). Proxy server s informací o stavech může provádět komplikovanější metody nalezení uživatele, například možnost zkusit volat na telefon v zaměstnání a v případě neohlášení volání přesměrovat na mobilní telefon. Bezestavová proxy to nemůže, protože nemá informaci, zda bylo dosaženo cíle či nikoliv. Většina SIP proxy serverů je s informací o stavech, často nabízejí účtování, větvení, některé druhy podporují i NAT. Ze zachycené signalizace poznáme
stateless SIP proxy dle informativních odpovědí, tato proxy nejdříve na žádost odpoví a až potom ji přepošle dál.



SIP Proxy se dále dělí na:
  • Transaction stateful Proxy, což je transakční Proxy udržující stav transakce, tzn. od přijetí požadavku až po odeslání konečné odpovědi,
  • Call stateful Proxy, což je dialogová Proxy udržující stav celého dialogu, tzn. od přijetí první žádosti INVITE až po ukončovací BYE.
 
Typický scénář spojení

Typická konfigurace je taková, že každá jednotka (např.firma) má vlastní SIP server, který je užíván všemi UA v rámci administrované jednotky, v drtivé většině případů se jedná o jednu doménu. Může se jednat ovšem i o případ, že jeden SIP server obsluhuje více domén, potom jde o multidoménovou SIP Proxy. Multidoménová Proxy je sice umístěná v konkrétní doméně, ale pomocí pole realm umí určit, do které domény uživatel patří. Předpokládejme, že jsou dvě firmy A a B a každá z nich má svůj Proxy server ve své doméně.
Obrázek ukazuje jak Joe ve firmě A inicializuje spojení s Bobem z firmy B.



Obr. 2: Inicializace spojení Joe – Bob



Uživatel Joe volá Boba a použije adresu sip:bo sip:bob@b.com. UA neví,
kam má poslat žádost o sestavení spojení, ale je nakonfigurován tak, že všechen odchozí provoz (outbound traffic) posílá na SIP proxy server své firmy s adresou proxy.a.com. Proxy server zjistí, že uživatel sip:bob@b.com je v jiné firmě a tak vyhledá odpovídající SIP proxy server, kam pošle žádost. Odpovídajícím serverem je proxy.b.com a je zadán staticky v proxy serveru firmy A anebo bude Proxy vyhledán pomocí záznamu DNS SRV. Žádost tedy dorazí na proxy.b.com. Proxy ví, že Bob je aktuálně ve své kanceláři a dosažitelný na telefonu na svém stole, jež má IP adresu 1.2.3.4, takže Proxy na ní posílá žádost. Zmínili jsme se o tom, že SIP proxy na proxy.b.com zná současnou polohu Boba, ale neřekli jsme, jak Proxy může lokalizovat uživatele. Bobův UA (SIP telefon) musí být registrován na registrar serveru. Registrar server je speciální část SIP serveru, která přijímá od uživatelů požadavky na registraci, tím získává
informaci o jejich aktuální poloze (IP adresa, port a uživatelské jméno) a ukládá informaci do lokalizační databáze (location database).
V lokalizační databázi v našem případě došlo k namapování adresy sip:bob@b.com k adrese sip:bob@1.2.3.4:5060. Lokalizační databáze je pak užívána Proxy serverem. Když Proxy server obdrží žádost pro sip:bob@b.com, vyhledá v lokalizační databázi záznam sip:bob@1.2.3.4:5060 a tam pošle žádost. Registrar server je velmi
často pouze jako logická část SIP serveru, jelikož je těsně svázán s Proxy serverem.


Redirect a Registrar server
Další Obrázek znázorňuje typickou SIP registraci.

Zpráva REGISTER je vyslána do Registrar serveru a obsahuje adresu záznamu sip:jan@iptel.org a kontaktní adresu sip:jan@1.2.3.4:5060 ,

kde 1.2.3.4 je IP adresa telefonu. Registrar zaznamenává
tyto informace do lokalizační databáze.



Pokud registrace proběhla správně, tak
Registrar server posílá odpověď 200 OK a proces registrace je ukončen.
 
 
Obr. 3: Registrar server



Každá registrace má limitovanou dobu platnosti, doba platnosti je v hlavičce kontaktu,

do té doby musí UA obnovit registraci, jinak bude nedostupný.
 
 
Obr. 4: Redirect server a přesměrování volání
 
Entita, která přijímá požadavek a odesílá zpět odpověď obsahující lokalizaci konkrétního uživatele se nazývá Redirect server. Redirect server přijímá požadavky a vyhledává zamýšlené příjemce v lokalizační databázi vytvořené registrar serverem. Následně vytváří seznam aktuálních lokalizací uživatele a posílá jej odesílateli požadavku v odpovědi zařazené do třídy 3xx. Odesílatel požadavku poté dostává seznam destinací a odesílá další požadavky přímo na ně. Obrázek 4 ukazuje typické přesměrování.

Nahoru

Metody a odpovědi
 
Komunikace užívající SIP (signalizaci) je tvořena zprávami, které jsou obvykle přenášeny v samostatných UDP datagramech. Každá zpráva obsahuje hlavičku zprávy (header) a vlastní obsah (body). V prvním řádku zprávy je identifikován její typ.

Známe dva typy zpráv :
 
  • • žádost (metoda),
  • • odpověď.
Žádosti jsou obvykle užívány k inicializaci procedury (sestavení, ukončení
spojení) nebo oznamují příjemci požadavek. Odpovědi jsou užívány k potvrzení, že žádost byla přijata a zpracována a obsahuje stav zpracování.

Typická SIP žádost vypadá následovně:

INVITE sip:7170@iptel.org SIP/2.0
Via: SIP/2.0/UDP 195.37.77.100:5060
Max-Forwards: 10
;From: „jiri“ <sip:jiri@iptel.org>tag=76ff7a07-c091-4192-84a0-
d56e91fe104f
To: <sip:jiri@bat.iptel.org>
Call-ID: d10815e0-bf17-4afa-8412-d9130a793d96@213.20.128.35
CSeq: 2 INVITE
Contact: <sip:213.20.128.35:9315>
User-Agent: Windows RTC/1.0
Proxy-Authorization: Digest username=„jiri“, realm=„iptel.org“,
algorithm=„MD5“, uri=„sip:jiri@bat.iptel.org“,
nonce=„3cef753900000001771328f5ae1b8b7f0d742da1feb5753c“,
response=„53fe98db10e1074
b03b3e06438bda70f“
Teorie a praxe IP telefonie – 2. dvoudenní odborný seminář
Hotel Olšanka, 8. a 9. listopadu 2006
strana 45
Content-Type: application/sdp
Content-Length: 451
v=0
o=jku2 0 0 IN IP4 213.20.128.35
s=session
c=IN IP4 213.20.128.35
b=CT:1000
t=0 0
m=audio 54742 RTP/AVP 97 111 112 6 0 8 4 5 3 101
a=rtpmap:97 red/8000
a=rtpmap:111 SIREN/16000
a=fmtp:111 bitrate=16000
a=rtpmap:112 G7221/16000
a=fmtp:112 bitrate=24000
a=rtpmap:6 DVI4/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap: 3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
První řádek nám říká, že se jedná o zprávu INVITE, jež je užívána k sestavení spojení. URI na první řádce sip:7170@iptel.org se nazývá Request URI a obsahuje URI dalšího skoku zprávy (next hop). V tomto případě bude hostitelem iptel.org. Request URI je tedy aktuální adresát požadavku. SIP žádost obsahuje v hlavičce jedno nebo více polí Via, jež jsou užívány k záznamu cesty žádosti. Následně jsou užívány ke směrování SIP odpovědí přesně takovou cestou, jakou byly odeslány. Naše INVITE zpráva obsahuje jedno pole Via, které bylo vytvořeno UA, který odeslal žádost. Z pole Via můžeme říct, že UA používá IP adresu 195.37.77.100 a port 5060. Pole hlavičky From a To identifikuje iniciátora volání (volající) a příjemce (volaného). Pole From obsahuje parametr tag, který slouží jako identifikátor dialogu a bude popsán v další kapitole. Pole hlavičky Call-ID je identifikátor dialogu a jeho cílem je identifikovat zprávy náležející jednomu volání. Takovéto zprávy mají stejný identifikátor Call-ID. Ke správě pořadí požadavků je užíváno pole CSeq. Protože žádosti mohou být odeslány nespolehlivým přenosem, který může způsobit zpřeházení zpráv, pořadové číslo se musí ve zprávě nacházet, aby příjemce mohl rozpoznat opakování přenosu a selektovat žádosti. V hlavičce je pole

Contact obsahující IP adresu a port, na kterém odesílatel očekává další žádosti odesílané volaným. Hlavička zprávy je oddělena od těla zprávy prázdným řádkem. Tělo zprávy žádosti INVITE obsahuje popis typu média vyhovující odesílateli a kódované v SDP.


Nahoru
Žádosti neboli metody

Žádosti neboli metody specifikované v RFC 3261 jsou následující:
 
  • • INVITE je žádost o inicializaci spojení nebo změnu parametrů již probíhajícího spojení,
  • • ACK tato zpráva potvrzuje přijetí odpovědi na žádost INVITE. Sestavení relace používá „3-way hand-shaking“, volaný periodicky opakuje odpověď
  • (OK), dokud nepřijme ACK, což indikuje, že volající je stále připraven komunikovat,
  • • BYE je zpráva je užívána k ukončení spojení některou z komunikujících
  • stran,
  • • CANCEL je užíván ke zrušení sestavovaného spojení, když volaný ještě nepotvrdil žádost INVITE a volající chce zrušit sestavování spojení,
  • • REGISTER smyslem žádosti je sdělit 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. Registrace jsou časově limitovány a potřebují periodicky obnovovat,
  • • OPTIONS je žádost o zaslání schopností (vlastností) serveru nebo UA.
  • V tabulce 2 je uveden seznam SIP metod, význam a odkaz na RFC, jedná se o základní typy metod.

 

 

Smysl žádosti

Doporučení

Název metody

sestavení relace

RFC 3261

INVITE

potvrzení na INVITE

RFC 3261

ACK

získání schopností entity

RFC 3261

OPTIONS

zrušení dosud nevyřízené žádosti

RFC 3261

CANCEL

ukončení existující relace

RFC 3261

BYE

registrace (svázáno s URI)

RFC 3261

REGISTER

přihlášení k odběru informací

RFC 3265

SUBSCRIBE

doručení informace
(přihlášeným k odběru informací)

RFC 3265

NOTIFY

aktualizace stavu informace na server

RFC 3903

PUBLISH

požadavek jiného UA k relaci
(např. inicializace spojení přes web)

RFC 3515

REFER

přenos zpráv Instant Message

RFC 3428

MESSAGE

aktualizace informace o stabu relace

RFC 3311

UPDATE

potvrzení prozatimní (1xx) odpovědi

RFC 3262

PRACK

přenos signalizačních
informací během relace

RFC 2976

INFO

 Tab. 2: URI a odkazy na doporučení

 
 
Odpovědi
 
Jestliže UA nebo Proxy server obdrží žádost, tak odesílá odpověď.
Každá žádost musí být zodpovězena kromě ACK žádosti.
 
Typická odpověď vypadá následovně:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.30:5060;received=66.87.48.68
From: sip:sip2@iptel.org
To: sip:sip2@iptel.org;tag=794fe65c16edfdf45da4fc39a5d2867c.b713
Call-ID: 2443936363@192.168.1.30
CSeq: 63629 REGISTER
Contact: <sip:sip2@66.87.48.68:5060;transport=udp>;q=0.00;expires=120
Server: Sip EXpress router (0.8.11pre21xrc (i386/linux))
Content-Length: 0
Warning: 392 195.37.77.101:5060 „Noisy feedback tells:
pid=5110 req_src_ip=66.87.48.68 req_src_port=5060 in_uri=sip:iptel.org
out_uri=sip:iptel.org via_cnt==1“
smysl žádosti název metody doporučení
sestavení relace INVITE RFC 3261
potvrzení na INVITE ACK RFC 3261
získání schopností entity OPTIONS RFC 3261
zrušení dosud nevyřízené žádosti CANCEL RFC 3261
ukončení existující relace BYE RFC 3261
registrace (svázáno s URI) REGISTER RFC 3261
přihlášení k odběru informací SUBSCRIBE RFC 3265
doručení informace (přihlášeným k odběru informací) NOTIFY RFC 3265
aktualizace stavu informace na server PUBLISH RFC 3903
požadavek jiného UA k relaci (např. inicializace spojení přes web) REFER RFC 3515
přenos zpráv Instant Message MESSAGE RFC 3428
aktualizace informace o stabu relace UPDATE RFC 3311
potvrzení prozatimní (1xx) odpovědi PRACK RFC 3262
přenos signalizačních
informací během relace INFO RFC 2976

Jak můžeme vidět, odpovědi jsou velmi podobní žádostem, kromě prvního
řádku. První řádek odpovědi obsahuje verzi protokolu (SIP/2.0), kód odpovědi (reply code). Kód odpovědi je celé číslo z rozsahu 100 až 699 a označuje typ odpovědi.
Celkem je 6 tříd odpovědí:
 
  • 1xx jsou informativní odpovědi, které jsou odesílány na žádosti, které byly přijaty, ale výsledek zpracování ještě není znám, na základě této odpovědimusí odesílatel zastavit opakování odesílání dané žádosti. Obvykle proxy servery odesílají odpovědi s kódem 100 (Trying), jestliže začínajízpracovávat INVITE a UA odesílají odpovědi s kódem 180 (Ringing), kteréoznamují vyzvánění volaného,
  • 2xx jsou pozitivní finální odpovědi, je to poslední odpověď, kterou odesílatel na svou žádost dostává, vyjadřuje výsledek zpracování konkrétní žádosti. Odpovědi s kódy 200 až 299 oznamují, že požadavek byl akceptován a úspěšně zpracován, například odpověď 200 OK je vyslána, jestliže uživatel akceptuje žádost INVITE. V případě větvení zprávy INVITE můžeme dosáhnout několik UAS a každý z nich bude akceptovat žádost.V tomto případě je každá odpověď rozlišena parametrem tag v poli To. Každá odpověď probíhá v odlišném dialogu s jedinečným identifikátoremdialogu,
  • • 3xx odpovědi jsou užívány k přesměrování. Tyto odpovědi dávají informaci o nové poloze uživatele nebo alternativní službě, která má být použita. Pokud Proxy přijme žádost a nezpracuje ji z nějakého důvodu, tak vyšle volajícímu v odpovědi požadavek na přesměrování a vloží do odpovědi jiné umístění, které má být kontaktováno. Může to být jiná Proxy nebo aktuální umístění volajícího (z lokalizační databáze vytvořené registrar serverem). Volající následně znovu vyšle žádost na nové umístění, odpovědi 3xx jsou konečné,
  • • 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 znamenají problém na straně serveru. Žádost je zřejmě v pořádku, ale server selhal při zpracování, klient by měl obvykle požadavek zkusit znovu,
  • • 6xx tento kód je vysílán, pokud žádost nemůže být splněna na žádnémserveru, to je odpověď obvykle vysílaná serverem, když má informacio konkrétním uživateli, např. UA vysílá 603 Decline response, když odmítá žádost o sestavení spojení,
 
 
Třída Kód Typické příklady
informativní a prozatimní 1 xx 100 Trying
180 Ringing
183 Session Progress
úspěšné 2 xx 200 OK
202 Accepted
přesměrování 3 xx 300 Moved
302 Multiple Choices
305 Use Proxy
chyba u klienta 4 xx 401 Unauthorized
403 Forbidden
415 Unsupported Media Type
486 Busy Here
428 Use Identity Header
chyba na serveru 5 xx 501 Not Implemented
503 Service Unavailable
globální chyba 6 xx 600 Busy Everywhere
603 Decline

Tab. 3: Typické odpovědi
 
Kromě odpovědi odpovídající třídy, první řádka obsahuje popis reason phrase, obsažený kód - určen ke zpracování, což je snadno analyzovatelné a popis lidsky oznamuje výsledek., UA může popis zobrazit uživateli. Přiřazení žádosti k odpovědi je na základě pole CSeq v hlavičce, kromě pořadového čísla obsahuje také metodu korespondující žádosti, v našem případě to byla žádost REGISTER.
Na obrázku 5 jsou pole žádosti INVITE a konečné odpovědi na ni 200 OK, zobrazeny jsou i obsahy SDP (popis médií).
 
Třída kód typické příklady:

Informace a prozatímní stav 1xx:
100 Trying

180 Ringing
183 Session Progress
úspěšně spojeno (navázáno) 2xx:
200 OK
202 Accepted

Přesměrování 3xx:
300 Moved

302 Multiple Choices
305 Use Proxy

Chyba u klienta 4xx:
401 Unauthorized
403 Forbidden
chyba u klienta 4xx 415 Unsupported Media Type
486 Busy Here
428 Use Identity Header

Chyba na serveru (mimo volajícíhoi) 5xx:
501 Not Implemented

503 Service Unavailable

Globální chyba 6xx:
600 Busy Everywhere

603 Decline
(Přihlášení k PBX např.:"register=246xxxxxx:SIP heslo:246xxxxxx@sip.volny.cz")
 
Obr. 5: Žádost a odpověď


Následně si vysvětlíme, co je to SIP transakce. Ačkoliv bylo řečeno, že SIP zprávy jsou posílány sítí nezávisle, tak obvykle jsou uspořádány do transakcí agenty UA a určitými typy Proxy serverů. Transakce je sekvence SIP zpráv vyměňovaných mezi síťovými SIP prvky. Transakce obsahuje jednu žádost a všechny odpovědi vztažené k této žádosti. To může znamenat žádnou, jednu nebo i více prozatimních odpovědí a jednu nebo více konečných odpovědí (např. při větvení v Proxy na zprávu INVITE).

Jestliže byla transakce zahájena žádostí INVITE , pak stejná transakce obsahuje i zprávu ACK, ale pouze tehdy, jestliže finální odpověď nebyla třídy 2xx, potom ACK není součástí dané transakce, důvodem je, že odpověď je zpráva 200 OK. Především UA jsou zodpovědni za opakování odpovědi 200 OK, dokud nepřijmou ACK. SIP entity, které sledují tyto transakce, se nazývají stateful, tzn. se záznamem o stavech. Vytvořený stav je spojován s transakcí a je držen v paměti po celou dobu trvání transakce. Pokud přichází žádost nebo odpověď, tak je zkoušeno vždy přiřazení zprávy do probíhající transakce. Aby tato operace byla proveditelná, tak musí ze zprávy přečíst jednoznačný identifikátor transakce a porovnat jej s identifikátory probíhajících transakcí. Jestliže takováto transakce existuje, tak dochází k jejímu doplnění o další informace. V předchozím SIP RFC2543 byl identifikátor transakce odvozován ze všech důležitých informací v hlavičce zprávy (zahrnující pole To, From, Request-URI a CSeq), což bylo komplikované a zpomalovalo zpracování a při testech interoperability bylo zdrojem problémů.
 
 
Obr. 6: Transakce

V novém RFC3261 byl způsob výpočtu identifikátoru transakce zásadně změněn. Namísto komplikovaného určování z polí hlavičky teď obsahuje SIP zpráva identifikátor přímo v políčku Via. To je významné zjednodušení, ale stále existují staré implementace, které nepodporují nový způsob určování identifikátoru transakce, proto musí být určování zpětně kompatibilní s oběmi verzemi. Obrázek 6. znázorňuje zprávy zařazené do transakcí během konverzace dvou UA.
 
 
Obr. 7: Dialog

V předchozím příkladě jsme si ukázali dvě transakce, jedna transakce obsahovala zprávu INVITE a odpověď, druhá obsahovala zprávu BYE a následnou odpověď. Obě transakce však spolu souvisí a náleží do jednoho dialogu. Dialog bychom mohli definovat jako soubor SIP zpráv peer-to-peer mezi dvěma UA, které mají vzájemnou spojitost. Dialogy popisují řazení a směrování zpráv mezi dvěma koncovými body. Dialogy jsou identifikované pomocí pole Call-ID, From a To. Zprávy, které mají tyto tři identifikátory stejné, tak náleží jednomu dialogu.

Ukázali jsme si, že pole CSeq je užíváno k řazení zpráv, je používáno k řazení zpráv uvnitř dialogu. CSeq číslo určuje transakci uvnitř dialogu, protože jsme řekli, že žádost a přidružená odpověď se nazývá transakce. To znamená, že v každém směru může být uvnitř dialogu aktivní pouze jedna transakce. Mohli bychom také tvrdit, že dialog je posloupnost transakcí. Obrázek 7 rozšiřuje obrázek 6 a ukazuje, které zprávy náleží jednomu dialogu. Pomocí CSeq snadno rozpoznáme zprávy dialogu. Dialogy usnadňují řízení komunikace, protože UA nedrží stavy dialogu. Například zpráva INVITE zahajuje dialog a zahajuje spojení, zpráva BYE patří do dialogu, protože ukončuje spojení, viz. [8], [9].


  Registrace a autentizace

Uživatelé se musí sami registrovat na Registrar serveru, aby byli dosažitelní. Registrace se skládá ze zprávy REGISTER následovanou odpovědí 200 OK, kterou posílá registrar v případě, že je registrace úspěšná. Pokud jsou registrace ověřovány, tak uživatel může dostat negativní odpověď 401 nebo 407, vysvětlující, že tato registrace
není oprávněná, tento případ je na obrázku 8.
Základním prvkem bezpečnosti je autentizace, která v SIPu vzhledem tomu, že ideovým rodičem je protokol HTTP, používá schéma HTTP Digest. Ve starší verzi standartu (RFC 2543) bylo uváděno i HTTP Basic, které již ovšem podle RFC 3261 nesmí být používáno, tj. vyžadováno ani přijímáno. V rámci komunikace se ještě rozlišuje autentizace mezi uživateli (User-to-User) a mezi proxy serverem a uživatelem (Proxy-to-User). S prvním případem se setkáme nejčastěji u registrace. Registrační
server je koncovým příjemcem požadavku, a proto je použita metoda User-to-User. Pokud nejsou potřebné údaje ve zprávě vyplněny, cílový klient posílá odpověď 401 Unauthorized a hlavička WWWAuthenticate obsahuje výzvu, viz. [10].
 
 
Obr. 8: Registrace


V případě, že proxy server potřebuje před zpracováním požadavku uživatele ověřit, žádá o to v odpovědi 407 Proxy Authentication Required a v hlavičce Proxy-Authenticate je obsažena výzva. Klient doplní do požadavku hlavičku Proxy-Authorization s patřičnými údaji. Celá procedura úspěšné registrace je pochopitelně zakončena konečnou odpovědí 200 OK.

Status-Line: SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP
195.113.150.114;rport=5060;branch=z9hG4bKc37196720000000b4536f34100 0
From: <sip:voznak@cesnet.cz>;tag=710614011481
To: <sip:voznak@cesnet.cz>;tag=c10ed4fff3e6fb17efd0bfbdcce87ce2.7c9b
Call-ID: 67C3FC83-B95C-4947-BAEB-12B222752CDB@195.113.150.114
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm=„cesnet.cz“,
nonce=„4536f4663721fbab2737d9f7131d2b4b9082b163“

Zdroj pak zopakuje požadavek s ověřovacími údaji odpovídajícími výzvě

v hlavičce Authorization.
Via: SIP/2.0/UDP
195.113.150.114;rport;branch=z9hG4bKc37196720000000b4536f341000
From: <sip:voznak@cesnet.cz>;tag=710620356
To: <sip:voznak@cesnet.cz>
Contact Binding: <sip:voznak@195.113.150.114>
Call-ID: 67C3FC83-B95C-4947-BAEB-12B222752CDB@195.113.150.114
CSeq: 2 REGISTER
Authorization: Digest username="voznak",realm="cesnet.cz", nonce="
4536f4663721fbab2737d9f7131d2b4b9082b163", uri="sip:cesnet.cz", response="
6bc245acb462a5d319ccefe9cb5bec3a"
 
 
Směrování spojení

Dialogy jsou užívány ke směrování zpráv mezi agenty. Předpokládejme, že
uživatel sip:bob@a.com chce volat uživatele sip:pete@b.com. Zná SIP adresu volaného sip:pete@b.com , ale tato adresa jasně nevypovídá o jeho aktuální lokalizaci, volající v prvé řadě odesílá žádost INVITE na Proxy server. Žádost bude odesílána z jednoho Proxy na druhý, dokud nebude volaný lokalizován, což je proces směrování. UA volajícího odešle odpověď volanému a uvnitř pole Contact bude obsažena jeho lokalizace. Původní žádost rovněž obsahuje pole Contact a tak oba UA mají informaci o své poloze. Protože oba UA už znají svou polohu, není nutné posílat další žádosti na Proxy a mohou být zasílány přímo mezi UA.
 
 
Obr. 9: Směrování



Další zprávy dialogu jsou zasílány přímo, Proxy nedostává všechny zprávy
dialogu, přímo směrované zprávy jsou doručeny s podstatně menším zpožděním, protože typická Proxy obsahuje složitou směrovací logiku.
Obrázek 9 ukazuje příklad zprávy uvnitř dialogu (BYE) , jež obchází Proxy.
 
Obr. 10: INVITE
 

Volající Volaný

Už jsme se zmínili, že identifikátory dialogu obsahují tři části Call-Id,
From a To. Call-ID je také nazýván jako identifikátor hovoru. Musí to být jedinečný řetězec znaků identifikující jedno spojení, které obsahuje jeden nebo více dialogů. Pokud se jednoho spojení účastní více UA, například v případě větvení na Proxy, tak odpovídají na žádosti a každý UA odesílá 2xx a vytváří separátní dialog s volajícím. Všechny tyto dialogy jsou ale součástí jednoho hovoru a mají stejné Call-ID. Do pole From je generováno volajícím označení (tag) jako jedinečný identifikátor dialogu. Do Pole To je označení vytvořené volaným jako jedinečný identifikátor v dialogu. Takto zvolené označení identifikátorů hovoru je nutné, protože jednoduchá inicializace spojení INVITE může znamenat několik dialogů s odpovědí a volající musí být schopen mezi nimi rozlišit. Zahájení spojení obsahuje jednu žádost INVITE obvykle odeslanou na Proxy. Proxy server okamžitě odpovídá zprávou 100 Trying, což pro volajícího znamená, aby neopakoval žádost, že je požadavek přeposílán dál. Všechny informativní odpovědi generované volaným jsou posílané volajícímu, např. zpráva 180 Ringing, viz. obr. 10. Zpráva 200 OK je generována ve chvíli, kdy volaný vyzvedne a je opakována, dokud odesílající UA neobdrží ACK od volajícího, v té chvíli je možné považovat spojení za sestavené. Spojení je ukončeno odesláním žádosti BYE v rámci dialogu zahájeného zprávou INVITE. Zprávy BYE jsou odesílány přímo z jednoho UA druhému UA, jestliže Proxy nepotřebuje zaznamenávat směrování. Účastník spojení, který zavěsí, odesílá zprávu BYE a z druhé strany, která se účastní spojení, přichází odpověď 200 OK, ta potvrzuje zprávu BYE a spojení je ukončeno, viz. obrázek. Veškeré požadavky odeslané v rámci dialogu jsou standardně odeslány přímo z jednoho UA jinému. Je několik situací, ve kterých SIP Proxy potřebuje sledovat všechny zprávy, například Proxy když spolupracuje s NAT nebo pokud zajišťuje účtování, tak musí dostávat zprávu BYE. Mechanizmus, kterým Proxy může informovat UA, že si přeje dostávat všechny další zprávy spojení, se nazývá směrování se záznamem. Proxy server vloží do hlavičky SIP zprávy pole Record-Route, kde udá svoji adresu a všechny zprávy v rámci tohoto dialogu jsou posílány na SIP Proxy. Pokud příjemce žádosti obdrží řadu polí Record-Route , tak je musí do odpovědi rovněž zařadit, protože odesílatel je rovněž potřebuje znát.


 
Obr. 11: BYE zpráva (směrování se záznamem a bez záznamu)
 
Na obrázku vlevo je zobrazení zpráv, které jsou směrovány přímo a vpravo je dialog, ve kterém se pracuje s polem Record-Route, což zásadně mění situaci ve směrování. U staršího RFC2543 se směrování se záznamem provádělo pomocí změny Request-URI, které bylo přepsáno. To znamená, že Request-URI vždy obsahovalo URI dalšího skoku (což může být jiný Proxy server nebo cílový UA). Jako poslední záznam pole Route (pro směrování) muselo být vloženo vždy původní Request-URI. Tomuto způsobu se říká přesně vymezené směrování (strict routing). Volné směrování (Loose routing) je specifikován v RFC3261 a pracuje
trošku odlišným způsobem. Request-URI není přepisováno a vždy obsahuje URI cílového UA. Jestliže pole Route v hlavičce obsahuje nějaký záznam, tak zpráva je poslána na URI nejvýše uvedeného záznamu (první v pořadí). Přechod mezi oběma typy směrování vyžaduje zpětnou kompatibilitu, především pro starší UA a to bývá častým zdrojem problémů.
 
Prezence a Instant Messaging

Specifikace SIPu byla rozšířena o podporu mechanizmů umožňující se přihlásit k odběru určitých informací a následně zasílat události jako jsou například výměny statistik se SIP Proxy, informace o osobě, změny spojení, atd... Mechanizmus je užíván hlavně k zprostředkování informací o osobách (např. ochotných komunikovat).
 
 
Obr. 12: Popis událostí a oznamování
 
Obrázek 13 ukazuje základní tok zpráv. UA, který chce dostávat oznámení, tak posílá zprávu SUBSCRIBE na SIP server. Zpráva SUBSCRIBE zahajuje dialog a server okamžitě odpovídá 200 OK. Od této chvíle je dialog sestaven a server zasílá žádost NOTIFY pokaždé, jestliže se změní událost, kterou chce uživatel sledovat. Zprávy NOTIFY jsou zasílány v rámci dialogu zahájeného zprávou SUBSCRIBE. Na obrázku je možné zaznamenat, že první zpráva NOTIFY je odeslána bez ohledu na událost spouštějící oznámení. Přihlášení k oznamování stejně jako registrace má
omezenou platnost, časově limitovanou a musí být periodicky obnovována. Zasílání naléhavých zpráv používá žádost MESSAGE. Zpráva MESSAGE nesestavuje dialog a text naléhavé zprávy je přenášen uvnitř SIP žádosti.

 
Obr. 13: Naléhavé zprávy



Využití DNS pro adresaci
 
Jak již bylo zmíněno, SIP entity jsou identifikovány použitím SIP URI (Uniform Resource Identifier), SIP URI má formát sip:user@host. SIP je vázán na doménu, to je důležitá vlastnost protokolu, pokud SIP Proxy obdrží INVITE s uživatelem jehož doménu nezná, může se dotázat DNS a zpravidla dostane zpět adresu SIP Proxy, která doménu obsluhuje. V DNS může být tento účel vytvořen SRV záznam. SRV záznam (service record) v DNS obsahuje specifické informace o dostupných službách, je definován v RFC 2782 z roku 2000.

SRV záznam poskytuje následující informace:
 
  • Service, symbolické jméno požadované služby,
  • Protocol, obvykle TCP nebo UDP,
  • Domain name, název domény pro níž je záznam platný,
  • TTL: pole pro expiraci,
  • Class: pole pro třídu (vždy IN),
  • Priority: priorita pro cíl, nižší číslo bude dřív vybráno
  • Weight: váha priority záznamu, při více spojení se stejnou prioritou je brána dříve v potaz vyšší váha,
  • Port: TCP nebo UDP port, na kterém je služba dostupná,
  • Target: název stroje (hostname) poskytujícího službu.

SRV záznam může vypadá následovně:


_sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com.
SRV nám vyřeší doménové jména, ale problém máme s telefonními čísly, protože SIP URI je vázáno na doménu a pokud bychom nahradili položku username telefonním číslem (e164), tak stále máme problém, jak se dovolat mimo svou doménu anebo přesněji, jak zjistit, která SIP Proxy obslouží volání na žádané číslo. Tento problém vyřešil ENUM. Standard ENUM přináší mapování telefonních čísel E.164 do doménových jmen. Lze ho chápat jako most mezi číselnými identifikátory telefonních sítí definovaných v ITU-T E.164 a jmennými identifikátory URI uložených v záznamech DNS a užívanými v Internetu. V roce 2000 byl ENUM poprvé popsán v RFC 2916, autorem byl švédský inženýr Patrik Fältström.
Nápad navázat telefonní čísla do DNS vzbudil velký zájem, jelikož protokol IETF SIP od původní verze přímo používá identifikátory URI (Uniform Resource Identifiers) a ITU-T H.323 od druhé verze umožňuje používání URI. Diskuze mezi odbornou veřejností vedla k další verzi ENUM v RFC 3761 z dubna roku 2004 a nahradila předchozí specifikaci protokolu z roku 2000. Pro ENUM se užívá doména e164.arpa a ta je delegována se souhlasem zástupce státu v ITU-T na organizaci, která se stává správcem národní domény. V případě ČR je to subdoména 0.2.4.e164.arpa a správcem této domény je CZ NIC. Standard ENUM (tElephone NUmbers Mapping) se vytváří ve spolupráci mezinárodní telekomunikační unie ITU a organizace Internet Engineering Task Force IETF. Cílem této spolupráce je standard na mapování telefonních čísel do systému doménových jmen DNS (Domain Name System), který by byl použitelný ke komerčním účelům. Tento standard je klíčovým prvkem pro konvergenci sítí založených na protokolu IP (Internet Protocol) a tradičních telefonních sítí s přepínáním okruhů PSTN (Public Switched Telephone Network). První část služby ENUM tvoří čísla ITU-T doporučení E.164. Za tímto účelem byla v ITU-T založena studijní skupina (SG2); pracuje na administrativních postupech týkajících se služby ENUM. Druhou část vytváří organizace IETF, kde tato služba vznikla a spočívá v začlenění tohoto standardu do struktury systému doménových jmen DNS. V souvislosti s IP telefonní je hlavním cílem ENUM zprostředkovat identifikaci a adresovat klienta služby přes internet na základě univerzálního identifikátoru, kterým bude telefonní číslo. V dubnu roku 2004 byl standard ENUM definován v dokumentaci IETF RFC 3761 The E.164 to Uniform Resource Identifiers
(URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM), viz. [11], [12]. Princip standardu ENUM spočívá v mapování telefonního čísla podle E.164 na řetězec znaků URI, který slouží k identifikaci služby nebo zdrojů, jako jsou dokumenty, soubory, maily a prakticky veškeré elektronické adresy v internetu prostřednictvím systému doménových jmen. Například https://www.enum.nic.at je URI pro rakouské webové stránky pro projekty ENUM. Výsledkem mapování telefonního čísla podle E.164 do systému DNS je naformátované telefonní číslo zapsané v opačném pořadí číslic navzájem oddělených tečkami, vložené do subdomény e164.arpa. Tato subdoména byla vytvořena pro účely standardu ENUM.

Samotné mapování telefonního čísla na URI vypadá následovně:


• z použitého telefonního čísla v mezinárodním formátu např. +420596991699“ odstraníme všechny znaky kromě číslic,

• mezi jednotlivé číslice se vloží tečky „4.2.0.5.9.6.9.9.1.6.9.9“,

• číslice se zapíší v opačném pořadí „9.9.6.1.9.9.6.9.5.0.2.4“,

• výsledný tvar se vloží do domény e164.arpa „ 9.9.6.1.9.9.6.9.5.0.2.4.e164.arpa“,

• do systému DNS se vyšle dotaz na NAPTR záznam pro příslušné doménové jméno,

• systém DNS nám vrátí příslušnou URI pro požadovanou službu např.
sip:420596991699@cesnet.cz“.

Pro praktickou realizaci aplikace je nutné, aby některý z prvků sítě VoIP
prováděl ENUM resolving. Tuto funkci mohou plnit buď koncoví klienti nebo SIP server. V současné době je z praktického hlediska pro ENUM resolving nejvýhodnější použití SIP serveru. Nejznámější open source aplikace, které umožňují službu SIP serveru s podporou ENUM resolvingu jsou SER (SIP Expres Router) a Asterisk, které pracují pod systémem Linux. Na obrázku je znázorněn průběh adresace pomocí ENUM, aby DNS server prováděl překlad adres pro službu ENUM, musí podporovat NAPTR (The Naming Authority Pointer) záznamy. V současnosti nejpoužívanější program pro službu DNS serveru, který splňuje tuto podmínku je deamon BIND (Berkeley Internet Name Domain), aktuálně verze 9. Jako koncového klienta lze využít softwarový nebo hardwarový telefon pracující s protokolem SIP.

DNS server musí obsahovat příslušný záznam,
např.:

$ORIGIN 9.9.6.1.9.9.6.9.5.0.2.4.e164.arpa.

IN NAPTR 100 10 „u“ „E2U+sip“ „!^+(.*)$!sip:1@cesnet.cz!“ .
IN NAPTR 200 10 „u“ „E2U+h323“ „!^+(.*)$!h323:1@gk1ext.cesnet.cz!“

Formát NAPTR je předepsán ve tvaru:

label IN NAPTR order pref #„u“ „E2U+enumservice“ regexp .
Tvar obsahuje pořadí (order), upřednostnění (pref) a aplikující se regulární
výraz (regexp). Výsledkem je URI adresa.ENUM definuje E2U pro službu, která je očekávána pro:

• SIP jako E2U+sip, např. s URI sip:miroslav.voznak@sip.vsb.cz,

• H.323 jako E2U+h323, např. s URI h323:miroslav.voznak@h323.vsb.cz,


• Internet FAX jako E2U+ifax, např. s URI mailto:fax@fax.vsb.cz,


• Telephone jako E2U+tel, např. s URI tel:+596991699:svc=voice,


• Fax jako E2U+fax:tel, např. s URI tel:+596991699:svc=fax,


• Email jako E2U+email:mailto, např. s URI mailto:miroslav.voznak@vsb.cz,


• Web jako E2U+web:http, např. s URI https://www.vsb.cz.


Pro vyhledání NAPTR můžeme v Linuxu aplikovat příkazy:


host -t naptr 9.9.6.1.9.9.6.9.5.0.2.4.e164.arpa
dig -t naptr NUMMER.e164.arpa.

Obdobně pro vyhledání SRV záznamů můžeme v Linuxu aplikovat příkaz:


host -t SRV _sip._udp.cesnet.cz

host -t SRV _sip._tcp.cesnet.cz

V případě Windows je použitelný příkaz nslookup pro vyhledání SRV, bohužel
naptr nezná:
nslookup
>set q=srv
>_sip._udp.cesnet.cz

Kromě veřejného stromu e164.arpa je možné si vytvořit libovolný privátní
strom, např. e164.cesnet.cz, ale číslo bude dosažitelné pouze uvnitř instituce anebo klientům, kteří se budou takovéto DNS dotazovat, což jde ošetřit na úrovni SIP Proxy nebo koncového zařízení. Privátní stromy nezaručují obecnou dostupnost a omezují se na skupinu nebo instituci. Pro více stromů musí být pochopitelně více dotazů a dochází k štěpení, proto je žádoucí používat e164.arpa. Na obrázku je adresace klienta s použitím ENUM. Vidíme, že klient odeslal INVITE s tel.č., z DNS byla vrácena SIP URI, která pak umožnila nalézt cílový SIP PROXY (pomocí
SRV). ENUM můžeme použít jako vyhledávací mechanizmus na osobním počítači, protože na základě univerzální identifikace (telefonního čísla) získáme informace o všech možných přístupech k požadovanému subjektu. Do databáze služby ENUM budou zařazena i negeografická čísla. Společnosti tak mohou používat jako adresu svých webových na místo doménového jména, které bývá často špatně zapamatovatelné např. číslo Zelené linky. Koncoví klienti sítě VoIP nemusí mít vlastní telefonní číslo, ale mohou použit číslo přidělené pevné lince.





Obr. 14: Adresace klienta SIP v síti VoIP pomocí ENUM




Možnosti služby ENUM jsou rozsáhle a lze očekávat, že praxe najde další
aplikace pro využití tohoto standardu. Aby bylo možné zahájit zkušební projekty ENUM je nutné zajistit možnost registrace. V červnu roku 2003 byla delegována na CZ NIC česká doména ENUM 0.2.4.e164.arpa a následně sdružení CESNET začalo experimentovat se standardem ENUM v rámci své akademické sítě. V současnosti je CESNET největším držitelem čísel alokovaných v doménách, jedná se o cca 200 tis. čísel.


Praktická ukázka SIPu

Zachycení jakékoliv komunikace na IP a její rozklíčování umožňuje nepřeberné množství aplikací jak pro Windows, tak i pro Linux. Bezkonkurenčně nejlepším nástrojem v poměru ceny a výkonu je aplikace Wireshark volně šiřitelná pod licencí GNU GPL. Wireshark přímo navazuje na Ethereal, je jeho následovníkem. Mnozí možná znají označení Ethereal, v polovině roku 2006 odešel původní autor Etherealu pracovat do nejmenované komerční firmy a nečekaně vzal sebou i registrovanou značku Ethereal. Pro zachování open source vývoje bylo nutné změnit název.


Na obrázku 14. je znázorněna komunikace v grafu, ta se získá přes menu
Statistics -> VoIP Calls, v okně se zobrazí všechny zachycené VoIP spojení, po označení lze vybrat položku graph a získat přehledně označený tok zpráv. Následuje rozparsování jenotlivých zpráv, ale pouze SIP bez SDP. Na obrázku 14 lze vidět, ve kterých zprávách se navíc přenáší SDP, výsledkem je dohoda na kodeku G.711 A law a UDP portech komunikujících stran, tyto položky jsou v SDP označeny jako Media format a Media port. RTP pakety jsou přenášeny už před přihlášením (200 OK), jelikož byl poslán 183 Session Progress, který obsahoval část SDP. Komunikace začala žádostí INVITE, která ovšem vyžadovala autentizaci na SIP Proxy (407 Authentication Required), po opakovaném odeslání INVITE rozšířeném o pole Proxy-Authorization, byl přijat 100 Trying.
Stateful Proxy odesílá 100 Trying okamžitě po přijetí INVITE a nečeká na 100 Trying od další SIP Proxy nebo UA, později přijatý 100 Trying už dále nepřeposílá. Jedná se o případ tohoto spojení, použitá SIP Proxy je SIP Express Router, což je i čitelné z rozparsovaných zpráv. Jak už bylo zmíněno, tak 183 Session Progress nese i část SDP a následně mohou být přenášeny RTP pakety již před přihlášením. Po přihlášení přichází konečná odpověď 200 OK potvrzená žádostí ACK. Ukončení spojení proběhlo ze strany volaného žádostí BYE, která byla potvrzena konečnou odpovědí 200 OK. Následuje rozparsovaný sled zpráv SIP vyměněných během spojení.



Request-Line: INVITE sip:596995779@cesnet.cz SIP/2.0
Method: INVITE
Resent Packet: False
Message Header
Via: SIP/2.0/UDP
195.113.150.114;rport;branch=z9hG4bKc3719672000000194536f381000006f20
0000005
From: "unknown"<sip:voznak@cesnet.cz>;tag=717026516927
SIP Display info: "unknown"
SIP from address: sip:voznak@cesnet.cz
SIP tag: 717026516927
To: <sip:596995779@cesnet.cz>
SIP to address: sip:596995779@cesnet.cz
Contact: <sip:voznak@195.113.150.114>
Contact Binding: <sip:voznak@195.113.150.114>
URI: <sip:voznak@195.113.150.114>
SIP contact address: sip:voznak@195.113.150.114
Call-ID: 34717910-B1CD-4563-9301-481F2F702E24@195.113.150.114
CSeq: 1 INVITE
Max-Forwards: 70
User-Agent: SJphone/1.61.321a (SJ Labs)
Content-Length: 246
Content-Type: application/sdp
Message body
Status-Line: SIP/2.0 407 Proxy Authentication Required
Status-Code: 407
Resent Packet: False
Message Header
Via: SIP/2.0/UDP
195.113.150.114;rport=5060;branch=z9hG4bKc3719672000000194536f381000
006f200000005
From: "unknown"<sip:voznak@cesnet.cz>;tag=717026516927
SIP Display info: "unknown"
SIP from address: sip:voznak@cesnet.cz
SIP tag: 717026516927
To: <sip:596995779@cesnet.cz>;tag=c10ed4fff3e6fb17efd0bfbdcce87ce2.be11
SIP to address: sip:596995779@cesnet.cz
SIP tag: c10ed4fff3e6fb17efd0bfbdcce87ce2.be11
Call-ID: 34717910-B1CD-4563-9301-481F2F702E24@195.113.150.114
CSeq: 1 INVITE
Proxy-Authenticate: Digest realm="cesnet.cz",
nonce="4536f4a73fe0b7da3d22aeef5150fc5259b2ab44"
Server: Sip EXpress router (0.9.5-pre1 (i386/linux))
Content-Length: 0
Warning: 392 195.113.144.245:5060 "Noisy feedback tells: pid=30674
req_src_ip=195.113.150.114 req_src_port=5060 in_uri=sip:596995779@cesnet.cz
out_uri=sip:596995779@cesnet.cz via_cnt==1"
Request-Line: ACK sip:596995779@cesnet.cz SIP/2.0
Method: ACK
Resent Packet: False
Message Header
Via: SIP/2.0/UDP
195.113.150.114;rport;branch=z9hG4bKc3719672000000194536f381000006f20
0000005
From: "unknown"<sip:voznak@cesnet.cz>;tag=717026516927
SIP Display info: "unknown"
SIP from address: sip:voznak@cesnet.cz
SIP tag: 717026516927
To:
<sip:596995779@cesnet.cz>;tag=c10ed4fff3e6fb17efd0bfbdcce87ce2.be11
SIP to address: sip:596995779@cesnet.cz
SIP tag: c10ed4fff3e6fb17efd0bfbdcce87ce2.be11
Teorie a praxe IP telefonie – 2. dvoudenní odborný seminář
Hotel Olšanka, 8. a 9. listopadu 2006
strana 65
Call-ID: 34717910-B1CD-4563-9301-481F2F702E24@195.113.150.114
CSeq: 1 ACK
Max-Forwards: 70
User-Agent: SJphone/1.61.321a (SJ Labs)
Content-Length: 0
Request-Line: INVITE sip:596995779@cesnet.cz SIP/2.0
Method: INVITE
Resent Packet: False
Message Header
Via: SIP/2.0/UDP
195.113.150.114;rport;branch=z9hG4bKc3719672000000194536f38100003812
00000006
From: "unknown"<sip:voznak@cesnet.cz>;tag=717026516927
SIP Display info: "unknown"
SIP from address: sip:voznak@cesnet.cz
SIP tag: 717026516927
To: <sip:596995779@cesnet.cz>
SIP to address: sip:596995779@cesnet.cz
Contact: <sip:voznak@195.113.150.114>
Contact Binding: <sip:voznak@195.113.150.114>
URI: <sip:voznak@195.113.150.114>
SIP contact address: sip:voznak@195.113.150.114
Call-ID: 34717910-B1CD-4563-9301-481F2F702E24@195.113.150.114
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: SJphone/1.61.321a (SJ Labs)
Content-Length: 246
Content-Type: application/sdp
Proxy-Authorization: Digest username="voznak",realm="cesnet.cz",nonce="
4536f4a73fe0b7da3d22aeef5150fc5259b2ab44",uri="sip:596995779@cesnet.
cz",response="88ae5edfd89f2f4ce5e9d6d267a99724"
Message body
Status-Line: SIP/2.0 100 trying -- your call is important to us
Status-Code: 100
Resent Packet: False
Message Header
Via: SIP/2.0/UDP
195.113.150.114;rport=5060;branch=z9hG4bKc3719672000000194536f381000
0381200000006
From: "unknown"<sip:voznak@cesnet.cz>;tag=717026516927
SIP Display info: "unknown"
SIP from address: sip:voznak@cesnet.cz
SIP tag: 717026516927
To: <sip:596995779@cesnet.cz>
SIP to address: sip:596995779@cesnet.cz
Call-ID: 34717910-B1CD-4563-9301-481F2F702E24@195.113.150.114
CSeq: 2 INVITE
Server: Sip EXpress router (0.9.5-pre1 (i386/linux))
Content-Length: 0
Warning: 392 195.113.144.245:5060 "Noisy feedback tells: pid=30676
req_src_ip=195.113.150.114 req_src_port=5060 in_uri=sip:596995779@cesnet.
cz out_uri=sip:596995779@195.113.144.77:5060 via_cnt==1"
Status-Line: SIP/2.0 183 Session Progress
Status-Code: 183
Resent Packet: False
Message Header
Via: SIP/2.0/UDP
195.113.150.114;rport=5060;branch=z9hG4bKc3719672000000194536f381000
0381200000006
From: "unknown"<sip:voznak@cesnet.cz>;tag=717026516927
SIP Display info: "unknown"
SIP from address: sip:voznak@cesnet.cz
SIP tag: 717026516927
To: <sip:596995779@cesnet.cz>
SIP to address: sip:596995779@cesnet.cz
Date: Thu, 19 Oct 2006 03:39:38 GMT
Call-ID: 34717910-B1CD-4563-9301-481F2F702E24@195.113.150.114
Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabled
CSeq: 2 INVITE
Content-Type: application/sdp
Session: Media
Content-Length: 140
Message body
Teorie a praxe IP telefonie – 2. dvoudenní odborný seminář
Hotel Olšanka, 8. a 9. listopadu 2006
strana 67
Status-Line: SIP/2.0 183 Session Progress
Status-Code: 183
Resent Packet: False
Message Header
Via: SIP/2.0/UDP
195.113.150.114;rport=5060;branch=z9hG4bKc3719672000000194536f381000
0381200000006
From: "unknown"<sip:voznak@cesnet.cz>;tag=717026516927
SIP Display info: "unknown"
SIP from address: sip:voznak@cesnet.cz
SIP tag: 717026516927
To: <sip:596995779@cesnet.cz>
SIP to address: sip:596995779@cesnet.cz
Date: Thu, 19 Oct 2006 03:39:38 GMT
Call-ID: 34717910-B1CD-4563-9301-481F2F702E24@195.113.150.114
Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabled
CSeq: 2 INVITE
Content-Type: application/sdp
Session: Media
Content-Length: 140
Message body
Status-Line: SIP/2.0 200 OK
Status-Code: 200
Resent Packet: False
Message Header
Via: SIP/2.0/UDP
195.113.150.114;rport=5060;branch=z9hG4bKc3719672000000194536f381000
0381200000006
From: "unknown"<sip:voznak@cesnet.cz>;tag=717026516927
SIP Display info: "unknown"
SIP from address: sip:voznak@cesnet.cz
SIP tag: 717026516927
To: <sip:596995779@cesnet.cz>;tag=1EB4EC64-4F0
SIP to address: sip:596995779@cesnet.cz
SIP tag: 1EB4EC64-4F0
Date: Thu, 19 Oct 2006 03:39:38 GMT
Call-ID: 34717910-B1CD-4563-9301-481F2F702E24@195.113.150.114
Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabled
Contact: <sip:596995779@195.113.113.206:5060;user=phone>
Contact Binding: <sip:596995779@195.113.113.206:5060;user=phone>
URI: <sip:596995779@195.113.113.206:5060;user=phone>
SIP contact address: sip:596995779@195.113.113.206:5060
Record-Route: <sip:195.113.144.245;ftag=717026516927;lr=on>
CSeq: 2 INVITE
Content-Type: application/sdp
Content-Length: 140
Message body
Request-Line: ACK sip:596995779@195.113.113.206:5060;user=phone SIP/2.0
Method: ACK
Resent Packet: False
Message Header
Via: SIP/2.0/UDP
195.113.150.114;rport;branch=z9hG4bKc3719672000000194536f38b000078da0
000000b
From: "unknown"<sip:voznak@cesnet.cz>;tag=717026516927
SIP Display info: "unknown"
SIP from address: sip:voznak@cesnet.cz
SIP tag: 717026516927
To: <sip:596995779@cesnet.cz>;tag=1EB4EC64-4F0
SIP to address: sip:596995779@cesnet.cz
SIP tag: 1EB4EC64-4F0
Call-ID: 34717910-B1CD-4563-9301-481F2F702E24@195.113.150.114
CSeq: 2 ACK
Max-Forwards: 70
User-Agent: SJphone/1.61.321a (SJ Labs)
Content-Length: 0
Route: <sip:195.113.144.245;ftag=717026516927;lr=on>
Session Initiation Protocol
Request-Line: BYE sip:voznak@195.113.150.114:5060 SIP/2.0
Method: BYE
Resent Packet: False
Message Header
Record-Route: <sip:195.113.144.245;ftag=1EB4EC64-4F0;lr=on>
Via: SIP/2.0/UDP 195.113.144.245;branch=z9hG4bK6812.3fca3643.0
Via: SIP/2.0/UDP 195.113.113.206:5060
From: <sip:596995779@cesnet.cz>;tag=1EB4EC64-4F0
SIP from address: sip:596995779@cesnet.cz
SIP tag: 1EB4EC64-4F0
To: "unknown"<sip:voznak@cesnet.cz>;tag=717026516927
SIP Display info: "unknown"
SIP to address: sip:voznak@cesnet.cz
SIP tag: 717026516927
Date: Thu, 19 Oct 2006 03:39:48 GMT
Call-ID: 34717910-B1CD-4563-9301-481F2F702E24@195.113.150.114
User-Agent: Cisco VoIP Gateway/ IOS 12.x/ SIP enabled
Max-Forwards: 5
Timestamp: 1161229194
CSeq: 101 BYE
Content-Length: 0
P-hint: rr-enforced
Status-Line: SIP/2.0 200 OK
Status-Code: 200
Resent Packet: False
Message Header
Via: SIP/2.0/UDP
195.113.144.245;branch=z9hG4bK6812.3fca3643.0,SIP/2.0/UDP
195.113.113.206:5060
From: <sip:596995779@cesnet.cz>;tag=1EB4EC64-4F0
SIP from address: sip:596995779@cesnet.cz
SIP tag: 1EB4EC64-4F0
To: "unknown"<sip:voznak@cesnet.cz>;tag=717026516927
SIP Display info: "unknown"
SIP to address: sip:voznak@cesnet.cz
SIP tag: 717026516927
Call-ID: 34717910-B1CD-4563-9301-481F2F702E24@195.113.150.114
CSeq: 101 BYE
Content-Length: 0
Server: SJphone/1.61.321a (SJ Labs)
Request-Line: BYE sip:voznak@195.113.150.114:5060 SIP/2.0
Method: BYE
Resent Packet: True
Suspected resend of frame: 1686
Message Header
Record-Route: <sip:195.113.144.245;ftag=1EB4EC64-4F0;lr=on>
Via: SIP/2.0/UDP 195.113.144.245;branch=z9hG4bK6812.3fca3643.0
Via: SIP/2.0/UDP 195.113.113.206:5060
From: <sip:596995779@cesnet.cz>;tag=1EB4EC64-4F0
SIP from address: sip:596995779@cesnet.cz
SIP tag: 1EB4EC64-4F0
To: "unknown"<sip:voznak@cesnet.cz>;tag=717026516927
SIP Display info: "unknown"
SIP to address: sip:voznak@cesnet.cz
SIP tag: 717026516927
Date: Thu, 19 Oct 2006 03:39:48 GMT
Call-ID: 34717910-B1CD-4563-9301-481F2F702E24@195.113.150.114
User-Agent: Cisco VoIP Gateway/ IOS 12.x/ SIP enabled
Max-Forwards: 5
Timestamp: 1161229194
CSeq: 101 BYE
Content-Length: 0
P-hint: rr-enforced
Status-Line: SIP/2.0 200 OK
Status-Code: 200
Resent Packet: True
Suspected resend of frame: 1688
Message Header
Via: SIP/2.0/UDP
195.113.144.245;branch=z9hG4bK6812.3fca3643.0,SIP/2.0/UDP
195.113.113.206:5060
From: <sip:596995779@cesnet.cz>;tag=1EB4EC64-4F0
SIP from address: sip:596995779@cesnet.cz
SIP tag: 1EB4EC64-4F0
To: "unknown"<sip:voznak@cesnet.cz>;tag=717026516927
SIP Display info: "unknown"
SIP to address: sip:voznak@cesnet.cz
SIP tag: 717026516927
Call-ID: 34717910-B1CD-4563-9301-481F2F702E24@195.113.150.114
CSeq: 101 BYE
Content-Length: 0
Server: SJphone/1.61.321a (SJ Labs)



Otevřená řešení pro SIP

V případě SIPu máme k dispozici několik zdařilých otevřených projektů, mezi které patří sipX na https://www.sipfoundry.org/index.html a dále SER a Asterisk. SER (SIP Express Router) je open source projekt napsaný v jazyce C. Zastává funkci registračního, redirect a proxy serveru pro komunikaci protokolem SIP. Původně byl vyvíjen jako páteřní SIP směrovač, tudíž s důrazem na výkon. Zvládá obsloužit tisíce hovorů za vteřinu na dvouprocesorovém PC a stovky hovorů na IPAQu. Server podporuje bezestavové i transakčně stavové zpracování SIP komunikace. Toto zpracování je řízeno silným skriptovacím jazykem. Síla jazyka v sobě
však skrývá i případnou složitost konfigurace. Server je modulární, tedy dobře rozšířitelný a s rostoucí uživatelskou základnou stále přibývají nové moduly. Server je možné vzdáleně řídit přes FIFO nebo UNIX socket a pro vlastní SIP komunikaci podporuje IP protokol verze 4 i 6 a transportní protokoly UDP,TCP a s příslušnými moduly i TLS. Server dále podporuje více uživatelských domén, aliasy a dotazy do ENUM domén. Autentizace a autorizace může být prováděna přes databázi (Mysql , Postgress), Radius nebo Diameter. Registrační vazby mohou být ukládány do Sql databáze. Server však nutně ke svému běhu databázovou podporu nepotřebuje. Registrační vazby pak zůstávají uloženy pouze v paměti, což je rychlé, ale při restartu serveru tyto záznamy zmizí. SER je schopen pomáhat při
NAT průchodu (nathelper, rtpproxy, mediaproxy) a jeho funkcionalitu je možné rozšiřovat i pomocí externích skriptů například v Perlu. SER je k dipozici pro Linux, BSD (NetBSD, FreeBSD), Solaris. Nedávno však došlo k rozštěpení projektu, původní projekt pokračuje na https://sip-router.org/ a nová větev na http://openser.org/ . Kompatibilita mezi větvemi není nezaručena především u rozšíření jako SerWeb. SER je používán v CESNETu jako přístupový směrovač i server pro obsluhu uživatelů.
Dalším otevřeným řešením je Asterisk. Oficiálně je Asterisk open source hybrid TDM a packet voice PBX, jedná se o IVR (Interactive Voice Response) platformu s funkčností Automatic Call Distribution (ACD). Jde tedy o kompletní open source softwarovou PBX, běžící na platformách Linux a Unix, poskytující veškeré vlastnosti PBX. Systém je navržen tak, aby vytvořil rozhraní telefonnímu hardwaru, softwaru a libovolné telefonní aplikaci.
 
Asterisk může být mimo jiné použit v těchto aplikacích:

• Různorodá VoIP gateway (MGCP, SIP, IAX, H.323),
• Pobočková ústředna (PBX),
• Voicemail služby s adresářem,
• Interaktivní hlasový průvodce (IVR) server,
• Softwarová ústředna (Softswitch),
• Konferenční server,
• Packet voice server,
• Šifrování telefonních nebo faxových volání,
• Překlad čísel,
• Aplikace Calling card,
• Prediktivní volič (Predictive dialer),
• Řazení volání do front se vzdáleným zprostředkovatelem,
• Vzdálené „kanceláře“ pro existující PBX.

Systém je navržen tak, aby povoloval použití nových rozhraní a umožňoval
snadno přidávat nové technologie. Jeho cílem je podpora veškerých možných typů současných i budoucích telefonních technologií.

Obecně jsou rozhraní rozdělená do tří základních skupin:

• Zaptel hardware,
• non-Zaptel hardware,
• packet voice.

Tvorba nenákladných rozhraní nebyla vůbec jednoduchým úkolem.

Tradiční TDM hardware (např. Dialogic, později majetkem Intelu) byl patentován a také byl příliš drahý. Pro dosažení vymezeného cíle bylo přistoupeno ke zcela nové myšlence. Místo, aby zpracování TDM probíhalo hardwarově, byl přidán hostitelský procesor a Asterisk pracoval s tímto procesorem. Jak se CPU stávaly stále rychlejšími a rychlejšími, začalo být rozumnější pro toto TDM zpracování ponechat software využívat hlavní CPU počítače. Po přidání TDM podpory do Asterisku začala firma Zapata Telephony s výrobou pseudo TDM rozhraní, které nazvala Zaptel. Pseudo TDM architektura poskytuje téměř stejnou kvalitu a real-time schopnosti jakou má hardware TDM. Podstatným rozdílem je však podstatně nižší cena a vyšší flexibilita. Zaptel rozhraní dodává firma Digium a to pro různé varianty síťových rozhraní (včetně PSTN, POTS, T1, E1, PRI, PRA, E&M a mnoho dalších).

Jelikož autor Asterisku (Mark Spencer) neměl v přílišné oblibě protokol
H.323, rozhodl se navrhnout a realizovat svůj vlastní protokol. Výsledkem je protokol IAX (Inter Asterisk eXchange) jenž se stará o signalizaci a transport packet voice mezi dvěmi připojenými uzly. Ačkoliv jméno naznačuje přítomnost Asterisku na obou koncích komunikace, IAX může ve skutečnosti spojit každé dva koncové body podporující tento protokol. Následně byla přidána podpora součinnosti s ostatními VoIP systémy a podpora pro další protokoly, jedná se o protokoly SIP, H.323 a MGCP.
Prostřednictvím kanálů vstupují do systému různé formáty komunikace.

Kanály jsou logická spojení s různými signalizačními a přenosovými cestami, které může Asterisk využívat k vytváření a spojování jednotlivých hovorů. Kanál by mohl představovat spojení s obyčejným telefonním přístrojem (telefonní linkou) nebo Internetové telefonní hovory („logické volání“). Asterisk nedělá žádný rozdíl mezi typem kanálu „FXO (Foreign eXchange Office)“ a „FXS (Foreign eXchange Station)“, nerozlišuje tedy mezi telefonními linkami a telefony. Každé volání je umístěno na odlišném kanále. Asterisk se všemi kanály zachází jako s přípojnými body, jejichž vzájemná interakce se definuje v Dialplan (extensions. conf). Je důležité si uvědomit, že i kdyby se kanály lišily v rámci použité technologie a konektivity, Asterisk umožňuje zacházet se všemi jakoby byly téměř stejné.

V současnosti existuje několik nezávislých implementací kanálu H.323 do
systému Asterisk (h323, oh323, ooh323c, woomera). V případě IAX se konfigurace kanálů provádí modifikací souboru iax.conf. Kanál chan_local je pseudo-kanál. Používá se pro vytvoření smyčky, která volá zpět do Dialplan v různých context. Užitečné je především rekurzivní směrování, které je schopno vracet se do Dialplan po ukončení volání. SIP kanálový modul umožní Asterisku VoIP komunikaci se SIP telefony a ústřednami.
Konfigurace SIP kanálů/klientů se provádí modifikací souboru sip.conf. Zap
kanálový modul poskytne mezivrstvu (interface layer) mezi Asteriskem na jedné straně a Zaptel a/nebo ZapHFC ovladači rozhraní na straně druhé.

Konfigurace ZAP kanálů se provádí modifikací souboru zapata.conf.
Dialplan je konfigurován v souboru extensions.conf. Je to nejdůležitější konfigurační soubor systému. Řídí způsob ovládání a směrování příchozích a odchozích hovorů. Toto je místo, kde kontrolujete chování všech spojení provedených prostřednictvím PBX.

Literatura
[1] Camp, K: IP Telephony Demistified. McGraw-Hill, New York 2003,
ISBN 0-07-140670-0.

[2] Vodrážka, J. – Pravda, I.: Principy telekomunikačních systémů, nakladatelství ČVUT,2006. ISBN 80-01-03366-X.

[3] Hardy,W.: VoIP service quality. McGraw-Hill, New York, 2003,
ISBN 0-07-141076-7.

[4] ITU-T P.861: Objective quality measurement of telephoneband (300-3400
Hz) speech codecs. Geneva, May 2000.

[5] H.323v5: Recommendation H.323,ITU-T, July 2003, https://www.itu.int/rec/TREC-H.323/en.

[6] Collins, D.: Carrier Grade Voice Over IP. McGraw-Hill, 2002, ISBN
0071406344.

[7] Peters, J. – Davidson, J.: Voice over IP Fundamentals. Cisco Press, Indianopolis, 2000, ISBN 1-57870-168-6.

[8] RFC 3261: SIPSession Initiation Protocol, IETF,
https://www.unix.org.ua/rfc/rfc3261.html, June 2002.

[9] Baroňák, I. – Halás,M.: SIP Protocol – the Future of IP Telephony, TSP
2004, Brno 2003, ISBN 80-214-2684-5.

[10] Vozňák, M. – Růžička, J.: Bezpečnost v sítích s VoIP, 5/2006, TaP, Wirelesscom Praha, Květen 2006, ISSN 1213-7162.

[11] Vozňák, M. – Machálek, P.: ENUM, Connect!, květen 2005, Computer
Press Praha, ISSN 1211-3085.

[12] Vozňák, M. : Co je nového v protokolu SIP, Connect! 1/2005, Computer
Press Praha, leden 2005, ISSN 1211-3085.

Ing. Miroslav VOZŇÁK, Ph.D.
VŠB – TUO, FEI, Katedra elektroniky a telekomunikační techniky.
 
 

Nahoru

IP telefonie se SIP signalizací

Dr. Ing. Sven Ubik, CESNET, z.s.p.o., ubik@cesnet.cz

IP telefonie, neboli přenos telefonních hovorů prostřednictvím datových sítí protokolem IP je jedním z trendů v oblasti telekomunikací. Jedním z důvodů je skutečnost, že objem datového provozu v telekomunikačních sítích stoupá mnohem rychleji než objem telefonního provozu. Je proto pravděpodobné, že v budoucnu nebude ekonomické udržovat dvě sítě – pro telefonní a pro datový provoz, nýbrž že dojde ke konvergenci telefonních a datových služeb v jedné síti. Druhým důvodem je potom možnost jednodušší implementace nových typů služeb v IP telefonii, které by v klasických telefonních sítích bylo možné implementovat obtížněji nebo vůbec ne. Jde například o multimediální komunikaci, lokalizaci uživatelů a integraci s jinými službami na Internetu.

Tento článek je věnován popisu technické stránky IP telefonie se signalizací protokoly SIP
a SDP. Zmíníme se také o vztahu k protokolu H.323 a o některých aspektech obecného vývoje IP telefonie.


Nahoru

Vývoj IP telefonie a přijetí uživateli

 IP telefonie je dnes úspěšně používána zejména pro dálkové přenosy hovorů mezi telefonními ústřednami nebo dalšími telekomunikačními zařízeními. Přesto zaznamenala menší úspěch než se původně předpokládalo, zejména v nasazení až k uživatelům, tedy v přenosu hovorů protokolem IP až do telefonů. Důvodů je několik. Za prvé, představy o rychlejším obecném rozšíření IP telefonie do značné míry vyplývaly z předpokladu, že IP telefonie umožní podstatně nižší ceny hovorů. V zemích, kde již určitou dobu funguje deregulovaný trh telefonních služeb jsou však operátoři služeb klasické telefonie schopni nabídnout své služby za ceny konkurující možnostem IP telefonie. Za druhé, pokud jde o nasazení IP telefonie až k uživatelům, ukázalo se, že velmi důležité je uživatelské rozhraní pro přístup k telefonním službám. Lidé jsou zvyklí zvednout sluchátko a vytočit číslo. V IP telefonii však až do nedávné doby museli uživatelé použít místo telefonu softwarovou aplikaci běžící na počítači. Taková aplikace vyžaduje instalaci a konfiguraci a při volání potom vyžaduje práci s klávesnicí nebo myší, která je pomalejší než práce s klasickým telefonem. Navíc uživatel samozřejmě potřebuje počítač, mikrofon a reproduktor nebo sluchátka, pokud nechce používat aplikaci jako hlasitý telefon, což mnoho uživatelů považuje za nepříjemné.

V současné době se pozornost ve vývoji IP telefonie soustřeďuje zejména do tří oblastí: ověření vlivu kvalitativních parametrů počítačové sítě (Quality of Services – QoS) na provoz telefonních služeb, implementace nových typů hlasových služeb a integrace s jinými službami, zejména s klasickou a mobilní telefonií. Studium QoS parametrů souvisí s tím, že zatímco v klasické telefonii je síť vyhrazena pro telefonní provoz, v IP telefonii je síť sdílena mezi telefonním a datovým provozem. Za hlavní výhody IP telefonie jsou nyní považovány snížení ceny instalace nové infrastruktury – stačí jedna síť a jedna sada aktivních prvků pro datový a telefonní provoz a možnost poskytování nových služeb. Tato druhá výhoda souvisí významně s existencí nového protokolu pro signalizaci v IP telefonii – SIP (Session Initiation Protocol). Protokol SIP navíc umožňuje i jednodušší přivedení IP telefonie až do telefonů.

Nahoru

Charakteristika protokolů SIP a SDP

 Signalizace se v telefonii stará o spojování a rozpojování hovorů, dohodu komunikačních parametrů mezi účastníky a přenos služebních údajů, například identifikace volajícího směrem k volanému účastníku. V IP telefonii v současnosti existují dva hlavní protokoly pro signalizaci – H.323 a SIP.


Protokol H.323 [1] podporovaný organizací ITU-T je dosud rozšířenější. Zahrnuje ve skutečnosti celou sadu různých protokolů pro jednotlivé úlohy signalizace. Implementace jsou zpravidla stabilní a dobře pracující. Nevýhodou protokolů rodiny H.323 je jejich monolitický charakter. Rozšíření o nové možnosti znamená potřebu vytvoření nové verze H.323. Protokoly jsou binární, s reprezentací založenou na ASN.1. Pro ladění implementací a řešení problémů je potřeba protokolový analyzátor. V transportní vrstvě byl původně vyžadován protokol TCP, který je relativně obtížné implementovat v malých systémech, má-li například být IP telefonie přivedena až do telefonu. Od verze H323v3 je možné použít i protokol UDP.

Protokol SIP [2] vytvořený pracovní skupinou MMUSIC v rámci organizace IETF je založen na jiné koncepci. Je textový, svojí strukturou obdobný protokolu HTTP, používanému službou WWW nebo protokolu SMTP, používanému pro přenos elektronické pošty. Jednotlivé zprávy sestávají z posloupnosti textových hlaviček. Vytváření a rozpoznávání těchto zpráv na straně odesílatele, resp. příjemce je jednodušší než u binárních zpráv. Implementační problémy se také mnohem snadněji ladí. Stačí kopírovat odesílané a přijímané zprávy na obrazovku nebo použít jakýkoliv program pro monitorování provozu na síti, který vypisuje obsah paketů. Protokol může být snadno rozšiřován přidáváním nových hlaviček, specifikovaných jako samostatné dokumenty RFC nebo IETF draft.

 Protokol SIP nespecifikuje jaký má být použit transportní protokol. Obvykle se proto používá protokol UDP, který lze snadno implementovat. Protokol SIP je určen pro spojování, rozpojování a zprávu spojení mezi dvěma nebo více účastníky. Není svázán s žádnými konkrétními protokoly pro vlastní přenos multimediálních dat.  Uvnitř zprávy protokolu SIP pro navázání spojení je proto zapouzdřena zpráva jiného protokolu, který specifikuje použitá kódování pro multimediální data, jejich parametry a čísla portů, na kterých mají být data vysílána nebo přijímána. Obvykle se pro tento účel používá protokol SDP (Session Description Protocol), který je rovněž textový. Protokol SIP plní ještě jednu funkci – registraci uživatelů, která umožňuje používat pro identifikaci uživatelů logické adresy nezávislé na fyzickém umístění uživatele.

 Ukázka zprávy protokolu SIP se zapouzdřenou zprávou protokolu SDP je na obrázku 1. Jde o zprávu sloužící k navázání spojení od volaného účastníka k volajícímu.

INVITE sip:ty@tam.cz SIP/2.0

Via: SIP/2.0/UDP 195.113.147.120:1912

Date: Tue, 17 Apr 2001 10:56:34 GMT

From: <sip:ja@tady.cz>

To: <sip:ty@tam.cz>

Subject: Hovor 1

Priority: normal

Expires: 3600

CSeq: 1691095645 INVITE

Call-ID: 884664559@195.113.147.210

Contact: <sip:ja@195.113.147.120:5060>

Content-Type: application/sdp

Content-Length: 143

v=0

o=ja 987504994 987504994 IN IP4 195.113.147.120

s=Hovor 1

c=IN IP4 195.113.147.120

t=3196493794 3196497394

m=audio 10000 RTP/AVP 0

Nahoru

Zpráva protokolů SIP a SDP

Zařízení pracující s protokolem SIP mohou komunikovat se zařízeními pracujícími s protokolem H.323 pomocí brány SIP/H.323 [3]. Tato brána převádí signalizační zprávy obou protokolů. Protože pro vlastní přenos multimediálních dat používají zařízení typu H.323 i SIP obvykle protokol RTP [5], mohou po navázání spojení prostřednictvím brány dále komunikovat přímo. Obdobně mohou zařízení pracující s protokolem SIP komunikovat s telefony v běžné telefonní síti (PSTN – public switched telephone system) pomocí brány SIP/PSTN nebo s ISDN zařízeními pomocí brány SIP/ISDN. Protokol SIP může být implementován buď přímo uvnitř telefonu, který pak umožňuje uživateli volání se stejným pohodlím jako při použití běžného telefonu nebo v softwarové aplikaci spuštěné na PC. V tomto případě může jít buď přímo o telefonní aplikaci nebo může být podpora protokolu SIP obsažena uvnitř jiné aplikace, například uvnitř prohlížeče služby WWW, který tak může vyvolat telefonní hovor při kliknutí na URL specifikujícím identifikaci volaného, například sip:hotline@firma.cz.

Komunikační možnosti při použití protokolu SIP jsou znázorněny na obrázku

Komunikace protokolem SIP

Signalizace

 SIP je protokol typu klient-server. Klient navazuje spojení se serverem. Jedno zařízení může pracovat současně jako klient i server. Například telefon pracuje jako klient pro odchozí volání a jako server pro příchozí volání. Fakt, že protokol je typu klient-server neznamená, že komunikace může být pouze dvoubodová. Hovor, který může být hlasový nebo multimediální, může probíhat mezi více účastníky. Multimediální data jsou potom přenášena najednou pro všechny účastníky spojením typu multicast, spojením typu unicast od každého účastníka přes propojovací bránu, spojením typu unicast mezi každou dvojicí účastníků nebo kombinací těchto metod. Zprávy protokolu SIP jsou dvojího druhu – žádosti a odpovědi.

Žádostem se též  říká metody a jsou následujících typů:
 

INVITE – žádost o navázání spojení nebo o změnu parametrů již existujícího spojení.

BYE – žádost o rozpojení spojení.

ACK – žádost, kterou klient potvrzuje, že obdržel odpověď na žádost INVITE

 

REGISTER – žádost o registraci klienta na registrar serveru

 

CANCEL – žádost o zrušení probíhající žádosti INVITE

 

OPTIONS – žádost o zaslání podporovaných funkcí na serveru

 

INFO – přenos informací během hovoru (rozšíření protokolu SIP popsané v RFC2976)

 

 
Volající klient může kontaktovat volaný server přímo nebo prostřednictvím jiného serveru, který pracuje jako tzv. proxy nebo redirect server. Přímé volání se používá, pokud klient zná IP adresu serveru, u kterého se nachází volaný uživatel. Typický průběh signalizačních zpráv u přímého volání je znázorněn na obrázku 3. Klient pošle žádost INVITE, server potvrdí její provedení odpovědí OK a klient potvrdí žádostí ACK, že obdržel konečnou odpověď na předchozí žádost INVITE.


Přímé volání volající – volaný.

 Častější je případ, kdy klient nezná IP adresu serveru, u kterého se nachází volaný uživatel. V tom případě klient naváže spojení s proxy nebo redirect serverem. Ten nejprve prostřednictvím lokalizační služby zjistí IP adresu serveru volaného uživatele. Uživatelé mohou totiž požádat svůj telefon (který pracuje jako SIP klient i server), aby se registroval u registrar serveru. Registrar server předá informaci o tom, kde se uživatel právě nachází lokalizační službě. Obvykle bývají registrar server a lokalizační služba realizovány společně v jedné aplikaci. Komunikace mezi proxy nebo redirect serverem a lokalizační službou a také mezi lokalizační službou a registrar serverm není součástí protokolu SIP a probíhá jiným protokolem, například LDAP, rwho nebo finger. Proxy server potom sám naváže spojení se serverem volaného uživatele a potvrdí navázání spojení volajícímu klientu, viz obrázek 4. Redirect server naproti tomu pouze sdělí volajícímu klientu IP adresu serveru volaného uživatele a klient potom musí sám navázat spojení přímo se serverem volaného uživatele, viz obrázek 5. Lokalizační služba může vrátit několik různých adres volaného uživatele. Proxy server může zkoušet kontaktovat jednotlivé adresy buď postupně nebo paralelně dokud některý server neodpoví. Obdobně může kontaktovat více serverů přímo volající klient, v případě použití redirect serveru. Podaří-li se kontaktovat některý ze serverů v seznamu a byla-li před tím poslána žádost INVITE ještě na jiné servery, mohou být tyto další žádosti INVITE stornovány žádostí CANCEL. Nakonec klient vždy potvrdí žádostí ACK, že obdržel konečnou odpověď na předchozí žádost INVITE.

Registrace klienta u registrar serveru je znázorněna na obrázku 6. V hlavičce To je uvedena adresa uživatele, která má být registrována. V hlavičce From je uvedena adresa uživatele, který posílá žádost o registraci. Uživatel si může registrovat svoji adresu sám nebo to může za něj provést někdo jiný. Klient může specifikovat dobu po níž má být adresa registrována v hlavičce Expires. Server může provést registraci buď na požadovanou nebo na kratší dobu. Pokud klient dobu registrace nespecifikuje, server jí zvolí sám. Skutečnou dobu registrace server buď vrátí v hlavičce Expires v odpovědi nebo platí standardní doba 1 hodina. Klient může zrušit existující registraci specifikováním doby registrace 0 v hlavičce Expires.

Ukončení spojení je znázorněno na obrázku 7. Klient pošle serveru žádost BYE, kterou server potvrdí odpovědí OK. Jak jsme se již zmínili, koncová zařízení obvykle obsahují klient i server, proto jak volající, tak volané koncové zařízení může poslat žádost BYE o ukončení spojení. Klient může dále požádat server žádostí OPTIONS o zaslání metod podporovaných serverem. Server vrátí seznam podporovaných metod v odpovědi v hlavičce Allow. Žádost INFO může být použita pro zaslání doplňujících informací během hovoru, například signalizace mezi bránami do veřejné telefonní sítě, informace o kvalitě signálu nebo informace o stavu účtu uživatele.

Nahoru

Navázání spojení přes proxy server.

 


 Navázání spojení přes redirect server.

 Nahoru


 Registrace serveru uživatele na registrar serveru.

Nahoru


Ukončení spojení.

 

Klient zabudovaný v koncovém zařízení se nazývá user agent client, ve zkratce UAC a server zabudovaný v koncovém zařízení se nazývá user agent server, ve zkratce UAS. Obsahuje-li koncové zařízení klient i server, nazývá se user agent, ve zkratce UA. Proxy, redirect a registrar server bývají často kombinovány v jednom zařízení, kterému se potom říká SIP server.

 Nahoru

Identifikace uživatelů a směrování hovorů

Základní adresa uživatele má tvar e-mailové adresy, například novak@organizace.cz. Lze ji též zapsat jako URL ve tvaru sip:novak@organizace.cz. Toto je adresa, kterou normálně použije uživatel, chce-li navázat spojení s jiným uživatelem. Adresa však může obsahovat i další údaje popisující způsob kontaktu uživatele. Úplný tvar adresy je následující:

 

sip: [username [:heslo] @ ] hostname [:port] [;parametr;parametr … ][?hlavička&hlavička …]


Hranaté závorky označují nepovinné části. Jediným povinným údajem je ve skutečnosti jméno zařízení (počítače, telefonu, atd.). Místo jména může být uvedena přímo IP adresa zařízení. Před jméno zařízení lze volitelně uvést jméno uživatele případně heslo na tomto zařízení. Pracuje-li zařízení jako brána do klasické telefonní sítě, ve které se uživatelé označují telefonními čísly, uvádí se místo jména uživatele jeho telefonní číslo. Za jménem zařízení může následovat seznam parametrů a hlaviček. Parametry určují jaký protokol má být použit v transportní vrstvě (UDP nebo TCP), zda je uvedeno jméno nebo telefonní číslo uživatele a další údaje.  Hlavičky se potom stávají přímo součástí signalizační zprávy, jak popíšeme dále.

 

V signalizačních zprávách se přenáší současně několik adres výše uvedeného tvaru. Nejdůležitější jsou tři adresy: adresa volajícího uživatele v hlavičce From, adresa volaného uživatele v hlavičce To a adresa uživatele, kterému je právě posílána daná zpráva, která se uvádí ma začátku zprávy v tzv. Request-URI. Adresa v Request-URI je nejprve shodná s adresou v hlavičce To. Je-li však zpráva přenášena přes proxy server, může být adresa v Request-URI přepsána proxy serverem na adresu následujícího serveru, kterému proxy server zprávu postupuje. Hlavička To zůstává stále stejná i při průchodu zprávy přes proxy servery. Všechny hlavičky a většina parametrů v adrese se používají jen při použití adresy v určitých hlavičkách signalizačních zpráv. V Request-URI a v hlavičkách From a To se nepoužívají. V žádostích REGISTER je v Request-URI adresa registrar serveru jako jeho doménové jméno (bez jména uživatele).

 IP adresa proxy nebo redirect serveru serveru může být buď obsažena v konfiguraci volajícího zařízení a nezávislá na jménu volaného zařízení nebo může být získána ze jména volaného zařízení pomocí služby DNS. V takovém případě je poslán na DNS server dotaz na záznamy typu SRV pro jméno volaného zařízení, před které se připojí _sip._udp nebo _sip._tcp podle použitého transportního protokolu. Jako odpověď je vrácen seznam IP adres a portů SIP serverů s uvedenými prioritami. Volající zařízení pak kontaktuje tyto servery v pořadí podle priorit dokud některý z nich neodpoví. Pokud DNS server nevrátí žádné SRV záznamy, je poslán ještě jeden dotaz na DNS server na záznamy typu A pro jméno volaného zařízení. Je-li vrácena IP adresa, je použita jako adresa SIP serveru. Číslo portu na který má být otevřeno spojení je uvedeno buď v SRV záznamu nebo v Request-URI nebo je použit standardní port 5060. Příklad odpovědi od DNS serveru obsahující SRV4.0.1.75. záznamy je na obrázku 8. Jako další možnost existuje ještě předdefinovaná multicastová adresa SIP serveru 22

 

$ nslookup

> set q=srv

> _sip._udp.tady.cz.

Server:  ns.tady.cz

Address:  195.113.147.230

 

_sip._udp.tady.cz         priority = 10, weight = 0, port= 5060, host = sip.tady.cz

sip.tady.cz                   internet address = 195.113.147.231

 

Nahoru

 

Je-li kontaktované zařízení koncovým zařízením (UAS), je s ním přímo navázán nový hovor. Je-li kontaktované zařízení SIP proxy nebo redirect server, potom, jak jsme se již zmínili, tento server nejprve použije registrar server k určení aktuální adresy uživatele a následně buď sám naváže s touto adresou spojení nebo jí vrátí zpět volanému zařízení. Registrar server může vrátit seznam více možných adres uživatele. Proxy server může navázat spojení na všechny zjištěné adresy současně a redirect server vrátí všechny adresy zpět. Proxy server potom obvykle potvrdí navázání spojení s prvním dalším serverem, který mu odpoví. Tento další server může být buď již koncové zařízení (UAS) nebo opět další SIP server. Tímto způsobem mohou být SIP servery zřetězeny za sebou.

 Struktura zpráv


Žádost vždy začíná řádkou se jménem metody, Request-URI a verzí protokolu SIP. Následují hlavičky a volitelně po prázdné řádce může následovat tělo zprávy. Příklad zprávy byl uveden na obrázku 1.

 

Hlavičky mají stejný tvar jako například v protokolech HTTP nebo SMTP, tedy jméno hlavičky, dvojtečka a hodnota. Hlaviček je celkem asi 40. Význam nejdůležitějších hlaviček je uveden dále.

 

Authorization           - Informace pro autentizaci klienta vůči serveru

Call-ID - Identifikace hovoru nebo registrace, kterou pro každý hovor resp. registraci vygeneruje klient. Následující žádosti INVITE, které pouze mění parametry již existujícího hovoru mají stejnou hodnotu Call-ID jako původní žádost INVITE, ale vyšší hodnotu CSeq.

Contact - SIP adresa, na které může být uživatel posílající tuto hlavičku příště dosažitelný, používá se například v odpovědi redirect serveru.

CSeq - Pořadové číslo žádosti v rámci jednoho hovoru. Je-li stejná žádost opakována, protože na ní nepřišla odpověď, má stejnou hodnotu CSeq. Následné žádosti INVITE pro stejný hovor posílané pro změnu parametrů existujícího hovoru mají vždy vyšší hodnoty CSeq.

From – Původní odesílatel žádosti, tedy volající uživatel nebo uživatel provádějící registraci (buď své adresy nebo adresy někoho jiného).

Require - Odesílatel uvede funkce, které musí příjemce implementovat. Pokud některou z funkcí příjemce neimplementuje, vrátí zpět chybový kód a seznam funkcí, které implementuje. Odesílatel se může rozhodnout, zda učiní další pokus o navázání spojení s jinou sadou požadovaných funkcí. Jména jednotlivých funkcí jsou registrována organizací IANA. Vývojáři mohou nezávisle vytvářet nové funkce a registrovat je.

To - Volaný uživatel nebo adresa, která má být registrována na registrar serveru.

Via - Každý proxy server směrující žádost vloží svoji adresu na začátek této hlavičky. Při přenosu odpovědi zpět servery opět své adresy vyjímají. Proxy server musí vždy ověřit, zda následující adresa, na kterou posílá žádost již není v této hlavičce. Tím se zabrání smyčkám.

 

Struktura odpovědí je obdobná, liší se pouze v prvním řádku, který obsahuje verzi protokolu SIP, návratový kód a návratový text. Návratový kód je třímístné číslo označující výsledek žádosti obdobně, jak je tomu například v protokolu HTTP. Návratový text stručně popisuje výsledek žádosti. Návratové kódy lze rozdělit do šesti skupin podle první cifry:

 

1xx – Informační odpověď, žádost obdržena, její zpracování probíhá. Posílá proxy nebo redirect server trvá-li směrování hovoru delší dobu.

2xx – Úspěšné provedení žádosti

3xx – Přesměrování (odpověď od redirect serveru)

4xx – Chyba způsobená klientem (například špatná syntaxe žádosti)

5xx – Chyba způsobená serverem

6xx – Obecná chyba, žádost nemůže být provedena ani na jiném serveru

 

Nejběžnější odpovědi jsou „200 OK“ – úspěšné provedení žádosti, „302 Moved temporarily“ – běžné přesměrování redirect serverem a „404 Not found“ – volaný uživatel se nenachází na daném serveru.

 

Tělo zprávy se používá zejména u žádostí INVITE, OPTIONS a ACK, kdy obsahuje popis, obvykle v protokolu SDP, kódování a dalších parametrů přenosu multimediálních dat.

 

Protokol SDP a přenos dat

Protokol SDP [4] slouží k specifikaci kódování a dalších parametrů přenosu multimediálních dat během komunikace. Zpráva protokolu SDP je obsažena v těle zprávy protokolu SIP a sestává z posloupnosti řádků ve tvaru typ=hodnota. Typ je vždy zapsán jen jedním písmenem a říká, jaký parametr komunikace je popisován. Nejprve jsou vždy uvedeny řádky týkající se celého spojení nebo všech toků přenášených dat. Potom následují řádky popisující jednotlivé toky dat.

Nejvýznamnější typy a jejich význam jsou následující:

v – verze protokolu SDP;

o – původce (originator) spojení, udává jeho uživatelské jméno, identifikátor spojení a IP adresu;

s – jméno (subject) spojení;

c – adresa spojení (connection), na kterou mají být posílána data, obvykle jde o multicastovou IP adresu, za kterou může následovat lomítko a hodnota TTL (Time To Live) definující rozsah šíření paketů v síti;

a – atribut přenášející doplňkové informace, může být ve tvaru hodnota nebo jméno:hodnota, například recvonly znamená, že odesílatel této zprávy bude pouze přijímat data;
m – popis toku dat (media), udává typ dat (audio, video, atd.), číslo portu na adrese udané řádkem c, na kterém bude tento proud dat posílán, transportní protokol (RTP, UDP, atd.) a kódování, obvykle jako číslo definované jako typ dat v protokolu RTP.

 Vlastní přenos multimediálních dat probíhá po navázání hovoru přímo mezi koncovými účastníky dohodnutým transportním protokolem, na dohodnutých adresách a portech. To znamená, že data již nejsou přenášena přes SIP proxy nebo redirect server. Nejčastěji používaným transportním protokolem pro přenos dat v IP telefonii se SIP i H.323 signalizací je protokol RTP spolu s řídícím  protokolem RTCP. Jak jsme se již zmínili, zařízení používající SIP a H.323 signalizaci mohou navzájem komunikovat prostřednictvím brány SIP/H.323 pro konverzi signalizačních zpráv a následně přímo protokolem RTP pro přenos dat.

Programování nových funkcí

Jak jsme již naznačili, textová povaha protokolů SIP a SDP je předurčuje k relativně snadné tvorbě nových funkcí v IP telefonii, například různých typů přesměrování hovorů a konferenčních hovorů. K tomu účelu bylo navrženo rozhraní SIP CGI (Common Gateway Interface) [6]. Princip použití je podobný rozhraní HTTP CGI. Obdrží-li server zprávu protokolu SIP, spustí skript napsaný v určitém jazyku, např. Perl, C, Tcl. Skript přečte hlavičky a tělo zprávy, provede jakoukoliv další činnost a vrátí serveru informaci o tom, jakou operaci má server provést s přijatou zprávou. Součástí této informace mohou být hlavičky a tělo pro novou zprávu, která má být odeslána. Komunikace mezi serverem a skriptem je znázorněna na obrázku 10.

SIP CGI 

Uvedeme několik důležitých poznámek k činnosti SIP CGI. Skripty jsou obvykle spouštěny na proxy, redirect nebo registrar serveru, nikoliv na serveru koncového zařízení (UAS). Zatímco u skriptů HTTP CGI je jméno skriptu určeno přímo v URL, u SIP CGI skriptů je jméno spouštěného skriptu určeno jiným způsobem, který závisí na konfiguraci serveru. Například může být spouštěn vždy stejný skript pro všechny příchozí zprávy nebo může být jméno skriptu určeno podle obsahu hlaviček ve zprávě. Způsob předávání informací mezi serverem a skriptem v obou směrech je obecně implementačně závislý. Nejčastěji skript čte údaje poslané skriptem přes svůj standardní vstup (stdin) a posílá zpět údaje serveru přes svůj standardní výstup (stdout). Kromě toho server předává další údaje skriptu prostřednictvím proměnných prostředí operačního systému. Návrh SIP CGI specifikuje množinu asi 20 standardních proměnných prostředí, například pro IP adresu klienta, který poslal danou SIP zprávu (REMOTE_ADDR), délku těla zprávy v bajtech (CONTENT_LENGTH) nebo Request-URI zprávy (REQUEST_URI). Konkrétní implementace mohou používat další proměnné.

Text poslaný skriptem na standardní výstup začíná vždy tzv. akční řádkou, určující operaci, která má být provedena s přijatou SIP zprávou. Například akční řádka „SIP/2.0 200 OK“ informuje server, že má vrátit zpět odpověď s udaným návratovým kódem a textem. Akční řádka „CGI-PROXY-REQUEST sip:ty@tam.cz SIP/2.0“ informuje server, že má postoupit zprávu (operace proxy) na udanou adresu. Server provede činnost příslušející k dané operaci. Tedy například v případě operace proxy server zkopíruje určité hlavičky z přijaté zprávy do odesílané zprávy. Standardně je skript spuštěn jen při příchodu první zprávy určitého hovoru nebo registrace. Akční řádkou „CGI-AGAIN yes SIP/2.0“ můžeme požádat, aby skript byl zpuštěn znovu i při příchodu další zprávy téže transakce, například při příchodu odpovědi nebo žádosti ACK či CANCEL. 

Za akční řádkou mohou následovat nepovinně hlavičky SIP, hlavičky CGI a za prázdným řádkem tělo zprávy. Zadané hlavičky SIP jsou připojeny za hlavičky vygenerované serverem pro odesílanou zprávu (některé zadané hlavičky přepisují hlavičky vygenerované serverem). Hlavičky CGI začínají vždy prefixem CGI a představují určité instrukce pro server, který je zpracuje, ale nevloží do odesílané zprávy. Například hlavička CGI-Remove může být použita jako žádost o vyjmutí určité hlavičky z odesílané zprávy, kterou by jinak server do této zprávy automaticky zkopíroval.


Praktické zkušenosti

Autor článku se podílel na vývoji E-Phone - IP telefonu se SIP signalizací vyvinutého na Columbia University. Různé typy zařízení pracující se SIP signalizací má k dispozici nebo vyvíjí řádově několik desítek pracovišť v různých zemích. Dvakrát až třikrát ročně probíhá tzv. SIP bakeoff, setkání vývojářů SIP komponentů. V rámci projektu Hlasové služby v síti národního výzkumu a vzdělávání CESNET2 bylo vytvořeno experimentální  pracoviště SIP zařízení zahrnující sipc (softwarový SIP telefon pro Windows a UNIX), sipd (proxy, redirect a registrar server), siph323 (brána SIP/H.323), vše komponenty vyvinuté na Columbia University a Cisco IP Phone 7960 (hardwarový telefon umožňující použít i image s podporou SIP) a směrovač Cisco 2620 s podporou SIP. Ve starších verzích software pro zmíněné hardwarové telefony a směrovač byly problémy v implementaci protokolu SIP. V některých případech byly posílány nekorektní hlavičky, což mělo za následek nemožnost navázání hovoru. Zdá se, že v novějších verzích byly tyto problémy již odstraněny. Kromě těchto problémů pracovala zmíněná zařízení dobře. Kvalita vlastního hovoru není závislá na tom, zda používáme signalizaci SIP nebo H.323. Je závislá na použitém algoritmu pro kódování hlasového signálu (kodek), na kvalitativních parametrech přenosu paketů sítí a tradičně výrazně na kvalitě použitého mikrofonu a sluchátek.

 Literatura

 [1] International Telecommunication Union, „Packet Based Multimedia Communication Systems“, Recommendation H.323, Telecommunication Standardization Sector of ITU, Ženeva, Švýcarsko, únor 1998.

[2] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg. „SIP: Session Initiation Protocol“, Request for Comments 2543, Internet Engineering Task Force, březen 1999.

 [3] K. Singh, H. Schulzrinne. „Internetworking Betwe en SIP/SDP and H.323“, Internet Draft draft-singh-sip-h323-00.txt, Internet Engineering Task Force, leden 2000.

 [4] M. Handley, V. Jacobson. „SDP: Session Description Protocol“, Request for Comments 2327, Internet Engineering Task Force, duben 1998.

[5] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. „RTP: a transport protocol for real-time applications“, Request for Comments 1889, Internet Engineering Task Force, leden 1996.

[6] J. Lennox, H.Schulzrinne, J. Rosenberg,
"Common Gateway Interface for SIP", Request for Comments 3050,
Internet Engineering Task Force, leden 2001.


 
NAVRCHOLU.cz

TOPlist
https://sip:ja@212.80.76.18
" alt="" />Datum - Vaše IP" alt="" />
 


Adresa IP :
54.144.82.216

TOPlist
TOPlist
Advertisement
 
" alt="" />Základní nabídka" alt="" />
 
" alt="" />ČTÚ" alt="" />SMS" alt="" />
 
Firemní telefonní čísla PA
" alt="" />Rozhlas on-line" alt="" />
 
Pravdavitezi.jpg
" alt="" />Měření internetu" alt="" />
 
Měření internetu
SPEEDTEST

Měření internetu
 
Dnes jste: 159 visitors (357 hits) na těchto stránkách
=> Do you also want a homepage for free? Then click here! <=
Osobní, soukromé stránky. Pokud máte nějaký dotaz, přání, či připomínku - kontaktujte mne, děkuji! Víte proč je pevná linka stále dobrá a často lepší než hojně používané mobilní telefony?!