1 6. přednáška SIP Obsah 2 1. Charakteristika a historie protokolu 2. Architektura protokolu 3. Bezpečnostní otázky 4. Konfigurace SIP na Cisco směrovačích 5. RAMS 6. Porovnání H.323 a SIP Charakteristika a historie protokolu 3  Protokol řízení aplikační vrstvy vycházející z textu ASCI  Vyvinutý IETF pro multimediální (hlasové, obrazové, textové) konference přes IP  Konkrétně nabízí vytvoření a udržování relace (session), což je výměna dat uvnitř seskupení účastníků  Je určen pro aplikace, kde - uživatelé se přesunují mezi koncovými body - uživatelé adresovatelní více jmény  Nejde o samostatný komunikační systém, SIP je spíše komponenta, kterou lze použít společně s dalšími protokoly IETF (RTP, RTSP, MGCP, SDP) k sestavení úplné multimediální architektury. Také používá URL pro adresování, DNS pro vyhledávání služeb a TRIP (Telegraphy Routing over IP) pro směrování hovorů. Podpůrné služby mohou poskytovat i LDAP servery databázové servery, aplikace XML atd.  Základní funkčnost a provoz SIP ale na jiných protokolech nezávisí Jak a proč SIP funguje 4  Funguje na principu pozvání k relacím založeným na transakčním modelu „požadavek – reakce“ podobnému HTTP. Transakce je tvořena požadavkem, ten aktivuje na druhé straně nějakou funkci (metodu) a min. jednu reakci  SIP patří do kategorie „peer-to-peer“ (end-to-end) protokolů. Normálně používá UDP port 5060 (pro TLS 5061 – sips), ale stejný port může fungovat i pro TCP.  Proč brány SIP jako hlasové brány? Výhody: - číslování se konfiguruje přímo na bráně – volání na přímo připojená zařízení lze zpravovat přímo na bráně a nemusí se přeposílat na speciální zařízení (např. CUCM). Obdobně se lze vyhnout i směrování na speciálních zařízeních v případě volání na zaregistrovaná místa přímo na bráně - překlady lze definovat na jednotlivých branách á tím uplatnit regionální požadavky (např. formáty speciálních čísel) - integrace hlasových bran různých výrobců (např. komunikace hlasové brány Cisco IOS – s hlasovou branou Alcatel-Lucent) Fitlr na Wiresharku 5 Odchycený SIP paket 6 Historie vzniku protokolu SIP 7 Work began in 1995 in IETF mmusic WG 02/1996: draft-ietf-mmusic-sip-00: 15 stran 12/1996: -01: 30 stran, dva typy request 01/1999: -12: 149 stran, 6 metod 03/1999: RFC2543, 153 stran, 6 metod 11/1999: SIP WG 11/2000: draft-ietf-sip-rfc2543bis-02, 171 stran, 6 metod 04/2001: rozdělení na skupinySIP WG a SIP a SIPPING 02/2002: RFC3261 – 269 stran (jádro protokolu) 03/2010: RFC5727 – změny Dokumenty 1 8 Dokumenty 2 9 Dokumenty 3 10 Dokumenty 4 11 Dokumenty 5 12 RFC 3261 – 269 stran! 13 SIP center 14 SIP Forum 15 OpenSIP 16 TechRepublic 17 P2P SIP 18 19 2. Architektura protokolu Architektura protokolu SIP 20 Prvky protokolu SIP 21 • účastnické stanice (User agent – UA) • SIP proxy server (zástupný server) SIP trapezoid Účastnické stanice 22  Účastnické stanice (User Agent – UA) jsou zařízení implementující protokol SIP používané zejména k uskutečnění a příjmu hovorů umístěné na konci sítě internetové telefonie.  Alternativně mohou být za účastnickou stanici považovány brány do dalších sítí jako například brána do sítě PSTN, umožňující volání a příjem hovorů ze sítě PSTN.  Častým případem jsou také účastnické stanice používané výhradně pro IM (Instant Messaging).  Uživatelské stanice mohou být ve formě softwaru na klasických PC (softwarové telefony), popřípadě se může jednat o specializovaná zařízení pro IP telefonii (hardwarové telefony).  Účastnické stanice musejí být schopny obsluhovat celou řadu protokolů používaných ve světe internetové telefonie (SIP, RTP, RTCP, STUN atd.).  Účastnické stanice jsou rovněž zodpovědné za kódování signálu před přenosem a musejí tak implementovat některé přenosové kodeky. Složení účastnické stanice 23  Každá účastnická stanice se skládá ze dvou částí: - Klientská část (UAC – User Agent Client) je část zodpovědná za vytváření volání, za registraci stanice atd. - Serverová část (UAS – User Agent Server) je část zodpovědná za příjem požadavků a generování odpovídajících odezev. Všechna koncová zařízení a servery implementují jak UAC, tak i UAS. SIP proxy server 24  SIP proxy server (zástupný server) je zařízení zodpovědné za příjem požadavků od uživatelských stanic a ostatních SIP proxy a jejich následné směřování na další SIP proxy popřípadě přímo na cílovou uživatelskou stanici tehdy, kdy je cílová stanice registrována na této SIP proxy.  Vyhledání další SIP proxy je možné pomocí DNS systémů popřípadě pomocí fixního směrování nastaveném v dané proxy.  Rozdělení: stateless a statefull (poznají opakující se zprávy, smyčky, větvení atd.) Stateful jsou transakční (do ukončení transakce) a dialogové (do ukončení dialogu) Další prvky architektury 25 • redirect (přesměrování) server • register (registrační) server • location (lokační) server • STUN • RTP proxy • brány Redirect, Register a Location servery 26 Register server (registrační server) je zodpovědný za příjem a zpracování REGISTER zpráv popisujících okamžitou lokalizaci uživatelské stanice (její IP a port). Registrační servery bývají spojeny s lokačními servery a SIP proxy servery v jeden homogenní celek.  Location server (server umístění, lokalizační server) využívá databáze pro uložení informace o lokalizaci účastnické stanice (IP adresa, port), která je location serveru poskytnuta registračním serverem na základě přijaté REGISTER zprávy. K vyhledání koncového uživatele může použít různé protokoly (finger, rwhois, LSDAP…) Redirect server (přesměrovací server) po přijetí zprávy INVITE provede vyhledání ve vlastní databázi a následně odpoví uživatelské stanici zprávou ze skupiny přesměrování (REDIRECT 3xx) která obsahuje novou adresu, kam by měla uživatelská stanice poslat novou zprávu INVITE. Register server poskytuje informace location serveru 27 Rozdíl v roli redirect a location serveru Kde je register server? 28 STUN a RTP proxy 29  STUN (Simple Traversal of UDP over NAT) je protokol umožňující překonat problém protokolu SIP nebo přesněji protokolu SDP (Session Description Protokol) užívaného uvnitř protokolu SIP (například uvnitř metody INVITE) k popisu cílové IP adresy a portu pro RTP stream. Prochází-li pak paket nesoucí metody INVITE přes NAT, je privátní IP adresa paketu nahrazena adresou veřejnou.  RTP proxy jsou užity pro řešení problémů s překladem adres v případech, kdy například oba účastnící jsou v různých privátních sítích za symetrickým NAT. RTP proxy se rovněž používají pro zvýšení úrovně zabezpečení v sítích. RTP proxy spolupracuje se SIP proxy. SIP proxy provádí náhradu adres pro RTP stream v SDP a instruuje RTP proxy k otevření příslušného RTP kanálu. Brány k PSTN a H.323 30 SIP adresace je podobná e-mailu 31 sip:user@domain:port sip:user@host:port sip:phone number@domain SIP URI 32 sip: user: password@host:port;uri-parameters?headers SIP URI 33 Úplný tvar adresy: sip:[uživatel[:heslo]@]hostname[:port][;parametry][?hlavičky] Jednoduchý příklad: sip:jaroslav.dockal@fi.muni.cz Složitější příklad: sips:jdockal:veslo@fi.muni.cz;transport=UDP;maddr=224.2.0.1 Příklad SIP adresy 34 Příklad topologie 35 Začátek: DHCP a TFP 36 Základní metody protokolu SIP 37 Typ zprávy Popis INVITE Slouží k žádosti o sestavení spojení ACK Acknowledgment – potvrzení INVITE (volaným). – realizuje třífázový handshaking BYE Ukončení spojení CANCEL Ukončení nesestaveného spojení REGISTER Registrace UA OPTIONS Dotaz na možnosti a schopnosti serveru Metoda je funkce, která je zabalena do zprávy Rozšíření metod protokolu SIP 38 Příklad pravidla pro zprávy 39 Všechny SIP požadavky musí obsahovat pole pro From To Call-ID CSeq Max-Forwards Via Volitelné pole záhlaví 40 Volitelné pole Struktura zprávy 41 CR LF start-line, CR LF záhlaví Metoda REGISTER 42 Via:SIP/2.0/UDP 195.122.198.236:5065; rport; branch=z9hG4bK4CA55835E62B4946BF92115DE0603D53 From: Jarda ;tag=4292754936 To: markl Contact: „jarda" Call-ID: 575AA2FBE68944D48AD5FAEC66C71855@sip.domain.cz CSeq: 1893 REGISTER Expires: 1800 Max-Forwards: 70 User-Agent: SIPphone Lite release 1104v Content-Length: 0  Metoda REGISTER informuje register server o aktuální pozici (IP adresa) telefonu.  Uživatel může mít zaregistrováno více lokací (několik IP adres přístrojů) přičemž preference pro výběr kontaktní lokace se nastavují pomocí tzv. q-hodnot.  Při nastavení většího množství kontaktních lokací pak může být kontaktováno více telefonů najednou (pomocí forking mechanizmu) popřípadě mohou být adresy zkoušeny postupně. Nejdůležitější pole metody REGISTER 43 Záhlaví Popis Contact Obsahuje URL, které může být použito pro zpřístupnění uživatele. Může rovněž obsahovat PSTN telefonní číslo nebo URL uživatelových webových stránek. Expires Indikuje dobu platnosti registrované adresy. Výměna registračních zpráv 44 Request 45 povinné parametry: Via, From, To, Call-ID, CSeq, and Max-Forwards zajišťují směrování, identifikaci paketů a uspořádání Via: odlišení RFC 2543 RFC 3261 46 Magická značka RFC 3261 Tagy identifikují dialog 47Call-ID seskupuje zprávy dialogu dohromady Cseq: 48 doporučená hodnota může obsahovat nejen číslo transakce, ale i metodu Response (OK) 49 redukuje počet zpráv Kategorie návratových kódů 50 • požadavek je zpracováván • požadavek byl úspěšně zpracován • požadavek je třeba směrovat jinam • chyba klienta • chyba na serveru • globální chyba  Protokol SIP používá číselné kódy pro předání informace o průběhu zpracování požadavku. Některé kódy jsou přímo převzaty z protokolu HTTP, jiné jsou specifické pro protokol SIP.  Návratové kódy jsou rozděleny do šesti kategorií: Šest kategorií návratových kódů 51 Třída Popis 1xx Požadavek je zpracováván (např. „100 Trying“, “180 Ringing”). 2xx Požadavek byl úspěšně zpracován (např. “200 OK”). 3xx Přesměrování: Požadavek je třeba směrovat jinam (např. “305 Use proxy”). 4xx Chyba klienta: Dotaz by se neměl ve stejné podobě opakovat (např. "403 Forbidden"). Např. 483, když MAX-FORWARDS = 0 5xx Chyba na serveru (např. "500 Server Internal Error", "501 Not Implemented"). 6xx Globální chyba ("606 Not Acceptable"). Příklad metody REGISTER 52 UDP je typický pro SIP, TCP je typický pro SIPS Příklad metody INVITE 53 INVITE sip:darda@sip.domainB.cz SIP/2.0 Via: SIP/2.0/UDP 195.122.198.236:5065;rport;branch=z9hG4bK1441F37B74154C09BD150D68AD 8B83F7 From: jarda ;tag=1603324369 To: Contact: Call-ID: 650ADF5C-0EB4-499A-9744-2B2561B30C94@192.168.2.111 CSeq: 9126 INVITE Max-Forwards: 70 Content-Type: application/sdp User-Agent: SIPphone Lite release 1104v Content-Length: 321 v=0 o=markl 212548077 212548116 IN IP4 195.122.198.236 s=SIPphone Lite c=IN IP4 195.122.198.236 t=0 0 m=audio 8000 RTP/AVP 0 8 3 98 97 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:3 gsm/8000 a=rtpmap:98 iLBC/8000 a=rtpmap:97 speex/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv Analýza požadavku 54 INVITE sip:darda@sip.domainB.cz SIP/2.0 Via: SIP/2.0/UDP 195.122.198.236:5065;rport;branch=z9hG4bK1441F37B74154C09BD150D68AD8B83F7 Via umožňuje dopručení odpovědi po stejné trase, branch slouží pro detekci smyček From: jarda ;tag=1603324369… pro rozeznání,kdo odpovídá u forku To: Contact: sip:jarda@195.122.198.236:5065.. Některé metody mi posílej přímo Call-ID: 650ADF5C-0EB4-499A-9744-2B2561B30C94@192.168.2.111....identifikátor stejného dialogu CSeq: 9126 INVITE … pořadové číslo žádosti Max-Forwards: 70 – omezení počtu skoků (70 default)  Metoda INVITE se používá pro inicializaci volání určitým uživatelem.  Volající ji posílá INVITE volanému pro nastavení nejrůznějších parametrů volání. Příklad metody INVITE 55 Popis základních polí 56 Pole Popis Request line Skládá se ze tří parametrů: Method, Request-URI and protocol version. Například: INVITE sip:novak@sip.domainB.cz SIP/2.0 Method Indikace SIP metody. Například INVITE, REGISTER atd. Request-URI Indikuje další skok, kam má být požadavek směrován. Tato hodnota se mění v každé proxy na cestě. Protocol version Version of SIP protocol. SIP/2.0 Via Každé proxy na cestě požadavku je do tohoto pole zaznamenáno a tak je možné tuto cestu opakovat. Pole Via lze rovněž použít pro detekci smyček. From Identifikuje iniciátora volání (volající). Pole From obsahuje parametr tag, který slouží jako identifikátor dialogu. To identifikuje příjemce (volaného). Contact Obsahuje IP adresu a port, na kterém odesílatel očekává další žádosti odesílané volaným. Call-ID Identifikátor relace (volání). Jeho cílem je identifikovat zprávy náležející jednomu volání. Takovéto zprávy mají stejný identifikátor Call-ID. CSeq Command Sequence – skládá se ze dvou částí – čísla a názvu metody. Číslo odlišuje požadavky v rámci relace. Metoda je použita k rozlišení mezi odpovědmi na zprávy CANCEL a INVITE. Protože žádosti mohou být odeslány nespolehlivým přenosem, příjemce musí rozpoznat opakování přenosu a selektovat žádosti. Max-Forwards Obdoba TTL u IP paketů. Slouží k vyřazení cyklujících zpráv. Každé proxy snižuje tuto hodnotu, v případě poklesu hodnoty na nulu je zpráva vyřazena. Content-Length Délka těla zprávy odděleného od záhlaví jednoduchým CRLF. Přenos parametrů hovoru 57 INVITE sip:darda@sip.domainB.cz SIP/2.0 Via: SIP/2.0/UDP 195.122.198.236:5065;rport;branch=z9hG4bK1441F37B74154C09BD150D68AD 8B83F7 From: markl ;tag=1603324369 To: Contact: Call-ID: 650ADF5C-0EB4-499A-9744-2B2561B30C94@192.168.2.111 CSeq: 9126 INVITE Max-Forwards: 70 Content-Type: application/sdp …typ těla zprávy User-Agent: SIPphone Lite release 1104v Content-Length: 321 …délka těla v=0 o=markl 212548077 212548116 IN IP4 195.122.198.236 s=SIPphone Lite c=IN IP4 195.122.198.236 t=0 0 m=audio 8000 RTP/AVP 0 8 3 98 97 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:3 gsm/8000 a=rtpmap:98 iLBC/8000 a=rtpmap:97 speex/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv o – originator IN – Internet s – session a – atribut Pole protokolu SDP (Session Description Protocol) 58 Pole Popis V Verze protokolu SDP. Platná verze je 0. O Origin – Není použito protokolem SIP. S Subject – Není použito protokolem SIP. C Connection – síť (IN pro Internet), typ addresy (IP4 pro IPv4) a adresa, kam směrovat proud RTP paketů. T Time – není použito protokolem SIP M Media – media type (audio, video), číslo portu (8000) atd. A Attribute – podporované kodeky, frekvence vzorkování atd. INVITE bez rozbaleného SDP 59 INVITE s rozbaleným SDP 60paket 20 ms Zobrazení paketu v syrovém tvaru 61 Základní typy výměn zpráv 62 • INVITE • INVITE s proxy autentizací • BYE • CANCEL • REGISTER Sestavení spojení pomocí zprávy INVITE 63  Když volající chce uskutečnit hovor, jeho telefon posílá zprávu INVITE na SIP proxy volaného (v dalším textu budeme pro zjednodušení vždy uvažovat jednoduchou variantu, kdy jsou oba účastnící ze stejné domény, popřípadě kdy účastník nepoužívá odchozí SIP proxy, hovor je tak směřován pouze přes jednu SIP proxy).  SIP proxy odpoví volajícímu provizorní odpovědí 100 Trying, která znamená, že se SIP proxy snaží kontaktovat telefon volaného (zabraňuje opakování INVITE).  SIP proxy pak provede vyhledání kontaktní IP adresy volaného v lokální databází a odešle zprávu INVITE na telefon volaného.  Telefon po přijetí zprávy INVITE začne zvonit a informuje o tom volajícího zprávou 180 Ringing.  Když potom volaný přijme hovor, odezva 200 OK je poslána volajícímu.  Telefon volajícího potvrdí úspěšné sestavení spojení zprávou ACK.  Spojení je nyní sestaveno a přenos RTP může začít. Sestavení spojení pomocí INVITE 64 Co vlastně měříme? Poznámka k výkonnostním metrikám 65 INVITE 180 RingingRinging delay (RD) 200 OK RTP RTPMedia clipping (MC) MC dle G.114 je max 150 ms Early media (RFC 3960) 66 jednosměrné, obousměrné, inicializované jednou stranou či oběma Media clipping (ztráta prvních slov hovoru) 67 UAS nemůže poslat tok, dokud nedostane ACK. UAC nemůže dostat tok, dokud nedostane 200 (OK). Early media pomocí 183 a PRACK (prozatímní ACK má své potvrzení, jinak by nemohl procházet přes proxy) 68 Příklad: Hned to valí 69 Sestavení spojení pomocí zprávy INVITE s autentizací 70  V případě, kdy SIP proxy vyžaduje autentizaci, je první zpráva INVITE poslána stejným způsobem, jako v předchozím případě.  Proxy reaguje na přijatou INVITE zprávu odezvou 407 Proxy Authentication Required, kde proxy umístí Proxy-authenticate výzvu s nastavenými poli realm a nonce.  Telefon volajícího potvrdí odpověď SIP proxy zprávou ACK a použije získaná pole realm a nonce k vytvoření hodnoty pole Response v nové INVITE zprávě.  Nová zpráva INVITE s Proxy-Authentication záhlavím, obsahující uživatelské jméno, realm, nonce a vygenerované pole Response, je poslána znovu na SIP proxy.  SIP proxy ověří zadané hodnoty a když proxy odpovídají, pokračuje ve zpracování požadavku stejně jako v předchozím scénáři bez proxy autentizace. INVITE s proxy autentizací 71 Časovače podle RFC3261 72 Časovač Defaultní hodnota Význam T1 500 ms Round-trip time (RTT) – odhad T2 4 s. Maximální interval retransmise T4 5 s. Maximální doba setrvání zprávy v síti Timer A původní T1 Interval retransmise žádosti INVITE (UDP) Timer B 64*T1 Vypršení transakce INVITE Timer D > 32 s. pro UDP Čekání na odpověď retransmisí 0 s. pro TCP a SCTP Timer E původní T1 Interval retransmise žádostí non-INVITE (UDP) Timer F 64*T1 Vypršení transakce non-INVITE Timer G původní T1 Interval retransmise odpovědi na INVITE Timer H 64*T1 Čekání na příjem ACK Timer I T4 pro UDP Čekání na retransmise ACK 0 s. pro TCP a SCTP Timer J 64*T1 pro UDP Čekání na retransmise non-INVITE žádostí 0 s. pro TCP a SCTP Timer K T4 pro UDP Čekání na odpověď retransmisí 0 s. pro TCP a SCTP describes the timer, and the meaning of the timer. Ukončení hovoru pomocí zprávy BYE 73  Když chce jeden z uživatelů ukončit hovor, pošle jeho telefon zprávu BYE telefonu druhého uživatele.  Telefon druhého uživatele potvrzuje ukončení hovoru zprávou 200 OK. Zde připadají v úvahu dvě varianty závisející na tom, zda je či není používán tzv. record-routing mechanizmus. Příklad metody BYE jeden 74 tento položil sluchátko Odpověď BYE druhý 75 Pole Record-route 76 Na předchozím slajdu je zobrazena varianta, kdy zpráva BYE je posílána druhému telefonu opět přes SIP proxy. Toho může být docíleno jednak nastavením telefonu tak, že je vynuceno užití odchozí proxy pro všechny zprávy, popřípadě použitím vnitřního mechanizmu SIP protokolu zvaného record-routing. Ten se používá zejména v případech, kdy potřebujeme zajistit plnou informovanost SIP proxy o stavu volání (plně stavová proxy), což je důležité například pro získání délky doby hovoru (doba mezi průchodem zprávy INVITE a zprávy BYE) pro účely účtování hovorů. Pole Record-route jsou přidávána každou SIP proxy, kterou zpráva INVITE prochází na cestě k telefonu volaného. Záhlaví record-route jsou poté zkopírovány telefonem volaného do odpovědi 200 OK a tato zpráva je zaslána volajícímu. Telefon volajícího transformuje obdržená record-route záhlaví z přijaté zprávy 200 OK na záhlaví Route, která jsou poté umístěna do další zprávy zasílané telefonem volajícího (to může být například právě zpráva BYE). Při zpracování následujících zpráv, ve kterých jsou nastavena pole Route, SIP proxy používá tato pole pro určení následující SIP proxy, kam mají být zprávy směrovány. Tak je zajištěno, že všechny následné zprávy procházejí stejnou cestou jako původní zpráva INVITE. Zrušení hovoru pomocí zprávy CANCEL 77  Zpráva CANCEL se používá pro zrušení právě probíhající transakce. Například když volající chce zrušit právě probíhající transakci INVITE (uživatel „vytočil telefonní číslo“, zpráva INVITE již byla odeslána, ale před tím než došlo ke spojení, uživatel se rozhodl hovor zrušit a zavěsil). Telefon v tomto případě pošle zprávu CANCEL se stejnou hodnotou pole Cseq, jaká byla v předchozí zprávě INVITE.  Transakce INVITE je nyní zrušena.  Celá situace je zachycena na dalším slajdu. CANCEL 78 Zpráva CANCEL s hodnotou pole CSeq 79  Na začátku pošle přístroj volajícího zprávu INVITE a tak započne transakci a procedura kontaktování volaného je spuštěna. Nyní volaný chce ukončit probíhající transakci, a proto pošle zprávu CANCEL s hodnotou pole CSeq nastavenou stejně jako v předchozí INVITE zprávě.  První SIP proxy v cestě odpoví zprávou 200 OK okamžitě poté, co obdrží zprávu CANCEL. Zpráva CANCEL je poté přeposlána volanému.  Přístroj volaného rovněž odpoví okamžitým odesláním zprávy 200 OK a následně pošle také zprávu 487 Request Cancelled na SIP proxy.  Proxy potvrdí přijetí zprávy zprávou ACK a přepošle zprávu 487 Request Cancelled volajícímu.  Přístroj volajícího potvrdí SIP proxy přijetí zprávy zprávou ACK. Scénář registrace v případě vyžadované autentizace 80  Nejprve je zaslána zpráva REGISTER se záhlavím Contact a bez jakéhokoliv autentizačního záhlaví.  Proxy na tuto zprávu reaguje odesláním odpovědi 401 Unauthorized, do níž proxy vloží záhlaví WWW-authenticate s nastavenými hodnotami polí realm a nonce.  Telefonní přístroj použije přijaté hodnoty polí nonce a realm k vygenerování hodnoty pole Response.  Poté je na SIP proxy znovu poslána zpráva REGISTER obsahující záhlaví Authorization s poli username, realm, nonce a vygenerovaným polem Response.  SIP proxy ověří přijaté hodnoty a v případě, že jsou správné, uloží získané kontaktní údaje (pole Contact) do location databáze a odpoví zprávou 200 OK registrovanému přístroji. REGISTER 81 Registrace 82  Registrační server se chová jako služba předřazená lokalizačnímu serveru, prakticky jsou obě služby realizovány v jediném zařízení.  Registrační server 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“ (globální chyba).  V záhlaví "To:" je uvedena adresa uživatele, pro koho je registrována, ve "From:“ je uvedena adresa uživatele žadatele o registraci. Klient může specifikovat dobu, po níž má být adresa registrována v záhlaví "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 záhlaví "Expires:" v odpovědi, nebo platí standardní doba.  Klient může zrušit existující registraci specifikováním nulové doby registrace. Použití pole INFO – RFC 2986 83 Přenos informace aplikační úrovně mezi koncovými body:  PSTN zprávy  DTMF signalizace  účetní informace  o síle WiFi signálu  obrazce Příklad použití pole INFO 84 INFO sip:2143302100@172.17.2.33 SIP/2.0 Via: SIP/2.0/UDP 172.80.2.100:5060 From: ;tag=43 To: ;tag=9753.0207 Call-ID: 984072_15401962@172.80.2.100 CSeq: 25634 INFO Supported: 100rel Supported: timer Content-Length: 26 Content-Type: application/dtmf-relay Signal= 1 Duration= 160 Nová náplň pole INFO – RFC 6086 85 Použití pole INFO podle RFC 6086 86 INFO sip:alice@pc33.example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef To: Bob ;tag=a6c85cf From: Alice ;tag=1928301774 Call-Id: a84b4c76e66710@pc33.example.com CSeq: 314333 INFO Info-Package: foo Content-type: application/foo Content-Disposition: Info-Package Content-length: 24 Info-Package – typ paketu Recv-info 87 Recv-Info: indikuje, který typ paketů INFO podporuje UA INVITE sip:bob@example.com SIP/2.0V ia: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 Max-Forwards: 70 To: Bob sip:bob@fi.muni.cz From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710@fi.muni.cz CSeq: 314159 INVITE Recv-Info: P, R Contact: sip:alice@fi.muni.cz Content-Type: application/sdp Content-Length: RFC 51188 – SIP IPv6 88 REGISTER sip:[2001:db8::10] SIP/2.0 To: sip:user@example.com From: sip:user@example.com;tag=81x2 Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111 Call-ID: SSG9559905523997077@hlau_4100 Max-Forwards: 70 Contact: "Caller" CSeq: 98176 REGISTER Content-Length: 0 SIPv6 INVITE s SDP 89 INVITE sip:user@[2001:db8::10] SIP/2.0 To: sip:user@[2001:db8::10] From: sip:user@example.com;tag=81x2 Via: SIP/2.0/UDP [2001:db8::20];branch=z9hG4bKas3-111 Call-ID: SSG9559905523997077@hlau_4100 Contact: "Caller" CSeq: 8612 INVITE Max-Forwards: 70 Content-Type: application/sdp Content-Length: 268 v=0 o=assistant 971731711378798081 0 IN IP6 2001:db8::20 s=Live video feed for today's meeting c=IN IP6 2001:db8::20 t=3338481189 3370017201 m=audio 6000 RTP/AVP 2 a=rtpmap:2 G726-32/8000 m=video 6024 RTP/AVP 107 a=rtpmap:107 H263-1998/90000 Volání v rámci jedné domény 90 1. Volání uživatele B 2. Dotaz “Kde je uživatel B?” 3. Odpověď “SIP adresa uživatele B” 4. Volání přes proxy 5. Odpověď 6. Odpověď 7. Vytvoření multimediálního kanálu Volání mezi doménami 91 1. Volání uživatele B 2. Dotaz: Jak se dostanu k uživateli B v doméně B?“ 3. Odpověď „Adresa řadiče proxy domény“ 4. Volání přes proxy na proxy domény B 5. Dotaz „Kde je uživatel B?“?” 6. Adresa uživatele B 7. Volání zprostředkované přes proxy 8. Odpověď 9. Odpověď 10. Odpověď 11. Vytvoření multimediálního kanálu Otázka pro zopakování: Které prvky topologie jsou zapojeny při navazování spojení? 92 ? ? ? ? Otázka pro zopakování: Které prvky topologie jsou zapojeny při navazování spojení? 93 ? ? ? 94 3. Bezpečnostní otázky Bezpečnostní mechanismy protokolu SIP 95  HTTP Digest  S/MIME  TLS  IPSec s ručně nastavenými klíči  IPSec s IKE  MIKEY SIP HTTP autentizace 96  Vychází z RFC 2617. Jde o jednoduchou autentizaci typu dotaz-odpověď, kde odpověď tvoří: - kontrolní suma uživatelova jména (defaultně MD5) - heslo - hodnota nonce - http metoda a požadované URI (Uniform Resource Identifier).  Heslo je přenášeno v zašifrované podobě, přesto tato metoda autentizace není v současnosti doporučovaná. S/MIME 97  Další autentizační metodou použitou v SIPu je S/MIME  Již samotný MIME (Multipurpose Internet Mail Extensions) používá metody pro kontrolu integrity a šifrování  S/MIME je doplňuje o takové mechanismy jako je distribuce veřejných klíčů a autentizace  V RFC 3261 je doporučeno pro UA TLS 98  Pro ochranu SIP signalizace mezi UA a proxy, redirect serverem a register serverem je v RFC 3261 doporučen protokol TLS. Tento protokol umožňuje - kontrolu integrity - zajištění důvěrnosti - ochranu proti přehrávání - integrovaný management klíčů se vzájemnou autentizací a jejich bezpečnou distribucí  Předpokládá se použití metodou skoku (hop-by-hop) mezi UA a proxy resp. mezi dvěma proxy  Stinnou stránkou použití TLS je nutnost použít spolehlivý transportní mechanismus (SIP signalizaci na bázi TCP), UDP použít nelze IPSec s ručně nastavenými klíči 99  Na síťové vrstvě lze využít mechanismu IPSec, který slouží k zajištění - autenticity - integrity - důvěrnosti - proti přehrávání  Scénáře mohou být typu hop-by-hop i end-to-end. IPSec zatím nemá definovanou kryptosadu pro SIP. IPSec s IKE integrovaným do SDP 100 INVITE / IPSec required UPDATE IKE 183 Session in progress 200 OK (UPDATE) 200 OK (INVITE) Internet Key Exchange (IKE nebo IKEv2) vytváří bezpečnostní asociace MIKEY 101 INVITE / MIKEY Init 200 OK / MIKEY Response 200 OK INVITE / MIKEY Init 183 / MIKEY Response PRACK Může být - v MIME - v SDP a=crypto: [] PRACK – Provisional ACK Problém s NAT 102 Problémy jsou zde obdobné jako u protokolu H.323 vyjma toho, že navázání spojení a analýza záhlaví jsou zde mnohem jednodušší. Velký problém je právě s NAT. Otázkou je, kde je umístěno proxy: - uvnitř vnitřní sítě (v rámci lokální LAN); - v rámci vnější sítě a z vnitřní sítě se je třeba k němu přihlašovat; - dvě administrativní domény jsou spolu propojeny, každá má vlastní proxy. Nejnepříjemnější situace je ta druhá uvedená, kdy se uživatel přihlašuje z vnitřní sítě k proxy ve vnější síti. Jeho privátní IP adresa je z privátní sítě (např. 10.1.1.100) a přichází k proxy v příkazu INVITE spolu s jeho SIP adresou (např. pepa@unob.cz). Odpověď OK pak nenalezne příjemce. Možným řešením je použití transportního protokolu TCP anebo protokolu STUN. A nejlepším řešením je NAT vůbec pokud možno nepoužívat – což je i jeden z argumentů pro přechod na IPv6. Kdy STUN a kdy firewall? 103 STUN – Simple traversal of UDP through NATs RFC3489 104 RFC5389 105 STUN (Simple/Session Traversal of UDP through NATs) 106  Dvojice adres „server-reflexivní“  Obvykle u ISP jako služba  STUN2 xoruje k adrese nonce  Klient je cloněn pouze nepříliš bezpečným NAT a je vystaven útokům kohokoliv, kdo odchytá STUN provoz  Nezajišťuje symetrický NAT, kdy mezi unikátními IP adresami a porty odesilatele a příjemce misí být unikátní i dvojice na NATu (jen pro ně). Příklad 107 Klient: Jako co mě vidíš? Server: Vidím tě jako 206.123.31.67:55123 draft-rosenberg-midcom-turn-08 108 TURN (Traversal Using Relay NAT) 109  Metoda náročná na šířku pásma  Server musí být blízko NATu a k dispozici po celou dobu komunikace  Zajišťuje symetrický NAT TURN je součást migrace do IPv6 110 Příklad 111 ICE (Interactive Connectivity Establishment) 112  Využívá STUN i TURN podle nastavené priority  Zprostředkovává je volanému prostřednictvím CDP  Po navázání spojení zastaví jejich použití Microsoft Office Communications Server 2007 R2, A/V Edge Server je rozšířen o STUN/TURN, blíže Mike Atkins v „Troubleshoot STUN with TURN in Office Communications Server 2007 R2“ v http://blogs.technet.com z prosince 2010 Microsoft ICE z roku 2008 – 1. krok Klient posílá požadavek na STUN/TURN server 113 Klient STUN posílá TURN Allocation request na A/V Edge Server Záznam: Microsoft Network Monitor 3.4 2. krok Odpověď STUN/TURN serveru 114 3. krok Výpočet MI a její odeslání na STUN/TURN server 115 Message-Integrity = MD5(username ":" realm ":" SASLPrep(password)) kde SASL (Simple Authentication and Security Layer) je obecná metoda ověřování v protokolech klient/server SASLprep – reprezentace jmen a hesel pro SASL - viz RFC 4013 4. krok Server STUN/TURN odpovídá vzdálenému klientu 116  Server STUN/TURN odesílá paket Allocate Response, v ní hodnotu časovače, šířky pásma…  XORMappedAddress je počítána XORem z MagicCookie z 1. kroku Rok 2010: Cisco s RFC5898 117 Navazování spojení s kontrolou na použití ICE 118 INVITE SDP1 119 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 20000 RTP/AVP 0 c=IN IP4 192.0.2.1 a=rtcp:20001 a=curr:conn e2e none a=des:conn mandatory e2e sendrecv (nabídka) a=candidate:1 1 UDP 2130706431 192.0.2.1 20000 typ host Pohled stanice A Session Progress SDP2 120 a=ice-lite a=ice-pwd:qrCA8800133321zF9AIj98 a=ice-ufrag:H92p m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.4 a=rtcp:30001 a=curr:conn e2e none a=des:conn mandatory e2e sendrecv a=conf:conn e2e send (chce potvrzení ve směru send) a=candidate:1 1 UDP 2130706431 192.0.2.4 30000 typ host Pohled stanice B UPDATE SDP3 121 Pohled stanice A po kontrole konektivity Zkontroloval konektivitu ICE k B v obou směrech Pohled stanice B po kontrole konektivity a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 20000 RTP/AVP 0 c=IN IP4 192.0.2.1 a=rtcp:20001 a=curr:conn e2e sendrecv a=des:conn mandatory e2e sendrecv a=candidate:1 1 UDP 2130706431 192.0.2.1 20000 typ host Pohled stanice B po UPDATE Útoky na SIP proxies Útoky na protokolovou sadu TCP/IP Např. Ping of Death, SYN Flood, Smurf… Útoky využívající specifické slabiny protokolu SIP Např. přerušením relací… Testování možnosti registrovat útoky 123 Test v SNORT na útok SYN Flood alert tcp any any -> $SIP_PROXY_IP any \ (msg: "TCP SYN packet flooding from single source"; \ threshold: type both, track by_src, count 200, seconds 20; \ flow:stateless; flags:S,12; sid:5000100; rev:1;) SNORT log [1:5000001:1] TCP SYN packet flooding from single source [**] [Priority: 0] {TCP} 160.216.1.102:1653 -> 160.216.1.103:506011/10-17:22:18.980228 [**] [1:5000002:1] TCP SYN packet flooding (simple or distributed) [**] [Priority: 0] {TCP} 143.110.215.175:3957 -> 160.216.1.103:506011/10-17:23:18.000308 [**] [1:5000002:1] TCP SYN packet flooding (simple or distributed) [**] [Priority: 0] {TCP} 151.170.194.143:11334 -> 160.216.1.103:506011/10-17:23:32.253141 [**] [1:5000004:1] INVITE message flooding [**] [Priority: 0] {UDP} 160.216.1.102:3069 -> 160.216.1.103:506011/10-17:23:35.037319 [**] [1:5000005:1] REGISTER message flooding [**] [Priority: 0] {UDP} 160.216.1.102:2002 -> 160.216.1.103:506011/10-17:24:14.483933 [**] [1:5000007:1] TCP/IP message flooding directed to SIP proxy [**] [Priority: 0] {UDP} 160.216.1.102:7777 -> 160.216.1.103:506011/10-17:24:40.652745 [**] [1:5000008:1] DNS No such name threshold. Abnormaly high count of No such name responses.[** [Priority: 0] {UDP} 160.216.40.10:53 -> 160.216.1.103:105411/10-17:24:54.120039 [**] [1:5000011:1] SQL Injection. Injection of DROP statement [**] [Priority: 0] {UDP} 160.216.1.102:1049 -> 160.216.1.103:506011/10-17:24:55.220988 [**] [1:5000012:1] SQL Injection. Injection of DELETE statement [**] [Priority: 0] {UDP} 160.216.1.102:1049 -> 160.216.1.103:506011/10-17:24:56.265353 [**] [1:5000013:1] SQL Injection. Injection of SELECT statement [**] [Priority: 0] {UDP} 160.216.1.102:1049 -> 160.216.1.103:506011/10-17:24:57.390944 [**] [1:5000014:1] SQL Injection. Injection of INSERT statement [**] [Priority: 0] {UDP} 160.216.1.102:1049 -> 160.216.1.103:506011/10-17:24:58.397378 [**] [1:5000015:1] SQL Injection. Injection of UPDATE statement [**] [Priority: 0] {UDP} 160.216.1.102:1049 -> 160.216.1.103:506011/10-17:24:58.994778 [**] [1:5000016:1] SQL Injection. Injection of UNION statement [**] [Priority: 0] {UDP} 160.216.1.102:1049 -> 160.216.1.103:5060 Zpráva INVITE RECEIVE TIME: 10913072 RECEIVE << 160.216.1.102:5060 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 160.216.223.122:5060;rport=5060; branch=z9hG4bKE0BCCD41AF0648378E3200A1924B454D From: Pepa ;tag=2110609961 To: ;tag=1461585288 Contact: Record-Route: Call-ID: 2F56AA96-23FD-4F06-8706-BF2866B97772@160.216.1.103 CSeq: 18188 INVITE Server: SIPphone Lite release 1104v Content-Length: 0 Test na útok INVITE Flood alert ip any any -> $SIP_PROXY_IP $SIP_PROXY_PORTS \ (msg:"INVITE message flooding"; content:"INVITE"; depth:6; \ threshold: type both, track by_src, count 200, seconds 60; \ sid:1000100; rev:1;) #Suppresion of alerting for known proxy 160.216.1.102 suppress gen_id 1, sig_id 1000100, track by_src, ip 160.216.1.103 SNORT log podruhé [1:5000001:1] TCP SYN packet flooding from single source [**] [Priority: 0] {TCP} 160.216.1.102:1653 -> 160.216.1.103:506011/10-17:22:18.980228 [**] [1:5000002:1] TCP SYN packet flooding (simple or distributed) [**] [Priority: 0] {TCP} 143.110.215.175:3957 -> 160.216.1.103:506011/10-17:23:18.000308 [**] [1:5000002:1] TCP SYN packet flooding (simple or distributed) [**] [Priority: 0] {TCP} 151.170.194.143:11334 -> 160.216.1.103:506011/10-17:23:32.253141 [**] [1:5000004:1] INVITE message flooding [**] [Priority: 0] {UDP} 160.216.1.102:3069 -> 160.216.1.103:506011/10-17:23:35.037319 [**] [1:5000005:1] REGISTER message flooding [**] [Priority: 0] {UDP} 160.216.1.102:2002 -> 160.216.1.103:506011/10-17:24:14.483933 [**] [1:5000007:1] TCP/IP message flooding directed to SIP proxy [**] [Priority: 0] {UDP} 160.216.1.102:7777 -> 160.216.1.103:506011/10-17:24:40.652745 [**] [1:5000008:1] DNS No such name threshold. Abnormaly high count of No such name responses. [Priority: 0] {UDP} 160.216.40.10:53 -> 160.216.1.103:105411/10-17:24:54.120039 [**] [1:5000011:1] SQL Injection. Injection of DROP statement [**] [Priority: 0] {UDP} 160.216.1.102:1049 -> 160.216.1.103:506011/10-17:24:55.220988 [**] [1:5000012:1] SQL Injection. Injection of DELETE statement [**] [Priority: 0] {UDP} 160.216.1.102:1049 -> 160.216.1.103:506011/10-17:24:56.265353 [**] [1:5000013:1] SQL Injection. Injection of SELECT statement [**] [Priority: 0] {UDP} 160.216.1.102:1049 -> 160.216.1.103:506011/10-17:24:57.390944 [**] [1:5000014:1] SQL Injection. Injection of INSERT statement [**] [Priority: 0] {UDP} 160.216.1.102:1049 -> 160.216.1.103:506011/10-17:24:58.397378 [**] [1:5000015:1] SQL Injection. Injection of UPDATE statement [**] [Priority: 0] {UDP} 160.216.1.102:1049 -> 160.216.1.103:506011/10-17:24:58.994778 [**] [1:5000016:1] SQL Injection. Injection of UNION statement [**] [Priority: 0] {UDP} 160.216.1.102:1049 -> 160.216.1.103:5060 Test na útok Register Flood alert ip any any -> $SIP_PROXY_IP $SIP_PROXY_PORTS \ (msg:"REGISTER message flooding"; content:"REGISTER"; depth:8;\ threshold: type both , track by_src, count 100, seconds 60; \ sid:1000200; rev:1;) SNORT log potřetí [1:5000001:1] TCP SYN packet flooding from single source [**] [Priority: 0] {TCP} 160.216.1.102:1653 -> 160.216.1.103:506011/10-17:22:18.980228 [**] [1:5000002:1] TCP SYN packet flooding (simple or distributed) [**] [Priority: 0] {TCP} 143.110.215.175:3957 -> 160.216.1.103:506011/10-17:23:18.000308 [**] [1:5000002:1] TCP SYN packet flooding (simple or distributed) [**] [Priority: 0] {TCP} 151.170.194.143:11334 -> 160.216.1.103:506011/10-17:23:32.253141 [**] [1:5000004:1] INVITE message flooding [**] [Priority: 0] {UDP} 160.216.1.102:3069 -> 160.216.1.103:506011/10-17:23:35.037319 [**] [1:5000005:1] REGISTER message flooding [**] [Priority: 0] {UDP} 160.216.1.102:2002 -> 160.216.1.103:506011/10-17:24:14.483933 [**] [1:5000007:1] TCP/IP message flooding directed to SIP proxy [**] [Priority: 0] {UDP} 160.216.1.102:7777 -> 160.216.1.103:506011/10-17:24:40.652745 [**] [1:5000008:1] DNS No such name threshold. Abnormaly high count of No such name responses. [Priority: 0] {UDP} 160.216.40.10:53 -> 160.216.1.103:105411/10-17:24:54.120039 [**] [1:5000011:1] SQL Injection. Injection of DROP statement [**] [Priority: 0] {UDP} 160.216.1.102:1049 -> 160.216.1.103:506011/10-17:24:55.220988 [**] [1:5000012:1] SQL Injection. Injection of DELETE statement [**] [Priority: 0] {UDP} 160.216.1.102:1049 -> 160.216.1.103:506011/10-17:24:56.265353 [**] [1:5000013:1] SQL Injection. Injection of SELECT statement [**] [Priority: 0] {UDP} 160.216.1.102:1049 -> 160.216.1.103:506011/10-17:24:57.390944 [**] [1:5000014:1] SQL Injection. Injection of INSERT statement [**] [Priority: 0] {UDP} 160.216.1.102:1049 -> 160.216.1.103:506011/10-17:24:58.397378 [**] [1:5000015:1] SQL Injection. Injection of UPDATE statement [**] [Priority: 0] {UDP} 160.216.1.102:1049 -> 160.216.1.103:506011/10-17:24:58.994778 [**] [1:5000016:1] SQL Injection. Injection of UNION statement [**] [Priority: 0] {UDP} 160.216.1.102:1049 -> 160.216.1.103:5060 Útok SQL Injection Select password from subscriber where username='myname; DROP table Subscriber -- ' and realm='160.216.1.102' Select password from subscriber where username='myname'; and realm='160.216.1.102' Test na útok SQL Injection alert ip any any -> $SIP_PROXY_IP $SIP_PROXY_PORTS \ (msg:"SQL Injection - Injection of DROP statement"; \ pcre:"/\'drop/ix"; \ sid: 1000510; rev:1;) alert ip any any -> $SIP_PROXY_IP $SIP_PROXY_PORTS \ (msg:"SQL Injection - Injection of DELETE statement"; \ pcre:"/\'delete/ix"; \ sid: 1000520; rev:1;) alert ip any any -> $SIP_PROXY_IP $SIP_PROXY_PORTS \ (msg:"SQL Injection - Injection of SELECT statement"; \ pcre:"/\'select/ix"; \ sid: 1000530; rev:1;) alert ip any any -> $SIP_PROXY_IP $SIP_PROXY_PORTS \ (msg:"SQL Injection - Injection of INSERT statement"; \ pcre:"/\'insert/ix"; \ sid: 1000530; rev:1;) ……………………………………………………………… SNORT log naposledy [1:5000001:1] TCP SYN packet flooding from single source [**] [Priority: 0] {TCP} 160.216.1.102:1653 -> 160.216.1.103:506011/10-17:22:18.980228 [**] [1:5000002:1] TCP SYN packet flooding (simple or distributed) [**] [Priority: 0] {TCP} 143.110.215.175:3957 -> 160.216.1.103:506011/10-17:23:18.000308 [**] [1:5000002:1] TCP SYN packet flooding (simple or distributed) [**] [Priority: 0] {TCP} 151.170.194.143:11334 -> 160.216.1.103:506011/10-17:23:32.253141 [**] [1:5000004:1] INVITE message flooding [**] [Priority: 0] {UDP} 160.216.1.102:3069 -> 160.216.1.103:506011/10-17:23:35.037319 [**] [1:5000005:1] REGISTER message flooding [**] [Priority: 0] {UDP} 160.216.1.102:2002 -> 160.216.1.103:506011/10-17:24:14.483933 [**] [1:5000007:1] TCP/IP message flooding directed to SIP proxy [**] [Priority: 0] {UDP} 160.216.1.102:7777 -> 160.216.1.103:506011/10-17:24:40.652745 [**] [1:5000008:1] DNS No such name threshold. Abnormaly high count of No such name responses. [Priority: 0] {UDP} 160.216.40.10:53 -> 160.216.1.103:105411/10-17:24:54.120039 [**] [1:5000011:1] SQL Injection. Injection of DROP statement [**] [Priority: 0] {UDP} 160.216.1.102:1049 -> 160.216.1.103:506011/10-17:24:55.220988 [**] [1:5000012:1] SQL Injection. Injection of DELETE statement [**] [Priority: 0] {UDP} 160.216.1.102:1049 -> 160.216.1.103:506011/10-17:24:56.265353 [**] [1:5000013:1] SQL Injection. Injection of SELECT statement [**] [Priority: 0] {UDP} 160.216.1.102:1049 -> 160.216.1.103:506011/10-17:24:57.390944 [**] [1:5000014:1] SQL Injection. Injection of INSERT statement [**] [Priority: 0] {UDP} 160.216.1.102:1049 -> 160.216.1.103:506011/10-17:24:58.397378 [**] [1:5000015:1] SQL Injection. Injection of UPDATE statement [**] [Priority: 0] {UDP} 160.216.1.102:1049 -> 160.216.1.103:506011/10-17:24:58.994778 [**] [1:5000016:1] SQL Injection. Injection of UNION statement [**] [Priority: 0] {UDP} 160.216.1.102:1049 -> 160.216.1.103:5060 134 4. Konfigurace SIP na Cisco směrovačích Scénář konfigurace brány SIP 135 Jako síťový administrátor máte nakonfigurovat hlasovou bránu tak, abyste integrovali konektivitu Vaší firmy s poskytovatelem Vašich hlasových služeb. Konkrétně:  Použít SIP jako signalizační protokol  Nastavit transportní protokol na UDP  Použít rozhraní Loopback 0 jako zdrojové rozhraní pro SIP  Změnit UA takto: - Zapnout místní ověřování - Aktivovat registraci adresy E.164 přímo připojených analog. Telefonů - Nastavit server SIP - Změnit počet opakování INVITE, RESPONSE, BYE A CANCEL na 2 Topologie bran IOS a ITSP (Internet Telephony Service Provider) 136 Integrace bran IOS s ITSP SIP s poznámkami 1/2 137 Router(config)#voice service voip ! Zadání VoIP jako typ zapouzdření hlasu (může být i POTS, VoFR, VoATM Router(conf-voi-serv)#sip ! Vstup do režimu konfigurace SIP Router(conf-serv-sip)#session transport udp ! Volba transportního protokolu Router(conf-serv-sip)#bind control source-interface Loopback 0 ! Svázání zdrojové adresy pro signalizaci s adresou IP rozhraní Router(conf-serv-sip)#bind media source-interface Loopback 0 ! Svázání zdrojové adresy pro přenos paketů hlasu s adresou IP rozhraní Router(conf-serv-sip)#exit Router(conf-voi-serv)#no shutdown ! Aktivace hlasové služby Router(config-sip-ua)#retry bye 2 Router(config-sip-ua)#retry cancel 2 Integrace bran IOS s ITSP SIP s poznámkami 2/2 138 Router(config)#sip-ua ! Vstup do režimu konfigurace UA SIP Router(config-sip-ua)#authentication username JD password secret ! Nakonfigurování ověřování typu Digest Router(config-sip-ua)#registrar dns:sip2.cisco.com expires 3600 ! Je umožněno registrovat čísla E.164 (číslovací plán používaný pro ! telef.) hlasových portů (FXS) analogových telefonů a IP telefonů ! u externího proxy SIP nebo registračního serveru SIP Router(config-sip-ua)#sip-server dns:sip2.cisco.com ! Zadání adresy hostitele Router(config-sip-ua)#retry invite 2 Router(config-sip-ua)#retry response 2 Router(config-sip-ua)#retry bye 2 Router(config-sip-ua)#retry cancel 2 ! Přizpůsobení parametrů podmínkám sítě Integrace bran IOS s ITSP SIP 139 Router(config)#voice service voip Router(conf-voi-serv)#sip Router(conf-serv-sip)#session transport udp Router(conf-serv-sip)#bind control source-interface Loopback 0 Router(conf-serv-sip)#bind media source-interface Loopback 0 Router(conf-serv-sip)#exit Router(conf-voi-serv)#no shutdown Router(config)#sip-ua Router(config-sip-ua)#authentication username JDoe password secret Router(config-sip-ua)#registrar dns:sip2.cisco.com expires 3600 Router(config-sip-ua)#sip-server dns:sip2.cisco.com Router(config-sip-ua)#retry invite 2 Router(config-sip-ua)#retry response 2 Router(config-sip-ua)#retry bye 2 Router(config-sip-ua)#retry cancel 2 Dial peer 140  Dial peer je adresovatelný koncový bod volání  Příslušná adresa se označuje za vzor cíle (destination patern) a konfiguruje se v každém dial peeru.  Vzory cíle mohou využívat přímo zadané číslice i zástupné proměnné  Dial peery definují parametry hovorů, kterým odpovídají  Hlasové brány Cisco podporují pět typů dial peerů: POTS, VoIP, VoFR, VoATM a MMoIP (Multimedia Mail over IP). - Dial peery POTS poskytují tel. Číslo a ukazují na konkrétní hlasový port - Dial peery VoIP zajišťují cílovou adresu (tel. Číslo) okrajového zařízení na druhé straně, přiřazují cílovou adresu ke směrovači Příklad topologie dial peeru SIP 141 SIP server Konfigurace dial peeru SIP 142 Router(config)#dial-peer voice 2000 pots Router(config-dial-peer)#destination-pattern 2... Router(config-dial-peer)#session protocol sipv2 Router(config-dial-peer)#session target sip-server Router(config-dial-peer)#dtmf-relay rtp-nte Router(config)#dial-peer voice 2001 pots Router(config-dial-peer)#destination-pattern 2... Router(config-dial-peer)#session protocol sipv2 Router(config-dial-peer)#session target ipv4:10.1.1.15 Router(config-dial-peer)#dtmf-relay sip-notify Router(config-dial-peer)#preference 1 Router(config)#dial-peer voice 90 voip Router(config-dial-peer)#destination-pattern 9T Router(config-dial-peer)#session target ipv4:192.168.1.100 Router(config-dial-peer)#session protocol sipv2 Router(config-dial-peer)#dtmf-relay rtp-nte Konfigurace dial peeru SIP 143 Router(config)#dial-peer voice 2000 pots Router(config-dial-peer)#destination-pattern 2... Router(config-dial-peer)#session protocol sipv2 Router(config-dial-peer)#session target sip-server Router(config-dial-peer)#dtmf-relay rtp-nte !DTMF tóny jsou zakódovány v nte (named telephone events) !formátu a přenášeny stejným RTP kanálem jako hlas !nte jsou vyhrazená čísla z rozsahu 96 až 127 Router(config)#dial-peer voice 2001 pots Router(config-dial-peer)#destination-pattern 2... Router(config-dial-peer)#session protocol sipv2 Router(config-dial-peer)#session target ipv4:10.1.1.15 Router(config-dial-peer)#dtmf-relay sip-notify ! Zajistí upozornění na události telefonu zprávami NOTIFY Router(config-dial-peer)#preference 1 Router(config)#dial-peer voice 90 voip Router(config-dial-peer)#destination-pattern 9T Router(config-dial-peer)#session target ipv4:192.168.1.100 Router(config-dial-peer)#session protocol sipv2 Router(config-dial-peer)#dtmf-relay rtp-nte Ověřování stavu brány 144 Router#show sip service SIP Service is up Router# Router#show sip-ua status SIP User Agent Status SIP User Agent for UDP : ENABLED SIP User Agent for TCP : ENABLED SIP User Agent bind status(signaling): DISABLED SIP User Agent bind status(media): DISABLED SIP max-forwards : 6 SIP DNS SRV version: 1 (rfc 2052) Redirection (3xx) message handling: ENABLED Router# Router#show sip-ua timers SIP UA Timer Values (millisecs) trying 500, expires 180000, connect 500, disconnect 500 comet 500, prack 500, rel1xx 500, notify 500 refer 500, register 500 Ověřování stavu brány 145 Router#show sip-ua register status Line peer expires(sec) registered 4001 20001 596 no 4002 20002 596 no 5100 1 596 no 9998 2 596 no router#show sip-ua calls SIP UAC CALL INFO Number of SIP User Agent Client(UAC) calls: 0 SIP UAS CALL INFO Call 1 SIP Call ID : D215F304-7B5A11DC-8005EA1A-6A8F4AD@10.10.10.2 State of the call : STATE_ACTIVE (7) Substate of the call : SUBSTATE_NONE (0) Calling Number : 2818902001 Called Number : 1003 Bit Flags : 0x1212003A 0x100000 0x488 CC Call ID : 1 Source IP Address (Sig ): 10.10.10.1 Destn SIP Req Addr:Port : 10.10.10.2:5060 Destn SIP Resp Addr:Port: 10.10.10.2:56884 Destination Name : 10.10.10.2 Zpráva INVITE 146 router#debug ccsip messages SIP Call messages tracing is enabled router# *Mar 6 14:19:14: Sent: INVITE sip:3660210@166.34.245.231;user=phone;phone-context=unknown SIP/2.0 Via: SIP/2.0/UDP 166.34.245.230:55820 From: “3660110” To: Date: Sat, 06 Mar 1993 19:19:14 GMT Call-ID: ABBAE7AF-823100E2-0-1CD274BC@172.18.192.194 Cisco-Guid: 2881152943-2184249568-0-483551624 User-Agent: Cisco VoIP Gateway/ IOS 12.x/ SIP enabled CSeq: 101 INVITE Max-Forwards: 6 Timestamp: 731427554 Contact: Expires: 180 Content-Type: application/sdp Content-Length: 138 Zpráva OK 147 *Mar 6 14:19:16: Received: SIP/2.0 200 OK Via: SIP/2.0/UDP 166.34.245.230:55820 From: “3660110” To: ; tag=27DBC6D8-1357 Date: Mon, 08 Mar 1993 22:45:12 GMT Call-ID: ABBAE7AF-823100E2-0-1CD274BC@172.18.192.194 Timestamp: 731427554 Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabled Contact: CSeq: 101 INVITE Content-Type: application/sdp Content-Length: 138 v=0 o=CiscoSystemsSIP-GW-UserAgent 1193 7927 IN IP4 166.34.245.231 s=SIP Call t=0 0 c=IN IP4 166.34.245.231 m=audio 20224 RTP/AVP 0 Zpráva Bye 148 *Mar 6 14:19:19: Received: BYE sip:3660110@166.34.245.230:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 166.34.245.231:53600 From: ;tag=27DBC6D8-1357 To: “3660110” Date: Mon, 08 Mar 1993 22:45:14 GMT Call-ID: ABBAE7AF-823100E2-0-1CD274BC@172.18.192.194 User-Agent: Cisco VoIP Gateway/ IOS 12.x/ SIP enabled Max-Forwards: 6 Timestamp: 731612717 CSeq: 101 BYE Content-Length: 0 Konfigurace dial peeru SIP 149 Router(config)#dial-peer voice 2000 pots Router(config-dial-peer)#destination-pattern 2... Router(config-dial-peer)#session protocol sipv2 Router(config-dial-peer)#session target sip-server Router(config-dial-peer)#dtmf-relay rtp-nte Router(config)#dial-peer voice 2001 pots Router(config-dial-peer)#destination-pattern 2... Router(config-dial-peer)#session protocol sipv2 Router(config-dial-peer)#session target ipv4:10.1.1.15 Router(config-dial-peer)#dtmf-relay sip-notify Router(config-dial-peer)#preference 1 Router(config)#dial-peer voice 90 voip Router(config-dial-peer)#destination-pattern 9T Router(config-dial-peer)#session target ipv4:192.168.1.100 Router(config-dial-peer)#session protocol sipv2 Router(config-dial-peer)#dtmf-relay rtp-nte Vývoj SIPu 150 5. RAMS Multicast RTP 151 RAMS (Unicast-based Rapid aquisition of Multicast RTP Sessions) 152 Diskuse RAMS (Rapid aquisition of Multicast RTP Sessions) 153 Scénář se skupinou dvou SSM (Source-Specific Multicast) 154SSRC – SIP Synchronization Source Identifier Závěr 155 6. Porovnání H.323 a SIP Porovnání SIP a H.323 156 Výhody SIP 157 SIP H.323 výhody SIP specifikace Internetové komunity (IETF, 1999) ITU-T (1996) určen pro práce po Internetu použitý model Internet / WWW telefonie (Q.sig) kódování textové binární (založené na ASN.1, Abstract Syntax Notation One) textové kódování snazší na porozumění i na řešení problémů využití v mobilních sítích 3G ano ne nástup 3G může znamenat konec H.323 složitost střední vysoká architektura modulární monolitická monolitický návrh činí aktualizace obtížné a drahé podpora pro IM ano ne zpoždění při navazování spojení 1,5x RTT (Round-Trip Time) 1,5x RTT - 7x RTT rozšiřitelnost otevřené pro nové protokolové prvky ASN.1 nestandardní změny podle výrobce pouze na předdefinovaných místech adresace URL, e-mailová adresa, H.323, E.164 E.164, alias stanice zjištěný pomocí gatekeeper transportní protokol UDP (hlavně) nebo TCP UDP nebo TCP (hlavně) UDP je jednodušší Testy spojení 158 Aplikační testování 159 VoIP testování 160