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 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, 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 zpravovávat 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) Historie vzniku protokolu SIP 5 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 6 Dokumenty 2 7 Dokumenty 3 8 Dokumenty 4 9 Dokumenty 5 10 RFC 3261 – 269 stran! 11 SIP center 12 SIP Forum 13 OpenSIP 14 TechRepublic 15 P2P SIP 16 17 2. Architektura protokolu Architektura protokolu SIP 18 • účastnické stanice (User agent – UA) • SIP proxy server (zástupný server) SIP signalizaceSIP signalizace SIP signalizace SIP proxy Pro síť volajícího SIP proxy Pro siť volaného RTP tok VolanýVolající SIP trapezoid Účastnické stanice 19  Úč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ě software 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 20  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 21  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 22 • redirect (přesměrování) server • register (registrační) server • location (lokační) server • STUN • RTP proxy Redirect, Register a Location servery 23  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 (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í) 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…) STUN a RTP proxy 24  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. SIP URI 25 sip: user: password@host:port;uri-parameters?headers Základní metody protokolu SIP 26 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 Rozšíření metod protokolu SIP 27 Příklad metody INVITE 28 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 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 29 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í. Popis základních polí 30 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 31 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 Pole protokolu SDP (Session Description Protocol) 32 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. Metoda REGISTER 33 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 34 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. Kategorie návratových kódů 35 • 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ů 36 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"). 5xx Chyba na serveru (např. "500 Server Internal Error", "501 Not Implemented"). 6xx Globální chyba ("606 Not Acceptable"). Základní typy výměn zpráv 37 • INVITE • INVITE s proxy autentizací • BYE • CANCEL • REGISTER Sestavení spojení pomocí zprávy INVITE 38  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.  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. INVITE 39 Caller SIP proxy 100 Trying INVITE 100 Trying 180 Ringing 180 Ringing 200 OK 200 OK ACK ACK RTP media flow INVITE Callee Co vlastně měříme? Poznámka k výkonnostním metrikám 40 INVITE 180 RingingRinging delay (RD) 200 OK RTP RTPMedia clipping (MC) Příklad 41 Sestavení spojení pomocí zprávy INVITE s autentizací 42  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í 43 Caller SIP proxy 100 Trying INVITE 100 Trying 180 Ringing 180 Ringing 200 OK 200 OK ACK ACK RTP media flow INVITE Callee 407 Proxy Authentication Required ACK INVITE + creditials Časovače podle RFC3261 44 Č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 45 Caller SIP proxy RTP media flow BYE Callee BYE 200 OK 200 OK  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. Pole Record-route 46 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 47  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 48 Caller SIP proxy CANCEL Callee CANCEL INVITE INVITE 100 Trying 100 Trying 180 Ringing 180 Ringing 200 OK 200 OK 487 Request Cancelled ACK 487 Request Cancelled ACK Zpráva CANCEL s hodnotou pole CSeq 49  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 50  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 51 Caller SIP proxy 401 Unauthorized REGISTER REGISTER + creditials 200 OK Volání v rámci jedné domény 52 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 53 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 54 3. Bezpečnostní otázky Bezpečnostní mechanismy protokolu SIP 55  HTTP Digest  S/MIME  TLS  IPSec s ručně nastavenými klíči  IPSec s IKE  MIKEY SIP HTTP autentizace 56  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 57  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 58  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 59  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 60 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 61 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 62 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? 63 STUN – Simple traversal of UDP through NATs RFC3489 64 RFC5389 65 STUN (Simple/Session Traversal of UDP through NATs) 66  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 67 Klient: Jako co mě vidíš? Server: Vidím tě jako 206.123.31.67:55123 draft-rosenberg-midcom-turn-08 68 TURN (Traversal Using Relay NAT) 69  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 70 Příklad 71 ICE (Interactive Connectivity Establishment) 72  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 73 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 74 3. krok Výpočet MI a její odeslání na STUN/TURN server 75 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 76  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 77 Navazování spojení s kontrolou na použití ICE 78 INVITE SDP1 79 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 80 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 81 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 83 SIP signalizaceSIP signalizace SIP signalizace SIP proxy A IP: 160.216.1.102 SIP proxy B IP: 160.216.1.103 RTP tok Telefon B IP: 160.216.1.104 URI: Ferda@160.216.1.103 Telefon A IP: 160.216.1.109 URI: Pepa@160.216.1.102 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 94 4. Konfigurace SIP na Cisco směrovačích Scénář konfigurace brány SIP 95 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) 96 Integrace bran IOS s ITSP SIP s poznámkami 1/2 97 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 98 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 99 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 100  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 101 SIP server Konfigurace dial peeru SIP 102 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 103 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 104 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 105 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 106 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 107 *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 108 *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 109 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