protokol sip

Protokol SIP file:///D:/Downloads/aaa/sip.htm

1 z 15 31.10.2007 14:38

Protokol SIP (I) - Architektura, typy zpráv aidentifikaceSession Initiation Protocol (SIP) je jednou z alter nativ pro realizaci (nejen) hlasovéhopřenosu v rámci IP sít ě. V příslušném RFC je charakterizován jako signaliza ční protokolsloužící k sestavení, modifikaci a ukon čení spojení mezi dv ěma a více ú častníky. Spojenímůže představovat obecn ě jakýkoliv multimediální p řenos, v praxi je ale SIP nej častějivyužíván pro telefonování po IP síti.

Cílem tohoto seriálu je seznámit čtenáře se základními charakteristikami tohoto protokolu anastínit možnosti jeho nasazení jak v IP sítích, tak i při integraci stávajících telefonních sítí s IPprostředím.

Asi každý, kdo někdy přišel do kontaktu s principy VoIP přenosu, narazil na specifikaci H.323.Uveďme alespoň základní rozdíly mezi H.323 s SIPem.

H.323 je architektura, která specifikuje vše nezbytné pro realizaci multimediálního přenosupaketovou sítí (komponenty systému, signalizaci, dohadování parametrů přenosu, atd.)SIP je pouze signalizační protokol. K dohadování parametrů a k vlastnímu přenosu sevyužívají jiné existující standardyH.225 (signalizační protokol z rodiny H.323) je binární protokol kódovaný pomocí ASN.1SIP je textově orientovaný protokol využívající principy známé z internetových protokolůSMTP nebo HTTP.H.225 je přenášen přes TCPSIP může využívat jak TCP, tak UDP. Obvyklejší je použití UDP.H.323 je doporučením ITU-TSIP se rozvíjí v rámci otevřeného prostředí IETFSIP není vázaný pouze na telefonii, ale může jím např. zjišťovat dostupnost uživatele,instant messaging a další.

Prvky SIP architektury

Podobně jako H.323 i SIP definuje architekturu v rámci které funguje a která sestává znásledujících komponent:

User AgentUser agents (UA) jsou koncovými zařízeními SIP sítě. Starají se o navazování spojení s ostatnímiUA. Nejčastěji se jedná o SIP telefony (ať už fyzické nebo ve formě aplikací běžících na PC) abrány do jiných sítí, typicky do JTS. V rámci UA rozlišujeme ještě User Agent Client (UAC), což ječást UA která má na starosti iniciaci spojení a User Agent Server (UAS), která reaguje na příchozížádosti a posílá odpovědi. V koncovém zařízení (SIP telefonu) je implementován jak UAC, tak iUAS.

ServeryServery jsou v SIP architektuře zařízení, jejichž úkolem je zprostředkovat kontakt mezi volajícími avolanými (tedy mezi UA), což ale nevylučuje přímý kontakt koncových zařízení bez účasti serverů.Rozlišujeme tyto tři typy SIP serverů:

1.Proxy server. Tento server přijme žádost o spojení od UA nebo od jiného proxy serveru a předá ji dalšímu proxyserveru (pokud volanou stanici nemá ve své správě) nebo přímo volanému UA pokud je tento vrámci jím spravované domény.

2.Redirect server.


2 z 15 31.10.2007 14:38

Stejně jako proxy přijímá žádosti o spojení od UA nebo proxy serverů, ale nepřeposílá je dále vesměru volaného, nýbrž posílá tázajícímu informaci, komu má žádost poslat, aby se dostala kvolanému. Je pak na dotazujícím se, aby žádost na takto získanou lokalitu (další proxy/redirectserver nebo volaný UA) poslal.

3. Registrar server.Registrar server přijímá registrační žádosti od UA a aktualizuje podle nich databázi koncovýchzařízení (location service), které jsou v rámci domény spravovány.

Jakkoliv jsou tyto servery definovány odděleně, v praxi se často jedná o jednu aplikaci, kterápřijímá registrace koncových uzlů a podle konfigurace se chová zároveň buď jako proxy neboredirect server. Ti z vás, kteří znají architekturu H.323 si určitě uvědomili určitou analogii sgatekeeperem.

Metody a odpov ědi

O komunikaci mezi komponenty SIP architektury jsem se zatím zmínil pouze v obecné rovině.Agenti a servery si posílají požadavky pomocí takzvaných metod. Jedná se o zprávy v textovémformátu a šesti základními metodami jsou

INVITE - slouží k žádosti o sestavení spojeníACK - potvrzení INVITE finálním příjemcem zprávy (volaným)BYE - ukončení spojeníCANCEL - ukončení nesestaveného spojeníREGISTER - registrace UAOPTIONS - dotaz na možnosti a schopnosti serveru

Další metody jsou předmětem samostatných RFC nebo draftů.

Odpovědi na SIP metody jsou zprávy uvedené číselným kódem. Systém kódů je převzat z HTTPprotokolu. Např. SIPovská odpověď "404 Not Found" je velmi podobná té, které se objeví na webprohlížeči při přístupu na neexistující stránku. Číselné kódy odpovědí jsou členěny do šestiskupin:

1XX - informační zprávy (např. "100 Trying", "180 Ringing")2XX - úspěšné ukončení žádosti ("200 OK")3XX - přesměrování, dotaz je třeba směřovat jinam ("302 Moved Temporarily", "305 UseProxy")4XX - chyba, dotaz by se neměl ve stejné podobě opakovat ("403 Forbidden")


3 z 15 31.10.2007 14:38

5XX - chyba na serveru ("500 Server Internal Error", "501 Not Implemented")6XX - globální selhání ("606 Not Acceptable")

Identifikace volaného v síti SIP

Zatímco v běžné telefonní síti jsme zvyklí identifikovat jednotlivé účastníky pomocí telefonníhočísla (E.164) , v rámci SIP se používá Uniform Resource Identifier (URI) resp. Universal ResourceLocator (URL), což je další ukázka toho, jak SIP využívá již existující standardy. Zde jsou tostandardy pro popis zdrojů vyskytujících se v Internetu.

Tímto způsobem jsou identifikováni samozřejmě nejen koncoví účastníci ale i hlasovézáznamníky, brány do jiných sítí, skupina účastníků, atd.

Telefonovat můžeme např. na takovéto adresy:

sip:[email protected]: "Milkman Dan" [email protected]:[email protected]:[email protected], user=phonesip:[email protected]:+420244470645

Tolik tedy základní teorie na úvod. V příštím pokračování budu dokumentovat uvedené principy napraktických příkladech, což jak věřím, povede k osvětlení případných nejasností.

Protokol SIP (II) - SignalizaceV minulém díle jsme se seznámili se základními rysy protokolu SIP a v tomto článku siukážeme jeho fungování na n ěkolika p říkladech.

Začněme navázáním spojení mezi dvěma účastníky prostřednictvím proxy serveru.

Diagram znázorňuje situaci, kdy volající i volaný jsou registrovány ke stejnému serveru v rámcispolečné domény. Kdyby byl volaný v jiné doméně, zobrazený proxy server by směroval INVITEna další proxy server, který se o doménu volaného stará.


4 z 15 31.10.2007 14:38

Už v minulém pokračování jsem uvedl, že proxy server není pro navázání komunikace nezbytněnutný a koncová zařízení se mohou kontaktovat přímo. Je ale zřejmé, že takovéto řešení neníprakticky z důvodů rozšiřitelnosti příliš vhodné.

Pro dokreslení situace je na dalším obrázku zobrazen ještě záznam z paketového analyzátoru. Na něm uživatel sip:[email protected] volá na stanici sip:[email protected].

Podívejme se podrobněji na první paket (číslo 3 v levém sloupci):

Je na něm zobrazena struktura INVITE zprávy a zároveň vidíme, že je v ní integrována zprávaprotokolu SDP (Session Description Protocol). SDP je protokol specifikující formát, kterým seinzeruje multimediální vysílání. Ti z vás, kdo měli možnost pracovat např. se sítí MBONE tentoprotokol spolu s protokolem SAP (Session Announcement Protocol – realizuje distribuci SDP


5 z 15 31.10.2007 14:38

zpráv) asi dobře znají. SIP využívá SDP pro dohodnutí parametrů spojení mezi účastníky. V rámcizobrazeného paketu vidíme, že volající bude vysílat UDP/RTP tok z portu 31756 a nabízí 3kodeky (G.711 alaw, G.711ulaw a G.729).

V hlavičce zprávy SIP jsou následující položky:

From : identifikuje volajícího a v rámci spojení se nemění (zůstává tedy stejná i ve zprávách,které posílá volaný volajícímu)To: identifikuje volanéhoVia: vedle verze SIPu a použitého transportního protokolu obsahuje IP adresu původcezprávy. Každý server, který zprávu posílá dál, vloží do hlavičky další záznam Via se svou IPadresou. Tyto záznamy se mimo jiné používají pro detekci smyček.Call-ID : jednoznačná identifikace daného spojeníContact : obsahuje URI, pomocí kterého lze účastníka (zde volajícího) kontaktovat přímo

Pro zajímavost se ještě podíváme na paket s číslem 9, tedy zprávu "200 OK“, kterou posílávolaný:

Opět vidíme číslo UDP/RTP portu a dohodnutý kodek G.711 ulaw.

Pakety 12 a 13 představují začátek RTP streamu, tedy vlastního telefonního hovoru.

Ukončení spojení probíhá tak, že jeden z účastníků pošle „BYE“ a protější strana odpoví „200OK“. Ukončení spojení může být realizováno opět přes proxy servery nebo přímo mezi koncovýmiuzly. Proxy server má při sestavování spojení možnost zařídit, aby veškerá další signalizace šlaopět přes něj nebo může ponechat další signalizaci (nejen ukončení ale i např. přidržení hovoru)proběhnout přímo mezi zúčastněnými stranami. Pokud chceme mít přesný přehled o proběhlýchspojeních, je nutné na proxy serveru zvolit první variantu a zařídit vhodný způsob logování (např.na RADIUS server). Proxy server si vynucuje směrování signalizace přes sebe pomocí záznamuRecord-Route v hlavičce SIP zprávy.

Další možnost jak sestavit spojení, je využít redirect server . V tomto případě je diagramsignalizace následující:


6 z 15 31.10.2007 14:38

A ješt ě záznam paketového analyzátoru

Z výpisu je patrné, že Dan obdržel od Redirect serveru kontakt na Karen a následně s ní navazujepřímé spojení.

Modifikace navázaného spojení

Kterýkoliv z účastníků má možnost během spojení změnit jeho parametry pomocí nové zprávyINVITE (v této souvislosti se také používá termín re-INVITE). Tato obsahuje stejně nastavenépoložky From, To a Call-ID, přičemž SDP uvnitř zprávy popisuje nově navrhované parametryspojení. Protější strana má možnost požadavek na nové nastavení přijmout nebo odmítnout („405Not Acceptable“) a v tom případě spojení pokračuje podle původního nastavení.

V příštím pokračování se seznámíme, jakým způsobem probíhá registrace koncových zařízení ajaké to nabízí možnosti pro podporu mobility.

Protokol SIP (III) – Registrace a službyV minulém pokra čování jsme se v ěnovali funkcím protokolu SIP, které se vztahujík sestavení spojení. A ť už pomocí proxy nebo redirect serveru. P ředpokládali jsme, že tytoservery n ějakým zp ůsobem v ědí, kde se nacházejí jednotliví klienti náležející do doménypod správou daného serveru. Jakkoli je možná static ká konfigurace t ěchto informací,typi čtější je, že klienti o sob ě dají vědět sami prost řednictvím registra čního serveru.

Registrace

Prvním krokem při registraci klienta k příslušnému serveru je zjistit, na jaké adrese se nachází.Adresa serveru může být na klientovi konfigurována staticky a nebo je prostřednictvím DNS SRVzáznamu získána dynamicky. Poté si klient prostřednictvím metody REGISTER registruje URI,které spravuje.

VÝPIS

Přiložený výpis dokumentuje uvedený postup s tím, že klient má v tomto konkrétním případě na


7 z 15 31.10.2007 14:38

starosti 3 URI, proto i zpráva REGISTER je na registrační server posílána třikrát. Registračníserver poté co požadavek přijme provede aktualizaci na lokační službě (location service) což jedatabáze, jejíž obsah pak využívají ostatní servery (proxy, redirect). Způsob realizace lokačníslužby a forma komunikace mezi ní a ostatními servery není nijak specifikována a závisí nakonkrétní implementaci SIP serverů.

Na celém mechanismu je pěkné to, že uživatel může být během dne registrován z různých lokalit.Po příchodu do práce se zaregistruje ze svého SIP telefonu, když jde během dne něco vyřizovat,registruje si prostřednictvím SIP/GSM brány mobilní telefon a pokud o to stojí může se domaregistrovat z domácího SIP telefonu nebo opět prostřednictvím brány zaregistruje PSTN telefon.Je tak pod stejným URI neustále dosažitelný.

Rovněž je možné v rámci jedné registrace uvést více Contact položek, každou vybavenou určitýmiatributy specifikujícími typ zařízení. Volající má pak možnost specifikovat, že volaného má zájemkontaktovat pouze na určitých typech zařízení (např. cokoliv kromě mobilu a hlasové schránky).

Služby

Uživatel SIP telefonu, může jít se svých požadavcích na to jak mají být příchozí hovoryzpracovávány ještě dál. Může mít např. následující požadavky:

chci akceptovat pouze hovory od nejbližších spolupracovníků, vše ostatní skončí na telefonusekretářkyje-li můj telefon obsazený, provede se redirect na záznamníkvolá-li někdo z domény podlodka.ua, bude automaticky přesměrován na právní odděleníbude-li mezi 14:00 a 22:00 volat Karen, dostane informaci, že mám obsazeno

K realizaci podobných požadavků lze využít speciální programy, které využívá proxy server přisestavování hovoru. Přijde-li žádost o sestavení hovoru, proxy server předá potřebné atributyvolání příslušnému programu (skriptu) a ten podle toho, jak byl napsán, vrátí informaci o tom, kamhovor směrovat.


8 z 15 31.10.2007 14:38

Jedním ze způsobů, jak tento mechanismus realizovat je SIP CGI, což je analogická věc k HTTPCGI. SIP CGI definuje rozhraní pro předávání informací mezi SIP serverem a externí aplikací(CGI programem), která může být podle potřeby napsaná v Perlu, TCL, C nebo v jiném jazyku.SIP CGI definuje skutečně pouze rozhraní.

Jinou doporučovanou možností je využití Call Processing Language (CPL). Jedná se o jazyk protvorbu aplikací, kterými lze ovlivňovat signalizaci hovoru a který je postaven na XML specifikaci.Definice tohoto jazyka nespecifikuje přímo signalizační protokol, čili předpokládá se nasazenínejen v sítích SIPovských, ale i v sítích H.323. Jazyk by měl umožňovat tvorbu jednoduchýchuživatelských aplikací a jejich upload na signalizační server, podporující CPL. Níže je ukázkajednoduchého příkladu CPL, vybraného z IETF draftu. Aplikace realizuje odmítnutí hovorůpřicházejících od anonymních volajících.

Další možností pro realizaci hlasových aplikací je VoiceXML. Technologie, která opět staví naXML a které umožňuje i interakci s volajícím. Dokáže zpracovávat DTMF signály, přehrávatvolajícímu na základě jeho volby připravené sekvence, což umožňuje tímto způsobem realizovatnapř. IVR systém.

Jakkoliv je těžiště aplikací na serverech, mohou být aplikace implementovány i na inteligentníchterminálech (IP telefonech). Mohou např. zajišťovat odlišná vyzvánění pro různé volající nebopřesměrování volání opět podle volaného nebo i na základě jiných atributů.

V příštím pokračování se budeme věnovat bezpečnostním aspektům SIPu.

Protokol SIP (IV) – Bezpe čnostní aspekty


9 z 15 31.10.2007 14:38

Autentizace

Jednou z důležitých voleb při komunikaci mezi klienty a servery je možnost ověření identityvolajícího. SIP pro tyto potřeby převzal opět metody používané v HTTP. Nejběžnější je„authentication digest“, kdy na základě serverem vyslané výzvy obsahující náhodné číslo, posíláklient odpověď obsahující takzvanou hash, tedy výsledek hashovací funkce (obvykle MD5), do nížvstupují jako parametry náhodné číslo a heslo. Tuto hash pak server ověří obdobným výpočtemna své straně. Algoritmus tedy vyžaduje znalost stejného hesla na obou stranách.

Vlastní komunikace probíhá tak, že klient nejprve pošle neautentizovanou zprávu (např. INVITE),na kterou server odpoví zprávou „401 Unauthorized“ obsahující výzvu a metodu, kterou se máautentizace provést. Klient poté opakuje původní zprávu a doplní do ní vypočtenou hash. Pokudtato na serveru souhlasí, je zpráva potvrzena.

Na následujícím výpisu je celý postup dokumentován na příkladu registrace.

Zde je vidět detail zprávy "401 Unauthorized“. Nonce je ono zmiňované náhodné číslo.

Další registrační zpráva již nese hlavičku Authorization obsahující vypočtenou odpověď (hash).

Důvěrnost a celistvost

Pro potřeby utajení obsahu signalizačních zpráv a kontrolu jejich celistvosti může být využitospecifikace S/MIME. Tento standard využívá metod asymetrické kryptografie a předpokládá, žekaždý uživatel má klíčenku veřejných klíčů osob se kterými chce tímto způsobem komunikovat.Podobně jako je tomu u elektronické pošty, kde se uvedený standard rovněž používá. Přišifrovaném přenosu je zajištěno, že některé hlavičky zprávy (To, From, Call-ID, CSeq, Contact) sepřenáší v otevřené podobě. Jedná se o ty, které mohou být využívány mezilehlými uzlyzajišťujícími spojení mezi dvěma koncovými zařízeními .

NAT a firewally

Použití privátního adresového prostoru v podnikové infrastruktuře je dnes samozřejmostívynucenou situací okolo dostupnosti veřejných IP adres. Řešení prostřednictvím nasazení IPv6


10 z 15 31.10.2007 14:38

asi stále v dohledné době nelze očekávat a tak překlad IP adres (NAT, NAPT) při komunikacimezi privátní sítí a Internetem je věc, se kterou je nutnou počítat. Bohužel SIP spadá do skupinyprotokolů, která se s NATem moc ráda nemá. Pro tyto protokoly je typické, že přenášejí IP adresya čísla portů i na aplikační úrovni.

Tato vlastnost způsobí, že se nezdaří buď už samotná signalizace, ale určitě znemožní doručeníRTP streamu mezi účastníky volání.

Další nepříjemností je, že v rámci SIP signalizace se dohadují parametry budoucího RTP streamu(čísla portů), jehož pakety jsou pak obvykle na vstupu do firewallu z veřejné sítě blokovány.

Možným řešením problémů spojených s firewallem je nasazení aplikační brány (ALG – ApplicationLayer Gateway), která realizuje proxy službu pro SIP a RTP. Umístíme do DMZ a na firewallu proni povolíme doručování SIP a RTP paketů.

Jinou možností je zřízení inspekce SIP paketů přímo na firewallu (např. SIP fixup na Cisco PIXfirewallu). SIP paketům, které firewallem procházejí jsou podle aktuální konfigurace NATuměněny údaje uvnitř hlaviček (především SDP) a následně je pak povolena (a správněNATována) RTP komunikace. V rámci IETF skupiny MIDCOM je zpracovávána specifikace provzdálenou komunikaci s firewallem (FCP – Firewall Control Protocol), která by umožnilaoddělenou realizaci inspekce paketů od samotného firewallu.

V případě nedostupnosti uvedených řešení je možné využít toho, že někteří SIP klienti mají ve svékonfiguraci možnost definovat externí (veřejnou) IP adresu, kterou použijí uvnitř hlaviček SIPu.Signalizace tak odchází od klienta v privátní části sítě s hlavičkami obsahujícími veřejnou adresu,jak dokumentuje i následující výpis, ukazující INVITE paket odcházející z privátní adresy naveřejný SIP proxy server


11 z 15 31.10.2007 14:38

SIP (V) – Instant messagingPosílání přímých zpráv je již delší dobu populární služba a programy jako ICQ a AOL InstantMessenger mají své uživatele. Nevýhodou těchto řešení je centralizovanost a proprietárnostznemožňující interoperabilitu . V rámci IETF skupiny SIMPLE (SIP for Instant Messaging andPresence Leveraging Extensions) je připravována specifikace, která umožňuje provozovatzasílání přímých zpráv a přenos informací o aktuální dostupnosti jednotlivých účastníků (InstantMessaging and Presence – IMP) nad protokolem SIP.

Výsledkem těchto snah by mělo být řešení přinášející následující rysy:

Otevřené řešení díky aplikaci IETF standardů.Využití SIP protokolu

SIP je schopen zajišťovat některé klíčové úkony nutné pro fungování IMP (registrace,autentizace)Účastníci se neregistrují na centrálním serveru, nýbrž na serveru v rámci své domény.Informace o přítomnosti je přenášena prostřednictvím SIP signalizaceJe možné využívat SIPovských uživatelských databází

Na SIPovských IP telefonech bude možno provozovat obdobu SMS a MMS, pouštět video,hrát hry …SIP klienti budou mít rovněž k dispozici informaci o aktuální dostupnosti ostatních účastníků

Zejména poslední bod je zajímavý, neboť jednak zpříjemní běžnou telefonní komunikaci meziúčastníky a dává prostor pro tvorbu užitečných aplikací zajišťujících např. automatické zavoláníúčastníka jakmile se přihlásí, ke svému telefonu.

Zobrazení p řítomnosti

Cílem tohoto řešení je, aby uživatel mohl na svém zařízení (telefon, aplikace) sledovat, zdakonkrétní zvolení účastníci jsou dostupní (on-line), nebo zda právě hovoří, či jsou úplně mimodosah.

Pro účely transportu informací o přítomnosti účastníka jsou v SIPu definovány dvě nové metody:SUBSCRIBE a NOTIFY.

Zprávu SUBSCRIBE generuje účastník, který se chce dozvědět v jakém stavu (on-line, off-line,..)je jiný účastník. Tato zpráva je stejně jako jiné SIP zprávy poslána prostřednictvím proxy serverůna presence agenta (PA) zjišťovaného účastníka. PA přitom může být implementován přímo naproxy/registrar serveru.Uvnitř každé zprávy SUBSCRIPTION je nastaven čas platnosti a před jehovypršením je třeba generovat novou zprávu.

PA na základě přijetí SUBSCRIPTION generuje zprávu NOTIFY, kterou oznamuje aktuální stavdotazovaného účastníka. Tato zpráva je pak samozřejmě posílána při každé změně stavu všemúčastníkům, kteří zaslali SUBSCRIPTION. V případě, že mě přestane zajímat v jakém stavu sekonkrétní účastník nachází, je na jeho PA poslána SUBSCRIPTION s expirační dobou nula.

Pro dokreslení opět výpisy z protokolového analyzátoru .

Zpráva SUBSCRIBE


12 z 15 31.10.2007 14:38

Dále následuje ukázka zprávy NOTIFY u níž bohužel analyzátor nedokázal dekódovat formátpopisující aktuální stav. Klíčová slova open a online jsou zvýrazněna:

V předchozím odstavci byl použit pojem Presence Agent. Jedná se o jednu komponentu celéarchitektury jejíž významné součásti jsou:

Presence User Agent – Nástroj uživatele (aplikace, telefon), kterým ovládá stav svépřítomnostiPresentity – Komponenta, která zprostředkovává standardní formou informaci o stavupřítomnosti na Presence ServicePresence Service – Udržuje a distribuuje informace o aktuálním stavu svých uživatelůPresence Agent – SIP UA, reaguje na zprávy SUBSCRIBE, komunikuje s Presence Service,odesílá zprávy NOTIFY.


13 z 15 31.10.2007 14:38

Přenos zpráv

Vlastní přenos zpráv je realizován metodou MESSAGE a probíhá běžným postupem, na jakýjsme u systému přímých zpráv zvyklí. Následující obrázky dokumentují komunikaci meziuživatelem využívajícím aplikaci na PC a jiným uživatelem, který používá IP telefon.

První zprávu vyšle uživatel z PC

Tato je zobrazena na telefonu příjemce


14 z 15 31.10.2007 14:38

Příjemce vytvoří odpověď, kterou odešle zpět uživateli na PC.

Tomu se zobrazí opět v rámci jeho aplikace.

Paket metody MESSAGE vypadá takto .

Tímto článkem krátký seriál o protokolu SIP končí. Zaměřil jsem se v něm hlavně na důležitéaspekty protokolu, které se mohou hodit všem, kdo chtějí využívat telefonování přes IP, ať užv rámci privátní sítě nebo po Internetu.

Relevantní dokumenty:IETF draft - A Presence Event Package for the SIPRFC 2778 - A Model for Presence and Instant Messaging

Další užitečná URL:http://www.xten.nethttp://www.iptel.orghttp://fwd.pulver.com


15 z 15 31.10.2007 14:38

Petr Hrubý, 10.7.2003

protokol sip

Documents

jedn se

jinch st

kter se

proxy server

protokol sip

cz sip

sla port

location service