Modern Technology of Internet

Modern Technology of Internet Jiří Navrátil, Josef Vojtěch, Jan Furman, Tomáš Košnar, Sven Ubik, Milan Šárek, Jan Růžička, Martin Pustka, Laban Mwansa, Rudolf Blažek

Katedra počítačových systémů FIT České vysoké učení technické v Praze MI-MTI, ZS2010/11, Předn.13 VoIP a další aplikace

Evropský sociální fond Praha & EU: Investujeme do vaší budoucnosti

Jan Růžička FIT ČVUT

VoIP a další aplikace

MI-MTI,2010, Předn.13 1

IP telefonie 



Simulujeme telefonní síť pomocí mnohem složitějšího souboru zařízení vyvinutého ke komplexnímu přenosu dat přes IP síť. IP síť − −



Přenos obsahu – RTP − − − −



Přenosová kapacita není vždy nejdůležitější Ztrátovost Zpoždění všech procesů Rozptyl zpoždění

Signalizace − −



Přepínání paketů – neudržuje spojení Best effort

Standardizovaná H.323, SIP Uzavřená – Skype

Unified Communication




Kodeky 

Vysílání −



Příjem −



Dejitter → Dekódování → Výstup

Každá část přispívá k celkovému zpoždění −



Zdroj → Kódování → Paketizace

Nemělo by přesáhnout 200ms

Audio − − −



G.711 A/u law GSM G.722

Video − − − −



H.261 H.263 H.264 H.264 SVC MI-MTI,2010, Předn.13 3

RTP    

RFC 3550, původně v rámci ITU H.225.0 RTCP doprovodný řídící protokol Obaleno UDP (8 oktetů) a IP (20 oktetů IPv4) Hlavička (12 oktetů) obsahuje (hlavní údaje) − − − − −

 

payload type – co přenáším sequence number – pořadí timestamp – časová známka prvního oktetu dat SSRC Synchronization source – identifikace zdroje CCRC Contributing source – původní zdroj (po průchodu mixerem má výstup jedno SSRC)

RTCP-XR – Extented Reporting SRTP – SecureRTP – šifrování




H.323 

 

Sada protokolů definovaná ITU používající několik řídících kanálů ASN.1 PER Identifikátor − − −



E.164 číslo IP URI h323:user@domain

Prvky −

−

Koncové zařízení  Endpoint  MCU  brána Gatekeeper




H.225.0 Registration, Admission and Status (RAS) 

Tři typy zpráv − − −



Požadavek xRQ Odmítnutí xRJ Potvrzení xCF

Používá UDP − −

Port 1719 (unicast) Port 1718 (multicast)




RAS zprávy 

Gatekeeper request, reject, and confirm messages (GRx)



Registration request, reject, and confirm messages (RRx)



Unregister request, reject, and confirm messages (URx)



Admission request, reject, and confirm messages (ARx)



Bandwidth request, reject, and confirm message (BRx)



Disengage request, reject, and confirm (DRx)



Location request, reject, and confirm messages (LRx)



Info request, ack, nack, and response (IRx)



Nonstandard message



Unknown message response



Request in progress (RIP)



Resource availability indication and confirm (RAx)



Service control indication and response (SCx)



Admission confirm sequence (ACS)




H.225.0 Call Signaling   

vychází z Q.931 Slouží k navázání hovoru Std port 1720 TCP Setup Call Proceeding Alerting Information Release Complete Facility


Progress Status Setup Acknowledge Notify Connect



Příklad Q.931 a RAS

3. LCF

GK

4. ACF

GK 7. ACF

2. LRQ 1. ARQ 6. ARQ

5. Setup

GW


8. Connect


GW


H.245 

řídící protokol pro multimedia − − − −

 

Terminal capability exchange Master/Slave determinations Logical channel signaling Conference control

Paralelní kanál k H.225.0 Volitelně jako zcela sepárátní spojení




H.323 doprovodné služby  

 

H.235 popisuje bezpečnost pro signalizaci i média H.239 popisuje druhý kanál obvykle použivaný ve videokonferencích H.450 různé doprovodné služby. H.460 rozšíření H.460.17, H.460.18, and H.460.19 pro podporu průchodu Network address translation (NAT) / Firewall (FW).




Typy směrovaní v H.323  

Přímé spojení (DRC) Přes Gatekeeper (GRC) − přímé H.245, H.225.0 (Q.931) přes GK − včetně H.245 (GK Routed H.245) − Proxy mód




SIP 

RFC3261, textový protokol podobný HTTP



Protokol pro sestavení, řízení a ukončení spojení





Nezávislost na přenášených mediích (hlas, video, text ...) Adresace – URI sip,sips,tel (sip:user@host:port;uriparameters)



Vícenásobný kontakt, IM, Prezence, 3rd PCC



Využití DNS SRV, NAPTR



Už dávno ale není jednoduchý




Architektura 



UAC je logická část posílající požadavky přijímající odpovědi UAS je logická část agenta přijímající požadavky a odesílající odpovědi




Prvky architektury 

Registrar



B2BUA



Server



Gateway

−

redirect



MCU

−

proxy



Outbound proxy



SBC SBE+DBE



ALG



Klient



stateless

Statefull  Transaction  Dialog (Call) 




Metody 

INVITE – začíná a mění spojení



BYE – ukončuje spojení



OPTIONS – dotaz na schopnosti a “ping“



ACK – potvrzení konečné odpovědi na INVITE



REGISTER - vazba mezi sip adresu a aktuální pozici



CANCEL – přerušuje nedokončený INVITE




Metody




Odpovědi 







1xx: Dočasné – potvrzení přijetí požadavku – 100 Trying – 180 Ringing – 183 Session Progress 200 - 699 finální odpovědi 2xx: Úspěch – požadavek byl akceptován – 200 OK 3xx: Přesměrování – 301 Moved Permanently – 302 Moved Temporarily – 305 Use Proxy




Odpovědi 





4xx: Chyba u klienta – Požadavek je špatný nebo nemůže být takto nebo na tomto serveru zpracován – 401 Unauthorized – 404 Not Found – 407 Proxy Authentication Required – 408 Request Timeout – 481 Call/Transaction Does Not Exist 5xx: Chyba u serveru – serveru se nezdařilo zpracovat požadavek i když je v pořádku – 503 Service Unavailable 6xx: Globální chyba – požadavek nemůže být zpracován nikde. – 603 Decline Jan Růžička FIT ČVUT



Transakce a dialog Transakce 



Jeden požadavek a všechny příslušné odpoědi Unikatní branch parametr Via (část za z9hG4bK)

Dialog 





Identifikován sadou Call-ID, From tag, To tag CSeg pořadí požadavků (z každé strany nezávislý čitač)


Registrace 





Vytvoření vazby mezi konkrétní polohou (IP) klienta a je identifikátorem v SIP doméně (To) Poloha = Contact − prázdný Contact v žádosti = zjištění stavu registrací − V odpovědi může být i více záznamů v jedné hlavičce Expires − v požadavku navrhovaná doba − v odpovědi serverem potvrzená − 0 je zrušení registrace Bob


SIP Server | | | REGISTER F1 | |------------------------------>| | 401 Unauthorized F2 | |<------------------------------| | REGISTER F3 | |------------------------------>| | 200 OK F4 | |<------------------------------| | |



Registrace

SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP a.b.c.d:49252;branch=z9hG4bK.6afb7404;rport=49253. From: sip:[email protected];tag=6c2c90b8. To: sip:[email protected];tag=c10ed4fff3e6fb17efd0bfbdcce87ce2.c76e. Call-ID: [email protected]. CSeq: 1 REGISTER. WWW-Authenticate: Digest realm="cesnet.cz", nonce="43eeaeb76e6eeaeffbc37d4f4018dc659c5d282a". Server: Sip EXpress router. Content-Length: 0. REGISTER sip:cesnet.cz SIP/2.0. Authorization: Digest username="user", uri="sip:cesnet.cz", algorithm=MD5, realm="cesnet.cz", nonce="43eeaeb76e6eeaeffbc37d4f4018dc659c5d282a", response="9ebbc39e6a7aaa2901 Via: SIP/2.0/UDP a.b.c.d:49252;branch=z9hG4bK.32f02bf2;rport. From: sip:[email protected];tag=6c2c90b8. To: sip:[email protected]. Call-ID: [email protected]. CSeq: 2 REGISTER. Content-Length: 0. Max-Forwards: 70. Expires: 15. Contact: sip:[email protected]:1234. Jan Růžička FIT ČVUT



INVITE sip:[email protected] SIP/2.0. Max-Forwards: 10. Record-Route: <sip:a.b.c.d;ftag=5DAA94E7;lr=on>. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK0a5d.90580ee2.0. Via: SIP/2.0/UDP g.h.i.j:5062;branch=z9hG4bK2E1FD348. CSeq: 262 INVITE. To: <sip:[email protected]>. Proxy-Authorization: Digest username="bbb", realm="ces.net", nonce="43788e90381ccbec64fced4dc7097828391e81", uri="sip:[email protected]", cnonce="abcdefghi", nc=00000001, response="ed4adec8 Content-Type: application/sdp. From: "Franta Vomacka" <sip:[email protected]>;tag=5DAA94E7. Call-ID: [email protected]. Subject: sip:[email protected]. Content-Length: 234. User-Agent: kphone/4.2. Contact: "Franta Vomacka" <sip:[email protected]:5062;transport=udp>. Remote-Party-ID: "Franta Vomacka" <sip:[email protected]>;party=calling;idtype=subscriber;privacy=off; screen=yes. . v=0. o=username 0 0 IN IP4 g.h.i.j. s=The Funky Flow. c=IN IP4 g.h.i.j. t=0 0. m=audio 33728 RTP/AVP 0 97. a=rtpmap:0 PCMU/8000. a=rtpmap:97 iLBC/8000.

INVITE




Hovor

http://www.tech-invite.com/Ti-sip-ex3261.html Jan Růžička FIT ČVUT



Směrování požadavků podle RURI a Route Směrování odpovědí podle Via

http://www.tech-invite.com/Ti-sip-ex3261.html



Hovor


Record routing 

Jak zajistit aby prvek zůstal v cestě dalších požadavků



Outbound proxy není dostatečná



Do požadavků prvek přidá Record-Route: <sip:adresa;lr>



V odpovědi dorazí Record Route sada



Další požadavky jsou vybaveny a směrovány podle record route sady (Route hlavičky)




RR II

Tech Invite http://www.tech-invite.com/Ti-sip-dialog.html Jan Růžička FIT ČVUT



Tech Invite http://www.tech-invite.com/Ti-sip-dialog.html

RR III



Události - Prezence 







Zápis k odběru oznámení o události např stavu jiného uživatele (prezence) Změna stavu vyvolá poslání NOTIFY např. Busy na Online SUBCRIBE započne dialog a NOTIFY jsou v jeho rámci


Autentizace a integrita 

WWW Digest −

User-to-user (401 Unauthorized, WWWAuthenticate,Authorization)

−

User-to proxy (407 - Proxy authentication required, ProxyAuthenticate, Proxy-Authorization)



S/MIME



TLS – Hop by Hop



identity assertions 

Podmínka zabezpečený “first hop” - TLS



Tokeny, SAML



Podepsané hlavičky




NAT 





Klient za NATem vkládá privátní IP adresu do zpráv – Via, Contact, SDP c-line,... Typy NAT – full cone, restricted cone, port restricted cone, symmetric Řešení – STUN – TURN – ICE – Pomoc proxy serveru (nathelper, mediaproxy in ser and openser) – SBC+DBE – ALG




INVITE

INVITE sip:[email protected] SIP/2.0. Max-Forwards: 10. Record-Route: <sip:g.h.i.j;ftag=5DAA94E7;lr=on>. NAT Via: SIP/2.0/UDP g.h.i.j;branch=z9hG4bK0a5d.90580ee2.0. Via: SIP/2.0/UDP a.b.c.d:5062;branch=z9hG4bK2E1FD348. CSeq: 262 INVITE. To: <sip:[email protected]>. From: "Franta Vomacka" <sip:[email protected]>;tag=5DAA94E7. Call-ID: [email protected]. Subject: sip:[email protected]. Content-Length: 234. User-Agent: kphone/4.2. Contact: "Franta Vomacka" <sip:[email protected]:5062;transport=udp>. Remote-Party-ID: "Franta Vomacka" <sip:[email protected]>;party=calling;idtype=subscriber;privacy=off; screen=yes. . v=0. o=username 0 0 IN IP4 a.b.c.d. s=The Funky Flow. c=IN IP4 a.b.c.d. t=0 0. m=audio 33728 RTP/AVP 0 97. a=rtpmap:0 PCMU/8000. a=rtpmap:97 iLBC/8000.

pro



důležitá místa


SIP „trapezoid“ Domain alfa sip01.alfa

Domain beta sip01.beta

User B sip:b@beta

User A sip:a@alfa

    

Enterprise vs. P2P Autentizace heslem a jiné metody vs. polohou Identita člověka vs. stroje Domácí část Mezidoménová část, i více než jeden krok




DATA SIP

Mezidoménová komunikace zjištění cílové adresy



Číslo na Doménu − − − −



Doména na IP adresu – DNS RFC3263 − − −



Lokální pravidla – přepisy ENUM – DNS SIP peering servery OSP,.... NAPTR SRV A,AAAA

Příma komunikace versus hierarchie (GDS)




Co je ENUM 

 



Slouží k mapování různých adresových a jmenných prostorů mezi sebou Výchozím prostorem je prostor telefonních čísel Cílovým prostorem může být jakékoliv URI (Uniform Resource Indicator) Využití (v IP telefonii) − −

 

Příchozí – ostatní vám mohou volat a vy říkáte „kam“ Odchozí - Voláte vy a nemusíte mít každého ve svém lokálním směrovacím seznamu (informaci spravuje držitel čísla)

ENUM není telefonování zadarmo ENUM zlatý důl spammera !? − −

Držitel čísla zveřejňuje jen to co chce aby bylo vidět Dobře prohledatelný strom (pevné kroky, NXDOMAIN)




Prostory ENUMu Veřejný

Uživatelský

e164.arpa

Operátorský • •

Privátní

nrenum

e164.info

http://crawler.enum.at http://enumdata.org




Příklad 

V jmenném serveru pro 5.3.4.2.2.0.2.4.e164.arpa :

;; order pref flags IN NAPTR 100 50 "u" IN NAPTR 200 50 "u" IN NAPTR 300 50 "u" 

service "E2U+h323" "E2U+sip" "E2U+smtp"

regexp replacement "!^\\+420(.*)$!h323:\\[email protected]!" . "!^\\+420(.*)$!sip:\\[email protected]!" . "!^(.*)$!mailto:[email protected]!“ .

Dotazující SIP klient nebo server provede:

+420224352942 -> 2.4.9.2.5.3.4.2.2.0.2.4.e164.arpa Obdrží oba výše uvedené záznamy a vybere si dle služby E2U+sip Aplikováním regulární ho výrazů získá SIP URI sip:[email protected] Pomocí SRV záznamů je přesměrován na SIP server ser.cesnet.cz 

RFC 3401-3405, RFC3761, RFC3762, RFC3764, …



host -t naptr 9.9.4.0.8.6.4.3.2.0.2.4.e164.arpa




Mezidoménová komunikace zjištění cílové adresy



Číslo na Doménu − − − −



Doména na IP adresu – DNS RFC3263 − − −



Lokální pravidla – přepisy ENUM – DNS SIP peering servery OSP,.... NAPTR SRV A,AAAA

Příma komunikace versus hierarchie (GDS)




Nalezení SIP serveru 

Doménová část URI sip:[email protected]



RFC3263 Locating SIP servers



“servisní” NAPTR záznamy

;;

order pref flags service

regexp

replacement

IN NAPTR 1 5 "s" "SIPS+D2T" "" _sips._tcp.dom.cz. IN NAPTR 2 5 "s" "SIP+D2T"

"" _sip._tcp.dom.cz.

IN NAPTR 3 5 "s" "SIP+D2U"

"" _sip._udp.dom.cz.




NAPTR 

Výchozí URI sip nebo sips – preference volajícího



NAPTR vyjařuje nabídku a preference voláného



TLS s nejvyšší prioritou = nejnižší hodnota



Sip URI je možno „povýšit“ na TLS



Při selhání je možné využít dalších protokolů – Nikoliv u sips




SRV záznamy 

RFC 2782



„záznam pro služby” - rozšířené MX

_sip._udp, _sip._tcp, _sips._tcp, _sip._tls ;;

priority weight port server

_sip._tcp.dom.cz IN SRV 10

0

5060 ser1.dom.cz.

_sip._udp.dom.cz IN SRV 10

0

5060 ser1.dom.cz.

_sips._tcp.dom.cz IN SRV 10

0

5061 ser1.dom.cz.

_sip._tls.dom.cz

0

5061 ser1.dom.cz. ;M$

IN SRV 10

_h323ls._udp.dom.cz _h323rs._tcp.dom.cz Jan Růžička FIT ČVUT

IN SRV 10 0 IN SRV 10 0

1719 gk1.dom.cz. 1720 gk1.dom.cz.



DNSSEC   



Nástup DNSSEC – slepice nebo vejce Informaci je nutné dostat do aplikace Politika - Žádný nebo nevalidní DNSSEC záznam = žádná odpověď? Nedostatek knihoven v aplikacích −



Další možná využití −



Vložení DNSSEC resolveru do cesty (BIND, unbound) těsně před službu – na tomtéž stroji Úložistě certifikátů …

Stav v ČR – podepsané .cz i .0.2.4.e164.arpa




Útoky na infrastrukturu 







Automaticky „poděděny“ útoky v rámci IP − Útoky na podpůrné systémy - DNS Útoky na prvky infrastruktury (DoS, DDoS) − sip servery, brány − rychlé vyčerpání některých prostředků například ISDN linky do ústředny Jednoduchost provedení − SIP už sice dávno není jednoduchý, ale stále je dost jednoduchý Ostrovy vs. mezidoménová komunikace − Email také nefunguje jen uvnitř firmy




Útoky na signalizační úrovni 







  

Odposlech a skenování − lokalizace komponent a číslovacího plánu DoS, DDoS − využití implementačních chyb nebo jen záplava Odposlech medií − E2E šifrování (SRTP, ZRTP, problematika výměna klíčů) Krádež identity (hesla) a zneužití účtu http://www.voipsa.org http://sipp.sourceforge.net/ http://www.tech-invite.com




Útoky na signalizační úrovni 

příklady −

Převzetí či ukončení registrace

−

Pozměnění či ukončení hovoru

−

Podvržení identity (Caller ID)

−

Upravení SDP




Registrace REGISTER sip:cesnet.cz SIP/2.0. Authorization: Digest username="user", uri="sip:cesnet.cz", algorithm=MD5, realm="cesnet.cz", nonce="43eeaeb76e6eeaeffbc7d4f4018aad59c5d282a", response="9e83aaae8abba62901 Via: SIP/2.0/UDP a.b.c.d:49252;branch=z9hG4bK.32f02bf2;rport. From: sip:[email protected];tag=6c2c90b8. To: sip:[email protected]. Call-ID: [email protected]. CSeq: 2 REGISTER. Content-Length: 0. Max-Forwards: 70. Expires: 15. Contact: sip:[email protected]:1234.




ACK BYE

ACK sip:[email protected]:5060 SIP/2.0. Via: SIP/2.0/UDP g.h.i.j:5060; branch=z9hG4bK-62fa494f. From: "user" <sip:[email protected]>;tag=d71ce015c904084do0. To:<sip:[email protected]>;tag=fcbce42a-a00c-4e6e-9208-8d4aafa39602-25051818. Call-ID: [email protected]. CSeq: 102 ACK. Max-Forwards: 70. Route: <sip:k.l.m.n;ftag=d71ce015c904084do0;lr=on>. Contact: "user" <sip:[email protected]:5060>. User-Agent: Linksys/SPA942-6.1.5(a). Content-Length: 0. BYE sip:[email protected]:5060 SIP/2.0. Via: SIP/2.0/UDP g.h.i.j:5060; branch=z9hG4bK-1cfe22de. From: "user" <sip:[email protected]>; tag=d71ce015c904084do0. To:<sip:[email protected]>; tag=fcbce42a-a00c-4e6e-9208-8d4aafa39602-25051818. Call-ID: [email protected]. CSeq: 103 BYE. Max-Forwards: 70. Route: <sip:k.l.m.n; ftag=d71ce015c904084do0;lr=on>. User-Agent: Linksys/SPA942-6.1.5(a). Content-Length: 0. Jan Růžička FIT ČVUT



RTP manipulace v=0

v=0

o=- 0 2 IN IP4 192.168.192.32

o=- 0 2 IN IP4 10.113.113.1

s=CounterPath Bria

s=CounterPath Bria

c=IN IP4 192.168.192.32

c=IN IP4 10.113.113.1

t=0 0

t=0 0

m=audio 58940 RTP/AVP 0 8 3 101

m=audio 57890 RTP/AVP 0 8 3 101

a=sendrecv

a=sendrecv

a=rtpmap:0 PCMU/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:3 GSM/8000

a=rtpmap:3 GSM/8000

a=rtpmap:101 telephone-event/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=fmtp:101 0-15

Pozor na hodnotu Content-Length Jan Růžička FIT ČVUT



SPIT  

Hovory, IM, Prezence Hovor = zvonění telefonu, které okamžitě vyruší −



ZATÍM není moc vidět − − −



Ostrůvky Cena je vyšší než u emailu, ale nižší než PSTN, některé typy ochrany lze překonat botnety. Důležité je nezaspat – nesmíme se dostat do situace, jaká je u mailu, ale uzavřené ostrůvky nejsou řešení.

IETF EG – RUCUS −



Mail „jen“ spadne do schránky

Průzkum navrhovaných metod a standardizace těch efektivních

RFC5039 SIP s SPAM




Metody obrany 

  





Podstata komunikace v reálném čase − Odložení do fronty je problém − Obrana vs. možné omezení dostupnosti služby Whitelisty, Blacklisty, Greylisty ... Problém počátečního představení iniciátora Interakce s uživatelem − CAPTCHA (IVR), − výpočetní zátěž – problém poměru výkonu zařízení − mikroplatby Silná identita jako podmínka fungování předchozích bodů pro následnou komunikaci Centralizovaná architektura jako u PSTN




Metody obrany II  



Silná = důvěryhodná identita Domácí část - první krok − nahrazení či zabalení HTTP Digest − TLS – perzistentní spojení - „obálka“, nutně nemusí být klientské certifikáty, chrání i odpovědi Mezidoménová identita – obdoba DKIM − TLS – Hop By Hop – omezené na 1 skok − P-Asserted-Identity je nedostačující − SIP Identity (RFC4474) a SIP SAML − Princip vložení doménového podpisu




SIP identity 





Persistentní SIP hlavičky podepsány hraničním SIP elementem Ověřitelná identita přes více skoků bez nutnosti důvěry mezi skoky Pro vložení je třeba − − −

Definova sadu hlaviček (RFC) – rozšiřitelnost? Politiky – kdo může podposi vložit Zabezpečený první skok - TLS.



Nejen cílová proxy může ověřit identitu



Problémy − −

Jen pro odpovědi Čísla (nemají jednoznačnou vazbu na doménu)




SRTP 

Rozšíření RTP − −

Důvěrnost Autenticita




Distribuce master klíče 

Přímo v SDP SDES RFC4568 – – –

a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:WbTBosdVUZqEb6Htqhn+m3z7wUh4RJVR8nE1 5GbN Slabě nebo vůbec nechráněno TLS? Jen Hop by hop

• MIKEY RFC3830 – – – – 

E2E bezpečnost Jednoduše a efektivně (málo pásma, kódu, zátěže, kroků komunikace – Initiator I a Responder R Message ) Možnost tunelování (vnoření do sestavení spojení, SDP) Nezávislost na transportním protokolu nižší vrstvy

ZRTP




ZRTP    

 

DH Krátký autentizační kód SAS Hash přes utajované hodnoty a krátký kód Hodnota použita jen jednou a část uložena pro forward secrecy Ochrana pro MitM Postup − − −

Detekce podpory ZRTP Výměna symetrických klíčů Přepnutí do SRTP




Troubleshooting



logy



ngrep -W byline port 5060



tethereal -s 1600 -w teth.eth port 5060



Ethereal →Statistics → VoIP calls



http://wiki.freeswitch.org/wiki/Packet_Capture




Příklad aplikací • • • • •

Sip-router.org (Kamailio) Freeswitch.org Asterisk.org pjsip.org Sipp http://sipp.sourceforge.net/




Otázky

Modern Technology of Internet

Recommend Documents