Teorie a praxe IP telefonie 2014
Principy signalizace SIP
Lukáš Macura
[email protected]
Obchodně podnikatelská fakulta v Karviné
Slezská univerzita v Opavě
CESNET, z.s.p.o.
Obsah
●
Historie telefonie obecně
●
VoIP protokoly a jejich vývoj
●
Bezpečnost
●
Asterisk vs Kamailio
●
Doporučení
●
SIP protokol
●
Závěr
2
Historie
●
Spojovací systémy dělíme do generací,
●
0. generace – manuální spojovací pole,
●
1. generace – ústředny na elektro-mechanické bázi,
●
2. generace – ústředny na elektro-magnetické bázi,
●
3. generace – první decentralizované použití mikroprocesorů,
●
4. generace – centralizované digitální systémy,
●
5. generace – softswitche.
3
Historie
●
První pokusy s přenosem hlasu v paketových sítích již v
70.letech,
●
První komerční produkt – 1995 Izraelská firma VocalTec,
●
Standard H.323 definován v roce 1996 (ITU-T),
●
Standard SIP definován v roce 1999 (IETF),
●
V témže roce Mark Spencer zakládá f. Digium a vydává první
verzi PBX Asterisk.
4
VoIP protokoly
●
●
●
●
●
Na 3. vrstvě používán Internet Protocol,
O vrstvu výše zejména UDP, existují i
implementace využívající TCP,
V 5. vrstvě hraje klíčovou roli protokol RTP pro
přenos médií a protokoly H.323, SIP, MGCP,
H248, IAX, SCCP v případě signalizace,
Užitečná data pro protokol RTP na 6. vrstvě
zajišťují implementace kodeků (G.711,
G.729…).
5
VoIP protokoly
SCCP
●
Skinny Call Control Protocol,
●
Proprietární řešení firmy Cisco,
●
●
●
Využívá několik prvků v síti, mezi nimi Call
Manager, Endpoint a případadně Gateway,
Spolupracuje s ostatními protokoly, zejména s
H.323, který zjednodušuje,
Endpoint zvládá poměrně jednoduchou
komunikaci prostřednictvím SCCP, zatímco Call
Manager vyjednává v rámci H.323.
6
VoIP protokoly
MGCP, H.248
●
●
●
●
●
Oba protokoly jsou implementací architektury
Media Gateway Control Protocol,
Daná architektura slouží zejména k propojení
IP sítí se sítěmi na bázi PSTN
V případě implementací se někdy hovoří o tzv.
PSTNoverIP, tj. jsou přenášeny standardy a
zvyklosti z PSTN do VoIP,
Využívá SDP k popisu relace a RTP k přenosu
hlasových dat.
7
VoIP protokoly
IAX
●
●
Inter-Asterisk eXchange Protocol
Vyvinut firmou Digium pro zajištění komunikace
mezi servery Asterisk,
●
Není standardizován,
●
Přenášen v binární formě,
●
●
Data i signalizace přenášeny v jednom streamu
na jediném portu 4569,
Multiplexuje více kanálů do jednoho streamu,
čímž redukuje požadavky na signalizaci.
8
●
VoIP protokoly
H.323
●
Rodina standardů vyvinutá v rámci ITU-T,
●
Vznik první verze v r. 1996, nyní verze 7,
●
Hlavní protokoly – H.225.0, H.245, RTP,
●
TCP/UDP port 1720,
●
Binární forma zpráv kódovaných pomocí ASN.1
●
Prvky v síti dělíme na:
●
Gatekeeper, Endpoint,
●
Nejpoužívanější implementace - GNUGk
●
9
VoIP protokoly
H.323 architektura
●
10
VoIP protokoly
Skype
●
jedna firma
●
Technické detaily jsou tajné
●
Uzavřený protokol
●
Vlastněno Microsoftem
●
Postupná migrace na Lync
11
NGN
●
Next Generation Network
●
Migrace všech služeb pod jednu infrastrukturu
●
Původní plán SS7, ATM
●
Dnes implementováno pomocí IMS
●
IMS je postavená na SIP a IP
12
IMS
13
OpenIMS
14
Dnešní stav ve firmách
●
Lync
●
CCM
●
Siemens, Awaya, ...
●
Staré digitaly
●
OpenSource
●
Hybrid
15
VoIP ve firmě
●
●
Asterisk
–
Víceprotokolový
–
Funkce pobočkové ústředny
–
Podpora HW karet EuroISDN
–
Velká flexibilita, Mnoho forem a rozhraní
OpenSIPs, OpenSER, Kamailio, ...
–
Jednoprotokolový
–
Funkcionalita SIP proxy
–
Výkonnější, méně používaný
16
VoIP u operátora
●
●
Požadavky
–
Vysoká dostupnost (HA)
–
Reference, Cena
–
Modulárnost, Rozšířitelnost
–
Propojitelnost s ostatními operátory
–
Oddělení financí od provozu ústředny?
Možnosti
–
OpenSER, OpenSIPs, Kamalio, …
–
Asterisk, FreePBX
17
Bezpečnost
●
Potřeba „pohlídat“ placené směry
●
Potřeba kvalitních hesel pro SIP
●
Potřeba ošetřit veřejné části
●
Ochrana proti SPIT
●
Obecná ochrana OS „pod ústřednou“
●
Nejlepší OS je … :)
18
Bezpečnost
Log z honeypotu
●
sip:[email protected]:5100 972598545473
●
sip:[email protected]:5078 000972595341444
●
sip:[email protected]:5071 000972595341444
●
sip:[email protected]:5089 00972598545473
●
sip:[email protected]:5080 00972595341444
●
sip:[email protected]:5097 000972598545473
●
sip:[email protected]:5091 900972598545473
●
sip:[email protected]:5076 972598545473
●
sip:[email protected]:5080 000972595341444
●
sip:[email protected]:5087 900972598545473
19
Bezpečnost
Nestačí spoléhat..
●
Např. FreePbx (vybrán náhodně)
●
Zdroj cvedetails.com
●
20
Bezpečnost
Ďábel je ukryt v detailech
●
Natvrdo ukrytý login v admin interface
●
Nezaheslovaný telefon
●
Chyba v firmware telefonu
●
Chyba v vyhodnocování ACL
●
Průměrná životnost telefonu na veřejném IP?
●
„Náhodné“ zvonění telefonů
21
Asterisk nebo Kamailio?
●
Který OS je nejepší?
●
Která ústředna je nejlepší?
●
Asterisk je nej, protože je multiprotokolový
●
Kamailio je nej, protože je jednoprotokolový
●
Asterisk je lepší, protože je to B2BUA
●
Kamailio je lepší, protože je to SIP proxy
22
Prepaid vs Postpaid
●
Předem placené služby většinou bezpečnější
●
Nedá se provolat více, než předplaceno
●
Mnoho operátorů používá místo antifraud
●
Postpaid jednodušší, dá se fakturovat následně
●
Ale antifraud složitější
●
Nutno se operátora ptát, zda antifraud má
23
Asterisk
●
B2BUA
●
Přináší funkce pobočkové ústředny
●
Má plnou kontrolu nad hovorem
●
Každá strana hovoru si „žije vlastním životem“
●
Nevyužívá většinu vlastností SIPu
●
Využíván mnoha operátory pro jednoduchost
●
Nevhodný na tranzitní přenosy
●
Jednoduchá implementace prepaid
24
Kamailio
●
Jedná se o SIP proxy se vším všudy
●
Výborný pro tranzit
●
Zvládá mnohem více hovorů
●
Lepší ochrana prot DoS a útokům
●
Jednodušší HA
●
Nemusí řešit média
●
Média může řešit rtpproxy nebo mediaproxy
●
Složitý prepaid
●
Jedna instance až pro milióny telefonních čísel (v reálném provozu)
25
Kamailio
26
High Availability
●
Zdvojení serverů
●
Dá se řešit i na úrovni DNS (ale špatně)
●
Nutno řešit synchronizaci DB
●
Jednodušší na kamailiu
●
Asterisk umí Realtime, ale …
●
Pokud stačí reregistrace, relativně jednoduché
●
Složitější s prepaidem
27
Jaký HW?
●
●
Záleží na situaci
Bez transkodingu může asterisk běžet na
Asus WL-500g (32MB RAM, 8MB Flash)
●
Není nutné předimenzovávat
●
Samotný softswitch není náročný na CPU
●
Vhodnými technikami se dá zátěž omezit
●
Nutná znalost sítě
28
Embeding
●
Technika pro „zapouzdření“ Linuxu do
rozmanitých zařízení
●
Pokud je dokumentace k HW, jde relativně vše
●
Standardní Linux distribuce k tomu nevhodné
●
OpenWrt
●
BeeSip
29
BeeSip
●
Bright Efficient Embedded Solution for IP
Telephony
●
http://besip.cesnet.cz
●
“Be SIP”
●
Build system nad OpenWRT buildroot
●
Spojujeme balíky dohromady
●
Kamailio, Asterisk, Rtpproxy, Mediaproxy, …
30
Asterisk everywhere
●
Součást OpenWrt i Beesipu
●
Pokud máte OpenWrt kompatibilní HW, huráá!
●
●
Hodně druhů HW od malých krabiček až po
výkonnější
BeeSip může běžet i jako virtual (VmWare,
VirtualBox, Kvm, …)
31
Kamailio everywhere
●
●
Součást OpenWrt i BeeSipu
V základu mnohem méně náročnější než
Asterisk
●
Složitější konfigurace
●
V rámci BeeSipu se snažíme zjednodušit
32
SIP teorie
●
Session Initiation Protocol,
●
RFC 2543 (SIP 1.0 1999), RFC 3261 (SIP 2.0 2002)
●
Protokol zajišťující signalizace při vytváření, udržování
a rozpadu spojení,
●
Textový protokol s kořeny v HTTP a SMTP,
●
Velmi jednoduchý,
●
●
Řada nástaveb – RFC 3264 (SDP), RFC 3265
(SUBSCRIBE, NOTIFY)…,
Výhradní protokol pro hlasovou komunikaci v NGN.
33
SIP teorie
jednoduchost :)
34
SIP teorie
●
Textový formát
●
Obvykle jeden UDP paket
●
Zpráva se může ztratit, SIP s tím počítá
●
Dva základní druhy: požadavky (request) a
●
Odpovědi (response)
35
SIP teorie
Terminologie
●
●
●
Koncové zařízení z hlediska protokolu SIP je
UserAgent (UA).
V rámci transakce (požadavek-odpověď) UA
bud’ roli klienta (UAC), nebo roli serveru (UAS).
UA může být najednou obojí.
Mezilehlá zařízení jsou SIP Proxy. Slouží k
směrování a přeposílání zpráv. Podobně jako
routery v IP sítích.
36
SIP teorie
●
K zajištění hovoru SIP využívá dalších protokolů, zejména
pak:
●
SDP – Session Description Protocol,
●
RTP – Real-time Transport Protocol,
●
V síti rozeznáváme prvky:
●
UA – User Agent,
●
SIP Server (registrar, proxy, redirect),
●
B2BUA,
●
Nejznámější implementace – Asterisk, OpenSIPS,
Kamailio
37
SIP teorie
SIP uri
●
Sip:[email protected]
●
Sips:[email protected]
●
Sip:[email protected]
●
„Rozpor“ v routování (čísla vs. Domény)
●
User part v rámci SIP proxy
●
Domain part zajišťuje DNS
●
User part v režii správce, domain part správce
domén (podobně jako email)
38
SIP teorie
metody
●
Metody=žádosti,
●
V RFC 3261 definováno 6 metod:
●
REGISTER,
●
INVITE,
●
ACK,
●
CANCEL,
●
BYE,
●
OPTIONS,
●
Dále definovány např. PRACK, SUBSCRIBE, NOTIFY
39
SIP teorie
struktura žádosti
40
SIP teorie
Odpovědi
●
Obdoba HTTP,
●
6 tříd odpovědí:
●
1XX – provizorní odpovědi,
●
2XX – finální úspěšné odpovědi,
●
3XX – odpovědi odkazující na jinou lokaci volaného,
●
4XX – indikují chybu na straně klienta,
●
5XX – indikují chybu na straně serveru,
●
6XX – globální chyby.
41
SIP teorie
struktura odpovědi
42
SIP teorie
transakce
●
●
●
A transaction is a sequence of SIP messages exchanged between
SIP network elements. A transaction consists of one request and all
responses to that request. That includes zero or more provisional
responses and one or more final
responses (remember that an INVITE might be answered by more
than one final response when a proxy server forks the request).
If a transaction was initiated by an INVITE request then the same
transaction also includes ACK, but only if the final response was not a
2xx response. If the final response was a 2xx response then the ACK
is not considered part of the transaction.
43
SIP teorie
dialog a transakce
44
SIP teorie
registrace
●
Telefon sděluje ústředně svoji adresu
●
Nutnost pro příchozí hovory
●
SIPové telefony (UA) jsou v podstatě mobilní
●
Pro registraci je obvykle nutné použít autorizaci
●
●
Location table (přepis „hezkých“ url na
„škaredé“)
[email protected] Na [email protected]:5066
45
SIP teorie
Registrar a Proxy
●
●
●
Registrar udržuje informace o klientech v
location table
Proxy směruje hovory
Mohou a nemusí být v rámci jedné SW
implementace
●
Ve většině případů na jednom místě
●
Pro funkční NAT musí být na jednom místě
46
SIP teorie
Multiple registrations
●
●
Registrar si pro každého uživatele může
udržovat více kontaktů
SIP Proxy může zprávu INVITE rozmnožit a
poslat ji na více telefonů
●
Na jednom účtu může být registrováno více
telefonů (ne ve všech implementacích)
●
Jedno volání může navázat více hovorů!
47
Forking
48
Forking 200 OK
49
SIP teorie
Proxy
●
Telefon potřebuje server se stálou (a hezkou)
adresou, který mu předává hovory
●
Terminologie: SIP Proxy
●
Typickým příkladem SIP Proxy je Kamailio
●
Stejnou úlohu může sehrát i B2BUA, pak se vlastnosti
SIPu moc nevyužívají
50
SIP teorie
Výstavba spojení
51
SIP teorie
data flow
52
SIP teorie
NAPTR
●
Slouží klientovi pro výběr nejvhodnějšího transportního protokolu dle
domény
●
IN NAPTR order preference Flags Service
●
Flags
●
–
SIP+D2T – TCP
–
SIP+D2U – UDP
–
SIPS+D2T – TLS
–
E2U+SIP – Převod čísla na SIP uri (ENUM)
Service
–
„S“ - dohledání SRV záznamu
–
„U“ - výstup je URI
53
SIP teorie
SRV
●
Slouží k dohledání konkrétních SIP serverů pro daný transportní
protokol. Pokud je shodný weight, může sloužit pro load balancing.
●
_service SRV weight port host
●
_sip._udp SRV 0 5060 somehost.somedomain.
●
_sip._tcp SRV 0 5060 somehost.somedomain.
●
_sips._tcp SRV 0 5061 somehost.somedomain.
54
SIP teorie
NAPTR,SRV
●
●
●
●
●
$ORIGIN example.com.
IN NAPTR 100 10 "S" "SIP+D2U" "" \
_sip._udp.example.com.
IN NAPTR 102 10 "S" "SIP+D2T" "" \
_sip._tcp.example.com.
IN NAPTR 100 10 "U" "E2U+sip" \
"!^(.*)$!sip:[email protected]!"
_sip._tcp.example.com. 86400 \
IN SRV 0 5060 sipserver.example.com.
●
http://en.wikipedia.org/wiki/SRV_record
●
http://en.wikipedia.org/wiki/NAPTR_record
55
SIP teorie
TLS
●
Bezpečná „obálka“ pro signalizační data
●
Nutno důvěřovat všem proxy po cestě
●
Klíče k šifrování SRTP se přenášejí v signalizaci
●
Aby mohla proxy směrovat, musí umět zprávu rozbalit
●
Výhodné pro bezpečnou registraci klientů
●
Slabá implementace v zařízeních
●
TLS nešifruje hovory, pouze signalizaci
●
Pro bezpečné šifrování leda ZRTP (Diffie-Hellman)
●
ZRTP používá SAS (vizuální kontrola klíče) proti MitM
56
SIP teorie
SDP
●
Session Description Protocol
●
Výměna kodeků
●
Media description (if present)
m= (media name and transport address)
i=* (media title or information field)
c=* (connection information — optional if included at session level)
b=* (zero or more bandwidth information lines)
k=* (encryption key)
a=* (zero or more media attribute lines — overriding the Session attribute lines)
57
SIP teorie
SDP
●
v=0
●
o=root 1821 1821 IN IP4 1.2.3.4
●
s=session
●
c=IN IP4 10.10.1.99
●
t=0 0
●
m=audio 11424 RTP/AVP 0 8 101
●
a=rtpmap:0 PCMU/8000
●
a=rtpmap:8 PCMA/8000
●
a=rtpmap:101 telephone-event/8000
●
a=fmtp:101 0-16
●
a=silenceSupp:off - - - -
●
a=ptime:20
●
a=sendrecv
58
SIP teorie
RTP
●
Real-time Transport Protocol,
●
RFC 1889 (1996), RFC 3550 (2003),
●
Slouží k přenosu médií přes IP sítě,
●
●
Doplňuje UDP o funkce opětovného řazení paketů, detekci
ztracených paketů…
Klíčová pole:
–
SSRC,
–
Sequence number,
–
Timestamp,
–
Payload type.
59
SIP teorie
kodek
●
Kodek=kodér a dekodér,
●
Možné problémy s licencí
●
3 základní skupiny:
●
–
Kodéry vlny (waveform coding),
–
Kodéry parametrů zdroje zvuku (Source coding),
–
Hybridní kodéry,
Hlavními parametry kodeků jsou:
–
Bitová rychlost,
–
Kvalita hovorových dat.
60
SIP teorie
kodeky
●
Některé kodeky:
–
G.711 ulaw (USA) - (64 Kbps).
–
G.711 alaw (Europe) - (64 Kbps).
–
G.722 (širokopásmový kodek) – (64 Kbps).
–
G.723.1 – nutná licence
–
G.726 - (16/24/32/40kbps)
–
G.729 – nutná licence (8Kbps)
–
GSM - (12-13 Kbps)
–
iLBC - (15 Kbps)
–
LPC10 - (2.5 Kbps)
–
Speex - (2.15-44.2 Kbps)
61
SIP teorie
Metoda INVITE
●
Příklad
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 142
62
SIP teorie
INVITE
63
SIP teorie
Metoda INVITE
●
64
SIP teorie
Hlavička Route
●
●
●
●
UAC může do zprávy přidat Route hlavičku a
vynutit si směrování.
V Route hlavičce může být více záznamů,
záleží na pořadí
SIP proxy směruje na základě těchto hlaviček
Pokud je seznam prázdný, směruje se podle
RURI
65
SIP teorie
Hlavička Via
●
Via vkládá každý po cestě
●
Udává tím, kudy směrovat odpovědi
●
Druhá strana zkopíruje Via hlavičky do
odpovědi a pošle zpět
66
Hlavička Via
SIP/2.0 200 OK
From: "Jana" <sip:[email protected]>;tag=psvz
To: "Petr" <sip:[email protected]>;tag=bflm
Via: SIP/2.0/UDP 3.3.3.3:5060;branch=z9hG4bKz
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKy
Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bKx
Call-ID: 5b063520
67
SIP teorie
Hlavička Record-Route
●
Slouží k popisu cesty při navázání dialogu
●
Každý prvek po cestě přidá svou adresu
●
Na konci se zkopírují do odpovědi a putují zpět
●
Record-Route slouží k záznamu směrování
●
Route slouží k směrování
●
Via slouží k směrování odpovědí
68
Www.in2eps.com
●
●
●
Pro pochopení SIP routingu
http://www.in2eps.com/fo-sip/tk-fo-sip-dialog.ht
ml
Všechny možné scénáře včetně hlaviček
69
Routing - INVITE
70
Routing – 180 RINGING
71
Routing – 200 OK
72
SIP teorie
metoda REGISTER
73
SIP teorie
metoda REGISTER
REGISTER sip:slu.cz SIP/2.0
To: "Limo" <sip:[email protected]>
From: "Limo" <sip:[email protected]>;tag=484d
Call-ID: Acu1Ey1m
Max-Forwards: 70
Expires: 3600
CSeq: 2855 REGISTER
Contact: <sip:[email protected]:15060>
Via: SIP/2.0/UDP 1.2.3.4:5060;branch=z9hG4bKx
Content-Length: 0
74
SIP teorie
NAT
●
Problém
●
IP je obsaženo na více místech ve zprávě
●
Je i v SDP
●
Je nutno „opravit“
●
Neexistuje cesta mezi endpointy
75
SIP teorie
NAT
●
Obecně nekombinovat NAT traverzaly
●
Buďto ponechat na ústředně nebo na telefonu
●
Nikdo nemůže garantovat, že to projde
●
Nejlepší řešení je proxy na hraně sítě
76
Závěr
●
Dotazy
●
Lukáš Macura
●
Slezská univerzita v Opavě, OPF Karviná
●
CESNET, z.s.p.o.
●
[email protected]
77
Download

Principy signalizace SIP - Teorie a praxe telefonie