Teorie a praxe IP telefonie 2014

Principy signalizace SIP

Lukáš MacuraLukas.macura@gmail.com

Obchodně podnikatelská fakulta v KarvinéSlezská univerzita v Opavě

CESNET, z.s.p.o.

2

Obsah

● Historie telefonie obecně

● VoIP protokoly a jejich vývoj

● Bezpečnost

● Asterisk vs Kamailio

● Doporučení

● SIP protokol

● Závěr

3

● 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.

Historie

4

● 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.

Historie

5

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…).

●

6

VoIP protokolySCCP

● 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.

7

VoIP protokolyMGCP, 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.

●

8

VoIP protokolyIAX

● 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.●

9

VoIP protokolyH.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●

10

VoIP protokolyH.323 architektura

●

11

VoIP protokolySkype

● jedna firma● Technické detaily jsou tajné● Uzavřený protokol● Vlastněno Microsoftem● Postupná migrace na Lync

12

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

13

IMS

14

OpenIMS

15

Dnešní stav ve firmách

● Lync● CCM● Siemens, Awaya, ...● Staré digitaly● OpenSource● Hybrid

16

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ý

17

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

18

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 … :)

19

BezpečnostLog z honeypotu

● sip:210@8.33.7.65:5100 972598545473● sip:40@198.27.70.5:5078 000972595341444● sip:35@198.27.70.5:5071 000972595341444● sip:210@8.33.7.65:5089 00972598545473● sip:40@198.27.70.5:5080 00972595341444● sip:210@8.33.7.65:5097 000972598545473● sip:210@8.33.7.65:5091 900972598545473● sip:210@8.33.7.65:5076 972598545473● sip:40@198.27.70.5:5080 000972595341444● sip:2007@8.33.7.65:5087 900972598545473

20

BezpečnostNestačí spoléhat..

● Např. FreePbx (vybrán náhodně)● Zdroj cvedetails.com●

21

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ů

22

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

23

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á

24

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

25

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)

26

Kamailio

27

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

28

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ě

29

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

30

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, …

31

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, …)

32

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

33

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.

34

SIP teoriejednoduchost :)

35

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)

36

SIP teorieTerminologie

● 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.

37

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

38

SIP teorieSIP uri

● Sip:macura@opf.slu.cz● Sips:macura@opf.slu.cz● Sip:42059xxxxx@slu.cz● „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)

39

SIP teoriemetody

● Metody=žádosti,

● V RFC 3261 definováno 6 metod:

● REGISTER,

● INVITE,

● ACK,

● CANCEL,

● BYE,

● OPTIONS,

● Dále definovány např. PRACK, SUBSCRIBE, NOTIFY

40

SIP teoriestruktura žádosti

41

SIP teorieOdpově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.

42

SIP teoriestruktura odpovědi

43

SIP teorietransakce

● 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.

44

SIP teoriedialog a transakce

45

SIP teorieregistrace

● 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é“)● macura@slu.cz Na limo@192.168.1.1:5066

46

SIP teorieRegistrar 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ě

47

SIP teorieMultiple 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ů!

48

Forking

49

Forking 200 OK

50

SIP teorieProxy

● 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í

51

SIP teorieVýstavba spojení

52

SIP teoriedata flow

53

SIP teorieNAPTR

● 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

54

SIP teorieSRV

● 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.

55

SIP teorieNAPTR,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:$1@example.com!"

● _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

56

SIP teorieTLS

● 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

57

SIP teorieSDP

● 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)

58

SIP teorieSDP

● 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

59

SIP teorieRTP

● 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.

60

SIP teoriekodek

● 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.

61

SIP teoriekodeky

● 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)

62

SIP teorieMetoda INVITE

● Příklad

INVITE sip:bob@biloxi.com SIP/2.0Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhdsMax-Forwards: 70To: Bob <sip:bob@biloxi.com>From: Alice <sip:alice@atlanta.com>;tag=1928301774Call-ID: a84b4c76e66710@pc33.atlanta.comCSeq: 314159 INVITEContact: <sip:alice@pc33.atlanta.com>Content-Type: application/sdpContent-Length: 142

63

SIP teorieINVITE

64

SIP teorieMetoda INVITE

●

65

SIP teorieHlavič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

66

SIP teorieHlavič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

67

Hlavička Via

SIP/2.0 200 OKFrom: "Jana" <sip:jana@a.cz>;tag=psvzTo: "Petr" <sip:petr@b.cz>;tag=bflmVia: SIP/2.0/UDP 3.3.3.3:5060;branch=z9hG4bKzVia: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKyVia: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bKxCall-ID: 5b063520

68

SIP teorieHlavič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í

69

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

70

Routing - INVITE

71

Routing – 180 RINGING

72

Routing – 200 OK

73

SIP teoriemetoda REGISTER

74

SIP teoriemetoda REGISTER

REGISTER sip:slu.cz SIP/2.0To: "Limo" <sip:macura@slu.cz>From: "Limo" <sip:macura@slu.cz>;tag=484dCall-ID: Acu1Ey1mMax-Forwards: 70Expires: 3600CSeq: 2855 REGISTERContact: <sip:limo@1.2.3.4:15060>Via: SIP/2.0/UDP 1.2.3.4:5060;branch=z9hG4bKxContent-Length: 0

75

SIP teorieNAT

● 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

76

SIP teorieNAT

● 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ě

77

Závěr

● Dotazy

● Lukáš Macura ● Slezská univerzita v Opavě, OPF Karviná● CESNET, z.s.p.o.● macura@opf.slu.cz