Technologie a protokoly multimediálních komunikací pro

Transkript

VYSOKÁ ŠKOLA BÁŇSKÁ–TECHNICKÁ UNIVERZITA OSTRAVA
Fakulta elektrotechniky a informatiky
Technologie a protokoly multimediálních
komunikací pro integrovanou výuku VUT a
VŠB-TUO
Garant předmětu:
Miroslav Vozňák
Autor textu:
Miroslav Vozňák
Ostrava 2014
Vznik těchto skript byl podpořen projektem č. CZ.1.07/2.2.00/28.0062
Evropského sociálního fondu a státním rozpočtem České republiky.
Za odbornou náplň tohoto vydání odpovídá autor. Miroslav Vozňák je docentem na Fakultě
elektrotechniky a informatiky VŠB-Technické univerzity v Ostravě, kde přednáší předmět Voice over
IP pro studenty navazujícího magisterského studia, kurz VoIP je na fakultě nabízen ve studijním
programu Informační a komunikační technologie.
Vznik skript byl podpořen projektem č. CZ.1.07/2.2.00/28.0062 Evropského sociálního fondu a
státním rozpočtem České republiky.
Tato publikace neprošla redakční ani jazykovou úpravou.
© Miroslav Vozňák, 2014, VŠB-Technická univerzita Ostrava
Autor:
Katedra:
Název:
Místo, rok, vydání:
Počet stran:
Vydala:
Náklad
Miroslav Vozňák
Katedra telekomunikační techniky
Technologie a protokoly multimediálních komunikací pro integrovanou výuku
VUT a VŠB-TUO
Ostrava, 2014, 1. vydání
188
Vysoká škola báňská-Technická univerzita Ostrava
CD-ROM, 100 ks
Neprodejné
ISBN 978-80-248-3326-2
PŘEDMLUVA
Vážené studentky a vážení studenti, mým cílem bylo vytvořit studijní materiál, který by reflektoval
na současný trend hlasových komunikačních systémů. Do jaké míry má snaha byla úspěšná,
nepochybně ukáže čas a především, do jaké míry bude koncept po obsahové stránce nadčasový.
VoIP lze chápat jako technologii, která využívá prostředky sítě Internet k přenosu hlasu,
v aplikační rovině pak vidíme IP telefonii jako aplikaci nad VoIP. První pokusy s přenosem hlasu
datovaných v počátcích Internetu uskutečnil Danny Cohen v roce 1977. Komerční úspěch Internetu
znamenal podnět k intenzivnímu vývoji v této oblasti a přijetí mezinárodně uznávaných standardů, a
to především H.323 v roce 1996 z organizace ITU-T a SIP doporučení v roce 1999 z dílny IETF.
V naší publikaci se budeme orientovat na SIP, a to vzhledem k faktu, že SIP se stal de-facto
stěžejním protokolem pro IP telefonii a s přihlédnutím k rozsahu publikace a užitné hodnotě informací
byl pro autory jednoznačnou volbou.
V první části se čtenář seznámí s nezbytnými teoretickými základy VoIP technologie a SIP
protokolu, které zužitkuje v druhé části věnované Asterisku. Tak jako je Apache symbolem
úspěšného projektu webového serveru, tak analogicky Asterisk představuje v IP telefonii uznávané
komunikační řešení pro nasazení IP telefonie.
Na závěr této předmluvy bych rád poděkoval své manželce Pavle a našim dětem za trpělivost, bez
které by tato skripta nevznikla a rovněž děkuji kolegům, kteří se mnou odborně spolupracují a přispěli
tak k formování obsahu této publikace a to především svým nejbližším spolupracovníkům Honzovi
Rozhonovi a Filipovi Řezáčovi. V neposlední řadě patří poděkováním i mým kolegům z FEKT VUT
v Brně za spolupráci při řešení projektu OP VK č. CZ.1.07/2.2.00/28.0062 “Společné aktivity VUT a
VŠB-TUO při vytváření obsahu a náplně odborných akreditovaných kurzů ICT“, za jehož podpory byl
obsah předmětu inovován a vytvořena tato skripta.
V Ostravě, leden 2014
Miroslav Vozňák
Miroslav Vozňák, nar. 1971, je docentem Fakulty elektrotechniky a
informatiky VŠB-Technické univerzity v Ostravě, je ovšem zván rovněž
k přednáškám na řadu zahraničních univerzit jako např. v letech 2007-2009 na
University of Milan, 2012 na University of Ankara, v roce 2013 byl hostujícím
profesorem na University of Calabria a od téhož roku je veden jako overseas
profesor na Ton Duc Thang University v Saigonu. Je autorem či spoluautorem
více než 300 článků v časopisech, příspěvcích na konferencích či kapitol
v knihách, z toho přes 80 z nich je indexováno v citační databázi vědeckých
publikací Scopus společnosti Elsevier a v Google Scholar je u jeho jména zaevidováno na 500 citací
článků. Od roku 2011 je rovněž výzkumným pracovníkem národního superpočítačového centra
IT4Innovations. Profesně se věnuje informačním a komunikačním technologiím, doménami jeho
výzkumných aktivit jsou Voice over IP, kvalita řeči a síťová bezpečnost.
E-mail: [email protected]
OBSAH
1 Přenos sítí Internet v reálném čase
1
1.1 Real Time Protocol
1
1.2 Zabezpečení přenosu RTP
4
1.2.1 Zabezpečení pomocí SRTP
5
1.2.2 Návrh vylepšení SRTP pomocí ZRTP
9
1.3 Přenos DTMF a jiných tónů přes RTP
11
1.4 SCTP Stream Control Transmission Protocol
13
2 Standard ITU-T H.323
14
2.1 Rodina protokolů H.32x
15
2.2 Verze H.323
15
2.3 Koncepce komunikace v H.323
17
2.3.1 Protokolový model H.323
18
2.3.2 Prvky H.323 a jejich vlastnosti
18
2.3.3 Signalizace RAS
20
2.3.4 Signalizace Q.931
25
2.3.5 Signalizace H.245
27
2.3.6 Modely spojení DRC a GRC
28
2.4 Vybrané scénáře toku zpráv H.323
30
2.5 Konfigurace ISDN modulů v Cisco směrovačích
32
2.5.1 Příklad nastavení BRI
33
2.5.2 Příklad nastavení PRI
33
2.5.3 Pravidla volby čísel a směrů
34
2.5.4 Třídy kodeků
36
2.5.5 Chybějící kontrolní vyzváněcí tón
36
2.6 Diagnostika na hlasové bráně
37
2.7 GNU Gatekeeper
40
2.7.1 Instalace a konfigurace GnuGK
41
2.7.2 Registrace EP
42
2.7.3 Propojení GnuGK s jiným GK
44
2.7.4 Statická registrace GW v GnuGK
44
2.7.5 Autentizace v GnuGK
45
2.7.6 Autorizace v GnuGK
47
2.7.7 Návrh sítě s konfigurací GnuGK
48
2.7.8 Nastavení GK a mezizónové propojení
49
8.2.2 Nastavení VoGW a dynamické registrace na GK
50
i
3 Session Initiation Protocol
53
3.1 Základní popis protokolu SIP
53
3.2 Prvky SIP řešení
55
3.2.1 User Agent a Back to Back User Agent
56
3.2.2 SIP Proxy Server
57
3.2.3 SIP Registrar Server
59
3.2.4 SIP Redirect Server
60
3.3 SIP žádosti a odpovědi
61
3.3.1 Základní popis SIP hlavičky typické žádosti
61
3.3.2 SIP metody
62
3.3.3 SIP odpovědi
63
3.3.4 Transakce
66
3.3.5 Dialog
68
3.3.6 SIP časovače a retransmise
69
3.3.7 Zabezpečení v SIPu
71
3.4 Registrace
72
3.5 Směrování
73
3.5.1 Směrování dle RURI a Via
74
3.5.2 SIP trapezoid
75
3.5.3 Udržení SIP Proxy v signalizační trase
79
3.6 SDP- protokol popisu relace
81
3.6.1 Konstrukce položek SDP pro komunikaci SIP/SDP
82
3.6.2 Offer/Answer model
84
4 Další metody rozšiřující SIP
86
4.1 Metoda PRACK (Provisional Response Acknowledgement)
86
4.1.1 Použití PRACK při volání do PSTN
87
4.1.2 Early Media
88
4.2 Metoda UPDATE
88
4.3 Metoda REFER
90
4.4 Metoda MESSAGE (Instant Messaging)
91
4.5 Metody SUBSCRIBE,NOTIFY,PUBLISH (Event/Notification)
92
4.6 Realizace vybraných doplňkových služeb v SIPu
95
4.7 Síťování SIP s PSTN
96
4.8 Paralelní vyzvánění - Forking
97
4.9 Přidržení hovoru - Call hold
98
4.10 Hudba při přidržení – Music on Hold
99
4.11 Předání hovoru - Call transfer
99
4.12 Přesměrování volání - Call forwarding
101
4.13 Indikace zprávy - Message waiting indication
102
ii
4.14 Vytočení kliknutím - Click to dial
103
4.15 Zpětné volání – Call Back
105
4.16 Metoda INFO
106
5 SIPp a jeho použití k emulaci SIP relací
108
5.1 Instalace
108
5.2 Scénáře pro SIPp
109
5.2.1 SIPp v příkazovém řádku
110
5.2.2 Vytváření XML schémat
111
5.2.3 Vkládání hodnot z externích souborů
116
5.2.4 Ovládání SIPp za běhu
118
5.2.5 Další tipy pro SIPp
119
6 NAT vs. IP telefonie
120
6.1 Terminologie
120
6.2 Popis problému s průchodem SIP zpráv přes NAT
121
6.3 Klasifikace typů NAT
122
6.4 Provozování IP telefonie přes NAT
123
6.4.1 STUN server
124
6.4.2 Překonání NATu pomocí TURN, ICE a rport
125
7 Asterisk
128
7.1 Verze Asterisku
128
7.2 Popis Asterisku
129
7.2.1 Režimy Asterisku
130
7.2.2 Kodeky a protokoly Asterisku
131
7.2.3 Služby Asterisku
132
7.3 Instalace
134
7.4 Globální nastavení asterisk.conf a modules.conf
135
7.5 Konfigurace SIP a IAX uživatelů v sip.conf a iax.conf
137
7.5.1 SIP uživatel v sip.conf
138
7.5.2 IAX uživatel v iax.conf
138
7.5.3 Další možnosti sip.conf a iax.conf
139
7.6 Dialplan extensions.conf
142
7.6.1 Kontexty
142
7.6.2 Pobočky
142
7.6.3 Priority
143
7.6.4 Aplikace
143
7.6.5 Tvorba dialplanu
144
7.6.6 Vzory – Pattern Matching
145
iii
7.6.7 Offset při práci s řetězcem
146
7.6.8 Vložené kontexty – Include Statements
147
7.6.9 Časové Vložené kontexty
147
7.6.10 Proměnná ${EXTEN} a funkce ${CALLERID(num)}
148
7.7 Voicemail
148
7.8 IVR – Interactive Voice Response
149
7.8.1 Jednoduché IVR
150
7.8.2 Neplatný vstup (extension i)
150
7.8.3 Pauzy
150
7.8.4 Víceúrovňové IVR
151
7.9 DAHDI/ZAPTEL
152
7.9.1 Chan_dahdi.conf (Zapata.conf)
153
7.10 Peering mezi dvěma Asterisky
154
7.11 Použití SRTP a SIPS/TLS
157
7.11.1 Zabezpečení médií pomocí SRTP
157
7.11.2 Zabezpečení signalizace v Asterisku pomocí SIPS
158
7.12 Asterisk a kalendáře
159
7.12.1 Instalace Davical serveru
160
7.12.2 Propojení Asterisku a Davical serveru
162
7.13 Aplikace kalendářových funkcí
163
7.13.1 Směrování volání na základě zaneprázdněnosti
163
7.13.2 Zapisování do kalendáře
163
7.13.3 Čtení záznamů uložených v kalendáři
164
7.13.4 Upozornění na schůzku
166
7.14 XMPP server a Asterisk
166
7.14.1 Instalace Openfire
167
7.14.2 instalace XMPP klientů
168
7.14.3 Propojení XMPP a Asterisku
170
8 Kamailio
173
8.1 Popis modulů Kamailia
174
8.2 Instalace o rozběhnutí Kamailia
176
9 WebRTC a nové směry v IP telefonii
179
Literatura
182
Rejstřík
186
iv
Přenos sítí Internet v reálném čase
1
Transportní protokoly Internetu nabízí spolehlivou službu s potvrzováním doručených datagramů
pomocí spojově orientovaného protokolu TCP (Transmission Control Protocol) anebo nespolehlivou
službu na nespojově orientovaném protokolu UDP (User Datagram Protocol). UDP protokol přidává k
IP záhlaví důležitá pole, kterými jsou: zdrojový a cílový port služby, délka přenášených dat včetně
záhlaví a kontrolní součet pseudozáhlaví. Nepochybně stojí za zmínku, že UDP nezaručuje doručení
ve správném pořadí, což některým aplikacím přináší komplikace. Je zřejmé, že u požadavku na realtime přenos není možné použít službu s potvrzováním datagramů, neboť informace pozbývá svou
platnost s časem a pro IP telefonii je nutné použit transportní službu zajišťovanou UDP [v92]. UDP
protokol je vhodnější pro Real-time aplikace, umožňuje sice nespolehlivé, ale rychlé doručování. I
tady ovšem najdeme nedostatky a potřebu adaptace pomocí dalšího protokolu nad UDP, řešením je
protokol přenosu v reálném čase RTP, struktura zprávy je na zobrazena na obr. 1.1. [v92].
Obr.1.1. Struktura zprávy pro real-time přenos.
1.1
Real Time Protocol
Real Time Protocol je označován jako protokol aplikační vrstvy, který využívá transportní protokol
UDP, ale dle účelu a obsahu polí hlaviček nese důležité znaky transportního protokolu a tak se jeví
logičtější ho zařadit na transportní vrstvu hned nad UDP, jehož přenos vylepšuje. Tento pohled je ale
spíše filozofický a neřeší nic zásadního, pojďme se podívat na jednotlivá pole RTP a způsob
adaptace real-time aplikací na přenos v Internetu, viz. obr. 1.2 RTP protokol především zajišťuje
seřazení zaslaných paketů (Sequence Number) a jejich časové značkování (Timestamp), další
vlastnost, která ho řadí do transportní vrstvy je multiplexování a demultiplexování. Pokud si vezmeme
postup odesílání hlasu v IP sítí, tak tok bitů digitalizovaného hlasu ve zvoleném formátu (např. PCM)
je naporcován do bloků (typicky 20 B až 160 B) a každý blok je opatřen hlavičkou RTP o velikosti 12
B, dále se před hlavičku zařadí 8 B hlavičky UDP, viz. obr. 1.1. Tím je datagram připraven ke vstupu
do vrstvy síťové, kde dostane IP hlavičku o velikosti 20 B, celkově tedy bylo k užitečné zátěži přidáno
40 B. Jednotlivá pole RTP obsahují tyto položky, viz. obr.1.2 :
1
•
•
•
•
•
•
•
•
•
•
V je verze. Určuje verzi RTP,
P je doplnění. Pokud je nastaveno, paket obsahuje na konci jeden či více doplňkových oktetů,
které nenesou užitečná data,
X je rozšiřující bit. Pokud je nastaven, pak pevné záhlaví je následováno právě jedním
rozšířením záhlaví, které má definovanou strukturu,
CC je CSRC count obsahuje číslo identifikátoru příspěvku zdroje,
M je značka. Interpretace značky je různá. Lze jí použít např. jako označení konce rámce v
paketovém toku, na své využití ještě čeká.
Payload Type určuje formát užitečného zatížení RTP a stanovuje jeho význam pro aplikaci.
Další kód typu užitečného zatížení je definován dynamicky, ale ne již přes RTP,
Sequence number se zvyšuje o jeden pro každý vyslaný RTP paket Přijímač jej využívá pro
určení případné ztráty paketu a pro obnovení souslednosti paketu,
Timestamp vyjadřuje vzorkovací značku prvního oktetu v RTP paketu. Vzorkovací značka
musí být odvozena od lineárního časovače z důvodu synchronizace a korekce rozptylu
zpoždění (jitter). Rozlišení časovače musí být dostatečné pro požadovanou synchronizační
přesnost a pro zjištění jitteru příchozího paketu (např. jeden kmit za videosnímek není
dostačující),
SSRC identifikuje synchronizační zdroj. Tento identifikátor je zvolen náhodně s tím, že žádné
dva synchronizační zdroje v rámci jedné RTP relace nemají stejný SSRC identifikátor,
CSRC je identifikační seznam přispívajících zdrojů. Identifikuje přispívající zdroj z důvodu
užitečné informace obsažené v tomto paketu.
Obr.1.2. Jednotlivá pole RTP dle specifikace RFC 1889.
Samotný přenos audia/videa v RTP bývá doplněn o dohledový protokol RTCP (Real Time
Control Protocol), který nese statistické informace o průběhu přenosu. Port pro RTCP je nastaven o
jedničku vyšší než RTP, minimální doba pro odeslání RTCP je stanovena na 2 sec., např. u G.711 by
to znamenalo jeden paket RTCP na sto paketů RTP, pro čísla portů platí (1.1), přičemž portům RTP
jsou přidělována sudá čísla.
port_RTCP=port_RTP+1
(1.1)
2
Obr. 1.3. Formát pole Payload Type.
3
V současné době prošel Real-Time protokol třemi verzemi, a to:
•
•
RFC 1889, z roku 1996 (Transport Protocol for Real-Time Applications), původní doporučení;
RFC 3550, z roku 2003, drobná vylepšení oproti RFC 1889 především v části dohledu nad
RTP tokem, tím původní RFC 1889 zastaralo;
RFC 3711, z roku 2004, specifikuje zabezpečený přenos RTP jako SRTP (Secure Real-time
Transport Protocol). Hlavička RTP může být komprimována ze 40B na 2-3B s použitím kompresního
protokolu cRTP (compressed RTP), jelikož je vyžadována podpora na obou stranách, tak je použití
víceméně omezeno na dvoubodové spoje a cRTP není příliš rozšířen [coli], [cam]. Typickým portem
RTP je 5004 a RTCP tím pádem 5005, ale v zásadě může být použit jakýkoliv port vyšší než 1024,
např. Cisco zařízení alokují pro RTP porty v rozmezí 16384 až 32767. Řídící protokol RTCP
Původní RFC 1889 pro RTP z ledna 1996 vydrželo poměrně dlouho a další RFC pro RTP bylo
uvolněno až v červnu roku 2003. Implementace RTP dle RFC 3550 si dokáže poradit se starší RFC
1889, neboť ve formátu paketu či v obsahu hlaviček nedošlo ke změnám, změny jsou v RTCP, čili
v protokolu dohledu toku médií. Změnila se pravidla a algoritmy užití protokolu, nejvýznamnější
změnou je specifikace typů zpráv RTCP a rozšíření týkající se pravidel odesílání RTCP (jedná se o
algoritmus časování odesílání RTCP). RTCP shromažďuje statistiky přenosu na RTP, informace o
množství odeslaných bajtů a počtu paketů, ztracených paketů, rozptylu zpoždění. Dle RFC 3550 je
definováno celkem pět typů zpráv:
•
•
•
•
•
1.2
SR (Sender Report) – soubor statistik od odesílatelů, posílá se aktuální identifikace zdroje
synchronizace (SSRC), časová značka (timestamp), počet odeslaných paketů a odeslaných
bajtů,
RR (Receiver Report) – soubor statistik od příjemců, obsahuje jednak podíl ztracených paketů
k celkovému množství očekávaných, počet ztracených paketů, aktuální sekvenční číslo (SN),
jitter, poslední timestamp a čas, který uběhl od poslední zprávy SR,
SDES (Source DEScription) – vlastnosti odesílatelů RTP komunikace (jejich „vizitky“), jednak
je to SSRC a jméno (obvykle URI),
BYE (End message) – signalizuje ukončení relace;
APP – funkce specifické pro jednotlivé aplikace.
Zabezpečení přenosu RTP
Použitím nešifrovaného přenosu pomocí RTP zvyšujeme riziko odposlechu hovoru [v191], [v193].
Oblíbený síťový softvérový analyzátor Wireshark umí ze zachyceného RTP toku rekonstruovat
původní zvukovou stopu. Získání zvukové stopy z RTP paketů a její následné přehrání či uložení, je
v aplikaci Wireshark možné pouze u kodeků PCM A-law a µ-law, ovšem existuje řada placených
analyzátorů, které zpracují pro přehrání audio signál i s jinými kodeky (např. Observer). Nešifrovaný
přenos RTP je proto velkým hazardem a zabezpečení je nezbytné. U transportních protokolů
užívaných pro multimédia musíme hlavně brát zřetel na to, že komunikace pomocí těchto protokolů
probíhá v reálném čase, proto i zabezpečovací techniky musí byt implementovány tak, aby vznikalo
minimální časové zpoždění [v138], [v166] a [v194].
4
1.2.1
Zabezpečení pomocí SRTP
Stejně jako u signalizačních protokolů, tak ani nejpoužívanější protokol RTP neobsahuje ve svém
základu žádné ochranné metody či mechanizmy, a proto byl v roce 2004 v RFC 3711 definován
protokol SRTP (Secure Real-time Transport Protocol). Formát paketu SRTP je odvozen od RTP,
šifrován je přenášený obsah užitečné informace (payload) a integrita polí hlaviček je zajištěna
pomocí autentizační značky (authentication tag), která je získána algoritmem HMAC-SHA-1. Do této
hašovací funkce vstupuje klíč auth_key a užitečná zátěž RTP, výstupem je autentizační značka,
která je přidána do poslední položky zabezpečeného SRTP datagramu.
Obr. 1.4. HMAC-SHA1 funkce
Použití SRTP autentizační značky je v RFC 3711 doporučeno vždy, zatímco další značka SRTP
MKI je nepovinná
Obr. 1.5. Obsah polí hlavičky SRTP
5
MKI (Master Key Identifier) je prezentován jako hlavní klíč a může být použit pro správu klíčů
(key management), využití je pro účely obměny klíčů během relace, identifikuje konkrétního hlavní
klíč (master_key) užívaného v SRTP, z něj jsou odvozeny další důležité klíče, což je zobrazeno v obr.
1.5. MKI zvyšuje bezpečnost, protože během jedné relace mohou být klíče střídány [v120].
Obr. 1.6. Režim šifrování OFB.
Podívejme se nyní na kryptografické mechanizmy užité v RFC 3711. SRTP definuje používání
režimu šifrování AES-CTR (Counter Mode) anebo AES-f8, přičemž výchozím módem je AES-CTR.
Povinně implementováno musí být šifrování AES-CTR a případně může být nepovinně podporován i
algoritmus AES-f8. Zatím jsme se s implementací algoritmu AES-f8 v SRTP dosud nesetkali, všichni
implementují AES-CTR. V případě f8 jde o aplikaci módu OFB (Output Feedback) a používá se pro
šifrování v UMTS sítích. U OFB se otevřený text sčítá na členu nonekvivalence s výstupním blokem
získaným aplikací blokové šifry, viz. obr. 1.8. První výstupní blok je vytvořen šifrovací funkcí CIPHK z
inicializačního vektoru a je zároveň vstupem do druhého bloku, kde po aplikaci šifrovacího algoritmu
získáme druhý výstupní blok, který je opět vstupem do dalšího.
Šifrový text získáme operací exkluzivní disjunkce, vstupními hodnotami jsou jednak bity
otevřeného textu a jednak bity z jednotlivých výstupních bloků. Jedná se o režim proudové šifry
(stream cipher mode) anebo exaktně řečeno, u OFB dochází k převodu blokové šifry na proudovou.
Čítačový režim CTR, viz. obr. 1.7, je zjednodušenou verzi zpětnovazební šifry OFB, kdy při
šifrování je namísto vazby na předchozí blok použita vazba s hodnotou inkrementálního čítače, viz.
obrázek. Opět dochází převodu blokové šifry na proudovou. CTR rovněž využívá inicializační
hodnotu, která se načte do vstupního registru (Counter 1) a po zašifrování funkcí CIPHK dostáváme
první výstupní blok, který se sčítá na členu XOR s otevřeným textem. Poté doje k aktualizaci čítače
6
(obvykle přičtením jedničky) a získáváme Counter 2, opět se opakuje jeho šifrování a operace
operací exkluzivní disjunkce s otevřeným textem.
Obr. 1.7. CTR režim šifrování.
Aktualizace čítače je definována poměrně volně, hodnota nemusí být inkrementována o jedničku,
musí být ovšem splněna podmínka, že obsah čítačů nesmí být stejný.
Obr. 1.8. Blokové schéma šifrování obsahu RTP
Podívejme se nyní na aplikaci AES-CTR v SRTP, viz. obr. 1.8. Důvěrnost přenášených dat v
paketu zajišťuje kryptografický primitiv AES, který funguje v tomto případě jako generátor
pseudonáhodných klíčů.
Vstupem do generátoru je šifrovací klíč encr_key a inicializační vektor IV, který sestává z
kontrolního součtu salt key, SSRC a indexu paketu. Výsledný klíč je pomocí logické operace XOR
7
aplikován na nezašifrovaný obsah paketu, což odpovídá CTR režimu šifrování. Inicializační vektor IV
je získán z rovnice (1.6), ve které SSRC je identifikátor synchronizace, ks je sůl a i je index SRTP
paketu odesílatele
IV = (k s ⋅ 216 ) ⊕ (SSRC ⋅ 264 ) ⊕ (i ⋅ 216 )
(1.6)
Šifrovací klíče encr_key a salt_key, jsou získány opět pomocí AES-CTR, přičemž jsou odvozeny
z hlavního klíče master_key, viz. obr. 1.19. Problém je ovšem v distribuci hlavního klíče, který je
distribuován během sestavení spojení, v signalizaci SIP se používá SDP (Session Description
Protocol).
Obr. 1.9. Odvození klíčů pro šifrovací schéma.
Pokud je šifrování provedeno na úrovni SIP, není pochopitelně nutné používat silné
kryptografické algoritmy pro přenášení informací uvnitř SIP, sice je to možné, ale je to zbytečné
plýtvání výpočetním výkonem.
Jako ukázku naprosto nevhodné implementace a přenosu šifrovacího klíče, uvádím příklad
zachycený při použití MS Messenger
k=base64:D0c7ni7jtkF+mJJY7bfXioIhnJe6rrckZ46GSTvXElE=
Zda bylo použito base64 či nebylo, to už není zásadní, base64 je triviální způsob kódování, který
lze dekódovat ručně s papírem, tužkou a ASCII tabulkou po ruce a navíc interoperabilita s dalšími
zařízeními bude problematická. Zásadním problémem je zde přenos šifrovacího klíče přímo v SDP
s využitím deskriptoru k=* (encryption key), takto by to opravu býti nemělo.
8
V dalším příkladu je způsob vyjednávání klíčů popsaného v RFC 4568 z roku 2006, jedná se o
SDES (Security Descriptions for Media Streams). V SDP pod “m“ řádkem s popisem médií se
přidává crypto atribut ve formě “a“ řádku s popisem režimu šifrování obsahu (AES_CM_128_,
F8_128_) a vytvoření autentizační značky (HMAC_SHA1_80, HMAC_SHA1_32).
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
Pod crypto atributem je “inline“ řádek obsahující klíče (master key a salt key) a politiky vztažené
k master klíči, tzn. jak dlouho bude platit (lifetime) a zda se bude používat MKI (master key identifier)
s konkrétním master klíčem "inline:" <key||salt> ["|" lifetime] ["|" MKI ":" length] . Zřetězení dvou klíčů
key||salt je opět kódováno v base64. Níže je uveden příklad použití SDES dle RFC 4568.
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): 9911 8000 8000 IN IP4 158.196.81.105
Session Name (s): SIP Call
Connection Information (c): IN IP4 158.196.81.105
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 5004 RTP/SAVP 0
Media Attribute (a): sendrecv
Media Attribute (a): crypto:1 AES_CM_128_HMAC_SHA1_80
inline:NUC6m+o/EO+BEJIVQDtOzO4j3pb4awZyQ05Z07QD
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): ptime:20
Bez použití TLS anebo S/MIME, kterým by bylo zašifrován obsah SDP v SIP relaci, neposkytuje
ani výše uvedené řešení dostatečnou úroveň zabezpečení. S tím nebyl spokojen Philip Zimmermann,
který přišel s dalším vylepšením umožňující bezpečně sestavit klíče na obou komunikujících stranách.
Philip Zimmermann již zanechal ve světě sítí důležitou stopu v oblasti šifrování emailové komunikace
a proslavil se protokolem PGP (PGP Pretty Good Privacy). Jelikož produkt svého intelektu poskytl
v roce 1991 k volnému použití pro tehdy rodící se Internet, tak si zasloužil v USA obvinění z
nelegálního vývozu kryptografického softvéru, na který se tehdy stahovalo embargo a tři roky byl
vyšetřován a pronásledován FBI, než byl zbaven tohoto absurdního obvinění. Návrhem nového
zabezpečení RTP s označením ZRTP se bude zabývat další podkapitola.
1.2.2
Návrh vylepšení SRTP pomocí ZRTP
ZRTP (Zimmermann Real-time Transport Protocol, RFC 6189) neslouží jako náhrada za SRTP,
ale pouze jako nadstavba pro jeho lehčí použití a implementaci. ZRTP rozšiřuje SRTP protokol o
mechanismus pro počáteční dohodu na klíčích a dokáže chránit i proti útokům zvaných jako MiTM
(Man in the middle). Zimmermann si všiml způsobu distribuce hlavního klíče v SRTP, ve kterém viděl
slabinu a možnost prolomení šifrované komunikace třetí stranou. Zásadním rozdílem je, že výměna
probíhá v dohodnuté trase pro média a zprávy jsou transportovány přes stejné porty jako RTP. Návrh
ZRTP používá při dohodě na klíčích Diffie-Hellmanův algoritmus, komunikující strany si vyměňují
řetězce, ze kterých je odvozen utajený šifrovací klíč, tento klíč se přitom nepřenáší, jeho získání z
přenášených zpráv třetí osobou je velmi časově náročným matematickým problémem řešení
diskrétního logaritmu s velkými čísly. Detekce MiTM útoků se řeší zobrazováním krátkých
9
autentizačních řetězců SAS (Short Authentication String). ZRTP užívá tři fáze k tomu, aby zjistil a
nastavil potřebné klíče a přešel na SRTP mód:
•
•
•
detekce, zda-li účastníci podporují ZRTP implementaci,
výměna hodnot pro dohodu na klíčích s využitím DH algoritmu
přepnutí do SRTP módu a úspěšné používání SRTP.
V první fázi si oba ZRTP účastníci vymění mezi sebou informace o šifrování, dohodnutých klíčích
a způsoby autentizace, které budou používat. Současně ZRTP specifikace tyto šifrovací režimy:
•
•
AES Counter Mode s délkou klíče 128 bit,
AES Counter Mode s délkou klíče 256 bit.
Pro dohodu na klíči se používá ZRTP Diffie-Hellmanův algoritmus. Pro tento algoritmus ZRTP
může využívat dva různé módy:
•
•
3072 bit Diffie - Hellman hodnoty,
4096 bit Diffie - Hellman hodnoty.
Obr. 1.10. Princip DH algoritmu.
Princip DH algoritmu je znázorněn na obrázku 1.10, tento algoritmus umožňuje rychle sestavit
tajný klíč, aniž by byl přenesen komunikujícími stranami přenesen, přičemž útočník
odposlouchávající komunikaci by k jeho sestavení potřeboval extrémní výpočetní výkon a čas. DH
algoritmus je postaven na složitosti řešení diskrétního logaritmu. Mějme rovnici g a = y , přičemž
známe hodnoty g, y a neznámou a vypočteme jako a = log g y , to je triviální problém logaritmu.
Pokud ale aplikujeme funkci modulo p, kde p bude prvočíslo v rovnici g a mod p = y , tak dostáváme
10
netriviální problém tzv. diskrétního logaritmu, výpočet je při použití velkých prvočísel p velmi složitý a
současnými prostředky nezvládnutelný.
Jakmile se pomocí ZRTP vyjednají klíče, tak je nastavena v SRTP kryptografická souvislost a
komunikace se přepne do SRTP módu. Nakonec ZRTP změní některé kontrolní informace, aby si
mohl ověřit, zda celá operace proběhla úspěšně. ZRTP řeší také ochranu proti útoku MITM, kde se
případný útočník snaží řídit a kontrolovat spojení mezi komunikujícími stranami. Pro zamezení
tohoto útoku ZRTP používá metody Short Authentication String (SAS) a Retained Secrets (RS).
Zajímavým projektem implementace ZRTP je Zfone [zph], , který pracuje s běžnými SIP klienty.
Zfone GUI slouží k ujištění volaných, že hovor je šifrován a nebyl detekován útok MiTM. U SRTP
nelze MiTM vyloučit a ani detekovat.
Philip Zimmermann udělal svým návrhem ZRTP velký krok jiným směrem, než by chtěla
jakákoliv vláda, regulátor či úřední moc. Dosud bylo možné spojení odposlechnout a pokud bylo
šifrováno SRTP, tak výměnu klíče odchytit a rozšifrovat, případně šifrovat spojení hop-by-hop. ZRTP
zaručuje šifrování end-to-end a v případě MITM budou jeho uživatelé aspoň upozorněni, že spojení
není bezpečné. ZRTP je významný krok v bezpečném přenosu médií a bude mít značný dopad
zvláště v USA, kde platí od roku 2007 rozšíření CALEA (The Communications Assistance for Law
Enforcement Act) i na IP telefonii. CALEA jsou pravidla právně vynucovaného nahrávání hovorů,
které stanovily Ministerstvo spravedlnosti a FBI. V USA platí CALEA pro všechny poskytovatele
telefonních služeb a od roku 2007 nevyjímaje poskytovatele hlasových služeb na VoIP. I tito
poskytovatelé musí v USA poskytnout asistenci při nahrávání hovorů, to platí i např. pro Skype,
pokud je alespoň jeden účastník spojení v USA.
1.3
Přenos DTMF a jiných tónů přes RTP
V roce 2000 bylo uvolněno RFC 2833 (RTP Payload for DTMF Digits, Telephony Tones and
Telephony Signals), které specifikuje způsob přenášení tónové volby a obecně tónů pomocí RTP
protokolu. Dnes je RFC 2833 nejpoužívanější způsob pro přenos DTMF (tónové volby). Pomocí RFC
2833 či RFC4733 lze obecně přenášet tóny, jde o způsob přenosu out-of-band, čili mimo hovorové
pásmo, tóny jsou popsány určitou formou (u DTMF postačí čísla, lze i kmitočet) a příjemce je
generuje z popisu.
Druhý způsob přenosu in-band vyžaduje použití PCM a tóny v pásmu 300-3400 Hz jsou
přenášeny v digitalizované podobě dané standardem ITU-T G.711. Třetím způsobem je přenos
pomocí SIP metody INFO, který je používán zřídka. Pro přenos DTMF se dle výše uvedeného
používají tři způsoby:
•
•
•
in-band, v pásmu 300-3400 Hz pomocí PCM (G.711)
out-band, pomocí RFC 2833 a RFC 4733 (modifikovaný RTP)
out-band, pomocí SIP metody INFO
RFC 4733 z roku 2006 plně nahrazuje RFC 2833 z roku 2000 a je s ním zpětně kompatibilní.
Původní RFC definuje dva typy formátů:
11
•
•
první pro přenos DTMF čísel, kontrolních tónů a signálů trunku
druhý pro obecné MF (Multi-Frequency) tóny v RTP
Informace jsou přenášeny v RTP a níže uvedený příklad ukazuje přenos čísla 112, pole digit
nese přenášená DTMF čísla (112), pole duration indikuje dobu vysílání tónu (při výchozím
vzorkování 8 kHz jsou doby trvání 200ms, 250ms a 50ms. Pole timestamp offset prezentuje časovou
souslednost vysílaných tónů, první znak 1 znamená začátek časové osy 0 sec, z druhé hodnoty
4800/8 kHz určíme, že další znak 1 začne být reprodukován 800 ms od začátku přehrávání prvního a
poslední 11200/8Kz říká, že třetí znak 2 začne být reprodukován po 1,4 sec. od začátku generování
prvního.
Novější RFC 4733 na rozdíl od RFC 2833 přidává tři nové procedury:
•
•
•
rozdělení dlouhých událostí do segmentů,
oznamování více událostí v jednom paket,
oznamování stavů.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC
|M|
PT
|
sequence number
|
| 2 |0|0|
0
|0|
96
|
28
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
timestamp
|
|
11200
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
synchronization source (SSRC) identifier
|
|
0x5234a8
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|
block PT |
timestamp offset
|
block length
|
|1|
97
|
11200
|
4
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|
block PT |
timestamp offset
|
block length
|
|1|
97
|
11200 - 6400 = 4800
|
4
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|
Block PT |
|0|
97
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
digit
|E R| volume
|
duration
|
|
1
|1 0|
7
|
1600
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
digit
|E R| volume
|
duration
|
|
1
|1 0|
10
|
2000
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
digit
|E R| volume
|
duration
|
|
2
|0 0|
20
|
400
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Obr. 1.11. RTP paket dle RFC 2833 po volbě čísla 112
12
1.4
SCTP Stream Control Transmission Protocol
Stream Control Transmission Protocol je transportní protokol RFC 4960 (2007), který byl navržen
IETF skupinou Signaling Transport (SIGTRAN), která především řešila přenos SS7 přes IP. Jedním z
požadavků bylo vytvoření několika nezávislých kanálů přepravovaných paralelně, což je největší
odlišností SCTP od transportních protokolů jako je UDP a TCP. Po navázání spojení (asociaci), lze
přenášet několik navzájem nezávislých toků (streams), v rámci každého toku je garantováno
doručení ve správném pořadí a jednotlivé toky se navzájem neovlivňují, čili výpadek, opakování,
zdržení v jednom nemá vliv na další a jejich komunikace pokračuje bez přerušení či pozdržení. SCTP
je velmi zajímavým protokolem, ve VoIP se ovšem neprosadil. SCTP má jednodušší strukturu než
UDP či TCP: Hlavička 12B obsahuje Source port, Destination Port, Verification tag a Checksum,
následně zbytek datagramu tvoří Chunks (balíky – porce dat), viz. obr. 1.12.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Source Port Number
|
Destination Port Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Verification Tag
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Checksum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Chunk #1
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
...
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Chunk #n
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Obr. 1.12. Formát SCTP paketu
Výhody protokolu SCTP jsou následující:
•
Multihoming - komunikující uzel má několik IP adres (i směs IPv4 a IPv6), dostupné
adresy si komunikující strany vyměňují přes asociace, během komunikace je jedna z nich
brána jako primární a na tu jsou odesílána data. V případě opakování se ale vybírá jiná a
pokud je primární IP adresa opakovaně nedostupná, tak odesílatel začne používat jinou.
•
Chunks - doručení probíhá v balících a eliminují se chybějící bloky obdobně jako u TCP.
•
Výběr a sledování trasy - SCTP monitoruje všechny trasy, jedna je vybrána jako primární,
v případě problémů se přechází na další alternativní.
•
Ověřovací a potvrzovací mechanizmy - SCTP má vyšší rezistenci oproti DoS útokům,
zajišťuje ověření opakujících se a chybějících balíků (chunks).
13
2
Standard ITU-T H.323
Standard H.323 od ITU-T byl prvním doporučením, které popisovalo komunikaci v paketových
sítích. Již rok před jeho uvolněním firma VocalTec spustila v roce 1995 produkt Internet Phone
založený na vývojové verzi H.323 a stala se tak první firmou na světě, která začala nabízet IP
telefonii. Jako doporučený HW byl uváděn 486SX PC - 25 MHZ, 8MB RAM a minimální požadovaná
konektivita byla 14,4 kbit/s, podporovaný OS byl Windows 3.1 a připojení k Internetu bylo téměř
výhradně přes modem. Od roku 1995 urazil Internet závratný kus cesty a H.323 se dostala z
prenatální verze do své známé poslední verze 7 z roku 2009. Řada sítí je na H.323 dodnes
provozována a ačkoliv je zřejmé, že v souboji s protokolem SIP, tento vyzrálý standard prohrál,
nachází si nadále okruh uživatelů, kteří na něj nedají dopustit. Každopádně jeho vyhlídky nejsou
růžové a dnes existuje pouze několik málo aktivních projektů, ve kterých probíhá nadále
implementační vývoj produktů pro H.323.
Obr. 2.1 Vývoj H.323 od uvedení až po aktuální verzi.
14
2.1
Rodina protokolů H.32x
Za vývojem rodiny protokolů H.32x stojí mezinárodní telekomunikační unie ITU-T. H.32x rodina
řeší multimediální komunikace přes různé sítě, a to:
•
•
•
•
•
•
•
2.2
H.320, N-ISDN, úzkopásmová ISDN,
H.321, B-ISDN, širokopásmová ISDN (ATM),
H.322, LAN s garancí QoS,
H.323, paketově založené multimediální systémy,
H.324, PSTN, veřejné analogové telefonní sítě s přepojov. okruhů,
H.324M, rozšíření H.324 pro mobilní sítě 3GPP,
H.325, nový standard vyvíjený v SG16 jako AMS (Advanced Multimedia System).
Verze H.323
Doporučení H.323.v1 z roku 1996 ve verzi 1 popisuje terminály, zařízení a služby pro
multimediální komunikaci v lokálních počítačových sítích LAN bez garance kvality služby. Terminály
H.323 mohou přenášet hlas, data a video, nebo kombinaci služeb včetně videotelefonie. Evoluce
standardu H.323 přinesla další verze, v roce 1998 byla přijata verze 2, která řešila především
vylepšení H.245, nástroj QoS pomocí rezervačního protokolu RSVP a autentizaci standardem H.235.
Další verze 3 je z roku 1999 a přispěla především v oblasti doplňkových služeb, které řeší
doporučení H.450. Nové služby přináší i verze 4 z roku 2000, v roce 2003 byla uvolněna verze 5,
která řeší i podporu ENUM (univerzální identifikátory, vazba DNS a E.164), z roku 2006 je verze 6 s
vylepšeným zálohováním (hot standby) a poslední verze 7 je z roku 2009.
H.323v1 byla uvolněna v únoru 1996 jako Vizuální telefonní systém a zařízení pro LAN bez
poskytování garantované kvality služeb. Jedna z prvních implementací se objevuje v MS Windows
pod označením NetMeeting. Standard specifikuje komponenty, protokoly a procedury, které poskytují
služby multimediální komunikace přes paketové sítě. První verze neřeší bezpečnost a má problém s
vyjednáváním médií během sestavování spojení, později tato vlastnost dostává název Slow-Start.
H.323v2 je z roku 1998 a název standardu se mění na Paketově založené multimediální
komunikační systémy. Novými změnami jsou:
•
•
•
•
•
•
•
Fast Connect, metoda navazování spojení (Fast Start pole v Q.931),
Supplementary services H.450.x – doplňkové služby předání hovoru (Call Transfer) a
přesměrování volání (Call Diversion),
H.235, bezpečnost, definice bezpečnostních profilů, šifrování a kryptotokenů,
tunelování H.245, není nutné otevírat nové TCP spojení, celá H.245 se dá přenést v
Q.931,
overlap, metoda volby číslo po čísle,
empty capability set, zjednodušení restartu H.245,
alias adresy (URL, email),
15
•
•
•
•
RIP (znovunastavení expirace zasílání požadavků, pokud je nutný čas, např. V
mezizónové komunikaci),
TTL, doba vypršení registrace,
alternate GK, záložní GK (cold standby) vykryje výpadky primárního GK,
RAS QoS (EP mohou indikovat schopnost rezervace zdrojů).
H.323v3 v následujícím roce 1999 reaguje především na zoufalé naléhání vývojářů na zmenšení
obsáhlosti doporučení, neboť nejsou schopni plně implementovat celý H.323 stack, který je nesmírně
rozsáhlý a robustní, přichází nová vylepšení:
•
•
•
Simple Endpoint Terminal (SET) definovaný v Annex F, což je ořezaná H.323 pouze pro
audio, objevuje se řada výrobců HW telefonů s H.323,
H.450.x – přidržení hovoru, parkování, převzetí volání, indikace čekající zprávy a
čekajícího hovoru (call hold, call park, pickup, MWI, call waiting),
H.341 – MIB (Management Information Base) pro SNMP, je možné přes SNMP provádět
základní správu H.323, vyčítat stavy a provádět dohled.
H.323v4, opět po roce další verze (rok 2000) a ta přináší především:
•
•
•
•
•
•
•
dekompozice brán (GW), návaznost a podpora ITU-T H.248 (MG a MGC),
H.450.x – identifikace jména, zpětné volání, poklepání do hovoru, vstup do hovoru (name
identification, call completion, call offer, call intrusion),
vylepšení řešení záložního GK, EP indikuje zda-li podporuje procedury pro záložní GK,
sdílení zátěže přes záložní GK,
správa pásma,
transparentní tunelování non-H.323 protokolů jako QSIG a ISUP (SS7),
Fast Connect a H.245 Parallel můžou probíhat současně.
H.323v5 z roku 2003, která přinesla již v začátku kapitoly zmiňované vylepšení podpory URL a
spolupráci s DNS, nejvýznamnějšími přínosy jsou:
•
•
•
•
•
•
•
•
•
nově definovaný generický rámec implementace funkcí GEF (General Extensibility
Framework), ITU-T H.460.1,
přenositelnost čísel,
mapování stavu kanálů,
volání s prioritou,
přenos duplicitních informačních prvků Q.931,
rozšířená metoda FastConnect (změna parametrů H.245 bez uzavření logického kanálu),
QoS dohled a report,
Annex O popisuje použití URL a DNS,
Annex P modemový přenos.
H.323v6 z roku 2006 přináší:
•
•
assigned GK, model přidruženého GK, který umožňuje režim hot standby (H.323 síť při
výpadku GK okamžitě konverguje do provozuschopného stavu s přidruženým GK),
vylepšení H.235 – bezpečnost a SRTP,
16
•
zpoždění navazování spojení (ověření kvality trasy a až potom se sestaví spojení).
H.323v7 z roku 2009 je poslední verzí H.323, novým přínosem je:
•
•
single transmitter multicast , umožňuje otevřít multicast (výhodné např. pro Music on
Hold),
procedura Common Alerting Protocol (CAP) definuje nové zprávy pro použití v nouzové
komunikaci, umožňuje rozesílat nouzové zprávy a varování
Situace ve studijní skupině SG 16, která stojí za H.323 je nejasná, v roce 2007 byl oznámen
vývoj nového protokolu H.235, který by měl nahradit SIP i H.323 a měl by být použit v sítích NGN.
Jeho uvolnění bylo oznámeno na rok 2009, ale zprávy o postupu prací nelze najít a domnívám se, že
organizace ITU-T se smířila s faktem, že pro NGN byl vybrán SIP a sdružení IETF bylo úspěšnější.
Nelze říct, že v IETF byl vyvinut lepší protokol pro multimediální komunikaci, SIP uspěl díky své
jednodušší koncepci, otevřenosti a vůli vývojářů se dohodnout. Vývoj aplikací na SIPu je sice levnější,
ale má evidentně větší problémy v interoperabilitě, které se i více než deset let po jeho uvedení stále
vyskytují a řeší.
2.3
Koncepce komunikace v H.323
Hovor je přenášen na RTP/RTCP protokolech. RTP přenáší konkrétní hovor a RTCP přenáší
stavové a řídící informace. Signalizace, s výjimkou RAS, je přenášena spolehlivě přes TCP.
Následující protokoly se zabývají signalizací:
•
•
•
RAS -řídí registraci, přistup a stav,
Q.931 -řídí nastavení volání a jeho ukončení,
H.245 -určí využití kanálu a jeho kapacitu.
Následující protokoly zajišťují v rámci H.323:
•
•
H.235 -zabezpečení a identifikace,
H.450 -doplňkové služby.
V případě H.323 jsou signalizační informace k hovoru dány doporučením H.225.0, které využívá
obou protokolů UDP i TCP, standardně řídící prvek sítě (Gatekeeper) naslouchá signalizaci
H.225.0/RAS na portu UDP 1719 a případně i na 1718 (pro multicast 224.0.1.41, povoleno pro
zprávy GRQ a LRQ), hovorová signalizace spojení H.225.0/Q.931 se přenáší na portu TCP 1720.
Navíc je tu další část signalizace dle ITU-T H.245 pro vyjednávání parametrů audia/videa, která je
postavena na TCP, od verze H.323v2 je pomocí metody Fast Connect schopná většinu informací
přenést v H.225.0/Q.931.
17
2.3.1
Protokolový model H.323
H.323 protokoly jsou zobrazeny na obr. 2.2. Všechny H.323 terminály musí podporovat audio.
Podpora pro video a data jsou volitelné. Ve třetí verzi H.323 byl specifikován terminál SET (Simple
endpoint Terminal), který je zredukovanou verzi audio terminálu H.323.
Pro řízení spojení jsou důležité tři protokoly:
•
•
•
RAS (Registration, Admission and Satus) je komunikační protokol pro Gatekeeper (dále
jen GK), pokud jakékoliv zařízení (terminál, brána, další gatekeeper) komunikuje s GK,
tak používá RAS zprávy,
H.225.0/Q.931 protokol v H.323 je nazýván jako signalizace volání (Call signaling) a
obsahuje zprávy pro inicializaci i ukončení spojení (SETUP, ALERTING, CONNECT,
RELEASE COMPLETE, atd..), koncepce byla převzata z ISDN,
H.245 je označován jako protokol řízení médií (media control), obsahuje procedury pro
vyjednání kodeků a portů pro RTP toky, pro každý směr zvlášť.
Obr. 2.2 Protokolový model.
Jak jsme si již vysvětlili v předchozí kapitole, nezbytnou součástí H.323 audio terminálu je
vyrovnání zpoždění doručovaných RTP paketů, neboť jitter by znemožnil kontinuální dekódování.
Maximální velikost zpoždění mezi odesílatelem a příjemcem je 150 ms, což je podmínka pro spojení
s vysokou kvalitou, rozsahy zpoždění definuje ITU-T G.114.
2.3.2
Prvky H.323 a jejich vlastnosti
Na obr. 2.3 jsou vyobrazeny komponenty v H.323. Prvky sítě H.323 tvoří koncové body EP
(endpoints) a řídící prvky GK (gatekeepers). Množina EP registrovaná ke stejnému GK tvoří zónu,
zónu můžeme chápat jako logickou oblast spravovanou GK, v jedné zóně nemůžeme provozovat
více GK. Existuje způsob zálohování GK, kdy více GK se může postarat o EP, ovšem veškeré EP
18
jsou přihlášeny vždy v danou chvíli jen k jednomu GK. Zálohování je prováděno na principu
přeregistrace EP a replikací směrovacích tabulek, které více GK sdílí mezi sebou. Kupříkladu
budeme mít dva identické GK, jeden v Praze, druhý v Ostravě, EP geograficky náležející Moravě
budou přihlášeny na GK v Ostravě, zbytek bude registrován na pražském. Oba GK si mezi sebou
synchronizují směrovací informace (sousední GK a hlasové brány k výstupu z H.323 sítě). V případě
vypnutí ostravského, pošle tento GK všem EP v jeho zóně požadavek na přeregistrování do Prahy.
Pokud by došlo k nekorektnímu vypnutí a GK by už neměl možnost komunikovat EP, tak i na to je
pamatováno, jelikož už při první registraci EP na GK, je předán list s alternativními GK seřazenými
dle priorit, pro případ výpadku. Protože registrace EP na GK platí omezenou dobu, tak je zajištěno,
že mrtvá zóna vždy nakonec zkonverguje do jiné, pokud má ovšem kam.
Obr. 2.3 Komponenty H.323.
H.323 infrastruktura je logicky rozdělena do zón. Zóna je množina zařízení řízených jedním GK.
V H.323 rozeznáváme následující komponenty:
•
•
Endpoint (koncový bod, zařízení), tím může být MCU, brána GW nebo terminál TE,
Gatekeeper (řídící prvek sítě),
MCU (Multipoint Control Unit) je multikonferenční jednotka, která má za úkol podporovat
konference mezi 3 nebo více koncovými body, jde zpravidla o nejdražší část sítě, byť nepovinnou.
Podstatnou výhodou MCU pro audio je, že umí transkódování, čili propojit terminály i s různými
kodeky. MCU obsahuje řídící jednotku MC (controller) a procesorovou jednotku neboli audio mixér
MP (media processor).
GW (Gateway) je brána zajišťující propojení s telefonní sítí, obsahuje tedy zpravidla navíc ISDN
rozhraní (případně jiné) a DSP procesory pro podporu více kodeků, dle výkonu, kapacity, typu
rozhraní a podporovaných kodeků se odvíjí i cena.
TE (Terminal) je typické koncové zařízení, buď je realizováno na bázi SW pro Windows/Linux
(softphone) anebo jako HW terminál (IP telefon), trh je poměrně dobře zásoben stovkami typů IP
19
telefonů, cena pochopitelně záleží na výkonu zařízení (implementované funkce, podpora kodeků,
NAT, 802.1Q, diffserv, napájení 803.af, miniswitch uvnitř, apod..).
Gatekeeper je řídicím prvkem H.323 koncových bodů (terminal, gateway, MCU). Dle standardu
H.323 musí zajišťovat následující:
•
•
•
•
•
•
podpora signalizace RAS (Registration/Administration/Status). Pomocí signalizace RAS se
realizuje řízení přístupů k prostředkům sítě,
řízení přístupu (Admission Control), zajišťuje autorizovaný přístup pomocí zpráv
ARQ/ACF/ARJ (Admission Request/Confirm/Reject) definovaných v signalizaci RAS
(Registration, Admission and Status Signaling),
překlad adres (Address Translation) mezi E.164 číslem a IP síťovou adresou. Překlad na IP
adresy koncových bodů z přijatých adres typu „alias“ (jmeno@domena) nebo
„E.164“ (standardní tel.č.),
řízení přidělování kapacity pásma (Bandwidth Control). Řízení pásma dle požadavků z
koncových bodů pomocí zpráv BRQ/BCF/BRJ signalizace RAS,
řízení spojení (Call Control), zpracování zpráv nebo jejich směrování,
řízení zón (Zone Management), zajišťuje řídicí funkce pro všechny registrované koncové body
H.323 zóny. Koncové terminály a VoGW jsou rozděleny do zón, které představují
distribuovanou strukturu GK.
Dále GK obvykle podporují autorizaci volání (Call authorization). Autorizace jednotlivých volání
se provádí dle identifikačních kódů a umožňuje zavést hovorový kredit. GK může zajišťovat Least
Cost routing, optimalizaci směrování cestou nejnižších nákladů a možnosti nastavení záložního GK
(standby GK).
2.3.3
Signalizace RAS
RAS signalizace zajišťuje řídicí funkce spojení v H.323 sítích. Kanál RAS je sestavován mezi
koncovými body a GK. Nalezení GK probíhá z H.323 koncových bodů sítě automaticky nebo
manuálně. Manuální způsob spočívá v pevném nastavení IP adresy, automatické vyhledání vyžaduje
mechanizmus známý jako auto discovery. UDP discovery port je 1718 a GK UDP registrační port je
1719. Pomocí zpráv multicast je vyhledán GK na IP adrese 224.0.1.41. RAS zpráv jsou následující:
•
•
•
•
•
•
•
•
GRQ/GCF/GRJ Gatekeeper Request/Confirm/Reject,
RRQ/RCF/RRJ Registration Request/Confirm/Reject,
URQ/UCF/URJ Unregister Request/Confirm/Reject,
ARQ/ACF/ARJ Admission Request/Confirm/Reject,
IRQ/IRR Information Request/Request Response, Status,
LRQ/LCF/LRJ Location Request/Confirm/Reject,
BRQ/BCF/BRJ Bandwidth Request/Confirm/Reject,
DRQ/DCF/DRJ Disengage Request/Confirm/Reject.
Následující obr. 2.4 znázorňuje mechanizmus navázání spojení přes RAS signalizaci, hlasové
brány VoGW-A a VoGW-B se při startu registrují ke GK, kde předají svou IP adresu, H.323 Id
(identifikaci typu alias) a prefix Id (identifikaci typu E.164). GK zapíše tyto informace do směrovací
tabulky. Registrace má obvykle omezenou platnost a je vyžadováno její obnovování, pokud EP tak
nečiní, tak GK si opětovnou registraci vyžádá. Pokud je z VoGW-A vysláno na GK číslo, které
20
obsahuje řetězec začínající prefixem Id VoGW-B, potom GK ve zprávě ACF (Admission Confirm)
vrací příslušnou IP adresu a zprávy signalizace Q.931 jsou přenášeny přes H.225 protokolem TCP.
H.245 otevírá logický kanál pro řízení spojení a vlastní hovor je již přenášen protokolem RTP. Během
spojení GK monitoruje zprávou Status Enquiry, zda je spojení ještě aktivní. Při ukončení spojení
musí proběhnout ukončení logického spojení (H.245) a následně se mezi GK a koncovým bodem
vyměňují zprávy DRQ/DCF (Disengage Request/Confirm).
Obr. 2.4 Mechanizmus navázání spojení pomocí RAS signalizace.
Podstatnou výhodou signalizace RAS je dynamické přihlášení koncového bodu na GK.
Jednotlivé terminály a VoGW se autorizují na GK při zapnutí zařízení a není zapotřebí udržovat
statické tabulky. Přidání dalšího zařízení do zóny H.323 spočívá ve správném nakonfigurování
koncového bodu (nastavení autorizace na příslušném GK) a řídicí prvek H.323 zóny aktualizuje
údaje o spravovaných koncových zařízeních. Pro automatické nalezení koncového bodu H.323 zóny
jsou v RAS definovány tři zprávy GRQ/GCF/GRJ, což je Gatekeeper Request/Confirm/Reject. Při
registraci jsou v RAS definovány zprávy:
•
•
RRQ/RCF/RRJ - Registration Request/Confirm/Reject, viz. obr. 2.5
URQ/UCF/URJ -Unregister Request/Confirm/Reject.
Registrace proběhne po vyhledání před uskutečněním volání. Po úspěšné registraci získá GK
informace o H.323 koncovém bodu IP sítě (IP adresa, alias) a koncový bod může využívat zónu GK,
obr. 2.5. Ze zachycené zprávy RRQ je možné vyčíst, že EP je dosažitelný pod IP 192.168.1.10 na
portu 1164, kam mu může být zaslána zpráva SETUP. Terminál si registruje h323 jméno 950012305
a číslo 950012305, registraci navrhuje na 120 sec. Nakonec terminál připojí autentizační řetězec v
21
CryptoToken jako hash získaný pomocí MD5 a prozradí i některé vstupní parametry jednosměrné
hashovací funkce, ačkoliv ten nejdůležitější (heslo) tají, uživatelské jméno a heslo je uloženo v
útrobách terminálu.
Obr. 2.5 Průběh registrace na GK.
Gatekeeper srovná zaslaný autentizační řetězec s vlastním výsledkem výpočtu MD5 funkce
(pochopitelně musí znát všechny parametry do funkce vstupující) a pokud sedí, tak uživatel je
úspěšně autentizován a registraci potvrdí v RCF, případně upraví dobu registrace. Zachycená
zpráva RRQ:
H.225.0 RAS
RasMessage: registrationRequest (3)
callSignalAddress: 1 item
Item 0
Item: ipAddress (0)
ipAddress
ip: 192.168.1.10 (192.168.1.10)
port: 1164
terminalAlias: 2 items
Item 0
Item: h323-ID (1)
h323-ID: 950012305
Item 1
Item: dialedDigits (0)
dialedDigits: 950012305
timeToLive: 120
cryptoTokens: 1 items
Item 0
Item: cryptoEPPwdHash (0)
cryptoEPPwdHash
22
alias: h323-ID (1)
h323-ID: 950012305
timeStamp: Aug 19, 2008 19:13:09.000000000
token
algorithmOID: 1.2.840.113549.2.5 (md5)
paramS
hash: 6399514F2CAF26F70AA812383C4F6B12
ARQ/ACF/ARJ znamená Admission Request/Confirm/Reject. Zprávou ARQ požaduje koncový
bod inicializaci spojení, pokud je autorizován, dostává ve zprávě ACF koncovou IP adresu na jejímž
základě může být inicializováno Q.931 spojení mezi koncovými H.323 body IP sítě, obr. 2.6.
Inicializace signalizace volání Q.931 (Call Signaling) začíná odesláním zprávvy SETUP a výměnou
další zpráv Q.931, které nakonec vedou k sestavení spojení. Pokud je volaný IP Phone B registrován
na GK, tak na přijatou žádost o sestavení spojení SETUP odešle ARQ na GK a pokud dostane
potvrzení ACF (jinými slovy, že může volání akceptovat), tak odpovídá zprávou Call Proceeding a
následují další Q.931 zprávy na jejichž konci je sestavení hovoru. Pokud IP phone B není registrován
na GK, tak na SETUP odpovídá bezprostředně a RAS signalizace pochopitelně vůbec u volaného
neprobíhá.
Opět se podíváme do zprávy ARQ zaslanou na GK a vidíme, že terminál 950012305 se
dotazuje na 420596991699 a připojuje CryptoToken, pomocí kterého autorizuje svůj požadavek na
sdělení informace k číslu 420596991699.
Obr. 2.6 Průběh inicializace spojení.
H.225.0 RAS
RasMessage: admissionRequest (9)
admissionRequest
endpointIdentifier: 7254_gk1ext
destinationInfo: 1 item
Item 0
23
srcInfo: 2 items
Item 0
Item: h323-ID (1)
h323-ID: 950012305
Item 1
callReferenceValue: 4096
conferenceID: 56b08f95-7cbf-4345-86d4-e6627b290c8b
0... .... activeMC: False
.0.. .... answerCall: False
callIdentifier
guid: a8f00c6c-7324-ec49-a10e-5b42a4200791
cryptoTokens: 1 items
Item 0
Item: cryptoEPPwdHash (0)
cryptoEPPwdHash
alias: h323-ID (1)
h323-ID: 950012305
timeStamp: Aug 19, 2008 19:13:42.000000000
token
algorithmOID: 1.2.840.113549.2.5 (md5)
paramS
hash: 1E854B3876682FED75E90100082BFB98
Gatekeeper vyřídil kladně požadavek terminálu a odpověděl zprávou Admission Confirm, ve
které nařídil použití modelu gatekeeperRouted (model GRC) a sdělil informace pro signalizaci volání
(IP adresu a port, kam má být terminálem zaslán SETUP jako inicializace volání). Samozřejmě že
Gatekeeper uvedl pro zaslání SETUP sám sebe, neboť vybral model GRC a není naivní, aby
prozradil IP adresu a port protější strany, bude tedy přeposílat zprávy Q.931 jako prostředník a tím
má možnost kontrolovat jejich obsah. Gatekeeper rovněž sděluje terminálu v poli irrFrequency, že
chce dostávat každých 120 sekund hlášení o aktuálním stavu spojení.
H.225.0 RAS
RasMessage: admissionConfirm (10)
admissionConfirm
callModel: gatekeeperRouted (1)
gatekeeperRouted: NULL
destCallSignalAddress: ipAddress (0)
ipAddress
ip: 195.113.222.2 (195.113.222.2)
port: 1720
irrFrequency: 120
Monitorování koncových bodů je prováděno průběžně během spojení zprávami IRQ/IRR, což je
Information Request/Response. Status Enquiry je zpráva, kterou GK používá k ověření, zda je volání
ještě stále aktivní. Řízení pásma předchází sekvence řízení přístupu ARQ/ACF, nicméně šířka
přiděleného pásma může být změněna i během hovoru. K řízení pásma jsou v RAS signalizaci
24
definovány zprávy BRQ/BCF/BRJ, což je Bandwidth Request/Confirm/Reject. Pro ukončení hovoru
se používají zprávy DRQ/DCF/DRJ, což znamená Disengage Request/Confirm/Reject. Pomocí
uvedených zpráv může koncový bod spojení nebo GK vyslat požadavek k ukončení či potvrzení
ukončení spojení, případně odmítnout požadavek na rozpojení.
Další procedura popsaná v RAS signalizaci je určení umístění koncového bodu sítě, viz. obr. 2.7,
jestliže je volání terminováno na koncový bod, který není přihlášen v zóně inicializující spojení.
LRQ/LCF/LRJ znamená Location Request/Confirm/Reject. Zprávou LRQ se posílá požadavek na
E.164 adresu např. v případě, že koncový bod je mimo vlastní zónu GK. Řízení přístupů v H.323 síti
je zajištěno v RAS signalizaci pomocí zpráv ARQ/ACF/ARJ, pokud se podaří vyhledat umístění
volaného, tak je zasláno potvrzení ACF, proto potvrzení ACF logicky následuje až po přijetí LCF.
Obr. 2.7 Průběh inicializace spojení mezi zónama GK.
2.3.4
Signalizace Q.931
Signalizace RAS zajišťuje vždy komunikace čehokoliv s Gatekeeperem, viz.
obr. 2.8,
nevypovídá o tom, zda bylo spojení navázáno, jak dlouho trvalo vyzvánění, z RAS nelze sestavit
záznam o spojení CDR (Call Detail Record).
Standardně se pro RAS používá UDP s cílovým portem 1719 pro unicast, v případě multicastu
pak 1718 (GRQ), pomocí GRQ se dá v síti vyhledat GK. Další signalizací je H.225.0 Call Signalling,
čímž se myslí signalizace volání Q.931. Ta je znázorněna na dalším obr. 2.9. Obsahem této
signalizace jsou zprávy, které slouží k sestavení a ukončení spojení mezi koncovými terminály.
Standardně se používá TCP s cílovým portem 1720. Aby tato signalizace mohla proběhnout, tak
musí být známa cílová IP adresa a Q.931 port, což se zjistí ze zprávy RAS ACF. Přes Q.931 se
25
může v jednom TCP spojení přenášet i signalizace pro média (H.245 tunneling) anebo alespoň část
(H.245 Fast Connect).
Obr. 2.8 Signalizace RAS.
V Q.931 se jedná o výměnu následujících zpráv:
•
•
•
•
•
•
•
•
•
•
•
Setup
Call Proceeding
Alerting
Information
Release Complete
Facility
Progress
Status
Setup Acknowledge
Notify
Connect
Při ukončení spojení se posílá pouze Release Complete na rozdíl od ISDN, kde se posílá
Disconnect, Release a Release Complete, u H.323 je Q.931 přenášena spolehlivým transportním
protokolem TCP, a proto se upustilo od potvrzování přijetí odpovědi. Q.931 nemusí být přenášena
přímo mezi EP, H.323 signalizace umožňuje v zásadě dva režimy:
•
•
DRC, Direct Routed Call signalling, kdy veškerá komunikace kromě RAS jde přímo
mezi koncovými účastníky spojení (IP telefony, bránami),
GRC, Gatekeeper Routed Call signalling, která může být provozována ve více
režimech (přes GK prochází kromě RAS i Q.931 a případně i H.245).
26
Obr. 2.9 Signalizace H.225.0/Q.931.
2.3.5
Signalizace H.245
Pro média je určena signalizace H.245, přenáší se v oddělených zprávách anebo v rámci Q.931
pomocí metody Fast Connect (rychlé navazování spojení). H.245 obsahuje následující důležité
procedury, viz. obr. 2.10:
•
•
•
TCS, Terminal Capability Set, nastavení vlastností terminálů, každá strana poskytne druhé
list preferovaných kodeků s jejich vlastnostmi,
MSD, Master Slave Determination, tato procedura rozhodne, kdo je Master a čí zprávy jsou
tedy směrodatné v případě konfliktu,
OLC, Open Logical Channel, otevření logického kanálu, vybere se kodek i port a bude
otevřeno spojení pro RTP zvlášť pro každý směr.
Výměna zpráv v H.245 probíhá pomocí žádosti a potvrzení (Request, Acknowledge). Při použití
Fast Connect se přenášejí prvky Fast Start uvnitř zpráv SETUP, ALERTING, CONNECT a ty
obsahují parametry vyjednávání spojení, při přihlášení volaného je proto H.245 vždy sestavena a
RTP může přenášet obsah hovoru. Problém u H.323v1 byl ten, že H.245 probíhala odděleně od
Q.931 až po ukončení výměny Q.931, což nebylo šťastné a mohlo docházet k prodlení otevření
kanálu anebo jednostranné slyšitelnosti. Kromě Fast Connect může popsaný problém H.323v1
odstranit i Parallel H.245, která umožní spustit procedury H.245 paralelně s Q.931 a nakonec
tunelovaná H.245, u které se nemusí sestavovat nové TCP, pro odeslání H.245 PDU se může využít
zpráva FACILITY.
27
Obr. 2.10 Signalizace H.245.
Pokud se sestavuje nové TCP spojení pro H.323, tak IP adresa a port H.245 je přenesen ve
zprávě Connect, jak je uvedeno následovně:
Q.931 CONNECT
H245_IP_Address,
H245_Port = Called H245 Port,
q931.call_ref = 50:A4,
h225.t35CountryCode = 0
Otevřením logického kanálu H.245 je umožněno zasílání RTP paketů, pro ukončení H.245 se
jednak uzavře logický kanál a potom celá relace:
•
•
Close Logical Channel, CLC Request, Acknowledge,
End Session Command, ESC Request, Acknowledge.
Pokud během relace dojde ke změně parametrů médií, tak stačí zavřít kanál a otevřít jej znovu s
novými parametry, u H.323v4 je procedura zjednodušena pomocí mechanizmu ExtendedFast
Connect, ten umožňuje modifikaci médií zasláním FastStart prvku s jejich popisem v Q.931.
Odesílání RTP paketů ihned po sestavení logického kanálu se označuje jako Early Media.
2.3.6
Modely spojení DRC a GRC
Na následujících obrázcích jsou znázorněny modely spojení, na prvním obrázku je model DRC,
obrázky jsou převzaty přímo z doporučení H.323. DRC model umožňuje přes GK pouze komunikaci
RAS, vše ostatní probíhá přímo mezi koncovými body spojení. O použitém modelu rozhoduje GK, ve
zprávě ACF je určeno, který model se použije. Koncové zařízení sice může navrhnout typ modelu,
ale GK definitivně rozhodne.
28
Obr. 2.11 Model DRC.
Na druhém obrázku 2.12 je model GRC, u modelu GRC jde H.225.0 vždy přes GK, ale v
tomto modelu můžeme ovlivnit i cestu H.245 a RTP.
Obr. 2.12 Model GRC.
29
Signalizace v módu GRC může být tedy provozována následovně:
•
•
•
GRC bez H.245 (H.245 i RTP probíhají přímo mezi EP),
GRC včetně H.245 (H.245 je směrována přes GK, ale RTP přímo mezi EP),
a Proxy režim, kdy vše je směrováno přes GK včetně RTP, podmínkou je, že GK obsahuje
RTP Proxy, tento režim je výborný pro NAT.
Nejčastěji se používá první režim a H.245 vyjednávající parametry spojení se nechává
proběhnout mezi EP. Poslední režim se používá pro podporu zařízení za NATem, pokud GK zjistí,
že adresa EP je neveřejná, tak pro konkrétní spojení vyžádá Proxy režim. Na uvedeném obrázku
2.12 je režim GRC bez H.245.
2.4
Vybrané scénáře toku zpráv H.323
V této kapitole si ukážeme, jak náročné je sestavit spojení klasickou metodou Slow Start
popsanou H.323v1, viz. obr 2.13.
Obr. 2.13 Scénář se Slow Start.
Další scénář využívá běžně používaných prvků Fast Start (metoda Fast Connect) a nakonec s
tunelováním H.245. Na obr. 2.13 je první navázání spojení pomocí Slow Start. Ve druhém scénáři
na obr. 2.14 je Fast Connect, OLC procedura H.245 je přenášena přes Q.931 a už ve zprávě
Connect proběhlo otevření logického kanálu a pokud by byly použity Early Media, tak RTP výměna
mohla začít, z příkladu je čitelné, že RTP tok se rozběhl, až po ukončení všech procedur H.245.
30
Obr. 2.14 Scénář s Fast Connect
V posledním scénáři na obr. 2.15 je tunelovaná H.245 přes Q.931, kde je zřetelně vidět, jak je
využito zpráv Q.931 a pokud potřebuje H.245 nějakou další Q.931 zprávu, tak se použije FACILITY.
Otevření logického kanálu proběhlo už před zprávou Connect, tzn. před přihlášením volaného a RTP
pakety jsou přenášeny oběma směry, což znamená, že se jedná o Early Media (urychlená média).
Obr. 2.15 Scénář s tunelovanou H.245 a Early Media.
31
2.5
Konfigurace ISDN modulů v Cisco směrovačích
Pro registraci na GK je nutné v Ciscu konfigurovat položky na síťovém rozhraní pod označením
h323-gateway. Během registrace se zasílá GRQ a RRQ se jménem GK jako id (identifikátoru GK) a
brána je registrována s prefixy seřazenými v tech-prefix a s jeho h323-id.
# interface FastEthernet0/0
# ip address 158.196.81.200 255.255.255.0
# h323-gateway voip interface
# h323-gateway voip id OpenH323GK ipaddr 158.196.81.103 1718 priority 100
# h323-gateway voip h323-id gw1vsb
# h323-gateway voip tech-prefix 0
V případě použití GNU GK je název GNU GK zadán v sekci Main v souboru /etc/gatekeeper.ini ,
kde musí být stejné id GK jako v Cisco GW.
[Gatekeeper::Main]
Name=OpenH323GK
Pro registraci na SIP serveru se nekonfigurují položky pod síťovým rozhraním ale globálně.
# sip-ua
# authentication username jmeno heslo
# sip-server dns:asterisk.vsb.cz
# anebo sip-server ipv4:158.196.81.205
Pomocí IOS příkazů gateway a no gateway můžeme provést zaregistrování či odregistrování
brány a pomocí show gateway zjistit aktuální stav registrace.
# show gateway
H.323 ITU-T Version: 4.0 H323 Stack Version: 0.1
H.323 service is up
Gateway gw1vsb is registered to Gatekeeper OpenH323GK
A konečně se dostáváme ke konfigurací ISDN rozhraní na Cisco GW. Nejdříve několik globálních
nastavení, které je vhodné minimálně zkontrolovat. Co se týče nastavení v sekci voice, tak je to
ověření, že je zapnutý příjem i vysílání RTP a v podsekci voip, že je zakázán H.245 caps režim, bez
něj může být problém s dokončením vyjednání H.245, jelikož Cisco nechává nepotvrzenou H.245 pro
detekci DTMF, tónů a faxu, s touto vlastností mají produkty třetích stran většinou potíže.
# voice rtp send-recv
# voice service voip
# h323
# h245 caps mode restricted
32
Dále je nutné na voice portu nastavit české kontrolní tóny, evropskou kompresní křivku pro PCM
A-law a jako výchozí bearer-capability doporučuji 3100Hz.
# voice-port 0/0
# compand-type a-law
# cptone CZ
# bearer-cap 3100Hz
2.5.1
Příklad nastavení BRI
Následující nastavení je pro ISDN BRI na Cisco GW, která je konfigurovaná jako síťová strana,
tzn. k tomu portu můžu připojit koncové zařízení či PBX a nakonfigurovaný port se chová jako
poskytovatel (obdobně jako ISDN BRI veřejného operátora).
# interface BRI0/0
# no ip address
# isdn switch-type basic-net3
# isdn overlap-receiving
# isdn protocol-emulate network
# isdn layer1-emulate network
# isdn incoming-voice modem
# isdn send-alerting
# isdn sending-complete
# isdn static-tei 0
# isdn skipsend-idverify
/*identifikace rozhraní
/* basic-net3 znamená BRI s DSS1
/* basic-qsig znamená BRI s QSIG
/* schopnost přijímat číslo po čísle
/* L3 v režimu strany poskytovatele
/* L1/L2 v režimu poskytovatele
/* s příchozím volání je nakládáno jako s modemem
/* bude posílat ALERTING
/* pošle volbu v bloku
/* TEI=0 pro konfiguraci Point to Point
/* nebude verifikovat TEI
Pro stranu uživatele se změní několik položek. K tomuto rozhraní můžeme připojit ISDN BRI z
veřejné sítě.
# isdn protocol-emulate user
# isdn layer1-emulate user
# no skipsend-idverify
2.5.2
/* L3 je provozován v režimu strany uživatele
/* zašle TEI verifikaci v režimu PMP
Příklad nastavení PRI
Následující nastavení je pro ISDN PRI na Cisco GW, nejdříve nakonfigurujeme E1 kontroler.
# controller E1 1/0
# clock source line primary
anebo # clock source internal
# pri-group timeslots 1-31
/* L1 – synchronizace hodin z PCM traktu
/* interní zdroj časování
33
Následně můžeme přistoupit ke konfiguraci signalizační části ISDN PRI, která je podobná jako v
přechozím případě a začneme nejdříve stranou sítě, čili konfigurujeme Cisco GW v pozici
poskytovatele.
# interface Serial1/0:15
# no ip address
# isdn switch-type primary-net5
# isdn overlap-receiving
# isdn not-end-to-end 64
# isdn protocol-emulate network
# isdn incoming-voice modem
# isdn send-alerting
# isdn sending-complete
/* primary-net5 znamená PRI s DSS1
/* přepsání rychlosti, kterou avizuje síť
A pro stranu uživatele postačí změnit jednu položku.
# isdn protocol-emulate user /* interface operates in user side mode
Časovače na ISDN není doporučeno měnit z jejich výchozích hodnot, ale někdy to může prospět
a proto si uvedeme seznam vybraných časovačů.
# isdn overlap-receiving T302
# isdn overlap-receiving terminating-char #
/* T302 timer (v ms) vypršení volby
/* znak konce volby
# isdn t306
# isdn timer t309
/* časovač rozpadu spojení po odeslání zprávy disconnect
/* uvolnění B-kanálu a Call Reference po přerušení či restartu
# isdn t310
/* časovač rozpadu pokusu volání po přijetí Call Proceeding
2.5.3
Pravidla volby čísel a směrů
Abychom s Cisco GW mohli uskutečnit spojení, tak je nutné definovat příchozí volbu z VoIP sítě
do PSTN označovanou jako inbound peers (POTS) a odchozí volbu z PSTN do VoIP označovanou
jako outbound peers (VoIP). Tato konfigurace se provádí v sekci dial-peer voice. Následující
nastavení je pro ISDN PRI na Cisco GW, nejdříve nakonfigurujeme E1 kontroler.
Předpokládejme, že směrovač v tomto příkladu přijímá volání s volbou 59699XXXX z VoIP sítě,
kde XXXX je pobočka a 59699 je prefix. Níže uvedené pravidlo akceptuje řetězec začínající 59699,
za kterým následují čtyři čísla, tyto čísla jsou odeslány do připojené PBX přes port 0/0, což zajišťuje
příznak provolení direct-inward-dial.
# dial-peer voice 1 pots
# destination-pattern 59699....
# direct-inward-dial
# port 0/0
34
T je speciální znak časovače ukončení volby, jehož použití potlačuje čekání na přesný počet
čísel, namísto toho se spustí časovač T302 mezičíslicové pauzy (interdigit timer), po jeho uplynutí je
příchozí číslo považováno za úplné.
# destination-pattern 59699T
Pravidla odchozí volby směrem jsou chápána směrem do VoIP sítě a proto je dial-peer označen
jako voip. Předpokládejme, že potřebujeme nasměrovat na GK všechna čísla začínající 603565, z
PBX tedy přichází do Cisco GW devítimístné číslo, což vyjadřuje 603565... , na posledních třech
číslech nezáleží, GW spáruje takovýto řetězec s pravidlem odchozí volby číslo 20 a směruje volání
na cíl zadaný v session target. Na cíl je posláno celé přijaté číslo 603565... .
# dial-peer voice 20 voip
# destination-pattern 603565...
# codec g711alaw
# session target ras
/* použij tento kodek
/* v případě GK
nebo # session target ipv4:195.113.222.2 /* cíl je specifikován IP adresou (jiná GW)
Pokud je uvedeno session target ras, tak je použita RAS signalizace pro zjištění cílové IP adresy
a portu pro Q.931, což znamená, že RAS je směrován na GK. V případě session target ipv4 není
použita RAS signalizace a odchází se přímo zprávami signalizace Q.931, což značí odeslání zprávy
SETUP a protějším zařízením nemůže být GK nýbrž EP (GW anebo TE).
V praxi potřebujeme mnohdy s čísly manipulovat, různě je překládat, přepisovat, odříznout či
přidat určitou část a k tomu používáme pravidla, která jsou označována jako pravidla překladu čísel
(The Digit Translation Rules). Tato pravidla mohou být užita jak v příchozím, tak i v odchozím směru.
Dosáhneme tedy přepisu CPN (volaného čísla) anebo CLI (čísla volajícího). Přijaté číslo 59699XXXX
bude přeloženo na 42059699XXXX a čísla začínající číslicí 0 na 420, jakýkoliv typ čísla TON (Type
of Number) bude přeložen na typ UNKNOWN.
# translation-rule 1
# Rule 0 ^59699.... 42059699 ANY unknown
# Rule 1 ^0 420 ANY unknown
Popsaná pravidla jsme uložili do pravidel překladu čísel č. 1 a teď je použijeme po směr odchozí
volby číslo 20.
# translate-outgoing called 1
nebo # translate-outgoing calling 1
/* přepsání CPN
/* přepsání CLI
Pokud potřebujeme některé z pravidel použít rutinně, tak abychom je nemuseli zapisovat u
každého směru, tak se nastaví jako globální a v tom případě se zapisují na voice-port , pokud
potřebujeme použít jiné, tak je nastavíme přímo na konkrétní dial-peer.
35
# voice-port 1/0:15
/* the rule placed as a global into voice-port
# translate calling 2
# translate called 4
2.5.4
Třídy kodeků
Skvělým pomocníkem je nastavení třídy kodeků (voice class codec). Tím dosáhneme nastavení
preferencí a přiřadíme třídu pro konkrétní dial-peer. Nastavíme tím seznam položek kodeků, které
budou ve spojení ze strany Cisco GW nabízeny.
# voice class codec 99
# codec preference 1 g711alaw
# codec preference 2 g711ulaw
# codec preference 3 g729r8
Výše uvedeným nastavením byla sestavena třída kodeků č.99 obsahující tři kodeky a tuto třídu
teď přiřadíme na dial-peer voice 20 voip, tím docílíme, že se bude vytvořený list preferencí kodeků
nabízet v odchozím směru č. 20.
# voice-class codec 99
Zcela netypicky se nastavuje kodek pro příchod, a to rovněž v dial-peer voice voip, níže uvedený
příklad bude použit pro všechny příchozí volání s volbou delší než dvě číslice. Doporučuji používat
uvedené pravidlo, neboť výchozím kodekem je u Cisca G.729.
# voice-class codec 99
# incoming called-number ..T
2.5.5
Chybějící kontrolní vyzváněcí tón
Cisco brány jsou velmi spolehlivá zařízení. Pokud se vůbec objeví nějaký problém, tak obvykle
při volání přes Cisco GW volající neslyší kontrolní vyzváněcí tón, ačkoliv příchozí volání úspěšně
vyzvání u volaného. Proto si rozebereme řešení této situace. Důvodem je většinou situace, kdy
strana volaná posílá svůj kontrolní tón v hovorovém kanále (in-band) a volající strana nenaslouchá,
neboť nebyl propojen B-kanál. K nepropojení může dojít z více důvodů, informaci o propojení nese
informační prvek Progress Indicator (PI) a jeho nastavením dokážeme vynutit propojení B-kanálu již
během vyzvánění. Nemusí se jednat pouze o přenos kontrolních tónů, ale i různých ohlášení. PI
můžeme najít ve zprávách ALERTING, CONNECT, PROGRESS nebo DISCONNECT. Kde hodnota
PI=1 nebo PI=8 vyjadřuje přítomnost informace in-band. Můžeme přinutit otevření B-kanálu i přes
SETUP hodnotou PI=3, pokud takovéto PI v SETUPu dorazí na GW, tak to znamená, že je
očekávána informace in-band.
36
Pro Cisco jsou pomocí IOS řešení následující. Prvním krokem by mělo být nastavení globálním
parametrem.
# voice call send-alert
Pokud nastavení nezabralo, tak si vynutíme otevření B-kanálu přepisem PI , předpokladem je, že
kontrolní vyzváněcí tón (kvt) je skutečně v B-kanálu posílán. Tam, kde kvt v B-kanále není zasíláno,
tak naopak může způsobit nefunkčnost, protože přepíše PI a zabrání vygenerování lokálního kvt,
takže příkaz se používá selektivně a taky je možné zkusit nastavit PI pro konkrétní zprávu. Tady platí,
že měníme co nejméně, přepisy PI jsou dost tvrdým zásahem do signalizace.
# voice dial-peer 1 pots
# progress_ind alert enable 8
# progress_ind progress enable 8
# progress_ind connect enable 8
# progress_ind setup enable 3
Jestliže ani přechozí nastavení nepomohlo, tak přichází zaručený recept v podobě vynucení
lokálního generování kvt.
# voice dial-peer 20 voip
# progress_ind setup enable 3
nebo # tone ringback alert-no-pi
2.6
Diagnostika na hlasové bráně
Pokud se chceme přesvědčit zda Cisco GW je připravena a ISDN je v dobré kondici, tak
použijeme příkaz show isdn status a dostaneme odezvu, kde zkontrolujeme, zda je aktivní vrstva L3.
Pokud není, tak hledáme problém na L2, praxe je taková, že většina chyb je na L1, takže pokud
nevidíme aktivní první vrstvu, tak jdeme prověřit vedení. Vyplatí se mít po ruce LED diodu pro
testování fyzické vrstvy PRI, tímto nejlevnějším testerem lze rychle zjistit, na kterých párech jsou
vysílače obou propojovaných stran a hlavně, zda vysílají.
ISDN Serial1/0:15 interface
******* Network side configuration *******
dsl 0, interface ISDN Switchtype = primary-net5
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
Layer 3 Status:
0 Active Layer 3 Call(s)
Active dsl 0 CCBs = 0
The Free Channel Mask: 0xFFFF7FFF
Number of L2 Discards = 0, L2 Session ID = 1
Total Allocated ISDN CCBs = 0
37
Následně byl zachycen průběh signalizace na ISDN rozhraní mezi Cisco GW a PBX, a to na L3
příkazem debug isdn q931. Tučně jsou zvýrazněny zajímavé partie signalizace. Ze zprávy SETUP
vyčteme, že je číslo voleno v bloku a kompletní, jedná se o nosnou službu 3,1 kHz Audio a je
použitý první kanál z ISDN PRI, samozřejmě v SETUP najdeme číslo volajícího a volaného.
C2651-VoGW-OV#
Aug 19 19:06:23.024: ISDN Se1/0:15 Q931: TX -> SETUP pd = 8 callref = 0x5D9D
Sending Complete
Bearer Capability i = 0x9090A3
Standard = CCITT
Transfer Capability = 3.1 kHz Audio
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98381
Exclusive, Channel 1
Progress Ind i = 0x8183 - Origination address is non-ISDN
Display i = 'Voznak Mobil'
Calling Party Number i = 0x0180, '420596997002'
Plan:ISDN, Type:Unknown
Called Party Number i = 0x81, '1699'
Plan:ISDN, Type:Unknown
Aug 19 19:06:23.128: ISDN Se1/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0xDD9D
Channel ID i = 0xA98381
Aug 19 19:06:23.476: ISDN Se1/0:15 Q931: RX <- ALERTING pd = 8 callref = 0xDD9D
Progress Ind i = 0x8088 - In-band info or appropriate now available
Aug 19 19:06:43.544: ISDN Se1/0:15 Q931: RX <- CONNECT pd = 8 callref = 0xDD9D
Aug 19 19:06:43.552: ISDN Se1/0:15 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x5D9D
Další zprávou Call Proceeding byla strana inicializující volání informována o zpracování
požadavku na sestavení spojení. Ve zprávě ALERTING se volající strana dozvídá jednak, že u
volaného začal vyzvánět telefon a jednak dostává v PI informaci o zaslání in-band informace, což je
jistě kontrolní vyzváněcí tón a je nutné ho naslouchat na B-kanálu. Nakonec při přihlášení volaného
je přijat CONNECT, který je potvrzen CONNECT_ACK.
Dále byl zachycen rozpad spojení, jelikož požadavek DISCONNECT byl vyslán (TX), tak
spojení ukončila strana volající standardní cestou a rozpad je dovršen přijetím RELEASE a
potvrzením RELEASE_COMPLETE.
Aug 19 19:06:58.844: ISDN Se1/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x5D9D
Cause i = 0x8290 - Normal call clearing
Aug 19 19:06:58.992: ISDN Se1/0:15 Q931: RX <- RELEASE pd = 8 callref = 0xDD9D
Aug 19 19:06:59.000: ISDN Se1/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x5D9D
C2651-VoGW-OV#
38
Poslední příklad ukazuje odchozí spojení z PBX přes CiscoGW, což je indikováno jako RX
SETUP, čili zpráva SETUP byla přijata na E1 rozhraní (z PBX) a obsahovala opět kompletní volbu,
viz. Sending Complete, po čtyřech vteřinách od odeslání přišla zpráva o vyzvánění a od té chvíle
dostával volající kontrolní vyzváněcí tón, po dalších 4 vteřinách bylo volání přijato volaným, což
indikuje zpráva CONNECT. Spojení bylo ukončeno volající, účastníkem na pobočkové ústředně, což
je indikováno odesláním žádosti o rozpojení DISCONNECT.
C2651-VoGW-OV#
000160: Dec 30 16:41:55.988: ISDN Se1/0:15 Q931: RX <- SETUP pd = 8 callref = 0x0011
Sending Complete
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA9839A
Calling Party Number i = 0x0083, '3683'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x80, '603565965'
Plan:Unknown, Type:Unknown
High Layer Compat i = 0x9181
000161: Dec 30 16:41:56.088: ISDN Se1/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x8011
Channel ID i = 0xA9839A
000162: Dec 30 16:42:00.356: ISDN Se1/0:15 Q931: TX -> ALERTING pd = 8 callref = 0x8011
Progress Ind i = 0x8188 - In-band info or appropriate now available
000163: Dec 30 16:42:05.212: ISDN Se1/0:15 Q931: TX -> CONNECT pd = 8 callref = 0x8011
Date/Time i = 0x0D0C1E102A
000164: Dec 30 16:42:05.288: ISDN Se1/0:15 Q931: RX <- CONNECT_ACK pd = 8 callref =
0x0011
C2651-VoGW-OV#
000166: Dec 30 16:42:19.281: ISDN Se1/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x0011
Cause i = 0x8090 - Normal call clearing
000167: Dec 30 16:42:19.289: ISDN Se1/0:15 Q931: TX -> RELEASE pd = 8 callref = 0x8011
000168: Dec 30 16:42:19.385: ISDN Se1/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref =
0x0011 Cause i = 0x8090 - Normal call clearing
C2651-VoGW-OV#
Za povšimnutí rovněž stojí, že všechny přijaté zprávy GW z PBX mají shodný Call
reference ”callref = 0x0011” a odchozí odeslané GW do PBX ”callref = 0x8011” a byl použit TSL 26
(timeslot) 32-kanálové E1 ”Exclusive, Channel 26”. Podle Call reference najdu zprávy týkající se
jednoho spojení a v případě silně zatížené GW, kde probíhají desítky volání současně lze očekávat
poměrně slušný provoz zpráv z různých kanálů a je nutné najít nejdříve konkrétní Call reference,
podle kterých můžou býti zprávy analyzovaného spojení dohledány.
39
Výše zmíněná nastavení byla prakticky ověřena v rálném nasazení (autor stál u zrodu
akademické VoIP sítě v ČR postavené na Cisco technologii), ale je nutné vzít v potaz, že s dalšími
verzemi IOS byly možnosti ještě rozšířeny.
2.7
GNU Gatekeeper
GNU Gatekeeper je open-source projekt, který vznikl v roce 2001, jedná se o svobodný software
šířený pod licencí GNU GPL. Nejznámějším gatekeeperem je bezesporu GNU GK, jedná se o plně
H.323 kompatibilní gatekeeper (dále jen GK) dostupný na stránkách projektu http://www.gnugk.org
a použitelný pod licencí GPL. GNU GPL dovoluje aplikaci kopírovat, distribuovat, prodávat nebo
modifikovat, ale veškerá činnost musí být opět pod GPL, což znamená, že k případně provedeným
úpravám původního kódu musí být dodán i modifikovaný zdrojový kód. Aktuálně je aplikace v ostré
verzi 3.5 z roku 2014, během jednoho roku může být vydáno i několik verzí. GNU GK je úspěšný
projekt a existuje řada sítí, které jsou postaveny na GNU GK. V akademické komunitě je to např.
GDS (Global Dialing Scheme), což je síť pro videokonference a telefonii, projekt vznikl původně na
anglických univerzitách a postupně byl rozšířen po celém světě.
Obr 2.16 Logo projektu GnuGK
Současným koordinátorem projektu GNU GK (dále jen GnuGK) je Jan Willamowius. Jelikož se
jedná o open-source projekt, je možné se do samotného vývoje případně testování osobně zapojit.
GnuGK gatekeeper je velmi stabilní, proto je komerčně využíván mnoha organizacemi poskytujícími
VoIP služby. Autoři projektu poskytují GnuGK pro operační systémy: Linux, Windows, FreeBSD,
Solaris a MacOS X. Pod operačním systémem Windows může GnuGK běžet jako služba v pozadí.
GnuGK nabízí mnoho užitečných funkcí, jako např. flexibilní směrování hovorů, široké možnosti
autentizace a autorizace, plnou podporu H.323 proxy a NAT a rovněž H.235 bezpečnostních
mechanizmů. Vývojáři také postupně implementují nové funkce dle požadavků uživatelů. GnuGK je
možné dále rozšířit o grafické uživatelské prostředí usnadňující práci s gatekeeperem nebo možnost
vytvořit aplikaci call-centra. Stává se nedílnou součástí systémů pro IP telefonii, založených na
standardu H.323. Velká výhoda je vzájemná kompatibilita GnuGK gatekeeperu s řadou zařízení pro
VoIP služby. Na uvedené webové stránce projektu GnuGK je možné získat více informací o projektu,
procházet diskuze týkající se podpory, nalézt konfigurační tipy a ukázkové konfigurace, získat
samotný gatekeeper a přehledně zpracovaný manuál.
Implementace GnuGK vychází z knihoven projektu openh323 dostupného na stránkách
http://www.openh323.org , kde je rovněž ke stažení GK pro Linux i Windows pod názvem OpenGK,
ale nejedná se o GnuGK, nýbrž o projekt odlišný a OpenGK nedosahuje možností GnuGK
dostupného na http://www.gnugk.org . Implementaci H.323 přináší i Asterisk v podobě oh323 či
40
ooh323 kanálu a je možné propojit řešení GnuGK s Asteriskem, kterému je věnována kapitola
zabývající se otevřeným řešením pro SIP.
Příkladem nejrozsáhlejšího nasazení GnuGK v ČR je síť sdružení vysokých škol CESNET2 [v55].
V současné době je v rámci IP telefonie sdružení CESNET2 přihlášeno zhruba padesát hlasových
brán (dále jen VoGW), které jsou registrovány k vnitřním GK na platformě Cisco. K těmto VoGW jsou
připojeny pobočkové ústředny institucí (dále jen PBX), které mohou volat v rámci sítě CESNET2 a
subjekty mohou využívat i výstupu do veřejné sítě přes ČVUT. Sdružení CESNET byl přidělen
přístupový kód do neveřejné sítě sdružení ve tvaru 4209500. Na GNU GK je provozován národní
gatekeeper akademické sítě v ČR, který je zapojen jak do další mezinárodní struktury hierarchického
směrování (GDS), tak slouží pro připojení jiných GK. Doménové jméno národního GK je
gk1ext.cesnet.cz . Téměř všechny univerzity v ČR mají k síti CESNET2 připojeny své pobočkové
ústředny a GnuGK se uplatňuje jako hraniční Gatekeeper, je využíván pro peering se zahraničními
institucemi a kromě komunikace s interními GK spravuje číselný plán s prefixem 9500. Například v
roce 2005 bylo v síti CESNET2 pomocí technologie VoIP uskutečněno zhruba 1,5 mil. hovorů. Bližší
informace k projektu GnuGK na Cesnetu lze najít na stránkách projektu http://www.cesnet.cz a v
dalších publikacích [v50], [v67], [sir].
2.7.1
Instalace a konfigurace GnuGK
Předpokládejme, že pro otestování postačí zavolat mezi dvěma H.323 koncovými body a k tomu
nám postačí nějaká aplikace H.323 klienta, použijeme např. YATE, který stáhneme ze stránek
http://yate.null.ro anebo SPRANTO http://www.spranto.com/. S GnuGK budeme pracovat
v linuxovém prostředí, jelikož autor pracuje s distribucí Debian, tak je nutné vzít v potaz, že instalace
např. v Ubuntu bude nutné uvést příkazy vzhledem k uživatelským právům pomocí sudo a v případě
CentOS namísto apt-get se použije yum, apod. Nejdříve zjistíme, zda je balíček s gnugk dostupný a
potom nainstalujeme. Během instalace vidíme, jaká verze je instalována.
# apt-cache search gnugk
# apt-get install gnugk
Konfigurace GnuGK je uložena v souboru etc/gatekeeper.ini a za běhu GK se dá měnit přes
telnet přístupem na port 7000 telnet localhost 7000, to je standardní nastavení. Pro znovunačtení
konfigurace za běhu slouží příkaz reload, jinak při spuštění aplikace se vždy načítá nastavení z
inicializačního souboru gatekeeper.ini. Pokud někomu nevyhovuje editace inicializačního souboru,
tak může používat grafické rozhraní GnuGK Control Center, což je shareware program dostupný na
http://www.gnugk-cc.com/ . Obsahem souboru gatekeeper.ini jsou hodnoty parametrů v jednotlivý
sekcích, název sekce je v hranatých závorkách, pokud je jakýkoliv řádek uvozen středníkem, tak
není brán v potaz. Nejdříve bychom měli do gatekeeper.ini vepsat základní část konfigurace.
[Gatekeeper::Main]
Fourtytwo=42
Name=gk1ext
Home=195.113.113.131
TimeToLive=300
41
Hodnota 42 prvního parametru je údaj, kterým je zkontrolována přítomnost konfiguračního
souboru, do parametru Name zapíšeme název GK dle libosti a tento název se objevuje v některých
RAS zprávách, dále následuje IP adresa GK a poslední parametr je expirační čas registrace
přihlášeného koncového H.323 prvku na GK v sekundách.
GnuGK umožňuje čtyři režimy volání, jedná se o režim DRC (Direct Routed Call), GRC
(Gatekeeper Routed Call) pouze s H.225.0/Q.931, GRC včetně H.245 a režim Proxy. V režimu DRC
zpracovává GnuGK pouze RAS zprávy, veškerá komunikace se odehrává přímo mezi EP. Pokud je
povolen režim GRC, tak lze nastavit směrování signalizace H.225.0/Q931 a H.245 přes GK.
Nastavení se provede v sekci [RoutedMode]. Nastavuje se parametry GKRouted na hodnotu 0
(vypnuto) nebo 1 (zapnuto) a H245Routed opět pomocí dvou hodnot. Položku CallSignalPort pro
Q.931doporučuji posunout na typický port 1720.
[RoutedMode]
GKRouted=1
H245Routed=0
CallSignalPort=1720
Pokud je zapnut třetí režim GRC, tak může být povolen i Proxy režim, vše přes GK, pokud se
zadá v sekci [Proxy] volba Enable a hodnota 1.
[Proxy]
Enable=1
2.7.2
Registrace EP
Registrace EP (Endpoint - H.323 telefon nebo H323 brána) je na GnuGK časově omezená.
GnuGK vrací při registraci každému EP dobu platnosti registrace ve zprávě RFC (Registration
Confirm), která je zapsána v poli timeToLive. Po vypršení této doby je registrace zrušena. Každý EP
by měl svou registraci periodicky obnovovat zasíláním RRQ (Registration Request), je povoleno i
obnovování pomocí lightweight RRQ, tzn. pomocí keepAlive bit, to probíhá tak, že před uplynutím
registrace na GK (time to live) zašle EP zprávu RRQ s keepAlive a tím resetuje čítač timeToLive a
registrace je prodloužena. EP může pochopitelně požadovat i menší čas timeToLive ve zprávě RRQ,
než má GNU GK jako výchozí. Aby nedošlo k zahlcení GNU GK RRQ zprávami, tak GK vrací jako
nejmenší limitní čas pro registraci 60 sekund, ikdyž EP bude požadovat nižší hodnotu. Po expiraci
registrace na GK zašle GnuGK dvě zprávy IRQ (Information Request), kterými zjistí, zda je EP
komunikativní a pokud nedostane odpověď zprávou IRR, kterou může být registrace prodloužena,
tak posílá na endpoint URQ (Unregistration Request) s odůvodněním ttlExpired. V této chvíli je
vymazán z databáze aktivních EP na GnuGK a EP musí provést opětovnou registraci pomocí RRQ.
Problém může nastat u registrovaných EP, kteří mění svou IP adresu během doby registrace,
například bezdrátová LAN dle 802.11 a uživatel přemísťující se se softphonem na notebooku nebo s
42
WiFi telefonem. To lze vyřešit tak, že přidáme do gatekeeper.ini další sekci, ve které povolíme
přepisování IP adres registrovaných EP.
[RasSrv::RRQFeatures]
OverwriteEPOnSameAddress=1
Určitě bychom chtěli kontrolovat, jaký EP (Endpoint) se může registrovat na GK. GNU GK
umožňuje jednoduchou metodu autentizace, ověření uživatelského jména a hesla přenášeného v poli
cryptoTokens (hashed by MD5), pričemž uživatelské jméno je vidět transparentně. V GNU GK lze
například zadat, aby probíhala autentizace pouze při registraci na GK. Heslo zadané do sekce
SimplePasswordAuth se získá přes utilitu addpasswd. Ta se spustí z příkazové řádky a mezerami se
oddělí parametry, prvním je název souboru, kam se zapíše výsledek, následuje název sekce, uživatel
a heslo.
addpasswd gnugkpasswd.conf passwd cesnet cesnet
more gnugkpasswd.conf
Oblíbeným editorem nebo příkazem more si prohlídneme výsledek a ten zapíšem do
gatekeeper.ini ve stejném tvaru
[passwd]
cesnet=FVqqGh4sTxE=
Jednotlivé účty řadíme pod sebe do sekce SimplePasswordAuth. Nejdříve ale musíme
specifikovat v sekci Gatekeeper::Auth, které zprávy RAS budeme autorizovat k provedení
autentizace. Uvedený příklad vyžaduje autentizaci při registraci na GnuGK.
[Gatekeeper::Auth]
SimplePasswordAuth=required;RRQ
default=allow
[SimplePasswordAuth]
cesnet=FVqqGh4sTxE=
SW klient, který umí autentizaci je např. YATE, SPRANTO či EKIGA. Pokud máme koncová
zařízení, která neumí autentizaci, tak může být užitečné znát další mechanizmus s názvem Alias
Authorization a spočívá v ověření uživatelského jména a IP adresy ve zprávě RRQ. Můžeme oba
mechanizmy zkombinovat tak, že nejdříve proběhne ověření uživatelského jména a hesla v RRQ
modulem SimplePasswordAuth a pokud autentizace přes tento modul neprojde, tak postoupíme další
pravidlo a tady je už vyžadováno, aby prošlo přes Alias Authorization. Upravíme tedy sekci
Gatekeeper::Auth.
[Gatekeeper::Auth]
SimplePasswordAuth=optional;RRQ
AliasAuth=required;RRQ
43
default=allow
Následně vytvoříme novou sekci RasSrv::RRQAuth, kde je konkrétně vyžadována registrace u
čísla 950012345 z IP adresy 195.113.150.124 s TCP portem 1720.
[RasSrv::RRQAuth]
950012345=sigip:195.113.150.124:1720
default=reject
2.7.3
Propojení GnuGK s jiným GK
Infrastruktura H.323 ovšem bývá složitější, protože potřebujeme volat i mimo svou vlastní zónu
obsluhovanou GnuGK a v tom případě potřebujeme propojení s dalším GK. To je snadné,
potřebujeme znát jeho IP adresu a telefonní čísla, které používá. Přidání sousedního Gatekeeperu
se provádí přes dvě sekce, první RasSrv::Neighbors určuje typ GK a druhá Neighbor už obsahuje
konkrétní konfiguraci.
[RasSrv::Neighbors]
LSU=GnuGK
[Neighbor::LSU]
Host=130.39.252.136
SendPrefixes=1225578
AcceptPrefixes=*
Na vzdálenou zónu, kterou jsme si nazvali LSU (jedná se o univerzitu v Lousianě), jsou posílány
požadavky na spojení začínající čísly 1225578, a to včetně prefixu, z této zóny jsou přijímány
požadavky na vytočení jakéhokoliv čísla.
2.7.4
Statická registrace GW v GnuGK
Často potřebujeme propojení s jiným typem sítě, tak potřebujeme hlasovou bránu VoGW (Voice
Gateway), nejčastěji s rozhraním ISDN PRI nebo BRI. VoGW může být realizována například na
směrovači osazeném příslušným rozhraním pro propojení nebo kartou v PC. Pokud budeme mít v
popisu práce intenzivně šetřit a máme solidní znalosti Linuxu, tak je možné GK i VoGW postavit na
řešení Asterisk, což je doslovně SW pobočková ústředna, která je vyvíjena jako open-source projekt
http://www.asterisk.org/ a firma Digium, která za Asteriskem stojí, se zabývá prodejem a podporou
HW pro Asterisk.
Pokud se GW registruje na GK pomocí registračních zpráv RRQ obdobně jako klient, tak není
nutné statickou registraci provádět a nakládáme s GW stejně jako s IP telefonem, GW si na GnuGK
zaregistruje své prefixy a o nic se nemusíme starat. Pokud se nechceme spoléhat na dynamickou
registraci a chceme mít natvrdo v konfiguraci zapsáno, že čísla začínající určitým řetězcem mají být
směrována na konkrétní EP, tak GW do konfigurace přidáme, tím pádem GK bude volání na GW
44
směrovat, ať už bude GW funkční či nikoliv. Přidání VoGW je záležitostí jednoho řádku sekce
RasSrv::PermanentEndpoints, často je ovšem nutné přepisovat čísla. Například používáme-li
mezinárodní formát čísel a nechceme, aby uživatel musel točit před každým čísel ještě 420, příchod
na GW mu tedy ještě přepíšeme v sekci RasSrv::GWRewriteE164 , předtím je ovšem nutné dát GW
do sekce RasSrv::GWPrefixes. Přepisy mohou být nejen v příchodu na GW, ale taky při vytočení 420
950 0 z GW budeme chtít přepsat na 950 0.
[RasSrv::GWPrefixes]
GW-VUTBR=54114
[RasSrv::GWRewriteE164]
GW-VUTBR=out=54114=42054114
[RasSrv::PermanentEndpoints]
195.113.113.131:1720=GW-VUTBR;42054114
[RasSrv::RewriteE164]
4209500.....=9500.....
2.7.5
Autentizace v GnuGK
Autentizace je proces ověření identity subjektu vstupujícího do systému. V našem případě se
jedná o ověření identity uživatele žádajícího o přístup na gatekeeper za účelem využívat jeho
prostředků a služeb. Konfigurace možnosti autentizace se konkrétně týká již jednou v zmiňované
sekce [Gatekeeper::Auth]. Jednotlivá pravidla se poté konfigurují dle předem určené syntaxe. GnuGK
podporuje několik autentizačních mechanizmů, každý autentizační mechanizmus se konfiguruje
pomocí příslušné podsekce. Je možné definovat více pravidel a udělit jim prioritu. Pokud ověření
uživatele selže na primárním autentizačním pravidle, ověření uživatele pokračuje dle
nakonfigurovaného následujícího pravidla. Při ověřování uživatele pomocí autentizačního pravidla
mohou nastat tři výsledné stavy:
•
•
•
ok – úspěšně autentizován, ověření uživatele bylo úspěšné,
fail – ověření selhalo a požadavek by měl být zamítnut,
next – pravidlo nemůže rozpoznat požadavek, je možné přejít na jiné pravidlo.
Autentizační pravidlo můžeme definovat pomocí tří možností:
•
•
•
•
optional – pokud nemůže rozpoznat požadavek, je požadavek přeposlán
na následující pravidlo,
required – požadavek musí být autentizován pomocí tohoto pravidla nebo bude zamítnut.
sufficient – pokud je tímto pravidlem autentizován, požadavek může být přijat.
GnuGK gatekeeper podporuje následující autentizační mechanizmy:
•
SimplePasswordAuth - Modul se konfiguruje v podsekci [SimplePasswordAuth], kde se
definují uživatelská jména (identifikátory) a příslušná uživatelská hesla. Všechna hesla by
měla být šifrována pomocí dodávané utility addpasswd. Tento autentizační modul kontroluje
obsah token a cryptoToken polí v RAS signalizačních zprávách. Token by měl minimálně
obsahovat identifikátor uživatele generalID a uživatelské heslo. Pro zašifrování hesla
podporuje modul hash algoritmy MD5 a HMAC-SHA1-96. Je podporován také přenos
45
uživatelského jména a hesla ve formě čistého textu (nešifrovaně). Přijaté autentizační
informace, získané z příslušné RAS signalizační zprávy, jsou porovnávány s autentizačními
údaji definovanými v podsekci modulu, kdy na základě shody je uživatel autentizován.
•
SQLPasswordAuth - Modul se konfiguruje v podsekci [SQLPasswordAuth], kde se
konfigurují parametry SQL databáze, která obsahuje autentizační údaje příslušných
koncových bodů podporujících standard H.235. Kvůli zpětné kompatibilitě je také podporován
modul MySQLPasswordAuth. Přijaté autentizační informace jsou v případě tohoto modulu
porovnávány s autentizačními údaji uloženými v SQL databázi.
•
AliasAuth - Modul se konfiguruje v podsekci [RasSrv::RRQAuth], kde se specifikuje chování
modulu (přijmout/zamítnout) v případě přijetí RRQ (RegistrationRequest) signalizační zprávy,
tedy žádosti o registraci koncového bodu na gatekeeper. Alias adresa koncového bodu,
obvykle se jedná o H.323 identifikátor, se stává klíčovým parametrem pro chování
autentizačního pravidla. Aby byla autentizace koncového bodu úspěšná, je nutné, aby byly
všechny podmínky stanovené pro příslušnou alias adresu splněny. Jako příklad lze uvést
registraci podmíněnou IP adresou, ze které koncový bod žádá o registraci na gatekeeper.
•
SQLAliasAuth - Modul se konfiguruje v podsekci [SQLAliasAuth], kde se konfigurují
parametry SQL databáze, která obsahuje autentizační pravidlo. Tento modul vychází z
modulu AliasAuth, chování modulu (přijmout/zamítnout) je ovlivněno podmínkami a pravidly
uloženými v SQL databázi.
•
FileIPAuth - Modul se konfiguruje v podsekci [FileIPAuth], kde se definují IP adresy a sítě,
které mají povoleny přístup k prostředkům gatekeeperu. Je možné specifikovat seznam
povolených (zakázaných) prefixů společně s IP adresami, seznam může být také načítán
externě pomocí instrukce include. Modul tedy poskytuje jednoduchý postup jak zamezit
přístup na gatekeeper pomocí IP adresy nebo adresy sítě.
•
PrefixAuth - Modul se konfiguruje v podsekci [PrefixAuth], kde se definují příslušná
autentizační pravidla. Tento modul v současné době podporuje pouze signalizační zprávy
ARQ (AdmissionRequest) a LRQ (LocationRequest). Princip chování modulu spočívá v tom,
že IP adresy nebo alias adresy požadavku spolu s daným prefixem musí odpovídat
definovanému pravidlu, jinak bude požadavek zamítnut.
•
RadAuth - Modul se konfiguruje v podsekci [RadAuth], kde se využívá možnosti autentizace
pomocí RADIUS serveru, založené na H.235 CAT (Cisco Access Token) token mechanizmu.
Modul podporuje RAS signalizační zprávy RRQ, ARQ a signalizační zprávu Q.931 Setup.
Pracuje s H.235 bezpečnostními mechanizmy, kdy autentizační informace získané z CAT
tokenu posílá k ověření na RADIUS server. Pokud koncový bod CAT token nepodporuje, je
možné použít modul RadAliasAuth.
•
RadAliasAuth - Modul se konfiguruje v podsekci [RadAliasAuth], kde se nastavuje možnost
autentizace pomocí RADIUS serveru na základě alias adres nebo IP adres koncových bodů
obsažených v požadavku. Modul podporuje RAS signalizační zprávy RRQ, ARQ a
signalizační zprávu Q.931 Setup. Tento autentizační modul je vhodný jak pro registrované
koncové body, kde se pro autentizaci uplatňují signalizační zprávy RRQ a ARQ, tak i pro
neregistrované koncové body, kde se využívá pro autentizaci signalizační zpráva Setup.
Modul nevyžaduje přítomnost H.235 tokenu uvnitř signalizačních zpráv, proto je použitelný ve
větší míře, než modul RadAuth.
46
•
SQLAuth - Modul se konfiguruje v podsekci [SQLAuth], kde se konfigurují parametry SQL
databáze, která obsahuje potřebné informace pro autentizaci i autorizaci koncových bodů.
Modul podporuje RAS signalizační zprávy RRQ, ARQ, LRQ a signalizační zprávu Q.931
Setup. Jedná se o výkonný modul umožňující autentizovat i autorizovat požadavky na
základě různých parametrů, jako např. číslo volajícího uživatele, volané číslo, uživatelské
jméno apod. Pomocí tohoto modulu můžeme také stanovit maximální délku hovorů,
směrování hovorů, přiřazování alias adres apod.
Syntaxe konfigurace autentizačního pravidla může být provedena následujícím způsobem.
Autentizace na GnuGK probíhá pomocí modulu FileIPAuth. Povolený přístup mají pouze uživatelé
sítě s IP adresou 192.168.1.0/24, kromě IP adresy 192.168.1.240, která má přístup zakázán.
[Gatekeeper::Auth]
FileIPAuth=required;RRQ,LRQ,Setup
[FileIPAuth]
192.168.1.240=reject
192.168.1.0/24=allow
any=reject
2.7.6
Autorizace v GnuGK
Autorizace je proces pro ověření práv daného uživatele. Úspěšně autentizovaný a přihlášený
uživatel může mít totiž různá práva pro různé úkony. V oblasti IP telefonie to znamená např. omezit
uživateli možnost volat na určitá čísla nebo naopak omezit přístup na jeho číslo. V současnosti nabízí
GnuGK možnost autorizace uživatelů pomocí dvou modulů.
•
PrefixAuth modul podporuje autorizaci uživatelů pro signalizační zprávy ARQ a LRQ. Modul
ověřuje prefix z pole destinationInfo (volané číslo), obsažený v požadavku spolu s IP adresou
nebo alias adresou, jestli se shoduje s definovaným pravidlem. Na základě tohoto
definovaného pravidla je možné požadavek přijmout nebo zamítnout. Můžeme také definovat
implicitní pravidlo, pokud nedojde ke shodě prefixu s pravidlem. Modul tedy nabízí možnost
efektivně zamezit volání uživatelů na určitá zakázaná čísla. Ukázka autorizace uživatelů na
základě prefixu:
555=deny ipv4:10.0.0.0/27|allow ipv4:0/0
5555=allow ipv4:192.168.1.1|deny ipv4:192.168.1.0/255.255.255.0
86=deny !ipv4:172.16.0.0/24
09=deny alias:^188884.*
•
SQLAuth modul je výkonný modul nabízející více možností autorizace uživatelů. Podporuje
RAS signalizační zprávy RRQ, ARQ, LRQ a signalizační zprávu Q.931 Setup. Na základě
tohoto modulu můžeme autorizovat uživatele dle mnoha volitelných parametrů, které
ukládáme v SQL databázi. Uživatele můžeme autorizovat na základě volaného čísla,
uživatelského jména, můžeme stanovit maximální délku hovoru, můžeme směrovat jednotlivé
hovory apod. SQL databáze tedy tvoří flexibilní možnost libovolně autorizovat uživatele na
základě řady podporovaných parametrů.
Mechanizmus autentizace a autorizace na obr.
2.17 byl realizován jako diplomová práce [sir] a řešení přes RADIUS bylo zvoleno z důvodu
47
nepodporovaného protokolu LDAP v GnuGK, podpora LDAP byla přidána ve verzi 2.2.7 a dá
se zapnout při kompilaci GnuGK.
Obr 2.17 Příklad řešení mechanizmu autentizace a autorizace.
2.7.7
Návrh sítě s konfigurací GnuGK
Návrh topologie je v obr. 2.18, skládá se ze dvou GK, každý GK spravuje svou zónu, ve které
jsou umístěny IP telefony a v zóně B je navíc umístěna hlasová brána VoGW, která je propojena s
PBX a přes PBX do veřejné sítě PSTN, tato VoGW se registruje dynamicky s prefixem 9, čili cokoliv
začínající číslicí 9 posíláme přes VoGW do PBX.
Obr 2.18 Návrh topologie H.323 sítě.
48
V zóně A se budou nacházet čísla začínající pětkou, např. 5959991699 (IP phone A) a v zóně B
začínající dvojkou, např. 224352979 (IP phone B), navíc je v zóně B už zmíněná brána VoGW s
ISDN. Zvolíme ISDN BRI a jelikož se připojujeme k PBX, tak budeme emulovat stranu sítě, nechť je
konfigurace v PBX standardní.
Začneme s konfigurací GnuGKA umístěného na obr. 2.18 vlevo nahoře. Než nainstalujeme
gnugk, tak pro jistotu nejdříve odinstalujeme starší verzi, pokud se nachází a vyčistíme staré
konfigurační soubory, následně provedeme aktualizaci seznamu balíčku z repozitáře a poté konečně
nainstalujeme gnugk.
# apt-get remove gnugk
# dpkg --purge gnugk
# apt-get update
# apt-get install gnugk
Veškerá konfigurace je uložena v souboru /etc/gatekeeper.ini, změny budeme provádět vhodným
editorem. Po provedení změn můžeme přes telnet můžeme provést přehrání (reload) konfigurace
bez výpadku gnugk a rovněž se můžeme podívat příkazem rv na výpis aktuálních registrací.
# nano /etc/gatekeeper.ini
# telnet localhost 7000
reload
rv
exit
2.7.8
Nastavení GK a mezizónové propojení
V sekci Main si GK vhodně pojmenujeme a nastavíme režim (např. DRC), posuneme TCP port
Q.931 na standardní 1720 a abychom se vyhnuli problémům s detekcí duplicitní registrace (změna
IP u EP), tak raději povolíme i přepisování registrací.
[Gatekeeper::Main]
Name=GnuGKA
TimeToLive=600
[RoutedMode]
GKRouted=0 /* running in DRC
H245Routed=0
CallSignalPort=1720
Teď bychom měli nakonfigurovat IP klienta Yate, PacPhone nebo Ekiga a zkusit se zaregistrovat.
Registraci můžeme sledovat přes telnet v konzoli. Připravíme si mezizónovou komunikaci směrem na
GK-B, kam budeme směrovat volbu s čísly začínající dvojkou a devítkou, jako příchozí akceptujeme
jakoukoliv volbu (*).
49
[RasSrv::Neighbors]
GK-B=GnuGK
[Neighbor::GK-B]
Host=158.196.142.3
SendPrefixes=2,9
AcceptPrefixes=*
V dalším kroku si připravíme GnuGKB a jeho konfigurace je obdobná přechozí.
Připravíme
mezizónovou komunikaci směrem do zóny A, kterou pozorně porovnáme s přechozím zápisem na
GnuGKA
[Gatekeeper::Main]
Name=GnuGKB
TimeToLive=600
[RoutedMode]
GKRouted=0
H245Routed=0
CallSignalPort=1720
[RasSrv::Neighbors]
GK-A=GnuGK
[Neighbor::GK-A]
Host=158.196.81.102
SendPrefixes=5
AcceptPrefixes=*
8.2.2 Nastavení VoGW a dynamické registrace na GK
Nejdříve nastavíme doporučené globální parametry v kapitole věnující se konfiguraci hlasových
brán Cisco. Přihlášení na GK nakonfigurujeme tak, že se bude brána registrovat pod názvem VoGW
a prefixem 9, na GK není třeba provádět žádnou úpravu.
voice rtp send-recv
!
voice service voip
h323
h245 caps mode restricted
interface FastEthernet0/0
ip address 158.196.81.205 255.255.255.0
h323-gateway voip interface
h323-gateway voip id GnuGKB ipaddr 158.196.142.3 1718 priority 100
h323-gateway voip h323-id VoGW
50
h323-gateway voip tech-prefix 9
V další části nastavíme opět globální parametry brány ale tentokrát z pohledu ISDN, zatímco
předtím to byly parametry ze strany IP světa. Konfigurace ISDN BRI je dána tím, že emulujeme
stranu sítě a používáme signalizaci DSS1.
voice-port 0/0
compand-type a-law
cptone CZ
bearer-cap 3100Hz
interface BRI0/0
no ip address
isdn switch-type basic-net3
isdn not-end-to-end 64
isdn protocol-emulate network
isdn layer1-emulate network
isdn incoming-voice voice
isdn send-alerting
isdn outgoing-voice info-transfer-capability 3.1 kHz-audio
isdn static-tei 0
isdn skipsend-idverify
Poslední část konfigurace VoGW se týká nastavení směrů jak odchozí tak příchozí a v závorce
uvedený řetězec [25] je součást regulárního výrazu říkající, že platí pro číslo začínající dvojkou nebo
pětkou.
dial-peer voice 1 voip
destination-pattern [25]........
session target ras
codec g711alaw
no vad
!
dial-peer voice 20 pots
destination-pattern 9....
direct-inward-dial
port 0/0
!
dial-peer voice 999 voip
codec g711alaw
incoming called-number ..T
!
Komunikaci sledujeme protokolovým analyzátorem Wireshark a po úspěšném odzkoušení
návrhu změníme režim z DRC na GRC pomocí nastavení GKRouted=1. Obr. 2.19 zobrazuje příklad
mezizónové mezizónovou komunikace (IP adresy jsou odlišné).
51
Obr 2.19 Mezizónová komunikace.
GK na levé straně obr. 2.4 nemůže odpovědět ihned na ARQ, jelikož nezná umístění volaného
EP, posílá LRQ na sousední GK, kde se ptá na destinationInfo (hledané číslo 5969919699),
odpověď je očekávána na IP 158.196.244.177 portu 1719, viz. obr 2.20.
Obr 2.20 Obsah zprávy LRQ.
Odpověď LCF, viz. obr. 2.21 obsahuje callSignalAddress (Q.931) 158.196.81.101 port 1720,
tato informace je následně vložena do ACF, tím se volající EP dozvídá, kam má poslat žádost o
sestavení spojení SETUP. Sousední GK rovněž sděluje adresu pro další RAS komunikaci
158.196.244.176 port 1719.
Obr 2.21 Zpráva LCF v mezizónové komunikaci.
52
5 Základy protokolu SIP
3
Session Initiation Protocol
SIP (Session Initiation Protocol) je protokolem pro sestavení, modifikaci a terminaci obecné relace v
Internetu a nejčastěji je používán pro audio. Byl vyvíjen od roku 1996 pracovní skupinou MMUSIC
(Multiparty Multimedia Session Control) v rámci IETF (Internet Engineering Task Force). V roce 1999
byl předložen ve formě navrhovaného standardu (Proposed Standard) v RFC 2543. Téhož roku na
popud IETF vznikla nová pracovní skupina, nazvaná příznačně SIP, která převzala vývoj hlavního
jádra protokolu. Její práce v květnu roku 2002 vyústila v nový standard RFC 3261. Dnes existuje
kolem stovky dalších RFC, které se přímo týkají SIPu nebo na něj navazují, ať už jde přímo o nové
metody komunikace anebo např. rozšíření položek v hlavičkách.
3.1
Základní popis protokolu SIP
SIP pracuje na aplikační vrstvě, byl navržen tak, aby byl snadno implementovatelný, rozšiřitelný a
dostatečně flexibilní. Protokol je užíván pro sestavení, modifikaci a ukončení spojení s jedním nebo
více účastníky, ale není jediným protokolem, který je potřebný pro audiovizuální komunikaci, ve
spojení se SIPem jsou nejčastěji používány ještě dva další protokoly, RTP (Real-Time Protocol) pro
přenos vlastního obsahu a SDP (Session Description Protocol) pro popis přenášeného obsahu [sin1],
[sin2].
SIP je end-to-end orientovaný signalizační protokol, což znamená, že veškerá logika je uložená v
koncových zařízeních, koncová zařízení znají i jednotlivé stavy komunikace, chování lze popsat
stavovým diagramem, ve kterém se v rámci dialogu (spojení) probíhají jednotlivé transakce (žádosti
a odpovědi). Tím je zvýšena odolnost komunikace proti chybám. Cena, která se musí zaplatit za
decentralizaci a dostupnost služby, je vyšší režie hlaviček zpráv. Nepochybně stojí za zmínku, že
end-to-end koncept SIPu je zásadně odlišný od klasického řešení PSTN (Public Switched Telephone
Network), kde logika je uložena v síti a koncová zařízení jsou primitivní. Jedním z cílů SIPu je zajistit
stejnou funkcionalitu jakou mají klasické PSTN, ale end-to-end návrh umožňuje v SIPu podstatně
snadnější implementaci nových služeb a některé z nich mohou být jen stěží nasazeny v klasických
PSTN.
SIP je textově orientovaný protokol z rysy podobnými HTTP a SMTP protokolu. HTTP a SMTP
jsou nepochybně nejúspěšnějšími a nejpoužívanějšími protokoly v Internetu, volba osvědčeného
modelu komunikace zaručuje SIPu robustnost a nadčasovost. Klient posílá požadavky na server,
který zasílá odpovědi obdobně jako u HTTP, v hlavičkách najdeme položky From, To či Subject jako
53
u mailové komunikace pomocí SMTP. SIP entita je vázána k doméně obsluhovanou SIP Proxy a
mezidoménová komunikace je tedy mezi různými SIP Proxy, výjimkou je multidoménová SIP Proxy.
SIP entity jsou identifikovány použitím SIP URI (Uniform Resource Identifier), řekli bychom
jednoduše jmennými identifikátory, jejich obecný tvar je uveden níže.
sip:user:password@host:port;uri-parameters?headers
SIP URI se skládá jednak z části username identifikující uživatele a jednak z host vztažené k
doméně neboli hostiteli, který poskytuje uživateli určité prostředky k zajištění komunikace, následuje
pole password jehož použití není doporučeno. Port je standardně 5060 na UDP, případné parametry
se oddělují středníkem a pokud je potřebné přímo do URI zadat i nějaké parametry hlavičky, tak se
uvádějí za otazníkem. Většinou ale uvidíme SIP URI v podobě jednoduché konstrukce
sip:user@host , což nápadně připomíná emailovou adresu. Příkladem SIP URI může být:
•
•
sip:[email protected]
sip:[email protected]
SIP tedy pracuje se jmennými identifikátory a číslo můžeme přeložit na URI pomocí DNS, kde
jsou k tomu určeny záznamy NAPTR (Name Authority Pointer) a technika mapování URI na tel. čísla
(standard ITU-T E.164) se nazývá ENUM (E.164 NUmber Mapping). URI je obecně prezentováno
řetězcem znaků, jehož cílem je umožnit interakci se zdrojem pomocí určitého protokolu, tzn. musí
nutně obsahovat název schématu (protokol) a adresu zdroje, za schématem následuje dvojtečka.
URI dle RFC 3986 je definováno následovně:
<scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]
Příklady pro scheme name jsou:
•
•
•
sip, sips, h323, tel, http, https,
ftp, imap, ldap, mailto, telnet, im,
pop, news, atd...
Hierarchical part nese informaci o identifikaci zdroje, obvykle začíná dvojitým lomítkem “ // „ a
následuje např.:
•
•
•
•
domain name,
IP address,
username:password@,
user@host.
Pokud je specifikováno číslo portu, tak se začíná znakem „:“, např. :5060, :8080, :8085, atd...
Query je nepovinná část, která obsahuje doplňující informace, obecná syntaxe není definována,
obvykle se objevuje ve formě <key>=<value>, kde jednotlivé hodnoty jsou odděleny znakem „&“ ,
např. key1=value1&key2=value2&key3=value3 . Fragment je nepovinná část umožňující nepřímo
identifikovat další zdroj a začíná znakem „#”.
54
SIP adresa je vázána k doméně, a proto následuje několik základních informací k DNS. Jména
domén jsou vyjádřena pomocí adres 32-bitových (IPv4) A záznam nebo 128 bitových (IPv6) - AAAA
záznam. Systém DNS zajišťuje překlad doménových jmen na IP adresy, stejně tak zajišťuje zpětný
překlad IP adresy na doménové jméno - PTR záznam. Doménová jména jsou vytvářena hierarchicky,
stejně jako jsou hierarchicky organizovány DNS servery. Prostor doménových jmen tvoří strom, jeho
kořenem je kořenová doména, která se zapisuje jako samotná tečka, pod ní se v hierarchii nacházejí
tzv. domény nejvyšší úrovně (Top-Level Domain, TLD).
Při vyhledávání v DNS provádějí klienti obvykle dopředné vyhledávání (reverzní dotaz slouží
k získání doménového jména ze známé IP adresy), což je hledání založené na názvu DNS jiného
počítače, který je uložen v záznamu o prostředku hostitele (A). U odpovědi na tento typ dotazu se
jako údaj o prostředku očekává adresa IP. Systém DNS poskytuje rovněž zpětné vyhledávání, při
kterém klienti používají známou adresu IP a hledají název počítače na základě jeho adresy, pro tento
účel byla ve standardech DNS definována speciální doména in-addr.arpa. V rámci domény inaddr.arpa jsou pomocí opačného pořadí čísel adres IP v desítkovém formátu s tečkou vytvořeny
subdomény, které tvoří obor názvů pro zpětné dotazy. Stromová struktura domény in-addr.arpa
integrovaná do systému DNS vyžaduje definování dalšího typu záznamu o prostředku - záznamu o
prostředku ukazatele (PTR). Tento záznam o prostředku vytváří v zóně zpětného vyhledávání
mapování, které obvykle koresponduje se záznamem prostředku hostitele (A) pro název počítače
DNS hostitele v jeho zóně dopředného vyhledávání.
Strom je administrativně rozdělen rozdělit do zón, které spravují jednotliví správci. Obsah zóny
(domény či několika domén) je uložen v tzv. zónovém souboru, skládá se z jednotlivých záznamů
(resource records, RR) obsahujících dílčí informace. Zónový soubor vždy musí začínat záznamem
typu SOA. Nejčastěji se používají následující typy záznamů:
•
•
•
•
•
3.2
A (address record) obsahuje IPv4 adresu přiřazenou danému jménu, například neco.vsb.cz
má IP adresu 1.2.3.4, zónový soubor pro doménu vsb.cz bude obsahovat záznam,
neco IN A 1.2.3.4,
CNAME (canonical name record) je alias - jiné jméno pro jméno již zavedené, jeho definice
pomocí přezdívky umožňuje jej později snadno přestěhovat na jiný počítač, např. neco.vsb.cz
má sloužit zároveň jako nic.vsb.cz, v zónovém souboru přibude
nic
IN CNAME neco,
SOA (start of authority record) je zahajující záznam zónového souboru. Obsahuje jméno
primárního serveru, adresu elektronické pošty jejího správce a další údaje (serial, refresh,
retry, expire a TTL).
Prvky SIP řešení
Ačkoliv v nejjednodušší konfiguraci je možné použít dva UA posílající si navzájem SIP zprávy,
typická SIP síť bude obsahovat více než jeden typ prvků.
55
3.2.1
User Agent a Back to Back User Agent
Základními SIP prvky jsou:
•
•
SIP user agent (UA), který je prezentován koncovým terminálem,
SIP proxy, registrar, redirect a location servery, často označováno jako SIP server.
Jednotlivé servery jsou většinou stavěny jako logické části SIP serveru, jelikož z pohledu nákladů
je efektivnější jejich provoz na jednom společném HW, každopádně filozofie návrhu SIP architektury
umožňuje jejich plnou dekompozici, což je výhodou pro velká řešení, distribuovaná architektura vede
ke zvýšení robustnosti.
Koncové body, kde vzniká a je terminována SIP relace, jsou nazývány jako user agents (UA). UA
obvykle jsou představovány koncovými terminály ve formě HW SIP telefonu nebo aplikace, SIP UA
mohou být IP telefony, Smartphones, PSTN brány (GW), IVR systémy, atd. UA jsou vztaženi k User
Agent Server (UAS) a User Agent Client (UAC). UAS a UAC jsou pouze logické entity, každý UA
obsahuje UAC a UAS:
•
•
UAC je část vysílající požadavky a přijímající odpovědi,
UAS je část přijímající požadavky a odesílající odpovědi.
IN
V
IT
E
Žádost a odpověď jsou dva základní typy SIP zpráv. Protože koncové zařízení téměř vždy
obsahuje UAC a UAS, tak používáme pouze označení UA namísto UAC a UAS. Například, volající
UA funguje jako UAC, když odesílá zprávu INVITE (požadavek na sestavení spojení) a přijímá
odpověď na požadavek. Volaný UA se chová jako UAS, když obdrží zprávu INVITE a odesílá
odpověď. Ale tato situace se mění, když volaný se rozhodne zavěsit a odesílá se zpráva BYE a
ukončuje spojení. V tomto případě se volající chová jako UAC a volaný jako UAS.
V
IN
E
IT
Obr. 3.1
Rozeslání INVITE více příjemcům.
56
Obr. 3.1 ukazuje tři UA a SIP Proxy. UAC inicializuje spojení odesláním žádosti INVITE na
SIP Proxy, ta je přeposlána adresátovi, jelikož je příjemců více, tak dochází k rozeslání na dva UAS
(forking). Na prvním z nich, který přijme volání, tak je sestaveno spojení. Při ukončení spojení
odesílá UAC zprávu BYE přímo na UAS.
B2BUA je speciální typ UA vkládaného do cesty a vytvářejícího dvě spojení, na B2BUA je
ukončeno jedno spojení a sestaveno nové na cíl, B2BUA zprávy a odpovědi na rozdíl od SIP Proxy
nepřeposílá, ale vytváří nové směrem k oběma komunikujícím stranám. Koncový terminál ovšem
nerozezná rozdíl mezi voláním přes B2BUA a SIP Proxy. B2BUA má rozsáhlejší možnosti než SIP
Proxy, ovšem výkon vyjádřený počet obsloužených požadavků na spojení za jednotku času je
podstatně menší oproti klasickým SIP Proxy, což vyplývá z rozdílného přístupu k obsluze SIP zpráv
[v188] a [v191].
Použití B2BUA je poměrně časté, typickým příkladem je ASTERISK, který má rozsáhlé možnosti
doplňkových služeb pro koncové uživatele, je používán jako pobočková ústředna do velikosti řádově
tisíců uživatelů. Jako představitele klasické SIP PROXY si uveďme KAMAILIO, řešení je vhodné i pro
velké poskytovatele s dimenzování až pro stovky tisíc uživatelů [v133], [v191] and [v229].
3.2.2
SIP Proxy Server
SIP umožňuje vytvořit infrastrukturu sítě hostitelů nazývaných jako SIP Proxy servery. Koncové
terminály UA mohou odesílat zprávy na SIP Proxy server. SIP Proxy servery jsou důležité entity
infrastruktury. Zajišťují směrování žádostí o spojení dle aktuálního umístění adresáta, mohou
provádět autentizaci, účtování a realizovat doplňkové služby (např. přesměrování). Nejdůležitější
úloha SIP Proxy serveru je směrovat žádosti o sestavení spojení blíž k volanému. Při inicializaci
sestavení spojení je základní úlohou SIP Proxy nalézt další SIP Proxy, která obslouží požadavek a
na tuto danou zprávu odeslat. K nalezení SIP proxy pro next hop může kromě statického záznamu i
vyhledávat v DNS. Požadavek na sestavení spojení je tedy směrován přes jednotlivé SIP Proxy a
volaný nakonec žádost akceptuje nebo odmítne. Máme dva základní typy SIP proxy serverů:
•
•
stateless (bezestavový),
stateful (a s informací o stavech).
Kromě SIP Proxy serveru máme následující servery:
•
•
•
•
Redirect Server slouží pro přesměrování, vrací nové URI uživatele,
Registrar Server přijímá požadavky na registraci, aktualizuje lokalizační databázi a mapuje
logickou URI uživatele (user URI) na fyzickou URI zařízení (device URI), user URI je taky
označována jako AOR (Address of Record),
Location Server je úložištěm informací o umístění uživatelů a SIP Proxies,
posledním případem je B2BUA, který je používán v režimu SIP serveru.
Stateless SIP Proxy jsou poměrně jednoduché a pouze přeposílají zprávy nezávisle na jejich
vzájemné vazby. Zprávy jsou většinou v pořádku z hlediska souslednosti a významu v signalizaci,
bezestavové SIP Proxy servery neumí kontrolovat jejich výměnu z hlediska smysluplnosti, nezachytí
57
replikaci zpráv, detekce nekonečných smyček jim trvá déle, nejsou srovnatelné se stateless SIP
Proxy do rozsahu možností, neumí např. větvení či přesměrování. Stateless SIP Proxy servery jsou
jednoduché, ale rychlejší než Stateful SIP Proxy . Využití mají jako balanční servery, pro jednoduché
překládání zpráv a směrování.
Stateful SIP Proxy servery jsou mnohem komplexnější. Po přijetí požadavku, server vytvoří záznam
stavu a drží důležité informace, dokud nedojde k ukončení transakce či dialogu, dělí se tak na dva
typy.
•
•
transakční, drží stavy k žádosti (dokud není definitivně vyřízena),
dialogové, drží stavy dialogu (dokud neskončí celé spojení).
Některé transakce, zejména vytvořené zprávou INVITE, mohou trvat poměrně dlouho (dokud
volaný nevyzvedne nebo se neukončí volání). Protože proxy servery s informací o stavech musí
udržovat stav po celou dobu dané transakce, je jejich výkon limitován.
#1
Obr. 3.2.
#5
TE
VI
IN
IN
V
IT
E
Sestavení spojení přes dvě SIP Proxy.
Schopnost přiřazovat SIP zprávy do transakcí dává serveru některé zajímavé vlastnosti,
například může provádět větvení, na přijetí jedné zprávy, může být odesláno více zpráv (uživatel má
např. vícenásobnou registraci). Stateful SIP Proxy server může zachytit opakování zpráv, protože
ze stavu transakce ví, jestli byla stejná zpráva už přijata (Stateless Sip Proxy nemůže ověřovat,
protože nedrží stav). Stateful SIP Proxy server může aplikovat komplikovanější metody nalezení
uživatele, například možnost zkusit volat na telefon v zaměstnání a v případě neohlášení volání
přesměrovat na mobilní telefon, zatímco stateless SIP Proxy žádost přepošle a už o nemá k ní
58
informacemi, čili nemůže tedy provést např. přesměrování po čase. Většina SIP Proxy serverů je
stateful , často nabízejí generování záznamů o spojeních, větvení, některé druhy podporují i NAT.
SIP je připraven na situaci, kdy každá jednotka (např. firma) bude mít vlastní SIP proxy server, který
je užíván všemi UA v rámci administrované jednotky [v90]. Předpokládejme, že jsou dvě firmy A a B
a každá z nich má svůj Proxy server. Obr. 3.2 ukazuje situaci, kdy Alice z firmy A inicializuje spojení
na Boba z firmy B. Uživatel Alice volá Boba a použije URI adresu sip:[email protected]. UA neví, kam má
poslat žádost o sestavení spojení, ale je nakonfigurován tak, že veškerý odchozí provoz (outbound
traffic) posílá na SIP Proxy server své firmy A s adresou proxy.a.com. Proxy server zjistí, že uživatel
sip:[email protected] je v jiné firmě a tak vyhledá odpovídající SIP Proxy server, kam pošle žádost.
Odpovídajícím serverem je proxy.b.com a je zadán staticky v proxy serveru firmy A anebo bude
Proxy vyhledán pomocí záznamu DNS SRV, kterým je zjištěno, kdo poskytuje službu SIP v doméně
b.com. Žádost tedy dorazí na proxy.b.com. SIP Proxy ví, že Bob je aktuálně ve své kanceláři a
dosažitelný na telefonu na svém stole, jež má IP adresu 1.2.3.4, takže SIP Proxy přeposílá žádost
INVITE. Zmínili jsme se, že SIP Proxy na proxy.b.com zná současnou polohu Boba, ale neřekli jsme,
jak Proxy může lokalizovat uživatele. Bobův UA (SIP telefon) musí být registrován na SIP Registrar
serveru. Registrar server je speciální část SIP serveru, která přijímá od uživatelů požadavky na
registraci, tím získává informaci o jejich aktuální poloze (IP adresa, port a uživatelské jméno) a
ukládá informaci do lokalizační databáze (location database).
3.2.3
SIP Registrar Server
V lokalizační databázi v našem případě došlo k namapování adresy User URI sip:[email protected] k
adrese Device URI sip:[email protected]:5060. Lokalizační databáze je pak užívána Proxy serverem.
Když inbound Proxy server obdrží žádost pro sip:[email protected], vyhledá v lokalizační databázi záznam
sip:[email protected]:5060 a na danou IP adresu pošle žádost.
Obr. 3.3. Průběh registrace.
59
Registrar server je velmi často pouze jako logická část SIP serveru, jelikož je těsně svázán s
Proxy serverem. Obr. 3.3 znázorňuje typickou SIP registraci. Zpráva REGISTER je vyslána do
Registrar serveru a obsahuje adresu záznamu User URI sip:[email protected] a kontaktní adresu
Device URI sip:[email protected]:5060 , kde 1.2.3.4 je IP adresa telefonu. Registrar zaznamenává tyto
informace do lokalizační databáze. Pokud registrace proběhla správně, tak Registrar server posílá
odpověď 200 OK a proces registrace je ukončen. Každá registrace má limitovanou dobu platnosti,
doba platnosti je v hlavičce kontaktu (Expires), do té doby musí UA obnovit registraci, jinak bude
nedostupný.
3.2.4
SIP Redirect Server
si #1
p:
bo IN
b@ VIT
vs E
#2
b.
T e 302
cz
m M
po o
ra ved
ri l
y
Jak již bylo řečeno, SIP URI je vázána k doméně, ta je nezávislá na síťové topologii, a například SIP
server v doméně vsb.cz můžu používat odkudkoliv. Může být ovšem někdy nepraktické jej používat,
pokud jsem v doméně cvut.cz a nabízí se mi možnost využívat jejich SIP Proxy, v tom případě by
ale někdo měl vědět o mém novém SIP URI a zajistit přesměrování, viz. obr. 3.4
Obr. 3.4. Průběh přesměrování.
Entita, která přijímá požadavek a odesílá zpět odpověď obsahující lokalizaci konkrétního
uživatele se nazývá Redirect server. Redirect server přijímá požadavky a vyhledává zamýšlené
příjemce v lokalizační databázi vytvořené registrar serverem. Následně vytváří seznam aktuálních
lokalizací uživatele a posílá jej odesílateli požadavku v odpovědi zařazené do třídy 3xx. Odesílatel
požadavku poté dostává seznam destinací a odesílá další požadavky přímo na ně. Obr. 3.5 ukazuje
způsob přesměrování, Alice volá Boba a odeslaný INVITE přijme Redirect server, který zjistí, že Bob
má nový kontakt a vrací odpověď 302 Moved Temporarily, ve které do pole contact zapíše SIP URI,
na kterou je Bob přesměrován. Alice zasílá nový INVITE na URI z kontaktu předaného Redirect
serverem a INVITE již s novou požadovanou URI se dostává na SIP Proxy sip.cvut.cz , kde už o
Bobovi vědí a umí INVITE na něj přeposlat.
60
3.3
SIP žádosti a odpovědi
Komunikace v SIPu je tvořena zprávami, které jsou obvykle přenášeny v samostatných UDP
datagramech. Každá zpráva obsahuje hlavičku zprávy (header) a může obsahovat vlastní tělo zprávy
s popisem médií (body, většinou SDP), hlavička a tělo jsou odděleny volným řádkem (CRLF).
generic-message = start-line
*header fields
CRLF
[ message-body ]
V prvním řádku zprávy je identifikován její typ. Známe dva typy zpráv, jednak žádost (neboli
metoda) a jednak odpověď.
3.3.1
Základní popis SIP hlavičky typické žádosti
Žádosti jsou obvykle užívány k registraci uživatele, sestavení, modifikaci či ukončení spojení
anebo může jít o další služby (presence, instant messaging). Odpovědi jsou užívány k potvrzení
přijetí žádosti a její vyřízení, obsahují konkrétní status. Typická SIP žádost vypadá následovně:
Request-Line: INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 158.196.192.32;branch=z9hG4bK9ec4c0248acd48724710d7;rport
From: "SJphone" <sip:[email protected]>;tag=27df31582de
To: <sip:[email protected]>
Contact: <sip:[email protected]>
Call-ID: C317880624584EB9B1443F8B448CC2830x9ec4c020
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: SJphone/1.65.377a (SJ Labs)
Content-Length: 321
Content-Type: application/sdp
(v): 0
(o): - 3428274950 3428274950 IN IP4 158.196.192.32
(s): SJphone
(c): IN IP4 158.196.192.32
(t): 0 0
(m): audio 49162 RTP/AVP 18 3 8 0
(a): rtpmap:18 G729/8000
(a): rtpmap:3 GSM/8000
(a): rtpmap:8 PCMA/8000
(a): rtpmap:0 PCMU/8000
•
První řádek nám říká, že se jedná o zprávu INVITE, jež je užívána k sestavení spojení. URI
na prvním řádku sip:[email protected] se nazývá Request URI a obsahuje URI
61
•
•
•
•
•
•
3.3.2
dalšího skoku zprávy (next hop, směruje se dle RURI). V tomto případě bude hostitelem
asterisk.vsb.cz a hledá se uživatel 0738331699.
SIP žádost obsahuje v hlavičce jedno nebo více polí Via, jež jsou použity k záznamu cesty
žádosti. Následně jsou užívány ke směrování SIP odpovědí přesně takovou cestou, jakou
byly odeslány. Naše INVITE zpráva obsahuje jedno pole Via, to bylo vytvořeno UA, který
odeslal žádost. Z pole Via můžeme říct, že odpověď bude doručena UA na IP adresu
158.196.192.32 a port 5060.
Pole hlavičky From a To identifikuje iniciátora volání (volající) a příjemce (volaného). Pole
From obsahuje parametr tag, který slouží jako identifikátor dialogu a bude popsán později.
Pole hlavičky Call-ID je identifikátor dialogu a jeho cílem je identifikovat zprávy náležející
jednomu volání. Takovéto zprávy mají stejný identifikátor Call-ID.
V rámci dialogu jsou jednotlivé žádosti očíslovány v poli CSeq. Protože žádosti mohou být
odeslány nespolehlivým přenosem, může docházet k opakováním a pořadové číslo je nutné,
aby příjemce mohl detekovat opakování a správně tak selektovat žádosti.
V SIP hlavičce je dále pole Contact obsahující IP adresu a port, na kterém odesílatel očekává
další žádosti odesílané volaným, obě strany si vymění své kontakty v žádosti a odpovědi a
pokud bude chtít jedna ze stran poslat další požadavek, např. ukončení spojení BYE, tak
nemusí posílat žádost na SIP Proxy, ale pošle ji přímo. Samozřejmě že je možnost ovlivnit i
cestu dalších žádostí v dialogu, ale to si vysvětlíme v dalších kapitolách.
Hlavička zprávy je oddělena od těla zprávy prázdným řádkem. Tělo zprávy žádosti INVITE
obsahuje popis médií vyhovující odesílateli a kódované v SDP. Z SDP jsme se dozvěděli,
kdo poslal nabídku SDP a na které IP má být tok médií ukončen. A co se týče vlastní nabídky,
tak ta obsahuje čtyři kodeky seřazené dle preferencí G.729, GSM, PCM (A-law) a PCM (μlaw).
SIP metody
Žádosti neboli metody jsou obvykle užívány k inicializaci procedury (sestavení, aktualizaci či
ukončení spojení). V jádru SIP protokolu je dle RFC 3261 specifikováno šest metod, které jsou
následující:
•
•
•
•
•
INVITE je žádost o inicializaci spojení nebo změnu parametrů již probíhajícího spojení (reINVITE);
ACK je metoda potvrzující přijetí konečné odpovědi na žádost INVITE. Sestavení relace
používá „3-way hand-shaking“, volaný periodicky opakuje odpověď (např. 200 OK), dokud
nepřijme ACK, což indikuje, že odpověď byla doručena. Metoda ACK má řadu výjimek v
pravidlech gramatice SIPu, které budou zmíněny později;
BYE je zpráva užívána k ukončení sestaveného spojení;
CANCEL se používá ke zrušení sestavovaného spojení, když není sestaven dialog, volaný
ještě nepotvrdil konečnou odpovědí žádost INVITE a volající chce zrušit sestavování spojení;
REGISTER je žádost registrace anebo odregistrování uživatele, sváže se logická jmenná
adresa uživatele s jeho fyzickým umístěním (IP adresa a port), konkrétně jde o položky
FROM a CONTACT ze SIP hlavičky. Registrace jsou časově limitovány a je nutné je
periodicky obnovovat;
62
•
OPTIONS je speciální typ metody k zjištění vlastností SIP zařízení, má stejnou strukturu jako
INVITE, ale spojení není sestavováno, pouze se přijme odpověď. Využívá se např. nejen ke
zjištění podporovaných funkcí, ale SIP Proxy může periodickými dotazy zjišťovat mezi
registracemi, zda SIP UA odpovídá a je dostupný anebo naopak SIP UA může periodicky
posílat Options přes NAT k udržení záznamu překladu a tím pádem průchodnosti zvenčí.
Kromě výše vysvětlených šesti základních metod existují i další žádosti, které byly definovány
dodatečně v některých dalších RFC, viz. níže. Kupříkladu vyžadujeme-li funkcionalitu spolehlivé
doručování dočasných odpovědí (PRACK), tak je nutné zjistit, zda konkrétní zařízení podporuje RFC
3262. Pro základní telefonii postačí RFC 3261, pro přehled si uvedeme seznam metod užívaných
SIPem s odkazem na konkrétní RFC:
•
•
•
•
•
•
sestavení relace INVITE RFC 3261,
potvrzení na INVITE ACK RFC 3261,
ukončení existující relace BYE RFC 3261,
zrušení dosud nevyřízené žádosti CANCEL RFC 3261,
registrace (svázáno s URI) REGISTER RFC 3261,
získání schopností entity OPTIONS RFC 3261,
Další metody, které nejsou v RFC 3261, jsou následující:
•
•
•
•
•
•
•
•
3.3.3
přenos informací během relace INFO RFC 2976,
potvrzení dočasné (1xx) odpovědi PRACK RFC 3262,
přihlášení k upozornění na událost SUBSCRIBE RFC 3265,
doručení o události NOTIFY RFC 3265,
aktualizace stavu relace UPDATE RFC 3311,
zprávy pro instant messaging MESSAGE RFC 3428,
požadavek jiného UA k relaci REFER RFC 3515,
aktualizace prezence PUBLISH RFC 3903.
SIP odpovědi
Jestliže UAS obdrží žádost, tak na žádost odesílá odpověď. Každá žádost musí být zodpovězena,
výjimkou je metoda ACK, což je žádost, která má význam potvrzení doručení odpovědi na INVITE.
Naproti tomu PRACK (Provisional Acknowledgement) se potvrzuje. Odpovědi jsou svou strukturou
velmi podobné žádostem, kromě prvního řádku [col]. První řádek odpovědi obsahuje verzi protokolu
(SIP/2.0) a kód odpovědi (reply code). Typická odpověď vypadá následovně:
Status-Line: SIP/2.0 200 OK
Via: SIP/2.0/UDP 158.196.192.32;branch=z9hG4bK9ec4c02048ace1a554;rport=5060
From: "SJphone" <sip:[email protected]>;tag=164235a64f6
To: <sip:[email protected]>;tag=as04503766
Call-ID: 7798248D73F3443CABCD68EE653C791C0x9ec4c020
CSeq: 2 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
63
Content-Length: 312
(v): 0
(o): root 4648 4648 IN IP4 158.196.146.12
(s): session
(c): IN IP4 158.196.146.12
(t): 0 0
(m): audio 14290 RTP/AVP 0 8 3
(a): rtpmap:0 PCMU/8000
(a): rtpmap:8 PCMA/8000
(a): rtpmap:3 GSM/8000
Kód odpovědi je celé číslo z rozsahu 100 až 699 a označuje typ odpovědi. Celkem je definováno
6 tříd odpovědí, buď jsou informativní 1xx anebo finální 2xx-6xx:
•
•
•
•
•
•
1xx jsou dočasné informativní odpovědi, které jsou odesílány na žádosti, které byly přijaty,
ale výsledek zpracování ještě není znám, na základě této odpovědi musí odesílatel zastavit
opakování odesílání dané žádosti. Obvykle SIP Proxy servery odesílají odpovědi s kódem
100 (Trying), jestliže začínají zpracovávat INVITE a UA odesílají odpovědi s kódem 180
(Ringing), které oznamují vyzvánění volaného, kód 183 Session Progress má stejný význam
jako 180, ale je doplněn o popis médií (SDP),
2xx jsou pozitivní finální odpovědi, je to poslední odpověď, kterou odesílatel na svou
žádost dostává, vyjadřuje výsledek zpracování konkrétní žádosti. Odpovědi s kódy 200 až
299 oznamují, že požadavek byl akceptován a úspěšně zpracován, například odpověď 200
OK je vyslána, jestliže uživatel akceptuje žádost INVITE. V případě větvení zprávy INVITE
můžeme dosáhnout několik UAS a každý z nich bude akceptovat žádost. V tomto případě je
každá odpověď rozlišena parametrem tag v poli To. Každá odpověď probíhá v odlišném
dialogu s jedinečným identifikátorem dialogu,
3xx odpovědi jsou užívány k přesměrování. Tyto odpovědi dávají informaci o nové poloze
uživatele nebo alternativní službě, která má být použita. Pokud Proxy přijme žádost a
nezpracuje ji z nějakého důvodu, tak vyšle volajícímu v odpovědi požadavek na přesměrování
a vloží do odpovědi jiné umístění, které má být kontaktováno. Může to být jiná Proxy nebo
aktuální umístění volajícího (z lokalizační databáze vytvořené registrar serverem). Volající
následně znovu vyšle žádost na nové umístění, odpovědi 3xx jsou konečné,
4xx jsou negativní konečné odpovědi a znamenají problém na straně klienta. Žádost
nemohla být zpracována, protože obsahuje chybnou syntaxi,
5xx znamenají problém na straně serveru. Žádost je zřejmě v pořádku, ale server selhal při
zpracování, klient by měl obvykle požadavek zkusit znovu,
6xx představuje globální chybu a tento kód je vysílán, pokud žádost nemůže být splněna na
žádném serveru, to je odpověď obvykle vysílaná serverem, když má informaci o konkrétním
uživateli, např. UA vysílá 603 Decline response, když odmítá žádost o sestavení spojení,
Kromě odpovědi odpovídající třídy obsahuje první řádka popis reason phrase, obsažený kód je
určen ke zpracování, což je snadno analyzovatelné a popis jasně oznamuje výsledek. UA může
popis zobrazit uživateli. Přiřazení žádosti k odpovědi je na základě pole CSeq v hlavičce, kromě
64
pořadového čísla obsahuje také metodu korespondující žádosti, v našem případě to byla žádost
INVITE. Níže je uveden seznam odpovědí, se kterými se můžeme setkat v SIP protokolu:
1xx = informational responses
* 100 Trying
* 180 Ringing
* 181 Call Is Being Forwarded
* 182 Queued
* 183 Session Progress
2xx = success responses
* 200 OK
* 202 accepted: Used for referrals
3xx = redirection responses
* 300 Multiple Choices
* 301 Moved Permanently
* 302 Moved Temporarily
* 305 Use Proxy
* 380 Alternative Service
4xx = request failures
* 400 Bad Request
* 401 Unauthorized: Used only by registrars. Proxys should use proxy authorization 407
* 402 Payment Required (Reserved for future use)
* 403 Forbidden
* 404 Not Found: User not found
* 405 Method Not Allowed
* 406 Not Acceptable
* 407 Proxy Authentication Required
* 408 Request Timeout: Couldn't find the user in time
* 410 Gone: The user existed once, but is not available here any more.
* 413 Request Entity Too Large
* 414 Request-URI Too Long
* 415 Unsupported Media Type
* 416 Unsupported URI Scheme
* 420 Bad Extension: Bad SIP Protocol Extension used, not understood by the server
* 421 Extension Required
* 423 Interval Too Brief
* 480 Temporarily Unavailable
* 481 Call/Transaction Does Not Exist
* 482 Loop Detected
* 483 Too Many Hops
* 484 Address Incomplete
* 485 Ambiguous
* 486 Busy Here
* 487 Request Terminated
* 488 Not Acceptable Here
* 491 Request Pending
* 493 Undecipherable: Could not decrypt S/MIME body part
65
5xx = server errors
* 500 Server Internal Error
* 501 Not Implemented: The SIP request method is not implemented here
* 502 Bad Gateway
* 503 Service Unavailable
* 504 Server Time-out
* 505 The server does not support this version of the SIP protocol
* 513 Message Too Large
6xx = global failures
* 600 Busy Everywhere
* 603 Decline
* 604 Does Not Exist Anywhere
* 606 Not Acceptable
INVITE sip:[email protected] SIP/2.0
SIP/2.0 200 OK
Via: SIP/2.0/UDP here.com:5060
From: AG <sip:[email protected]>;tag=123
To: BG <sip:[email protected]>
Call-ID: [email protected]
Cseq: 1 INVITE
Contact: AG <sip:[email protected]>
Content-Length: 147
Via: SIP/2.0/UDP here.com:5060
From: AG <sip:[email protected]>;tag=123
To: BG <sip:[email protected]>;tag=65a35
Cseq: 1 INVITE
Contact: BG <sip:[email protected]>
Content-Length: 134
v=0
o=UserA 28908 28908 IN IP4 here.com
s=Session SDP
c=IN IP4 100.101.102.103
t=0 0
m=audio 49 172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=UserB 28908 28908 IN IP4 there.com
s=Session SDP
c=IN IP4 110.111.112.113
t=0 0
m=audio 3456 172 RTP/AVP 0
Obr 3.5 Žádost a odpověď.
Na obr. 3.5 jsou pole žádosti INVITE a konečné odpovědi na ni 200 OK, zobrazeny jsou i obsahy
SDP, obě strany si vyměnily na sebe kontakty, nabídku SDP a odpověď na ní, použit bude kodek
PCM G.711 µ-law.
3.3.4
Transakce
Transakce jsou v SIPu velmi důležité pro tok zpráv a zacházení s nimi, neboť většina SIP prvků
jsou transakční stroje. Ačkoliv bylo řečeno, že SIP zprávy jsou posílány sítí nezávisle, tak obvykle
jsou uspořádány do transakcí agenty UA a stavovými SIP Proxy servery.
66
Obr. 3.6. Transakce v SIP protokolu.
Transakce je sekvence SIP zpráv vyměňovaných mezi síťovými SIP prvky. Transakce obsahuje
jednu žádost a všechny odpovědi vztažené k této žádosti. To může znamenat žádnou, jednu nebo i
více dočasných odpovědí a jednu nebo více konečných odpovědí (např. při větvení v Proxy na
zprávu INVITE ). Jestliže byla transakce zahájena žádostí INVITE, pak stejná transakce obsahuje i
zprávu ACK, ale dle RFC 3261 pouze tehdy, jestliže finální odpověď nebyla třídy 2xx, potom ACK
není součástí dané transakce. Důvodem je, že odpověď je zpráva 200 OK, viz. obr. 3.6. Jiná situace
je po přijetí non-2xx odpovědi, např. 407 Proxy Authorization Required, pak by žádost ACK do
transakce patřila a v poli branch byl stejný identifikátor jako u předešlých zpráv stejné transakce.
Především UA jsou zodpovědní za opakování odpovědi 200 OK, dokud nepřijmou ACK. SIP entity,
které sledují tyto transakce, se nazývají stateful, vytvořený stav k žádosti je spojován s transakcí a je
držen po celou dobu trvání transakce. Pokud přichází žádost nebo odpověď, tak je zkoušeno vždy
přiřazení zprávy do probíhající transakce. Aby tato operace byla proveditelná, tak musí ze zprávy
přečíst jednoznačný identifikátor transakce a porovnat jej s identifikátory probíhajících transakcí.
Jestliže takováto transakce existuje, tak dochází k jejímu doplnění o další informace. V předchozím
SIP RFC2543 (SIP 1.0) byl identifikátor transakce odvozován jako hash z důležitých informací v
hlavičce zprávy (zahrnující pole To, From, Request-URI a CSeq), což bylo komplikované a
zpomalovalo zpracování a při testech interoperability bylo zdrojem problémů. V aktuálně používaném
RFC 3261 (SIP 2.0) byl způsob výpočtu identifikátoru transakce zásadně změněn. Namísto
komplikovaného určování z polí hlavičky teď obsahuje SIP zpráva identifikátor přímo v políčku Via s
názvem branch. To je významné zjednodušení, ovšem stále existují staré implementace, které
nepodporují nový způsob určování identifikátoru transakce, proto musí být určování zpětně
kompatibilní s oběma verzemi, noví UA a SIP Proxy musí rozeznat i předešlý způsob, skutečnost v
praxi je ovšem mnohdy jiná. Způsob nového určení transakce poznáme dle začátku řetězce
z9hG4bK v branch identifikátoru pole Via.
67
branch=z9hG4bK9ec4c0248acd48724710d7
Stavový transakční stroj okamžitě odpovídá 100 Trying na přijetí INVITE, čímž se potvrdí
přijetí INVITE a zastaví se případné její opakování, pokud už odpověď 100 Trying byla jednou
zaslána, tak se znovu nepřeposílá. Bezestavový stroj má jiné chování a přepošle vše, co dostane,
neboť si nepamatuje stavy transakce. Rozdíl mezi SIP Proxy pracující s transakcemi nebo bez je
vidět na obr. 3.7.
Alice's
UA
Stateful
Proxy
Stateless
Proxy
Stateful
Proxy
Bob's
UA
INVITE
100 TRYING
INVITE
INVITE
100 TRYING
100 TRYING
INVITE
100 TRYING
180 RINGING
180 RINGING
180 RINGING
200 OK
ACK
200 OK
200 OK
180 RINGING
200 OK
ACK
ACK
Media Session
Obr. 3.7. Rozdílné zacházení se 100 Trying u stavových transakčních strojů.
3.3.5
Dialog
V předchozím kapitole jsme si ukázali dvě transakce, viz. obr. 3.8, jedna transakce obsahovala
zprávu INVITE a odpověď, druhá obsahovala zprávu BYE a následnou odpověď. Obě transakce
však spolu souvisejí a náleží tak do jednoho dialogu, v první verzi SIPu RFC 2543 se používal pro
dialog výraz call-leg.
68
Caller
Callee
INVITE
100 TRYING
Transaction#1
180 RINGING
200 OK
Dialog
ACK
BYE
Transaction#2
200 OK
Obr. 3.8 Dialog.
Dialog bychom mohli definovat jako soubor SIP zpráv peer-to-peer mezi dvěma UA, které mají
vzájemnou spojitost. Dialogy popisují řazení a směrování zpráv mezi dvěma koncovými body.
Dialogy jsou identifikované pomocí pole Call-ID, From (tag) a To (tag). Zprávy, které mají tyto tři
identifikátory stejné, tak náleží jednomu dialogu. Ukázali jsme si, že pole CSeq je užíváno k řazení
zpráv, je používáno k řazení zpráv uvnitř dialogu. CSeq číslo určuje transakci uvnitř dialogu, protože
jsme řekli, že žádost a přidružená odpověď se nazývá transakce. To znamená, že v každém směru
může být uvnitř dialogu aktivní pouze jedna transakce. Mohli bychom také tvrdit, že dialog je
posloupnost transakcí. Pomocí CSeq snadno rozpoznáme zprávy dialogu. Dialogy usnadňují řízení
komunikace, protože UA nedrží stavy dialogu. V uvedeném příkladu zpráva INVITE zahajuje dialog,
neboť inicializuje spojení, všechny zprávy v tomto spojení patří do stejného dialogu, který je ukončen
konečnou odpovědí na žádost BYE. Dialogy jsou vytvářeny generováním odpovědí typu non-failure
(bez návratu chyby), pouze odpovědi typu 2xx a 101-199 jsou schopny sestavit dialog, neboť vrací
značku (tag) v poli To (To tag). RFC 3261 nepřináší zcela jednoznačnou definici, kdy je dialog přesně
sestaven a proto rozeznáváme dva stavy: napůl sestavený (early dialog) a potvrzený dialog
(confirmed dialog). Pokud se hovoří o dialogu, tak jde o potvrzený dialog, zatímco v prvním případě
se vždy uvádí plně jako early dialog. Early dialog je sestaven dočasnou (non-final) odpovědí 101199, potvrzený dialog je sestaven pomocí pozitivní konečné odpovědi 2xx. Dialog při typickém
sestavení spojení projde prvním stavem, než je potvrzen. Všimněme si, že dočasná odpověď typu
100 TRYING neumožňuje sestavit early dialog a v této odpovědi se nepřidává To tag.
3.3.6
SIP časovače a retransmise
Jelikož se v SIP signalizaci používá mnohdy nespolehlivý přenos (UDP), musí být ošetřeny
retransmise žádostí v transakcích. Po odeslání žádosti INVITE klientem se zprávy v transakcích
69
opakují po dosažení časovače T1 a následně vždy po dosažení dvojnásobné doby od poslední
retransmise, tzn. poprvé T1, podruhé 2*T1, dále 4*T1 a 8*T1. Základní časovač T1 je odvozen od
RTT (Round Trip Time) a jeho výchozí hodnota je nastavena na 500 ms. Téměř všechny časovače
jsou od T1 odvozeny a změna T1 se tak do nich promítá.
Tab. 3.1 Časovače dle RFC 3261.
Retransmise se neuplatňují při použití spolehlivého přenosu (TCP). Přijetí dočasné informativní
odpovědi 1xx zastavuje retransmise žádosti INVITE a UAC musí čekat na přijetí dalších odpovědí.
UAS může opakovat dočasnou odpověď 1xx před zasláním finální odpovědi, pokud se používá
nespolehlivý přenos. Každá finální odpověď na INVITE je potvrzena ACK. Na straně UAC je
dohlížen timeout transakce, žádná transakce by neměla trvat déle než 64*T1 (časovač B). Pokud
vyprší časovač A, tak se provede retransmise a časovač se zvedne na 2*T1, pokud i tento čas
vyprší , tak se zase zdvojnásobí. Níže jsou popsány časovače uvedené v RFC 3261.
70
3.3.7
Zabezpečení v SIPu
Protokol SIP je přenášen jako otevřený text a je snadněji analyzovatelný než H.323, který je
kódován v ASN.1 PER. Pro zachycení a nahlídnutí do SIPové komunikace nepotřebujeme
analyzátory, vystačíme si např. s linuxovým příkazem ngrep. Principy způsobu komunikace v SIPu
jsou podobné HTTP a díky této podobnosti se využívají stejné bezpečnostní mechanismy, které
používá právě Hypertext Transfer Protocol [dor].
•
•
•
•
HTTP Basic Authentication je prvním mechanizmem, který zajišťuje autentizaci pomocí
sdíleného hesla. Data nejsou šifrována a není také zaručena integrita zprávy, obsahuje pouze
základní kódování schématem Base64.
HTTP Digest Authentication vychází z předchozí metody s tím rozdílem, že místo přenosu
otevřeného hesla ho šifruje pomocí hashovaní funkce MD5 nebo SHA. Ta funguje tak, že
heslo vytvoří z náhodně generovaného řetězce, loginu a hesla. Tato metoda ověřuje
autenticitu na základě sdíleného hesla. Obsah zprávy se však nijak nešifruje.
Secure MIME (S/MIME) je, jak z názvu vyplývá, zabezpečení tzv. MIME (Multipurpose
Internet Mail Extension). Konkrétně tato metoda zabezpečí obsah zprávy a zaručí i její
integritu. Existuji dva způsoby šifrování obsahu dat MIME. První application/pkcs7-mime
dokáže digitálně podepsat a zašifrovat data. Druhý způsob multipart/signed je podobný
prvnímu s tím rozdílem, že zpráva obsahuje šifrovaná i nešifrovaná data. K ověření
autentizace se používá architektura veřejných klíčů (PKI). Pro utajení obsahu zprávy jsou
využity symetrické kryptografické primitivy (DES, 3DES, AES).
SIPS URI (TLS) využívá architekturu veřejných klíčů pro ověření autentizace. Při použití této
metody se mění prefix identifikační hlavičky na sips. Aby byla zaručena bezpečná
komunikace, používá tato metoda šifrovaný protokol Transfer Layer Security (TLS). Tento
protokol využívá asymetrické šifrování (RSA), symetrické algoritmy (DES, 3DES, AES) a
hashovací funkci. Při použití této metody je kladena podmínka, že protokol TLS je použit na
celé cestě zprávy a pro SIP musí být použit protokol TCP.
Princip používané metody HTTP digest bude prakticky vysvětlen v následující kapitole
zabývající se registrací, u registrace se neautentizovaná zpráva REGISTER odmítá pomocí 401
Unauthorized, v případě INVITE je to 407 Proxy Authentication Required, následně se pošle
REGISTER nebo INVITE s autentizačním řetězcem, který je ověřen. Pokud je použito TLS, tak další
autentizace pomocí HTTP digest je zbytečná a nepoužívá se, neboť už sestavení TLS obsahuje
jeden z kroků, u kterého se klient prokazuje certifikátem a zabezpečení je na mnohem vyšší úrovni.
Řada aplikací volně dostupných na Internetu se dá použít buď ke generování útoků, odposlechu
hovoru či modifikaci paketů spojení, proto je otázka zabezpečení nejen signalizace, ale i vlastního
hovoru velmi důležitá, což je argument pro použití TLS. Například aplikace SCAPY umožňuje nejen
prolomení základních způsobů zabezpečení, ale i modifikaci obsahu paketů v reálném čase. SIPp je
open-source generátor provozu, pomocí kterého zvládneme připravit DoS (Denial of Service) anebo
DDOS útok (distribuovaný DoS). Aplikace voipbot umí pět různých typů útoků a sipdump se sipcrack
umožňují uhodnutí hesla v autentizací s MD5. Zajímavou aplikací s použitím pro testování výkonnosti
SIP serveru anebo pro útoky je VoIPER.
71
3.4
Registrace
Při registraci se sváže User URI z pole From s Device URI z pole Contact hlavičky SIP. Pokud
pole Contact hlavička žádosti Registrace neobsahuje, tak se z Registrar serveru ve 200 OK vrátí
seznam platných registrací k SIP URI z pole From. Device URI nese IP adresu a port, na kterém je
uživatel se svou SIP URI k dosažení, např. pro SIP URI sip:[email protected] může být device URI
sip:[email protected]:5060 . Doba platnosti registrace je dána parametrem expires v hlavičce,
tento čas je Registrar serverem upravován, pokud UAC v návrhu nezadá čas, který by ležel v
povoleném intervalu mezi minimální a maximální dobou registrace na Registrar serveru. Pokud se
pošle nulová hodnota doby registrace expires=0, tak to znamená zrušení registrace, viz. níže.
Request-Line: REGISTER sip:cesnet.cz SIP/2.0
Via: SIP/2.0/UDP 195.168.1.10;branch=z9hG4bK-d8754zdf2acad8754z-;rport
Max-Forwards: 70
Contact: <sip:[email protected];rinstance=45b13194f4a07bb>;expires=0
To: "voznak"<sip:[email protected]>
From: "voznak"<sip:[email protected]>;tag=9043320d
Call-ID: MjY0YzU5OTdiMDYxNTI4YzgzNTIwYzE2NTUzNzgyZGM.
CSeq: 5 REGISTER
User-Agent: X-Lite release 1100l stamp 47546
Authorization: Digest username="voznak",realm="cesnet.cz", nonce="48ad92308a4f8ee",
uri="sip:cesnet.cz",response="6e6f1ca5803c805ac885f8cb4a8a1df1",algorithm=MD5
Content-Length: 0
Odregistrování všech lokalizací konkrétního URI uživatele se docílí tak, že do pole Contact se
zadá znak * a zároveň s nulovou hodnotu do expirace expires=0.
Registrar
Server
UA
A@
B@
C@
REGISTER
401 UNAUTHORISED
REGISTER with AUTH.
200 OK
Obr. 3.9. Registrace s autentizací.
Nepochybně je žádoucí, aby se uživatel při registraci autentizoval. Předpokládejme, že uživatel
obdržel důvěryhodným způsobem uživatelské jméno a heslo, které si uložil ve svém IP telefonu. SIP
používá stejnou metodu autentizace jako HTTP, a to HTTP digest authentication. Metoda spočívá v
tom, že obě strany, jak server tak i klient, mají sdílené tajemství (heslo) a pomocí daných vstupních
parametrů je jednosměrnou funkcí vygenerován otisk (hash). Vlastnost jednosměrné funkce spočívá
72
v tom, že není možné z otisku zpětně získat vstupní proměnné funkce, přesněji řečeno
pravděpodobnost získání vstupů je mizivá a otisk je jedinečný, tzn. neexistují dva stejné otisky pro
různé vstupy hashovací funkce. Pokud hash zaslaná klientem bude souhlasit s řetězcem, který
spočítal server, tak autentizace bude úspěšná a kladně tak vyřízena.
Na obr. 3.9 je znázorněna výměna při registraci s autentizací. Žádost INVITE je odeslána bez
autentizačních údajů na SIP Proxy, ta odmítá odpovědí 401 Unauthorized, v odpovědi posílá bližší
informace k autentizaci. Klient akceptuje zaslané informace a vypočte hash, kterou zašle ve zprávě
REGISTER, tentokrát je úspěšně autentizován a dostává 200 OK s potvrzením registrace.
Status-Line: SIP/2.0 401 Unauthorized
Message Header
Via: SIP/2.0/UDP 195.168.1.10:18188;branch=z9hG4bKd8754z-d8754z-;rport=33209
To: "voznak"<sip:[email protected]>;tag=c10ed4fff3e6fb17efd0bfbdcce87ce2.10f8
From: "voznak"<sip:[email protected]>;tag=f861ac5a
Call-ID: Mzg1M2VlZDRkOWQ5NmJlNzA0MTk1OGNhZDE3MjZiNDg.
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="cesnet.cz", nonce="48ad92c"
Server: Sip EXpress router (0.9.6 (i386/linux))
Content-Length: 0
Request-Line: REGISTER sip:cesnet.cz SIP/2.0
Via: SIP/2.0/UDP 195.168.1.10:18188;branch=z9hG4bK-d8bc45e75b347-;rport
Max-Forwards: 70
Contact: <sip:[email protected]:18188;rinstance=8546638886339213>
To: "voznak"<sip:[email protected]>
From: "voznak"<sip:[email protected]>;tag=f861ac5a
Call-ID: Mzg1M2VlZDRkOWQ5NmJlNzA0MTk1OGNhZDE3MjZiNDg.
CSeq: 2 REGISTER
Expires: 3600
User-Agent: X-Lite release 1100l stamp 47546
Authorization: Digest username="voznak",realm="cesnet.cz",nonce="48ad92c",
uri="sip:cesnet.cz",response="1ca1df39a865353b8703343cbdfbb062",algorithm=MD5
Content-Length: 0
Na příkladu výše je odpověď 401 Anauthorized, která obsahuje v odmítnutí výzvu k autentizaci
a podává klientovi realm a nonce pro hashovací funkci. Klient posílá žádost REGISTER znovu, ale
tentokrát již s autentizačními údaji, je použit algoritmus MD5, pro hash se použije username, realm,
nonce a password, což je sdílené tajemství. Výsledný hash je v poli response.
3.5
Směrování
Zásadním problémem směrování je, jak z URI adresy určit cíl. SIP v tomto směru může využít
buď DNS anebo statických směrovacích záznamů a dalších údajů lokalizace UA v databázi, do které
se dostaly přes Registrar server. Pokud se cíl určí a spojení je uskutečněno, tak se objevují další
zásadní otázky. Kudy budou směrovány další žádosti, zda by měla SIP Proxy být prostředníkem v
komunikaci a zůstávat v SIP signalizační trase či nikoliv.
73
Noční můrou každého signalizačního protokolu je vznik nekonečné smyčky (zacyklení), v tomto
ohledu má SIP dva silné nástroje. Prvním je detekce smyček pomocí branch parametru v poli Via,
který si umí zapamatovat ovšem pouze stateful SIP Proxy, pomocí branch zjistí, že zpráva patří do
jedné transakce a může tak limitovat počet zpráv v transakci. Druhým nástrojem je povinné pole
Max- Forwards v SIP hlavičce, které se snižuje o jedničku na každém skoku (výchozí hodnota je
obvykle 70), tzn. s každým průchodem přes SIP Proxy se hodnota sníží, až dosáhne 0, tak SIP Proxy
odešle 483 Too Many Hops a zpráva zanikne.
V obr. 3.10 je znázorněn tok zpráv v rámci jednoho SIP Proxy serveru, ze kterého je čitelná
souslednost konkrétních žádostí a odpovědí. Směrování mezi SIP Proxy servery je obsahem dalších
kapitol.
Obr. 3.10. Tok SIP zpráv v rámci SIP Proxy
3.5.1
Směrování dle RURI a Via
Žádosti jsou směrovány dle prvního řádku (RURI) SIP metody a odpovědi na žádost dle prvního
záznamu ve Via., viz. obr. 3.11. Alice volá Boba, odesílá se INVITE, původní SIP URI se zapisuje do
pole To , kde je logická adresa příjemce AOR (Address of Record) a neměl by ho po cestě nikdo
změnit. První řádek obsahující RURI (Request URI) může SIP Proxy změnit dle aktuálních
směrovacích informací, INVITE nakonec zastihne Boba na sip:[email protected] . Alicin
UA zapisuje do pole Via na první řádek sám sebe (a.example.com nebo svou IP), každá další Proxy
po cestě udělá to samé, opět se vepíše na první řádek, a tak INVITE, který dostane Bob, bude mít
74
čtyři záznamy ve Via, viz. obr. 3.11. Jelikož odpověď je směrována dle Via, tak prochází stejnou
cestou jako žádost, každý první záznam je z Via odstraněn ihned po přijetí odpovědi SIP Proxy, a tak
je aktuální informace ve Via vždy první. Jakmile si koncové komunikující strany vymění na sebe
kontakty (pole Contact v hlavičce), tak další žádosti mohou být odesílány napřímo. Ovšem i tato
cesta se dá ovlivnit, viz. další kapitola.
[email protected]
INVITE
Via: a.example.com
Via: a.example.com
[email protected]
[email protected]
Via: y1.yahoo.com
Via: a.example.com
Via: y1.yahoo.com
Via: a.example.com
Via: sip.columbia.edu
Via: y1.yahoo.com
Via: a.example.com
Via: y1.yahoo.com
Via: a.example.com
Via: cs.columbia.edu
Via: y1.yahoo.com
Via: a.example.com
[email protected].
columbia.edu
[email protected]
200 OK
Via: cs.columbia.edu
Via: y1.yahoo.com
Via: a.example.com
Obr. 3.11. Směrování žádostí a odpovědí.
3.5.2
SIP trapezoid
SIPu trapezoid je typickým příkladem směrování zpráv v SIPu, předpokládáme, že Alice
(sip:[email protected]) volá Boba z jiné domény (sip:[email protected]). INVITE je zaslán na SIP
Proxy domény atlanta.com, která vyhledá SIP Proxy obsluhující doménu biloxi.com a tam INVITE
odešle, SIP Proxy domény biloxi.com zná umístění Boba a přepošle tedy INVITE Bobovi. Odpovědi
jdou stejnou cestou jako žádost dle položky Via. ACK je další žádostí (potvrzení doručení finální
odpovědi) a ta je zaslána přímo Bobovi dle pole Contact. Alice provede hovor s Bobem a relaci
ukončí Bob odesláním žádosti BYE, která odchází na Alici přímo dle pole Contact. Tok zpráv
připomíná geometrický útvar trapezoid, viz. obr. 3.12. Následně se podíváme do hlaviček SIP zpráv
75
při sestavení spojení a popíšeme si, jak prvky na trase pracují s vybranými položkami hlavičky (bez
SDP, popis médií je obsahem samostatné kapitoly), budeme pracovat se stateful SIP Proxy. První
řádek obsahuje Request-URI a tato URI je zapsána do pole To jako AOR, tam nebude měněna. Do
Via se zapíše odesílatel a přidá branch pro identifikaci transakce, když se mu vrátí odpověď se
stejným branch , tak ji zařadí do této transakce.
IN
V
TE
VI
IT
E
IN
Obr. 3.12. SIP trapezoid.
Do pole From zapíše odesílatel svou logickou SIP URI (AOR), přičemž text před úhlovými
závorkami se zobrazuje na displeji jako textová identifikace odesílatele. Do pole Contact zapíše
odesílatel svou device SIP URI, na které je k zastižení. Je vytvořeno nové jedinečné Call-ID, pořadí
transakce Cesq a za ním název metody, nakonec je v hlavičce odkaz na tělo SDP (v naší ukázce
odebráno).
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Content-Length: 142
INVITE dorazil na SIP Proxy atlanta.com a jelikož je statefull, tak ihned odesílá 100 TRYING.
Odpověď 100 TRYING obsahuje stejné hodnoty To, From, Call-ID, Cseq jako v přijatém INVITE.
Parametr received je přidán do pole Via , kde SIP Proxy doplní stroj , ze kterého byla žádost přijata
pc33.atlanta.com (může být i IP).
76
SIP/2.0 100 Trying
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8;received=192.0.2.1
CSeq: 314159 INVITE
Content-Length: 0
SIP Proxy atlanta.com najde SIP Proxy, která obsluhuje doménu biloxi.com, ve které je volaný
Bob. Nejdříve zjistí, zda už nemá destinaci ve své lokalizační databázi a pokud ne, tak provede
vyhledání v DNS (DNS lookup), bude se hledat SRV záznam, ten obsahuje identifikaci stroje, který
poskytuje službu SIP v dané doméně. INVITE teď SIP Proxy přepošle na zjištěnou cílovou SIP Proxy,
přičemž připíše parametr received do prvního záznamu ve Via, následně zapíše sebe jako první
záznam ve Via a sníží hodnotu v položce Max-Forwards. Další položky SIP hlavičky zůstávají
nezměněny.
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
Max-Forwards: 69
CSeq: 314159 INVITE
Content-Length: 142
INVITE byl přijat SIP Proxy biloxi.com, která ihned odesílá 100 TRYING, obdobně
předchozím kroku je přidán parametr received do Via.
jako v
SIP/2.0 100 Trying
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
CSeq: 314159 INVITE
Content-Length: 0
SIP Proxy biloxi.com vyhledává ve své lokalizační databázi záznam Boba, který byl vložen při
registraci, v lokalizační databázi je device URI z pole Contact svázána s logickou URI
sip:[email protected]. Proxy biloxi.com odesílá INVITE Bobovi, přičemž připíše received do prvního
záznamu ve Via, následně zapíše sebe jako první záznam ve Via a sníží hodnotu v položce MaxForwards, zbytek hlavičky nemění.
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
77
Max-Forwards: 68
CSeq: 314159 INVITE
Content-Length: 142
Dále si ukážeme obsah odpovědi 180 RINGING odesílanou z Bobova UA. Bobův UA vyzvání a
odesílá 180 RINGING, do hlavičky připíše received do prvního záznamu ve Via a přidává tag do
pole To. Ačkoliv dialog není ještě sestaven, tak jsou už definovány všechny tři části, dle kterých se
identifikuje (Call-ID, from Tag a to Tag). Do pole Contact zapisuje Bob svou device URI, na které je k
zastižení, přičemž v příchozím INVITE získal kontakt na Alici.
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1;received=192.0.2.3
To: Bob <sip:[email protected]>;tag=a6c85cf
CSeq: 314159 INVITE
Odpověď 180 RINGING je přeposílána přes SIP Proxy Alici, přičemž každá SIP Proxy po přijetí
smaže první řádek v pořadí ve Via, a přepošle na další stroj v pořadí ve Via, odpověď se tak
postupně dostane až k odesílateli žádosti. Bobův UA vyzvání a na displeji zobrazuje text z pole From
přijatý v INVITE, tzn. vidí na displeji nápis Alice. Po přijetí volání odesílá Bobův UA odpověď 200 OK
s obdobnou konstrukcí jako 180 RINGING, akorát se posílá i SDP, což v ukázce teď není. Jelikož
jde o odpověď finální, tak se ukončuje transakce mezi biloxi.com a Bobem identifikovanou
branch=z9hG4bK4b43c2ff8.1, pořadí ukončené transakce je dané polem CSeq: 314159 INVITE.
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1;received=192.0.2.3
CSeq: 314159 INVITE
Content-Length: 131
Přijatá odpověď 200 OK je přeposlána na SIP Proxy atlanta.com a ukončí transakci mezi
biloxi.com a atlanta.com branch=z9hG4bK77ef4c2312983.1 se CSeq: 314159 INVITE. Nakonec je
200 OK přeposlána ze SIP Proxy atlanta.com Alici a ukončí na obou strojích transakci
78
branch=z9hG4bKnashds8 se CSeq: 314159 INVITE. Alicin UA přestává indikovat vyzvánění a
kontrolní vyzváněcí tón umlkne, Alice může začít mluvit.
Dokud Bobův UA neobdrží žádost ACK, tak nebude mít jistotu, že odpověď 200 OK byla
doručena a bude opakovaně odesílat 200 OK (retransmise). ACK žádost je zaslána přímo na Bobův
UA a obchází obě SIP Proxy, k tomuto dochází, protože obě strany si uložily na sebe kontakty z pole
Contact SIP hlaviček. Jelikož ACK nepatří do předchozí transakce, tak se vytvoří nový
branch=z9hG4bKnashds9, ale nezvedá se Cseq, neboť na žádost ACK není žádná odpověď a
nevytváří tak novou transakci. Jedná se o stejný dialog, a tak se musí zachovat značky From tag, To
tag a Call-ID.
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9
Max-Forwards: 70
CSeq: 314159 ACK
Content-Length: 0
Hovor ukončí Bob, zavěsí a jeho UA odesílá žádost BYE, opět přímo na Alici. Jedná o novou
transakci, takže se zvedne Cseq a zachová se From tag, To tag a Call-ID (patří do dialogu). Po
přijetí finální odpovědi 200 OK na BYE se dialog ukončí.
BYE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
Max-Forwards: 70
From: Bob <sip:[email protected]>;tag=a6c85cf
To: Alice <sip:[email protected]>;tag=1928301774
CSeq: 314160 BYE
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
From: Bob <sip:[email protected]>;tag=a6c85cf
To: Alice <sip:[email protected]>;tag=1928301774
CSeq: 314160 BYE
Content-Length: 0
3.5.3
Udržení SIP Proxy v signalizační trase
V předchozí kapitole byly další žádosti v dialogu zasílány přímo mezi koncovými účastníky
spojení a signalizace tak obcházela SIP Proxy. Nástrojem, který v SIPu umožní zachovat libovolný
prvek v signalizační trase během celého dialogu, je pole Record-route SIP hlavičky pro uložení
záznamu o cestě a pole Route, dle kterého se žádost směruje .
79
Do hlavičky žádosti INVITE se vloží pole Record-route obsahující záznam prvku, který chceme
udržet v trase, tzn. že SIP Proxy do INVITE přidá sebe např. p1.atlanta.com a pokud INVITE
prochází další SIP Proxy, která se chce udržet v trase, tak se opět zapíše do hlavičky jako např.
p2.biloxi.com, v INVITE nám tedy přibude:
Record-route: <sip:p2.biloxi.com;lr>
Record-route: <sip:p1.atlanta.com;lr>
Without record routing
UA1
SIP Proxy
With record routing
UA2
UA1
BYE
SIP Proxy
UA2
BYE
BYE
200 OK
200 OK
200 OK
Obr. 3.13. Rozdíl v komunikaci při použití Record-route pole
INVITE dorazil cílovému příjemci, pokud je detekováno pole Record-route , tak UA si nastaví
cestu odesílání žádostí dle seznamu URI v Record-route seřazeném tak, jak byly zapsány v přijatém
INVITE. Poté UA zkopíruje Record-route položky do odpovědi 180 RINGING a ta putuje původnímu
odesílateli INVITE, v odpovědi nikdo nesmí Record-Route změnit. Příjemce odpovědi si nastaví cestu
odesílání žádostí dle seznamu Record-route v obráceném pořadí. Pro další krok, je nutné vysvětlit
dva přístupy ke směrování SIP žádostí:
•
•
Strict routing přepíše RURI (Request-URI, první řádek SIP žádosti) dle údaje v Route poli
hlavičky, přepisuje RURI na každém skoku a prochází jen přes servery uvedené v Route poli
hlavičky;
Loose routing je metoda která se mnohem více užívá a její aplikaci vyjadřuje parametr lr v poli
Record-Route či Route. V tomto případě se nepřepisuje RURI, ale žádost se směruje dle
URI v Route poli hlavičky, na každém skoku se dané URI z Route hlavičky odstraní, až
neexistuje žádné URI v poli Route a potom se odsměruje dle RURI.
Další žádost (např. ACK) odešle UA tak, že sestaví Request-URI standardně z pole Contact v
odpovědi na INVITE, ale vytvoří Route pole v hlavičce ACK, které bude obsahovat:
Route: <sip:p1.atlanta.com;lr>, <sip:p2.biloxi.com;lr>
Údaje byly získány v Record-route a pořadí bylo obráceno (jelikož údaje byly získány z odpovědi).
Žádost je odsměrována dle prvního URI v route hlavičce. ACK tak dorazí na SIP Proxy
p1.atlanta.com, kde je odstraněn první záznam v pořadí z pole Route a na další je ACK odesláno, a
80
tak dorazí na SIP Proxy p2.biloxi.com, kde je opět odstraněn první záznam v pořadí, a jelikož je
Route pole prázdné, tak se dále směruje dle RURI.
3.6
SDP- protokol popisu relace
SDP je Session Description Protocol, který obecně slouží k popisu kterékoliv relace a je se SIP
signalizací velmi často používán. Používá se často se SIPem a proto se v souvislosti se SIPem
objevuje označení SIP/SDP. SDP protokol prošel třemi zásadními verzemi:
•
•
•
Session Description Protocol, RFC 2327 z roku 1998 je původní verze;
Support for IPv6 in Session Description Protocol (SDP), RFC 3266 z roku 2002 je aktualizací
RFC 2327 a rozšířením o IPv6;
Session Description Protocol, RFC 4566 z roku 2006 je nahrazením obou předešlých,
uvolněním RFC 4566 zastaraly obě RFC 2327 i 3266, ale je zde zpětná kompatibilita, tzn. že
implementace dle RFC 4566 dokáže porozumět starším verzím.
SDP se skládá z řádků obsahující text ve formě položek typ a hodnota oddělených rovnítkem,
položky, u kterých je symbol *, jsou nepovinné:
<type>=<value>
Položky jsou rozděleny do třech skupin:
•
•
•
Session description, popis relace,
Time description, popis časování,
Media description, popis médií.
Následně si projdeme seznam položek SDP dle skupin uvedených RFC 4566. Skupina Session
description obsahuje položky v,o,s,i,u,e,c,b,z,k,a, kde:
•
•
•
•
•
•
•
•
v= (protocol version), vždy je nastaveno v=0,
o= (owner/creator and session identifier), označuje iniciátora relace a má následující syntaxi:
o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
s= (session name), název relace, pole je povinné a nesmí být prázdné, často se do něj
zadává mezera, pomlčka anebo tečka,
i=* (session information), textová informace o relaci,
u=* (URI of description), URI adresa odkazující na dodatečné informace k relaci,
e=* (email address) p=* (phone number), kontaktní e-mail a tel.č.,
c=* (connection information - not required if included in all media), udává informace o
připojovaném koncovém bodu relace ve formátu
c=<nettype> <addrtype> <connectionaddress>,
b=* (bandwidth information), informace o využívaném pásmu,
81
•
•
•
z=* (time zone adjustments), ošetřuje posuny času, dají se naplánovat opakované přechody
letního a zimního času.
k=* (encryption key), pokud je SDP transportován přes důvěryhodný transportní kanál, tak
může být pole k využito pro zprostředkování výměny klíčů ve formátu
k=<method>:<encryption key>,
a=* (zero or more session attribute lines), rozšiřující atributy ve formátu a=<attribute>:<value>,
např. a=recvonly.
Skupina Time description obsahuje položky t a r, kde :
•
•
t= (time the session is active), řádek specifikuje v relaci časové značky pro start a stop ve
formátu t=<start-time> <stop-time>, pokud jsou značky nastaveny 0 0, tak jde o permanentní
přehrávání relace,
r=* (zero or more repeat times), časy opakování relace ve tvaru r=<repeat interval> <active
duration> <offsets from start-time>,
Skupina Media description obsahuje položky m, c, b, k, a, kde:
•
•
•
•
•
3.6.1
m= (media name and transport address), SDP může obsahovat více m řádků, každý je
chápán jako nabídka jednoho toku, který se udává ve formátu m=<media> <port> <proto>
<fmt> , jako média se uvádí audio, video, text, application nebo message, port udává
transportní port a fmt je popis formátu médií,
c=* (connection information - optional if included at session-level),
b=* (bandwidth information) ,
k=* (encryption key) ,
a=* (zero or more media attribute lines).
Konstrukce položek SDP pro komunikaci SIP/SDP
Povinnými položkami hlavičky SDP jsou řádku v, o, s, t, m :
v=0
o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-addr.>
s= název relace
t= 0 0
m=m=<media> <port> <proto> <fmt>
Popis médií v m řádku se obvykle doplňuje nepovinnými atributy, tyto atributy jsou specifikovány
v dalších RFC a jde o tyto atributy:
•
•
•
•
•
a=ptime:<packet time>, [RFC4566]
a=rtpmap:<payload type> <encoding name>/<clock rate> <encoding parameters>, [RFC4566]
a=orient:<orientation>, [RFC4566]
a=framerate:<frame rate>, [RFC4566]
a=quality:<quality>, [RFC4566]
82
•
•
•
•
•
•
•
•
•
•
•
•
•
a=fmtp:<format> <format specific parameters>, [RFC4566]
a=maxptime:<maximum packet time>, RFC3267, RFC4566
a=curr:<precondition-type> <status-type> <direction-tag>, [RFC3312]
a=des:<precondition-type> <strength-tag> <status-type> <direction-tag>,[RFC3312]
a=conf:<precondition-type> <status-type> <direction-tag>, [RFC3312]
a=mid:<identification-tags> , [RFC3388]
a=rtcp:<port> , [RFC3605]
a=crypto:<tag> <crypto-suite> <key-params> [<session-param>] , [RFC4568]
a=label:<pointer> , [RFC4574]
a=floorctrl:<role> ,[RFC4583]
a=confid:<conference-id> , [RFC4583]
a=floorid:<token> ,
[RFC4583]
a=content:<mediacnt-tag> , [RFC4796]
Uvedené atributy jsou použity výhradně pro média, dále existují atributy relace, které neuvádím,
neboť v SIP/SDP se s nimi nepotkáme, ale ještě máme atributy používané na obou úrovních, jak pro
popis médií, tak i relace, a ty si uvedeme:
a=recvonly , [RFC4566]
a=sendrecv , [RFC4566]
a=sendonly , [RFC4566]
a=inactive , RFC3108, RFC4566 (and used in RFC3264)
a=sdplang:<language tag> , [RFC4566]
a=lang:<language tag> , [RFC4566]
a=maxprate:<packet-rate> , [RFC3890]
a=setup:<role> , [RFC4145]
a=connection:<conn-value> , [RFC4145]
a=key-mgmt:<prtcl-id> <keymgmt-data> , [RFC4567]
a=source-filter:<filter-mode> <filter-spec> , [RFC4570]
a=fingerprint:<hash-func> <fingerprint> , [RFC4572]
Níže je uveden příklad obsahu SDP připojeného k SIP žádosti INVITE, ve kterém jsou nabídnuty
dva RTP toky. První je audio s preferencí kodeků PCM µ-law, A-law, GSM, iLBC a G.729, GSM,
očekávaný na portu 13226 a druhý tok je video H.263 na portu 15014, oba toky mají být zakončeny
na IP 158.196.196.146.12.
INVITE sip:[email protected] SIP/2.0 (SIP hlavička, volný řádek a SDP)
v=0
o=root 3177 3177 IN IP4 158.196.146.12
s=session
c=IN IP4 158.196.146.12
t=0 0
m=audio 13226 RTP/AVP 0 8 3 97 18
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:97 iLBC/8000
a=rtpmap:18 G729/8000
83
a=fmtp:18 annexb=no
a=silenceSupp:off - - - m=video 15014 RTP/AVP 34
a=rtpmap:34 H263/90000
Odpověď přišla v SDP připojeného k odpovědi 200 OK na INVITE. Druhá strana sděluje, že
naslouchá G.729 na portu 49154 a IP 158.196.192.32 a druhý m řádek s videem H.263 je vrácen s
portem 0, což znamená odmítnutí celého m řádku (toku), video tedy odesílatel SDP neumožňuje.
SIP/2.0 200 OK (SIP hlavička, volný řádek a SDP)
v=0
o=- 3428552716 3428552716 IN IP4 158.196.192.32
s=SJphone
c=IN IP4 158.196.192.32
t=0 0
m=audio 49154 RTP/AVP 18
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
m=video 0 RTP/AVP 0
3.6.2
Offer/Answer model
Vyjednávání probíhá v modelu označovaného jako Offer/Answer model specifikovaném v RFC
RFC 3264 z roku 2002. Doporučení zavádí následující pojmy:
•
•
•
•
•
Offerer, UA zasílající SDP jako požadavek na vytvoření či modifikaci relace,
Offer, nabídka, kterou zasílá offerer,
Answerer, UA přijímací SDP a zasílající na ní odpověď s popisem vlastních médií,
Answer, je SDP odpověď na nabídku,
Media Stream, je tok médií (např. video, audio, ...), každý media stream je popsán
konkrétním m řádkem a jeho přidruženými atributy.
U SDP řádek s= (subject) nesmí být volný. Jelikož v SIPu relaci vytváříme a ukončujeme pomocí
SIP signalizačních zpráv, tak nepoužíváme start a stop značky v SDP a relaci zde necháváme jako
permanentní pomocí řádku t = 0 0. Pokud odešleme nabídku s SDP, tak dokud není zaslána
odpověď, nesmí se odeslat další SDP nabídka, tzn. probíhá vždy pouze jedno vyjednávání. Jelikož
offer/answer model je řízen protokolem vyšší vrstvy (SIP), tak musí být následující situace ošetřena
na úrovni signalizace SIP:
•
•
UA nesmí generovat novou SDP nabídku, jestliže přijal nabídku, kterou dosud nezodpověděl
nebo neodmítnul;
UA nesmí generovat novou nabídku, jestliže předtím odeslal nabídku a dosud neobdržel
odpověď nebo odmítnutí.
Přesto může dojít výjimečně k situaci, kdy jsou zaslány dvě nabídky (např. INVITE a re-INVITE v
rámci offer/answer), tato situace se označuje jako SIP glare. Jestliže UAS obdržel druhý INVITE,
když předtím odeslal v témže dialogu odpověď na první INVITE s nižším Cseq, tak musí vrátit
84
odpověď 500 Server Internal Error na přijatý druhý INVITE a do hlavičky odpovědi přidat pole RetryAfter s náhodně zvolenou hodnotou v rozsahu 0 až 10. Jestliže UAS dostane INVITE v dialogu, v
rámci kterého má nevyřízený INVITE (před chvíli sám INVITE odeslal a dosud nedostal odpověď),
tak musí na přijatý INVITE vrátit odpověď 491 Request Pending.
Nabídka buď neobsahuje žádný nebo obsahuje jeden anebo více média toků a každý je popsán
v jednotlivém m řádku s přiřazenými atributy. Pokud neobsahuje žádný, tak si strana nabízející SDP
přeje komunikovat později a až získá odpověď na nabídku, tak bude svou nabídku modifikovat (zašle
novou). Pokud obsahuje více m řádků, tak každý musí popisovat jiný typ toku, neboť nelze žádat o
vícenásobný tok stejného typu (paralell stream), typ toku je určen portem, profilem a kodeky, takže
např. můžu si nechat poslat jeden šifrovaný tok a druhý nešifrovaný RTP či poslat jeden tok audio a
druhý video.
Na nabídku jednotlivých toků druhá strana odpovídá tak, že v odpovědi uvede na základě
nabídky své typy toků (port, kodeky), v odpovědi je uveden stejný počet m řádků obsažených v
nabídce a to i ve stejném pořadí. Nabídka toku může být odmítnuta z jakéhokoliv důvodu
(nepodporovaný tok – např. video), odmítá se konkrétní m řádek a to tak, že v odpovědi se v m
řádku nastaví port na hodnotu 0.
85
4
Další metody rozšiřující SIP
Jádro SIP protokolu v RFC 3261 z roku 2002 definuje šest základních žádostí, které jsme si již
uvedli. V dalších letech ale vznikla nutnost definovat nové typy žádostí z důvodu podpory nových
pokročilých služeb anebo jako vylepšení některé ze stávajících funkcí.
4.1
Metoda PRACK (Provisional Response Acknowledgement)
Tato metoda je umožňuje potvrzování i dočasných informativních odpovědí. Jak známo, SIP
potvrzuje finální odpověď na INVITE metodou ACK, čímž je zabezpečeno spolehlivé doručení
obvykle odpovědi 200 OK, ve které je SDP s popisem médií. Pokud by bylo SDP připojeno např. k
odpovědi 180 RINGING (častěji 183 Session Progress), tak vznikne potencionální problém na UDP,
důležitá odpověď se může cestou ztratit a druhá strana nemá popis médií. SIP postrádal
mechanizmus spolehlivého doručování dočasných odpovědí, a proto byla definována nová žádost
PRACK (Provisional Response Acknowledgement) v RFC 3262, obr. 4.1. Na žádost PRACK se
posílá odpověď (200).
S metodou PRACK se často používá i časné zasílaní médií EM (Early Media).V roce 2004 bylo
uvolněno RFC 3960 (Early Media and Ringing Tone Generation) v SIP protokolu. EM se vztahují k
médiím (např. audio, video), které jsou vyměněny předtím, než je konkrétní relace akceptována
volaným účastníkem (před přihlášením). EM mohou být jednosměrné, obousměrné a generovány jak
volajícím, tak volaným či oběma stranami. Typickými příklady EM generovanými volaným jsou
vyzváněcí tóny a ohlášení (např. čekání ve frontě Call Centra).
Základní SIP specifikace RFC 3261 podporuje pouze velmi jednoduchý mechanizmus EM. RFC
3262 používá volitelnou značku 100rel a definuje PRACK metodu. UAS musí odesílat každou non100 dočasnou odpověď spolehlivě, jestliže původní žádost obsahuje vyžadované pole hlavičky se
značkou 100rel. Jestliže UAS tak nemůže učinit, tak musí odmítnou žádost odpovědí 420 Bad
Extension a zahrnout do ní do pole Unsupported obsahující značku 100rel.
86
4.1.1
Použití PRACK při volání do PSTN
Typickým příkladem použití pro PRACK je volání do PSTN, kdy již během vyzvánění mohou
z PSTN přicházet informace, které se přehrávají volajícímu, např. „volaný účastník právě hovoří,
čekejte prosím.“
Obr. 4.1 Uplatnění PRACK při propojení s PSTN.
87
4.1.2
Early Media
SIP na rozdíl od jiných signalizačních protokolů neposkytuje EM indikátor (Early Media Indicator)
a není zde tak informace o výskytu či absenci médií během sestavování spojení (například v ISDN je
to Progress Indicator). Takovýto indikátor v SIPu by mohl být využitý k jasnému deklarování, zda má
být generován lokální kontrolní vyzváněcí tón anebo druhá strana poskytuje in-band kontrolní
vyzváněcí tón nebo nějakou ohlášku.
Pravidla při sestavování spojení jsou následující:
•
•
•
•
•
•
média jsou přehrávána před 200 OK, aby se zamezilo ořezávání prvních slabik hovoru
označovaných termínem media clipping,
užívá se offer/answer model k vyjednání parametrů relace,
nabídka médií může být odeslána v INVITE žádosti a odpověď může dorazit ve 200 OK
nebo případně, nabídka může být odeslána ve 200 OK v případě INVITE bez SDP a
odpověď může být zaslána v ACK,
pokud se používá PRACK ve spojení s metodou UPDATE, také existuje mnohem více
možností, jak pro média vyměnit nabídku a odpověď,
media clipping se vyskytuje, jestliže účastník spojení věří, že relace je již sestavena, ale
proces sestavení spojení ještě není dokončen, potom prvních několik slabik nebo slov
může být ztraceno,
jestliže výměna v modelu offer/answer proběhne ve 200 OK odpovědi a ACK žádosti, pak
je media clipping nevyhnutelný. Volaný účastník začíná mluvit ve stejný okamžik, kdy je
odeslána odpověď 200 OK, ale tento UA nemůže zaslat žádná média, dokud nedostane
odpověď na nabídku ve zprávě ACK.
SIP User Agent (UA) by měl implementovat následující politiky vyzvánění:
•
•
•
dokud odpověď 180 Ringing není přijata, nikdy negenerovat lokální vyzvánění,
jestliže je přijato 180 Ringing, ale nepřicházejí žádné pakety s médii, pak se generuje
lokální vyzváněcí tón,
jestliže je přijato 180 Ringing a přicházejí pakety s médii, pak se negeneruje lokální
vyzváněcí tón, ale přehrávají se přijaté média.
Zajímavostí je pole Alert-Info v hlavičce SIP zprávy. Alert-Info dovoluje specifikovat alternativní
obsah vyzvánění, např. zadáním URL nalinkuji kontrolní vyzváněcí tón umístěný v internetu.
4.2
Metoda UPDATE
Metoda UPDATE je obsahem RFC 3311 z roku 2002 a dovoluje klientům aktualizovat parametry
relace ale bez vlivu na stav dialogu. V tomto smyslu je metoda UPDATE podobná re-INVITE, ale na
rozdíl od re-INVITE může být UPDATE poslán předtím, než je INVITE dokončen (víme, že na INVITE
přichází finální odpověď, která je potvrzena ACK, tím je INVITE dokončen). UPDATE je tak velmi
užitečný pro aktualizaci parametrů relace v rámci časně sestaveného dialogu (early dialog), tím
pádem může volající či volaný modifikovat parametry relace, ještě než je volání vyzvednuto volaným.
88
Re-INVITE nemůže být pro tento účel použit, protože re-INVITE má vliv na stav dialogu. Jestliže
odpověď obsahuje v poli Allow hodnotu UPDATE , tak se UA dozví, že druhá strana UPDATE
podporuje a může metodu použít. UPDATE může být použit jak pro early dialog, tak pro sestavené
dialogy (potvrzené), ale po sestavení dialogu je doporučeno použít re-INVITE.
Obr. 4.2 Příklad použití UPDATE.
V příkladu, viz. obr. 4.2, je vidět INVITE s nabídkou SDP, která je zodpovězena ve 180. Protože
je použito spolehlivé doručování PRACK s odpovědí 200 a následně jde nová druhá nabídka SDP ve
zprávě UPDATE, dialog ještě není plně sestaven (pouze early dialog), tak nabídka je zodpovězena
odpovědí 200. Dále je odeslána další již třetí nabídka SDP opět zodpovězená odpovědí 200 a jelikož
byla v dalším kroku odeslána odpověď 200 na původní INVITE, tak je potvrzeno doručení přes ACK
a dialog je sestaven. Pro další aktualizaci popisu médií by měl být použit re-INVITE. V případě, že
UPDATE není na straně UA podporován, tak se musí použít re-INVITE, ale je nutné vždy čekat na
sestavení dialogu. Využití UPDATE je v situacích, kdy je nutné změnit vlastnosti médií během
sestavování spojení, např. volám-li přes GW do PSTN na fax, tak GW použije EM a zodpoví nabídku
SDP pomocí odpovědi 180 nebo 183, ale následně se detekuje faxová komunikace (tón CNG na 1,1
kHz vysílaný odesílatelem) a ještě během sestavování se může změnit kodek např. na G.711, čili se
použije UPDATE.
89
4.3
Metoda REFER
Metoda REFER je obsahem specifikace RFC 3515 z roku 2003 a umožňuje tzv. 3rd party control ,
což je řízení komunikace třetí stranou. Toto rozšíření SIPu umožňuje odeslat žádost REFER příjemci,
aby sestavil spojení s dalším UA a odesílatel žádosti REFER je informován o zpracování jeho
požadavku. Toto rozšíření je využíváno např. pro realizaci služby Call Transfer (předání hovoru) či
Click to dial (CTD, vytočení kliknutím na webu).
Obr. 4.3 Použití REFER.
Pro metodu REFER byla definována nová položka do SIP hlavičky, a to pole Refer-To indikující,
na které URI má být sestaveno spojení, viz. níže, přičemž konstrukce SIP žádosti REFER je
standardní a do Request-URI se zadává příjemce žádosti REFER.
Refer-To: sip:[email protected]
Jestliže nebyla na REFER generována žádná finální odpověď 4xx-6xx, pak UA musí vrátit
odpověď 202 Accepted předtím, než vyprší REFER transakce. Pro informování odesílatele REFER o
stavu vyřizování žádosti musí být použit mechanizmus NOTIFY.
Příklad v obr. 4.3 ukazuje, že žádost zaslaná agentem A na agenta B je potvrzena pomocí 202
Accepted a agent A je informován v žádosti NOTIFY o stavu vyřizování požadavku. Mezitím agent B
sestavuje spojení dle Refer-To. Postup s obsahem prvních třech zpráv je uveden níže.
90
Message One (F1)
REFER sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK2293940223
From: <sip:[email protected]>;tag=193402342
CSeq: 93809823 REFER
Max-Forwards: 70
Refer-To: (whatever URI)
Contact: sip:[email protected]
Content-Length: 0
Message Two (F2)
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK2293940223
To: <sip:[email protected]>;tag=4992881234
CSeq: 93809823 REFER
Content-Length: 0
Message Three (F3)
NOTIFY sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9922ef992-25
CSeq: 1993402 NOTIFY
Max-Forwards: 70
Event: refer
Subscription-State: active;expires=(depends on Refer-To URI)
Content-Type: message/sipfrag;version=2.0
Content-Length: 20
Dále se začne sestavovat spojení agentem B tam, kam vedla URI adresa v poli Refer-To žádosti
REFER zaslané agentem A.
4.4
Metoda MESSAGE (Instant Messaging)
Metoda MESSAGE (Extension for Instant Messaging) je rozšířením SIP signalizace, které je
obsaženo v RFC 3428 z roku 2002. IM (Instant Messaging) se vztahuje k přenosu zpráv mezi
uživateli a navozuje se prostředí interaktivní komunikace (chat). Tyto zprávy IM komunikace jsou
obvykle krátké, ale není to podmínkou.
UAS přijímá žádost MESSAGE a okamžitě odpovídá konečnou odpovědí. To, že UAS odpověděl
např. 200 OK (úspěšně přijato), však neznamená, že UAS přijatou zprávu zobrazil a už vůbec ne, že
91
si ji někdo přečetl, je to pouze informace o doručení. Odpověd 2xx na žádost MESSAGE nesmí
obsahovat tělo (SDP) a UAS nesmí vložit do odpovědi 2xx kontaktní pole SIP hlavičky Contact.
Odpovědi 4xx nebo 5xx oznamují, že zpráva nebyla úspěšně doručena a odpověď typu 6xx znamená,
že zpráva sice byla úspěšně doručena, ale byla příjemcem odmítnuta.
Velikost žádosti MESSAGE nesmí překročit 1300 bajtů, větší obsah se dá přenést jako část
média relace, tzn. např. textová relace s využitím SDP. MESSAGE nesestavuje dialog, jsou zde
pouze transakce, není zde vytvoření a ani ukončení dialogu. Pokud nám druhá strana bude chtít na
námi zaslaný obsah zprávy reagovat, tak rovněž pošle zprávu MESSAGE. Na obr. 4.4 je příklad
odeslání žádosti MESSAGE přes Proxy.
Obr. 4.4 Použití žádosti MESSAGE.
Obsah žádosti MESSAGE je zobrazen níže, zpráva je zaslána jako text.
MESSAGE sip:[email protected] SIP/2.0
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse
Max-Forwards: 70
From: sip:[email protected];tag=49583
To: sip:[email protected]
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 18
Watson, come here.
4.5
Metody SUBSCRIBE,NOTIFY,PUBLISH (Event/Notification)
V roce 2002 bylo uvolněno RFC 3265 (Session Initiation Protocol Specific Event Notification),
které přináší možnost požadovat zasílání oznámení při výskytu sledované události, schopnost tohoto
oznamování je označována jako Event/Notification. Příkladem použití může být:
92
•
•
•
služba zpětné volání, volaný je obsazen a po změně stavu (uvolnění) obdrží volající notifikaci,
že je volaný volný a spojení se automaticky sestaví,
buddy list, seznam kamarádů založený na přítomnosti-přihlášení (Presence),
MWI (Message Waiting Indications), indikace nově zanechaného vzkazu ve schránce (RFC
3842).
Subscriber
Notifier
SUBSCRIBE
Request state subscription
200 OK
Acknowledge subscription
NOTIFY
Return current state information
200 OK
NOTIFY
Return current state information
200 OK
Obr. 4.5 Příklad typického použití Event/Notification.
RFC 3265 obsahuje dvě nově definované metody:
•
•
SUBSCRIBE, metoda se používá k přihlášení a odběru sledovaných událostí, UA odesílající
SUBSCRIBE následně dostává notifikace obsahující informace o stavech, které jej zajímají, v
poli Expires se nastavuje, jak dlouho má UA notifikace dostávat a pokud chce UA ukončit
odběr těchto oznámení, tak odešle opět SUBSCRIBE s nastavenou nulovou hodnotou
hlavičky Expires=0,
NOTIFY, metodou NOTIFY odesílá UA žádosti odběratelům stavů, kteří se přihlásili k zasílání
upozorňování (přihlásili se pomocí SUBSCRIBE).
Žádost SUBSCRIBE vytváří dialog a UA, který se přihlásil k odběru oznámení na sledovaný stav,
může očekávat přijetí NOTIFY. Dokud nebyla doručena první žádost NOTIFY, tak UA by měl
předpokládat neutrální stav a rovněž musí být připraven na situaci, že již před dokončením transakce
SUBSCRIBE – 200 OK může obdržet NOTIFY. UA zasílající SUBSCRIBE je rovněž odpovědný za
obnovování přihlášení k odběru sledovaného stavu, tzn. před vypršením expirační doby znovu zašle
SUBSCRIBE.
V roce 2004 bylo definováno další rozšíření týkající se Event/Notification RFC 3903 (Session
Initiation Protocol - Extension for Event State Publication), obsahem je definování nového
mechanizmu s využitím metody PUBLISH. V RFC je definován vztah mezi EPA (Event Publication
Agent), což je UA publikující stav a ESC (Event State Compositor), který je zodpovědný za
93
zpracování stavů odesílaných z EPA. ESC je označován jako PA (Presence Agent). EPA zasílá stav
prezence (publikuje) pomocí PUBLISH. Na obr. 4.6 je znázorněn tok SIP zpráv v mechanizmu
Event/Notification s využitím metody PUBLISH. UA, který si nechává zasílat notifikaci na sledované
stavy se označuje jako watcher a používá již vysvětlené metody SUBSCRIBE a NOTIFY.
EPA
ESC, PA
Watcher
SUBSCRIBE
200 OK
NOTIFY
200 OK
PUBLISH
200 OK
NOTIFY
200 OK
Obr. 4.6 Mechanizmus Event/Notification s užitím metody PUBLISH.
Watcher inicializuje přihlášení k odběru zpráv presence z entity PA (Presence Agent)
[email protected] s expirací 3600 sekund, což je první zpráva M1.
SUBSCRIBE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds7
CSeq: 1 SUBSCRIBE
Max-Forwards: 70
Expires: 3600
Event: presence
Content-Length: 0
EPA posílá aktualizaci informací na PA pomocí PUBLISH, což je zpráva M5.
PUBLISH sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge
From: <sip:[email protected]>;tag=1234wxyz
94
CSeq: 1 PUBLISH
Max-Forwards: 70
Expires: 3600
Event: presence
Content-Type: application/pidf+xml
Content-Length: ...
Jelikož PA zjistil, že od EPA obdržel informace, které znamenají změnu presence, tak posílá
pomocí NOTIFY oznámení se stavem nové presence na iniciátora sledování (watcher), což je zpráva
M7, jejíž obsah je následně uveden.
NOTIFY sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK4cd42a
From: <sip:[email protected]>;tag=abcd1234
CSeq: 2 NOTIFY
Max-Forwards: 70
Event: presence
Subscription-State: active; expires=3400
Contact: sip:pa.example.com
Content-Type: application/pidf+xml
Content-Length: ...
Oblast Presence a IM je velmi zajímavá, ale SIP má zde velmi zdatné konkurenty v podobě
protokolu XMPP (Extensible Messaging and Presence Protocol), který využívá např. Google Talk a
Jabber. Rozšíření SIPu do oblasti IM a Presence nebude tak úspěšné a potenciál uplatnění připadá v
úvahu pouze jako doplňkové služby pro telefonii. Nejpoužívanějším řešením pro IM je dnes Jabber.
4.6
Realizace vybraných doplňkových služeb v SIPu
V následující kapitole se seznámíme s řešením několika vybraných doplňkových služeb pomocí
SIP signalizace, bude se jednat o následující služby:
•
•
•
•
•
•
•
síťování mezi SIP a PSTN, tady je nutné použít Early Media,
paralelní vyzvánění (Forking), tato služba se týká především transakcí na SIP Proxy
odesílající INVITE žádosti na více míst, tato SIP Proxy musí mít ošetřeny stavy rozjednaných
transakcí tak, aby po přihlášení volaného došlo ke zrušení sestavování zbylých dialogů,
přidržení hovoru (Call hold), v této službě jde o re-INVITE a úpravy toků médií na úrovni SDP,
takže podstatné úpravy jsou učiněny v SDP,
hudba při přidržení (Music on hold), je podobná přidržení hovoru s tím rozdílem, že je nutné
zakončit tok médií na Music serveru přehrávající MoH,
předání hovoru (Call transfer), dva přístupy k realizaci služby se řeší buď přes INVITE s
namapováním médií mezi předávanými stranami anebo pomocí 3rd party control,
přesměrování volání (Call forwarding), služba se řeší na stateful SIP Proxy pravidly
definujícími akce pro různé typy přesměrování,
indikace zprávy (Message waiting indication), realizuje se s využitím Event/Notification,
95
•
•
4.7
vytočení kliknutím (click to dial), služba je typickým příkladem řízení spojení třetí stranou,
takže to je úloha pro 3rd party control a tím pádem žádost REFER,
zpětné volání (Call Back) se řeší pomocí EVENT/Notification.
Síťování SIP s PSTN
V případě síťování SIP světa s PSTN se musí zabezpečit přenos kontrolních tónů či hlásek již
během vyzvánění, každý se už jistě setkal s ohlášením „volané číslo je nedostupné, zavolejte
později“ anebo „dovolali jste se do zákaznického centra společnosti ....“
Obr. 4.7 Tok zpráv v síťování SIP a PSTN
Tyto ohlášení pochopitelně nejsou generovány mobilním telefonem, ale jsou transparentně
přenášeny PSTN sítí a již během vyzvánění je otevřen příslušný B-kanál v ISDN trasách, ve kterém
se in-band přenášejí kontrolní tóny a ohlášení. SIP původně počítal s odlišným přístupem a mezi SIP
účastníky stačí na přijetí 180 RINGING lokálně generovat nastavený kontrolní vyzváněcí tón (např.
opakovat 425 Hz po dobu 1sek./4 sek. pauza). Řešením jsou Early Media a proto se nabídka SDP
potvrdí už ve 183 Session Progress a minimálně směrem z PSTN je přenášen RTP tok, vždyť
nakonec vlastnosti komunikace GW již předem zná, neboť ty jsou dány možnostmi GW (porty,
kodeky) a nikoliv účastníka v PSTN. Komunikace na obr. 4.7 by se dala pochopitelně vylepšit o
PRACK, který byl už rozebrán v předchozích kapitolách.
96
4.8
Paralelní vyzvánění - Forking
Předpokládejme, že budeme mít uživatele, který se zaregistruje z několika zařízení pod stejným
user URI (z telefonu z práce, domu či mobilu) a příchozí žádost INVITE rozešle SIP Proxy na
všechny aktivní registrovaná zařízení, viz. obr. 4.8
Stateful Proxy
Alice
Bob@home
Bob@work
INVITE
bob@proxy
INVITE
INVITE
180 Ringing
180 Ringing
180 Ringing
200 OK
Contact: bob@home
Answered
200 OK
CANCEL bob@work
200 OK (CANCEL)
487 Cancelled
(INVITE)
ACK bob@work
ACK bob@home
Media session
Obr. 4.8 Forking na SIP Proxy
Tato funkce se označuje jako forking, není ji možné realizovat na stateless SIP Proxy, jelikož je
založena na několika současně probíhajících transakcích a samozřejmě takováto Proxy není
schopna tyto transakce sledovat.
Na obr. 4.8 máme situaci, Bob je registrován pod user URI Bob@proxy na dvou device URI, a to
Bob@home a Bob@work. Alice volá Boba a SIP Proxy odesílá INVITE na obě místa, z obou míst je
odeslána odpověd 180 RINGING, což znamená, že došlo k paralelnímu vyzvánění. Bob přijal hovor
na bob@home, SIP Proxy musí teď vytvořit novou transakci a zrušit sestavované a stále vyzvánějící
97
volání na bob@work, je tedy odeslána žádost CANCEL. Na CANCEL je odeslána odpověď 200 OK
a původní transakce s INVITE je zodpovězena pomocí 487 Cancelled, což je potvrzeno metodou
ACK. Mezitím SIP Proxy odeslala 200 OK z bob@home, kde je v poli contact uveden bob@home,
díky tomu je další žádost ACK již přímo odeslána na kontaktní adresu a dialog je sestaven.
4.9
Přidržení hovoru - Call hold
Máme sestaveno spojení, potřebujeme provést přidržení hovoru a po chvíli se vrátit zpět. Existují
v zásadě dvě možnosti obě pomocí re-INVITE přes modifikaci v SDP, a to buď ukončit RTP tok a
potom jej znovu navázat, tzn. m řádek v SDP anebo pomocí atributu sendonly, což je elegantnější,
jelikož pouze změníme stav toku.
Předpokládejme, že máme sestaveno spojení mezi Alicí a Bobem a Bob aktivuje službu Call
Hold, Bobův UA odešle re-INVITE a v SDP nastaví atribut sendonly.
From: Bob <sip:[email protected]>;tag=b-tag
To: Alice <sip:[email protected]>;tag=a-tag
Call-ID: ab-cid
CSeq: 1 INVITE
v=0
o=bob 2890844527 2890844528 IN IP4 u2.biloxi.ex.com
s=c=IN IP IP4 u2.biloxi.ex.com
t=0 0
a=sendonly
Alice na INVITE odešle odpověď 200 OK, k ní připojí SDP a vloží atribut recvonly.
SIP/2.0 200 OK
From: Bob <sip:[email protected]>;tag=b-tag
To: Alice <sip:[email protected]>;tag=a-tag
Call-ID: ab-cid
CSeq: 1 INVITE
v=0
o=alice 2890844526 2890844527 IN IP4 u1.atlanta.com
s=c=IN IP IP4 u1.atlanta.ex.com
t=0 0
a=recvonly
98
Relace je teď jednosměrná a Bobův UA neodesílá žádná média, pro obnovení se opět použije
re-INVITE, tentokrát bez atributu, tím pádem se použije výchozí a=sendrecv a komunikace se obnoví.
4.10 Hudba při přidržení – Music on Hold
Hovor je sestaven mezi Alicí a Bobem, Bob aktivuje přidržení spojení s hudbou, Bobův UA posílá
INVITE bez SDP na Music server. Odpověď 200 OK na Bobem zaslaný INVITE obsahuje SDP s
atributem a=sendonly. Bob posílá re-INVITE Alici, kde v SDP použije a=sendonly a do řádku c
uvede Music server jako adresu pro ukončení RTP toku, Alice potvrdí 200 OK a připojí své SDP s
a=recvonly, Bob potvrdí přijetí 200 OK pomocí metody ACK a Alicino SDP připojí k žádosti ACK a
zašle na Music server. Music server zasílá RTP tok na Alici, viz. obr. 4.9. Při vrácení z přidržení s
hudbou k hovoru musí Bob nejdříve pomocí BYE ukončit spojení s Music serverem a potom pomocí
re-INVITE obnovit spojení s Alicí.
Obr. 4.9 Přidržení hovoru s hudbou
4.11 Předání hovoru - Call transfer
Předání hovoru se může realizovat pomocí re-INVITE anebo pomocí REFER, ukážeme si oba
způsoby, první způsob bude s využitím INVITE a jde o starší přístup.
99
Alice
Bob
Veronika
Media session
INVITE no SDP
200 OK SDPa
ACK SDPv
INVITE SDPa
200 OK SDPv
ACK
Media session
Obr. 4.10 Předání hovoru pomocí INVITE
Na obr. 4.10 je první způsob, ve kterém Bob má sestavenou relaci s Veronikou a předává ji Alici.
Jelikož nezná popis médií Alice, tak pošle nejprve INVITE bez SDP a získá nabídku médií Alice v
SDP jako součást odpovědi 200 OK. Tuto nabídku SDP následně připojí k žádosti re-INVITE a pošle
Veronice. Veronika odpoví 200 OK a připojí svou nabídku SDP, kterou Bob použije do žádosti ACK
zasílané Alici jako potvrzení na přijetí 200 OK. Bob ještě zašle ACK Veronice a dialog je sestaven,
přičemž Bob sloužil jako prostředník, přes kterého si vyměnily obě strany své SDP. Pochopitelně, že
Bob do hlaviček v poli Contact uvedl obě nově komunikující strany, takže v tomto dialogu už nemá
žádnou úlohu.
Ve druhém případě na obr. 4.11 je použita metoda REFER, spojení je sestaveno mezi Alicí a
Bobem. Alice pomocí REFER požádá Boba o sestavení spojení s Veronikou, když dostane potvrzení,
tak pomocí BYE ukončí stávající spojení. Bob sestaví nové spojení s Veronikou a potvrdí přes
NOTIFY Alici, že předání zdárně proběhlo. SDP s popisem médií se přenášejí standardně v INVITE
a 200 OK.
100
Obr. 4.11 Předání hovoru pomocí REFER
4.12 Přesměrování volání - Call forwarding
Služba přesměrování volání je možná na Stateful SIP Proxy, na které jsou definovány pravidla ke
stavům, které se v transakci při sestavování spojení mohou vyskytnout. Přesměrování můžeme
rozdělit na následující typy:
•
•
•
•
přesměrování při obsazení CFWB (Call Forwarding Busy), SIP Proxy při obdržení
návratového kódu 486 vytvoří nový INVITE na definovaný cíl přesměrování,
přesměrování při neohlášení (obvykle po čase 15-20 sek.) - CFWNR (Call Forwarding No
Reply), SIP Proxy sleduje dobu vyzvánění signalizované návratovým kódem 180 RINGING a
po překročení hraniční hodnoty vytvoří nový INVITE na definovaný cíl,
přesměrování nepodmíněné CFWU (Call Forwarding Unconditional), SIP Proxy zasílá INVITE
přímo na zvolený cíl,
přesměrování při nedostupnosti CFWNA (Call Forwarding Not Available).
101
Přesměrování se obvykle označují zkratkou CFW (Call Forwarding), což je uvedeno i v seznamu
výše, ale můžeme se setkat i s označením CD (Call Diversion). Z PSTN sítí je zažitější používání
CFW, a tak nové označení CD se stejným významem může být pro někoho zavádějící. Na obr. 4.12
je situace při CFWB (přesm. při obsazení), jak již bylo zmíněno, tak na návratový kód 486 vytvoří SIP
Proxy nové spojení odesláním INVITE.
SIP Proxy
Alice
Bob
Veronika
INVITE Bob@biloxi
100 Trying
INVITE [email protected]
486 Busy Here
ACK [email protected]
INVITE [email protected]
180 Ringing
180 Ringing
200 OK
200 OK
ACK [email protected]
Media session
Obr. 4.12 Přesměrování při obsazení - CFWB
4.13 Indikace zprávy - Message waiting indication
Signalizace zanechání vzkazu ve schránce hlasové pošty je založena na modelu EVENT/
NOTIFICATION, obr. 4.13. Zájemce o službu zasílá SUBSCRIBE na server hlasové pošty VMS
(VoiceMail Server), v notifikaci obdrží aktuální stav, v našem případě dvě nové zprávy z osmi
uložených. Po zanechání nového vzkazu na VMS, bude server vždy oznamovat tuto událost pomocí
NOTIFY, v našem případě Alice obdržela informaci, že má tři nové zprávy z celkových devíti
uložených.
Signalizace uložené zprávy je označována jako MWI (Message Waiting Indication) a zpráva
NOTIFY by měla na telefonu Alice aktivovat rozsvícení LED diody tlačítka, po jeho stisknutí by se
102
měl Alici zobrazit na displeji text upozorňující na nový vzkaz a ihned nabídnuto jeho vyzvednutí.
Způsob ovládání telefonu už pochopitelně záleží na jeho výrobci, každopádně by měla být
implementace jednoduchá, nejlépe rolovací menu nabízející položky dle pravděpodobnosti či četnosti
použití a jednoduchý pohyb v něm pomocí tlačítek Vpřed/Vzad anebo dotekovým jezdcem (Touch
Slider, kruhový pohyb/např. iPod anebo vertikální nahoru/dolů).
Hlasová pošta může být propojena s e-mailovou schránkou uživatele (odešle uložený vzkaz
pomocí SMTP na daný e-mail) , který tak může dostávat vzkazy např. v mp3 formátu na svůj e-mail,
případně naopak z emailu odesílat krátké vzkazy na telefon. Komunikace umožňující propojení
různých systémů zpracování zpráv se označuje jako Unified Messaging.
VMS
Alice
Voicemail
Server
SUBSCRIBE
Bob@vms
Event: Message-summary
200 OK
NOTIFY
VoiceMessage 2/8
200 OK
Event: someone leaves
voicemail forBob
NOTIFY
VoiceMessage 3/9
200 OK
Obr. 4.13 Oznámení o zanechání vzkazu - MWI
4.14 Vytočení kliknutím - Click to dial
Další služba je založena na zprávě REFER, jelikož se jedná o sestavení řízení spojení stranou
( 3 party control). Webová aplikace bude obsahovat např. korporátní adresář, soukromé kontakty
Alice anebo jen pole pro vložení jmenného identifikátoru (URI) či telefonního čísla, spojení je
inicializováno z webu. Kliknutím na položku (CTD – Click to Dial) jsou pomocí některé z metod (GET,
POST) přes HTTP odeslána data k provedení volby na webový server, Alice volá Boba. Web server
odesláním INVITE inicializuje spojení s telefonem Alice, Alice přijme volání, čímž odešle 200 OK a
webový server na tento návratový kód odešle žádost REFER, kde do Refer-To vloží URI Boba.
Žádost REFER je doručena Alici, jejíž telefon odpoví návratovým kódem 202 a zobrazí Alici na
rd
103
displeji informaci o zahájení spojení s Bobem, webová aplikace ukončí sestavené spojení s Alicí
žádostí BYE a telefon Alice odesílá INVITE na Boba, obr. 4.14.
Obr. 4.14 Vytočení kliknutím – CTD
104
Při implementaci této funkce je vhodné nastavit zpoždění cca 2-3 sek. mezi zobrazením
informace na displeji Alice o sestavování spojení s Bobem a skutečným odesláním INVITE, Alice tak
má možnost zavěsit. Pomocí REFER je realizována většina služeb CTI (podpora telefonování z PC),
druhá možnost je použití INVITE a re-INVITE, ale tento přístup je zastaralý.
Řada SIP telefonů podporuje XML, přes HTTP může přímo komunikovat s webovým serverem a
integrovat do telefonie řadu zajímavých aplikací, které mohou být postaveny nad XML. Dokumenty
XML mohou být zasílány i přes SIP žádosti NOTIFY a PUBLISH, avšak využití HTTP se zde jeví jako
vhodnější. Dalším příkladem využití spolupráce SIP telefonu a webového serveru může být CRM
(Customer Relationship Management), při příchozím volání se na základě identifikace volajícího
vyhledají v databázi informace o volajícím a volanému se zobrazí webová stránka s informacemi o
volajícím. Výsledkem je, že volaný má už během vyzvánění o volajícím informace, které může použít,
položit mu otázky k autentizaci, atd ... Informace o volajícím jsou využívány i ke směrování, ale to se
týká jiné oblasti (call processing) a patří do problematiky Call center. Na základě identifikace lze
například volajícího přepojit přímo na jeho osobního asistenta, na maďarsky hovořící operátorku
anebo zařadit do fronty, kde bude čekat na obsloužení.
4.15 Zpětné volání – Call Back
Zpětné volání je typickou službou pro použití EVENT/Notification. Jak jsme si již vysvětlili v
předchozích kapitolách, tak pomocí žádostí SUBSCRIBE a NOTIFY docílíme, že zájemci je zasláno
oznámení při výskytu hlídané události (změna stavu). Na obr. 4.15 je zaslán INVITE, ale Bob je
obsazen, odpověď je potvrzena přes ACK, ale telefon Alice podporuje zpětné volání a tuto funkci
nabídne. Alice potvrdí, čímž se odešle SUBSCRIBE a jako sledovaná událost se uvádí event: call
completion (dokončení volání), položka by měla být součástí nového návrhu RFC - Call Completion
for Session Initiation Protocol (SIP), který se připravuje. Bob zavěsí a jeho UA ihned odešle NOTIFY,
telefon Alice začne vyzvánět a po vyzvednutí odešle INVITE na Boba a dává Alici kontrolní
vyzváněcí tón.
Volání může být dokončeno ve stavu volno (CCNR – Call Completion on No Reply) i obsazeno
CCBS (Call Completion on Busy). Níže je obsah žádosti SUBSCRIBE.
SUBSCRIBE sip:[email protected] SIP/2.0
To: <sip:[email protected]>;
CSeq: 1 SUBSCRIBE
Contact: <sip:[email protected] >
Event: call-completion
Expires: 3601
105
Obr. 4.15 Zpětné volání při obsazení
4.16 Metoda INFO
Metoda INFO typicky obsahuje tělo zprávy, kde můžou být signalizační informace či události
během relace. Metoda byla původně navržena s cílem přenášet z PSTN signalizační informace
během sestaveného spojení jako ISUP (ISDN User Part) zprávy. Metoda INFO vždy inkrementuje
CSeq.
INFO sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP cavendish.kings.cambridge.edu.uk
;branch=z9hG4bK24555
Max-Forwards: 70
To: John Poynting <sip:[email protected]> ;tag=3432
From: J.C. Maxwell <sip:[email protected]>
;tag=432485820183
Call-ID: e71facaa7f7c0a29276054fe4951a9b6
Content-Type: application/ISUP
106
Content-Length: ...
(tělo zprávy není zobrazeno)
Původní specifikace INFO v RFC 2976 nemá žádné mechanizmy vyjednávání, jaký obsah v těle
zprávy je akceptovatelný. V roce 2011 původní RFC 2976 bylo nahrazeno novějším RFC 6086, které
je jednak zpětně kompatibilní se starším, ale hlavně obsahuje rozšíření chybějící vlastnosti pomocí
pole Recv-Info v hlavičce deklarující, jaký obsah v INFO konkrétní UA podporuje.
107
5
SIPp a jeho použití k emulaci SIP relací
SIPp je nástroj pro emulaci SIP relací, obsahuje UAC a UAS, poskytuje statistiky o zprávách
v SIP signalizaci, umožňuje rovněž emulovat i média, SIPp pracuje s audio či videem ve formě pcap.
Jedná se o open-source aplikaci, která je velmi flexibilní a umožňuje vytváření různých scénářů
v XML. Statistky, které jsou aplikací SIPp vytvářeny v reálném čase, poskytují informace o počtu
sestavených volání, round trip delay a statistiky jednotlivých SIP zpráv, kromě zobrazení v okně
terminálu, viz. obr. 4.1, lze tyto statistiky periodicky ukládat do CSV. Ve scénářích lze používat
proměnné či regulární výrazy, což dává SIPp rozsáhlé možnosti.
Port
5060
Total-time
200.47 s
----------> INVITE
<---------- 180
<---------- 200
----------> ACK
----------> BYE
<---------- 200
[
4000ms] Pause
-------- Scenario Screen -------Total-calls Transport
1814 UDP
Messages
1814
1814
1814
E-RTD1 1814
Retrans
0
Timeout
0
0
0
0
0
0
1814
0
0
1814
0
1814
-------- Sipp Server Mode --------
Unexpected-Msg
0
0
0
0
Obr. 5.1 Statistiky v okně terminálu SIPp
SIPp může být využit k testování reálných SIP zařízení jako SIP Proxy (např. Kamailio), B2BUA
(např. Asterisk), SIP media servery, SIP brány and SIP PBX. Nástroj může být využit k emulování
tisíců UA generujících relace do cílového zařízení. Kromě těchto výkonnostních testů lze využít SIPp
využít i k testování interoperability, čili k ověření chování neznámého zařízení.
5.1
Instalace
SIPp lze přímo instalovat z repozitářů většiny linuxových aplikací, např. pro Debian či Ubuntu lze
najít SIPp pod balíčkem s označením sip tester. Nakonec SIPp je dostupný i pro MS Windows na
URL http://sourceforge.net/projects/sipp/files/sipp/3.2/sipp-win32-3.2-setup.exe/download.
108
# apt-cache search sip-tester
sip-tester - Performance testing tool for the SIP protocol
Instalace je tedy záležitostí několik desítek vteřin, doporučuji předtím provést update pro získání
aktuálních seznamů balíčků a můžeme instalovat apt-get install sip-tester. Po nainstalování se SIPp
může okamžitě používat, ale ověříme si ještě verzi pomocí sipp-v.
# apt-get update
# apt-get install sip-tester
# sipp -v
SIPp v3.2-PCAP, version unknown, built Nov 3 2011, 11:30:21.
Zjistili jsme, že máme verzi 3.2, která podporuje PCAP a tím pádem můžeme relace emulovat
s reálnými médii (PCAP je podporovaný ve Wireshark, tzn. můžeme si takováto média extrahovat
s reálného provozu a uložit RTP jako pcap soubor). Pokud bychom přece jen chtěli vyšší verzi (v
roce 2013 byla dostupná v3.4), tak zkompilujeme. Pro v3.4 musíme před vlastní kompilací
doinstalovat tyto balíčky:
•
•
•
•
C++ Compiler
curses nebo ncurses library
pro TLS OpenSSL >= 0.9.8
pro pcap play: libpcap and libnet
# apt-get install gcc
# apt-get install libncurses5-dev
# apt-get install libssl-dev
# apt-get install openssl
# apt-get install libnet1-dev
# apt-get install libpcap0.8-dev
Stáhneme si aktuální balíček, rozbalíme a zkompilujeme s parametry pro podporu TLS --withopenssl a PCAP --with-pcap.
# tar -xvzf sipp-xxx.tar.gz
# cd sipp
# ./configure --with-pcap --with-openssl
# make
# make install
5.2
Scénáře pro SIPp
SIPp umožňuje generovat jeden či více SIP relací na vzdálený systém. Nástroj je spuštěn
z příkazové řádky. SIPp je možné ihned využívat s výchozím scénářem UAC a UAS např. pro zjištění,
zda přes danu síť je možné realizovat SIP relace, nejdříve spustíme UAS [rez1]:
# tar -xvzf sipp-xxx.tar.gz
109
# sipp -sn uas
a poté UAC s výchozím XML schématem, což můžeme provést i na lokální rozhraní 127.0.0.1,
port UAS je 5060 a UAC používá 5061 na stejné IP.
# ./sipp -sn uac 127.0.0.1
Tento výchozí scénář obsahuje následující schéma, viz, obr 5.1, vzhledem k použití stejné
adresy 127.0.0.1 nám Wireshark nezobrazil správně orientaci odesílaných žádostí a přijatých
odpovědí, ale pro prvotní odzkoušení funkčnosti SIPp nám můžou nakonec i postačit statistiky, kdy
uvidíme, že nějaké žádosti byly odeslány a na ně přijaty odpovědi. V dalších příkladech s reálným
nasazením mezi různými IP již bude výpis z Wireshark v pořádku, viz. obr. 5.2.
Obr. 5.2. Výchozí scénář SIPp
5.2.1
SIPp v příkazovém řádku
Spuštění SIPp se provádí zavoláním aplikace sipp a přepínači s parametry. Mezi nejpoužívanější
patří:
• -sd: výpis XML scénáře na obrazovku
• -sf : nahrání vlastního XML scénáře
• -sn : nahrání defaultního XML scénáře. (např. uac,uas)
• -t : nastavení transportního protokolu
• -u1,un,ui – UDP protokol a nastavení počtu soketů,
• -t1,tn – TCP protokol a nastavení soketů,
• -c1,cn – UDP s kompresí
• -i : nastavení lokální IP adresy pro SIP hlavičku
• -p : nastavení lokálního portu pro SIP
• -v : zobrazení verze a dostupných funkcionalit
• -bg : spuštění SIPp v daemon módu
• -sleep : pozdržení startup času
• -lost : simuluje ztrátovost v nastavených procentech
Další možnosti nám dávají následující volby používané pro bližší specifikaci generovaných relací:
•
•
•
-aa : zapnutí automatické odpovědi 200 OK na zprávy INFO, UPDATE a NOTIFY
-base_cseq : nastavení startovní hodnoty CSeq
-cid_str : Nastavení hodnoty CallID
110
•
•
•
•
•
•
•
•
-d : nastavení délky audio streamu v milisekundách
-au : nastavení username pro auth. Digest
-ap : nastavení password pro auth. Digest
-s : nastavení username v SIP hlavičce
-r : nastavení počtu hovorů
-rp : nastavení intervalu mezi hovory
-l : nastavení maximálního počtu paralelně běžících hovorů
-m : zastaví testování a ukončí sipp jakmile proběhnout všechny hovory
Příkladem může být spuštění výchozího scénáře UAC
# ./sipp –sn uac –r 10 –rp 1000 –s [login] [server]
Pomocí -sn uac vyvoláme výchozí scénář pro UAC, ve kterém bude generováno deset relací za
periodu -r 10 a perioda potrvá 1000 ms -rp 1000. Username volaného uživatele se nastaví pomocí -s
[login] a cílový server relace, kam budou zprávy zasílány je v [server]. Další příklad je s vlastním
vytvořeným scénářem v XML souboru. Zavolání XML souboru uac_sipuri.xml, který si předem
vytvoříme v adresáři, kde spouštíme sipp, následně provedeme pomocí -sf uac_sipuri.xml . Kde -r
500 -rp 1000 určuje násobnost 500 relací za periodu 1000 ms a voláme uživatele 6543 –s 6543 na
cílovém serveru iptel.org.
# ./ sipp -sf uac_sipuri.xml –s 6543 -r 500 -rp 1000 iptel.org
5.2.2
Vytváření XML schémat
Vytváření XML schémat á svá pravidla. Každé XML schéma začíná a končí značkou scenario.
<?xml version="1.0" encoding="ISO-8859-1" ?> <scenario name=„Basic">

</scenario>
Příkazy, které používáme v XML jsou následující:
•
•
•
•
•
•
•
•
<send> - Příkaz pro zasílaní SIP zpráv.
<recv> - Příkaz pro příjem SIP zpráv.
<nop> - Definování akce, která bude provedena (např. přehrání PCAP hlasového vzorku).
<pause> - Definování zapauzování běhu scénáře.
<sendCmd> - Zasílání příkazu pro scénář druhé strany.
<recvCmd> - Definice akce při příchozím příkazu.
<label> - Nastavení značek pro skoky ve scénáři.
<globals> - Vytváří vlastních proměnných ve scénáři.
Každý příkaz má své vlastní atributy, viz. URL: http://sipp.sourceforge.net/doc/reference.html.
Příkladem je základní XML scénář, který vygeneruje nejprve zprávu INVITE s SDP obsahující
nabídku kodeku G711ulaw.
<?xml version="1.0" encoding="ISO-8859-1" ?> <scenario name="Basic">
111
<send retrans="500">
<![CDATA[
INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[call_number]
To: sut <sip:[service]@[remote_ip]:[remote_port]>
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=c=IN IP[media_ip_type] [media_ip]
t=0 0
m=audio [media_port] RTP/AVP 0
]]>
</send>
Žádost INVITE je zaslána vzdálené straně a klient čeká na odpověď pomocí zpráv recv, přičemž
přijetí zpráv 100 a 180 je volitelné, zatímco 200 je povinná a čeká se do expirace časovače (výchozí
hodnota je 3000 ms):
<recv response="100"
optional="true">
</recv>
<recv response="180" optional="true">
</recv>
<recv response="200" rtd="true">
</recv>
<send>
<![CDATA[
Nyní se pošle žádost ACK signalizující potvrzení doručení finální odpovědi na žádost INVITE.
ACK sip:[service]@[remote_ip]:[remote_port] SIP/2.0
To: sut <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
112
Max-Forwards: 70
Content-Length: 0
]]>
</send>
V dalším kroku scénáře vložíme pauzu, která simuluje probíhající hovor, případně se může vložit
akce pro přehrání skutečného audio souboru.
<pause miliseconds "5000"/>
<nop>
<action>
<exec play_pcap_audio="pcap/g711u.pcap"/>
</action>
</nop>
Poté následuje ukončení hovoru pomocí zprávy BYE a očekávání odpovědi, scénář nesmíme
zapomenout zavřít pomocí </scenario>.
<![CDATA[
BYE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
To: sut <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 2 BYE
Max-Forwards: 70
Content-Length: 0
]]>
</send>
<recv response="200" crlf="true">
</recv>
</scenario>
Serverový scénář můžeme ponechat výchozí, čili spustíme pouze sipp -sn uas. Na straně
generující relaci se přepneme do adresáře s vytvořeným scénářem, který jsem si nazval
uac_basic.xml a spustíme jej na cílovou adresu, kde nám běží SIPp UAS. Namísto SIPp UAS se
může jednat o skutečný server. Zachytíme relaci např. pomocí tcpdump anebo ngrep a zachycenou
SIP relaci můžeme analyzovat Wiresharkem.
# sipp -sf uac_basic.xml 192.168.1.119
# tcpdump -w /home/voz29/trace8.pcap
113
Ověříme, že XML scénář se chová dle předpokladů, viz. obr. 5.3
Obr. 5.3 Výměna SIP zpráv v sestavené relaci
Nyní se podíváme ještě na obsah žádosti INVITE, viz. obr. 5.4, kde vidíme, že je v souladu
s očekáváním a její obsah je validní z pohledu RFC 3261 (jádra SIPu).
Obr. 5.4 Zobrazení žádosti INVITE
Pokud bychom přece jen chtěli sestavit vlastní UAS scénář, tak proměnné jsou podobné jako u
klientského scénáře, podstatně ovšem jednodušší co do obsahu, jelikož se používá proměnná
[last_*], která přebírá hodnoty polí z přijaté žádosti. Scénář začneme standardní hlavičkou, odpověď
100 vytvářet nemusíme a první zprávou tedy bude 180 Ringing, ve které otočíme přijaté hodnoty
v jednotlivých polích, přidáme tag do pole To a vytvoříme obsah pole Contact, které obsahuje údaje o
našem UAS.
<?xml version="1.0" encoding="ISO-8859-1" ?>
<scenario name="Basic UAS responder">
</recv>
<send>
<![CDATA[
SIP/2.0 180 Ringing
[last_Via:]
[last_From:]
[last_To:];tag=[call_number]
114
[last_Call-ID:]
[last_CSeq:]
Contact: <sip:[local_ip]:[local_port];transport=[transport]>
Content-Length: 0
]]>
</send>
Obdobně pokračujeme s 200 OK, kde přidáme SDP a použijeme kodek G711ulaw.
<![CDATA[
SIP/2.0 200 OK
[last_Via:]
[last_From:]
[last_To:];tag=[call_number]
[last_Call-ID:]
[last_CSeq:]
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=c=IN IP[media_ip_type] [media_ip]
t=0 0
m=audio [media_port] RTP/AVP 0
]]>
</send>
Následně ve scénáři UAS ošetříme přijetí potvrzení ACK, na tuto zprávu nereagujeme.
<recv request="ACK"
optional="true"
rtd="true"
crlf="true">
</recv>
Nakonec vytvoříme odpověď na přijetí žádosti BYE a opět nezapomene scénář ukončit pomocí
značky </scenario>.
<recv request="BYE">
</recv>
<send>
<![CDATA[
SIP/2.0 200 OK
115
[last_Via:]
[last_From:]
[last_To:]
[last_Call-ID:]
[last_CSeq:]
Content-Length: 0
]]>
</send>
</scenario>
5.2.3
Vkládání hodnot z externích souborů
Do XML scénářů lze vkládat dynamicky hodnoty z externích souborů, tato funkcionalita se vyvolá
pomocí příkazu –inf název_souboru při spuštění SIPp. Například budu potřebovat volat různá tel.
čísla s každým hovorem bez nutnosti parsovat XML scénář anebo měnit volajícího.
V následujícím příkladu si ukážeme, jak lze měnit volajícího s každým hovorem. Vytvoříme si
soubor .csv, kde první řádek značí, jak má SIPp soubor procházet
SEQUENTIAL – postupně,
RANDOM – náhodně,
USER – definováno uživatelem.
Každý další řádek reprezentuje jeden hovor a může být rozdělen na několik proměnných
pomocí ; . V našem příkladu jsou dvě proměnné [field0]; [field1].
SEQUENTIAL
#This line will be ignored
Sarah;sipphone32
Bob;sipphone12
#This line too
Fred;sipphone94
Parametry řádků podporují klíčová slova v argumentu, ve spojení s vyhledáváním je možné
vybrat hodnoty na základě vhodného klíče, viz. obr. 5.5. CSV soubor může obsahovat komentované
řádky (ty se neberou v potaz a začínají symbolem "#"). SIPp podporuje SIP autentizaci, a to
Digest/MD5 ("algorithm="MD5"") a Digest/AKA ("algorithm="AKAv1-MD5"", dle 3GPP pro IMS).
Povolení autentizace je snadné. Při přijetí 401 (Unauthorized) nebo 407 (Proxy Authentication
Required) se musí přidat auth="true" v příkazu <recv>, aby se autentizace vzala v úvahu, následně
bude do další zprávy vložena autorizovaná hlavička hlavička použitím klíčového slova
[authentication]. Použitím [authentication] bude vyvolána hashovací funkce a výsledek vložen do
hlavičky. V závislosti na použití ("MD5" nebo "AKAv1-MD5") se používá buď Digest/MD5 (example:
[authentication
username=joe
password=schmo])
anebo
Digest/AKA:
(example:
[authentication username=HappyFeet aka_OP=0xCDC202D5123E20F 62B6D676AC72CB318
aka_K=0x465B5CE8B199B49FAA5F0A2EE238A6BC aka_AMF=0xB9B9])
116
Obr. 5.5 Vazba klíčového slova v argumentu konkrétního pole SIP hlavičky na řádek v CSV souboru
V případě, že chceme použít autentizaci s různými username/password pro každé volání, tak
vytvoříme CSV soubor dle vzoru níže.
SEQUENTIAL
User0001;[authentication username=joe password=schmo]
User0002;[authentication username=john password=smith]
User0003;[authentication username=betty password=boop]
Ve scénáři vytvoříme zprávu REGISTER, při provedení XML scénáře bude [field1] nahrazeno
autentizačním řetězcem, který bude vytvořen jako nové klíčové slovo (hashovací funkcí MD5).
<![CDATA[
REGISTER sip:[remote_ip] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port]
To: <sip:[field0]@sip.com:[remote_port]>
From: <sip:[field0]@[remote_ip]:[remote_port]>
Contact: <sip:[field0]@[local_ip]:[local_port]>;transport=[transport]
[field1]
Expires: 300
Call-ID: [call_id]
CSeq: 2 REGISTER
Content-Length: 0
]]>
</send>
Nakonec vytvoříme čekání na odpověď.
117
<recv response="407" auth="true">
</recv>
5.2.4
Ovládání SIPp za běhu
Aplikace SIPp může být interaktivně ovládána přes klávesnici nebo přes UDP sokety. Tzv. “hot
keys“ můžou být vyvolány kdykoliv a umožňují vyvolat i jednoduchý příkazový režim.
Key
+
*
/
c
q
Q
s
p
1
2
3
4
5
6-9
Action
Increase the call rate by 1 * rate_scale
Increase the call rate by 10 * rate_scale
Decrease the call rate by 1 * rate_scale
Decrease the call rate by 10 * rate_scale
Enter command mode
Quit SIPp (after all calls complete, enter a second time to quit immediately)
Quit SIPp immediately
Dump screens to the log file (if -trace_screen is passed)
Pause traffic
Display the scenario screen
Display the statistics screen
Display the repartition screen
Display the variable screen
Display the TDM screen
Display the second through fifth repartition screen.
V příkazovém módu se mohou zadávat pouze následující příkazy, jejichž popis a příklad užití je
uveden níže.
Command
Description
Example
dump tasks
Prints a list of active tasks (most tasks are calls) to the error log. dump tasks
set rate X
Sets the call rate.
set rate 10
set rate-scale X
Sets the rate scale, which adjusts the speed of '+', '-', '*', and '/'.
set ratescale 10
set users X
Sets the number of users (only valid when -users is specified).
set rate 10
set limit X
Sets the open call limit (equivalent to -l option)
set limit 100
set hide <true|false> Should the hide XML attribute be respected?
set hide false
set index <true|false> Display message indexes in the scenario screen.
set index true
set display <main|ooc> Changes the scenario that is displayed to either the main or
the out-of-call scenario.
set display main
set display ooc
trace <log> <on|off> Turns log on or off at run time. Valid values for log are "error",
"logs", "messages", and "shortmessages".
trace error on
118
5.2.5
Další tipy pro SIPp
SIPp obsahuje podporu IPv6, k použití stačí specifikovat IP adresu pomocí přepínače –i.
V následujícím příkladu bude UAS naslouchající na portu 5063 a UAC bude na tento port generovat
provoz.
# ./sipp -sn uas -i [fe80::204:75ff:fe4d:19d9] -p 5063
# ./sipp -sn uac -i [fe80::204:75ff:fe4d:19d9] [fe80::204:75ff:fe4d:19d9]:5063
Pokud se používá "multi-socket" transport (více hovorů současně probíhajících), maximální
počet soketů, který může být otevřen (koresponduje s počtem současných hovorů), bude dán
systémem (limity se dají zvednout navýšením file deskriptorů “cat /proc/sys/fs/file-max“). Rovněž se
limit počtu užívaných soketů může nastavit přímo v příkazovém řádku pomocí -max_socket.
V případě dosažení maximálního počtu soketů je provoz distribuován pouze přes již otevřené sokety.
SIPp je původně generátor na signalizační úrovni a proto má omezenou podporu médií (RTP). Přece
jen má jednu zajímavou funkcionalitu, a to "RTP echo", která umožňuje SIPp naslouchat na lokální IP
a portu (specifikováno užitím přepínače -mi a -mp) RTP média. Cokoliv je přijato na této adrese/portu
je také vráceno odesílateli (použitelné pro echo audia i videa).
•
•
•
•
•
•
•
•
•
-mi
: Set the local media IP address (default: local primary host IP address)
-rtp_echo : RTP/UDP packets received on port defined by -mp are echoed to their
sender.
-mb
: Set the RTP echo buffer size (default: 2048).
-mp
: Set the local RTP echo port number. Default is 6000.
-min_rtp_port : Minimum port number for RTP socket range.
-max_rtp_port : Maximum port number for RTP socket range.
-rtp_payload
: RTP default payload type.
-rtp_threadtasks : RTP number of playback tasks per thread.
-rtp_buffsize
: Set the rtp socket send/receive buffer size.echoed back to the sender.
RTP streaming v SIPp "rtp_stream" podporuje strwming audia z kodeků PCMA, PCMU nebo
G729, podporované akce jsou následující:
•
•
•
•
<exec rtp_stream="file.wav" /> proběhne streaming audia z file.wav, formátu PCMA
<exec rtp_stream="[filename],[loopcount],[payloadtype]" /> vyvolá streaming audia ve
[filename], opakováno [loopcount] krát (výchozí hodnota je 1 a hodnota -1 indikuje
nekonečné opakování), a zacházeno s audiem bude dle [payloadtype] (8 je PCMA, 0 je
PCMU a 18 je pro G729).
<exec rtp_stream="pause" /> přejde z aktivního přehrávání d pauzy.
<exec rtp_stream="resume" /> bude pokračovat dále v aktivním přehrávání.
119
10 MGCP a IAX protokol
6
NAT vs. IP telefonie
V této kapitole se budeme zabývat problematikou překladu adres NAT (Network Address
Translation) z pohledu IP telefonie, seznámíme se s terminologií a klasifikací typů NAT a nakonec i
se zajímavými protokoly STUN, TURN a ICE, které umožňující průchod přes NAT [sil1]. Překlad
adres je důležitou vlastností směrovačů, používá se zejména ze dvou důvodů:
• omezit potřebný počet veřejných IP adres, s rozšiřováním IPv6 ztrácí tento důvod své
opodstatnění, přesto ještě dnes dominuje IPv4, kde je obvyklé dokonce poskytovateli za přidělení
veřejné adresy zaplatit,
• zvýšit bezpečnost podnikové či domácí sítě, skrytím vnitřních adres a jejich oddělením NAT
prvkem je nejjednodušší způsob ochrany proti neoprávněnému vniknutí z vnější sítě). Zařazením
NATu mezi vnitřní a vnější síť se automaticky vytvoří jednoduchý firewall a žádný počítač z vnější
sítě nemůže kontaktovat počítač na vnitřní síti, dokud to neudělá tento počítač sám.
Připojení vnitřní sítě LAN k internetu pak zajišťuje pouze jediná veřejná IP adresa. Ta je
přidělena na externí WAN rozhraní směrovače. U odchozího spojení dochází k nahrazení zdrojové
adresy z privátního rozsahu veřejnou IP adresou směrovače. Při příchozích spojeních zase dochází
ke změně cílové adresy z veřejné na privátní. Těmito privátními adresami jsou rozsahy:
•
•
•
6.1
Rozsah IP adres: 10.0.0.0 – 10.255.255.255, CIDR blok: 10.0.0.0/8
Terminologie
Pod funkcí NAT rozumíme překlad adres mezi veřejným a privátním (neveřejným rozsahem).
NAT pracuje v několika režimech [sin3]:
Dynamický NAT – mapuje vnitřní IP adresu na vnější IP adresu z nějaké skupiny IP adres
(address pool). NAT Pool je seznam globálních adres na externím rozhraní, je to množina
veřejných adres, které máme k dispozici při přístupu do vnější sítě WAN. Pokud se nějaké
zařízení z vnitřní sítě pokusí odeslat paket na IP adresu ve veřejné síti, tak NAT přidělí první
dostupnou IP adresu z NAT poolu a vytvoří se příslušný záznam v překladové tabulce, když
120
přijde odpověď z veřejné IP zpět, tak NAT zkontroluje cílovou adresu, podívá se do překladové
tabulky a zjistí, na které zařízení z vnitřní sítě má paket přeposlat. NAT rovněž vyměňuje IP
adresy v IP hlavičce, pracuje na L3. Existuje doba životnosti (timeout), po kterém se záznam v
překladové tabulce vymaže, díky timeoutu je umožněno obměňování IP adres.
Statický NAT – mapuje vnitřní IP adresu na vnější IP adresu. Statický NAT je používán pokud je
zapotřebí přistupovat z vnější sítě do vnitřní. NAT, provádí se statický překlad jedné IP adresy
vždy na tutéž IP adresu. Každá vnitřní IP adresa má pevnou externí veřejnou IP adresu, která je
nastavena v NAT prvku. Překladová tabulka je tedy statická a v případě nějaké změny je potřeba
ji upravit manuálně.
Overloading (PAT) – přetěžování, mapuje vnitřní IP adresy na jednu vnější IP adresu; bývá
označován jako PAT; jedná se o formu dynamického NATu. V případě PAT dochází k překladu
jak adres tak i příslušných portů, výhodou je, že za jednu externí IP adresu můžeme schovat
celou řadu služeb, které jsou hostovány na různých serverech. Překladová tabulka je rozšířena o
dvě položky: interní port, ze kterého byl paket odeslán a externí port, na který je paket odeslaný
ze zdrojového portu mapován. NAT prvek v tomto případě pracuje na L3/L4 a vymění IP adresu i
port v IP hlavičce paketu tak, jak to určuje překladová tabulka. Tento režim nejpoužívanější a
prakticky se takřka vždy setkáme u NAT se změnou IP a portů.
Mezi “ajťáky“ se běžně používá i sloveso “natovat“, což zahrnuje právě překlad IP adres a portů
mezi vnitřní a vnější sítí, kterou NAT odděluje.
6.2
Popis problému s průchodem SIP zpráv přes NAT
Jak jsem si vysvětlili v předchozí kapitole, tak NAT pracuje s IP adresami a porty, v hlavičkách IP
a TCP či UDP mění jejich hodnoty, ale SIP je aplikační protokol, který uvádí IP adresy a porty přímo
v polích SIP hlavičky. Co se stane, když tyto hodnoty z interní sítě za NATem nebudou odpovídat
hodnotám IP adres a portů ve veřejné síti před NATem? Situaci ilustruje obr. 6.1.
Ačkoliv bylo NATem vytvořeno mapování mezi vnitřní privátní adresou 10.0.0.1 s portem 42723 a
vnější veřejnou adresou 172.34.5.1 s portem 34123 a adresy i porty přepsány v hlavičkách IP a UDP,
tak odpověď na SIP žádost zpět nedorazí, protože ze znalosti fungování SIPu víme, že odpověď
putuje stejnou cestou jako žádost, a tato cesta je v polích Via, do kterých se zapíše nejdříve
odesílající UAC a následně další SIP Proxy, které žádost přeposílají, jenže ve Via je neveřejná
adresa 10.0.0.1, která ve veřejném prostoru IP adres neexistuje. Problémů je ovšem více, další
neveřejnou IP nalezneme v SDP v řádku o (původce), c (IP, na kterou bude terminován RTP stream)
a nakonec i port v m řádku bude jiný. Při registraci bude UA na REGISTRAR serveru zapsán na IP
10.0.0.1 a REGISTRAR sever se na UDP ani nedozví, že jeho odpověď 200 OK nebyla doručena
příjemci. Bez pomoci na straně klienta, serveru anebo přímo směrovači s NAT nebude možné SIP
provozovat.
121
Obr. 6.1. SIP zprávy přes NAT
6.3
Klasifikace typů NAT
Obr. 6.2. znázorňuje situaci, kdy host X za NAT komunikuje s dvěma různými zařízeními host 1 a
host 2. Pakety zasílané z X mají zdrojovou adresu a port X:x a cílová adresa a port Y:y, přičemž
NAT má k dispozici IP adresy pro mapování X1, X2, ... (nebo může mít pouze jedinou IP adresu
X1=X2). Existuje několik variant překladu adres a portů:
•
•
•
•
Full Cone NAT
Restricted Cone NAT
Port Restricted Cone NAT
Symmetric NAT.
Full Cone NAT (jedna k jedné) se chová tak, že všechny požadavky ze stejné vnitřní IP a portu
jsou mapovány na stejnou vnější IP a port. Jedná se v podstatě o statické mapování.
Restricted Cone NAT oproti předchozímu vyžaduje, aby nejprve vnitřní zařízení zaslalo paket
externímu. Poté všechny pakety z tohoto vnějšího zařízení (i s odlišnými porty) jsou poslány na toto
vnitřní zařízení.
122
Port Restricted Cone NAT dovoluje na vnitřní zařízení doručit paket jen tehdy, pokud byl
vnějšímu zařízení poslán paket z daného IP vnitřního zařízení a portu.
Symmetric NAT funguje tak, že požadavky ze stejné vnitřní IP a stejného portu jsou mapovány
na vnější IP a port pro danou komunikaci s externím zařízením. Pří komunikaci s dalším zařízením
ze stejné vnitřní IP a stejného portu je vytvořeno odlišné mapování, přičemž původní je odstraněno.
Obr. 6.2. Mapování v NAT
6.4
Provozování IP telefonie přes NAT
Naštěstí existuje několik způsobů, jak zajisti podporu provozování IP telefonie přes NAT, ty lze
roztřídit následovně:
•
•
•
•
•
•
pomocí STUN (Session Traversal Utilities for NAT) dle RFC5389, bohužel nevyřeší problém
NATu v případě Symmetric NAT
pomocí TURN (Traversal Using Relays around NAT) dle RFC 5766,
pomocí IEC (Interactive Connectivity Establishment) dle RFC 5245,
pomocí rport (receive port parameter) dle RFC 3581,
s pomocí překonání NATu na straně SIP serveru, kde je SIP Proxy doplněna RTP Proxy,
Media Proxy anebo NAT helperem,
podporou na routeru pomocí UPnP (Universal Plug and Play) anebo ALG (Application
Layer Gateway).
123
•
•
6.4.1
pomocí SBC (Session Border Controler), který se chová jako B2BUA (BAck to Back User
Agent) s podporou SIP ALG.
pomocí VPN, vytvořením šifrovaného tunelu.
STUN server
STUN byl poprvé publikován jako RFC 3489 (Simple Traversal of UDP through NAT), výrazně
byl rozšířen v RFC 5389 (Session Traversal Utilities for NAT). Základní myšlenka je znázorněna na
obr. 6.3. , STUN klient, který nezná použitou veřejnou adresu a port, odesílá žádost na STUN server
umístěného ve veřejném IP prostoru a v odpovědi dostává požadovanou informaci, tu použije do SIP
hlavičky a SDP těla odesílaných zpráv. Výhodou je podpora vícenásobných NATů, kdy STUN paket
odeslaný klientem může projít několika NAT servery, než dosáhne STUN server a nakonec se
dozvídá veřejnou IP adresu, se kterou byl požadavek na STUN server doručen. Právě tuto adresu
SIP klient potřebuje znát k správnému vyplnění polí SIP zprávy (o výměnu IP adres na L3 a portů na
L4 se postará NAT), čili prakticky všichni SIP klienti mají dnes v sobě integrovaného STUN klienta.
Obr. 6.3. Mapování vnější veřejné IP a portu pomocí STUN protokolu
Jednoduchý open-source STUN server je dostupný na URL http://sourceforge.net/projects/stun/
(je dostupná i verze pro MS WIN), jedná se o balíček cca 150 kB obsahující server a klienta. Po
instalaci je možné spustit STUN server příkazem stund a pokud máme na stroji dvě IP adresy, atk
můžeme specifikovat pomocí přepínače –h primární , pomocí –a sekundární a nakonec pomocí
přepínače –b poběží na pozadí (background), primární IP používá port 3478 a sekundární 3479
(může sloužit jako backup).
# apt-cache search stun
stun - Server daemon and test client for STUN
# apt-get install stun
# stund -h 195.113.113.147 -a 195.113.113.151 –b
124
STUN server version 0.96
Running with on interface 195.113.113.147:3478 with alternate 195.113.113.151:3479
Port 3478 for receiving UDP is in use
Port 3479 for receiving UDP is in use
Problémem STUN protokolu v SIP klientech pro překonání NATu je ovšem Symetric NAT, kde
vnější přidělený port pro komunikaci se STUN serverem bude odlišný od mapování pro komunikaci s
jiným zařízením (SIP serverem).
6.4.2
Překonání NATu pomocí TURN, ICE a rport
TURN (Traversal Using Relays around NAT) RFC 5766 je protokol, který umožňuje s využitím
TURN serveru ve veřejné síti přijímat data zařízení za NATem, včetně symetrickým NATem. Využití
je možné i pro IPv4 - IPv6 relay [sim], [sil2].
TURN relay server využívá významné zdroje stroje, na kterém běží, protože média jsou
přenášeny přes TURN relay a tím pádem serverem prochází up a down stream (incoming +
outgoing), oproti SIP klientovi dvojnásobné požadavky toku na pásmo. TURN server je vytěžován
v závislosti na počtu současně probíhajících hovorů. Tím, že musí zpracovat a přeposlat každý paket,
media relay rovněž zanáší zpoždění a vkládají další “hop“ do trasy paketu, čímž zvyšují
pravděpodobnost ztráty.
Myšlenka je postavena na alokaci portu pro média na TURN serveru, viz. obr. 6.4, tím pádem
SIP klient za NATem otevře trasu k TURN serveru pomocí TURN Allocate, poté komunikuje se SIP
serverem, kde v SDP uvádí pro terminaci médií adresu TURN serveru, kterou dostal jako Relay
address. Média přeposílá TURN relay na NAT, který ví, kam média přeposlat, jelikož SIP klient (resp.
TURN client) již záznam pro překlad v NAT vytvořil. Tím je dosaženo průchodu i symetrickým
NATem. Základní rysy TURN protokolu jsou následující:
•
•
•
•
funguje i pro symmetric NAT,
TURN klient inicializuje a udržují spojení na TURN relay,
média procházejí přes TURN relay.
je chápán jako rozšíření STUN
Adresa alokovaná TURN serverem se nazývá Relayed address, viz. obr 6.4 a je použita pro RTP.
TURN garantuje komunikaci ve všech případech použití NATu, pokud není cíleně zakázán politikou
na firewallu. Nevýhodou ovšem je, že je v trase komunikace, má vysoké nároky na zdroje, pásmo a
přináší další zpoždění. Co se týče posledně zmíněného, tento efekt se dá zmírnit tím, že TURN
server bude co nejblíže NAT zařízení, tzn. provozován jako služba ISP poskytovatele. TURN relay
server najdeme v balíčku rfc5766-turn-server , po instalaci okamžitě TURN běží jako služba,
můžeme jej ovšem spustit i s volbou –L naslouchající na konkrétní IP adrese.
# apt-get install rfc5766-turn-server
# turnserver stop
125
1388512160: RFC 3489/5389/5766/5780/6062/6156 STUN/TURN Server
1388512160: version Citrix-2.6.5.2 'Harding Grim'
# less /etc/default/rfc5766-turn-server
TURNSERVER_ENABLED=0
# turnserver –L 195.113.113.141
Obr. 6.4. Průchod IP telefonie s pomocí TURN serveru
IEC (Interactive Connectivity Establishment) RFC 5245 je protokol vhodně využívající STUN
a TURN. Koncepčně je poměrně jednoduchý, na základě analýzy sítě určí jednotlivé možnosti a
vypočte priority jednotlivých „kandidátů“.
Zdařilá implementace ICE kombinující STUN a TURN je v balíčku resiprocate-turn-server a je
součástí většiny linuxových distribucí. Po instalaci ihned běží, což je možné ověřit přes netstat, lze
ovšem i ručně nastavit IP adresy v konfiguračním souboru a poté službu restartovat.
# apt-cache search resiprocate-turn-server
resiprocate-turn-server - reSIProcate SIP stack - ICE/TURN server
126
# apt-get install resiprocate-turn-server
# netstat -nlp | grep reTurnServer
# nano /etc/reTurnServer.config
TurnAddress = 195.113.113.142
AltStunAddress = 195.113.113.155
AuthenticationRealm = osanet.cz
LongTermAuthPassword = hesloJEveslo
# service resiprocate-turn-server restart
Restarting TURN relay: reTurnServer.
V RFC 3581 je definován nový parametr rport do pole Via hlavičky SIP, který umožňuje klientům
zažádat SIP server o vložení zdrojové IP adresy a portu, ze které byla žádost obdržena, do Via.
Následující INVITE byl poslán z IP adresy 10.1.1.1 a zdrojového portu 4540. SIP Proxy je na IP
192.0.2.2 (proxy.example.com) a poslouchá na standardním UDP 5060.
Via: SIP/2.0/UDP 10.1.1.1:4540;rport;branch=z9hG4bKkjshdyff
UA posílá žádost INVITE přes NAT, která po průchodu NAT odchází z veřejné IP 192.0.2.1 a
zdrojového portu 9988. SIP Proxy přidává tyto informace do Via, tím pádem je možné doručit
odpověď pomocí informací received a rport, pokud tedy Via obsahuje tyto hodnoty, tak odpověď je
směrována na danou IP adresu a port.
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77
Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988;branch=z9hG4bKkjshdyff
Podstatnou výhodu má B2BUA, který má plnou kontrolu nad spojením včetně médií. V případ
Asterisku (B2BUA) je nutné v jednotlivých konfiguračním souboru /etc.asterisk/sip.conf nastavit
následující:
nat = yes
/* Asterisk ignoruje IP adresu (i port), kterou mu zasílá klient ve zprávě
SIP INVITE v poli Contact a odpověď zasílá na stejnou IP adresu a port,
odkud mu byla zpráva zaslána.
qualify = yes
/* dále je nutno udržet NAT mapování „otevřené“, Asterisk pravidelně
každou minutu zasílá zprávu SIP OPTION. Od verze Asterisku 1.6.0 lze
změnit frekvenci opakování parametrem qualifyfreq.
directmedia = nonat
/* rovněž je nutné (není li použit STUN) zakázat pro klienty za NATem
možnost re-invite. V IAX pak nastavit transfer = no (mediaonly).
127
11 Asterisk
7
Asterisk
Asterisk je fenomén posledních let, to co představuje Apache v oblasti webových serverů, tak
obdobné postavení má Asterisk v IP telefonii. Trend nasazování IP telefonie je dlouhodobý a
telefonie se ocitá v roli aplikace na IP sítích. Alfou a omegou IP telefonie ve firemním prostředí je
pobočková ústředna (PBX), v operátorském je to softswitch. V případě pobočkové ústředny se častěji
mluví o komunikačním serveru, protože většina nasazovaných řešení PBX může sloužit jako
aplikační server, překladová média brána či poskytovat podporu dalších služeb. V současné době
nejrozšířenější volně dostupnou softwarovou realizací takové ústředny představuje produkt Asterisk
od firmy Digium ™. V následujících kapitolách provedeme čtenáře jednotlivými konfiguracemi služeb,
tak aby byl po přečtení textu schopen vytvořit fungující systém a infrastrukturu umožňující efektivní
používání VoIP telefonie v praxi. Nejdříve ovšem pár vět k původu Asterisku. Při vzniku Asterisku byl
Mark Spencer, čerstvý absolvent Auburn University v Alabamě, který se v roce 1999 rozhodl napsat
pro linux svůj vlastní softvér realizující pobočkovou ústřednu s hlasovou poštou (voice-mail) namísto
zakoupení komerčního produktu, údajně nebylo na PBX dost prostředků. Výstup své práce zveřejnil
jako open-source a nabídl tím široké komunitě uživatelů, testerů i vývojářů.
“I was so excited the first time I got a phone call delivered through my PC using my
own software.”
Mark Spencer
Nevíme, nakolik je historka pravdivá, ale každopádně v roce 1999 vznikl jeden
z nejvýznamnějších open-source projektů. Mark Spencer založil o tři roky později firmu Digium, která
dlouhodobě stojí za vývojem Asterisku a protože SW Asterisk se prodávat nedá, tak její profit je z
především z technické podpory a z prodeje HW, který je plně kompatibilní s Asteriskem, jedná se o
Digium Cards jako je T1/E1/FXO/FXS.
7.1
Verze Asterisku
Dnes je vývoj Asterisku z větší části záležitostí open-source komunity, na jeho kódu se podílí
stovky vývojářů z různých částí světa, rychle se vyvíjí a pro řadu komerčních firem je velmi obtížné
Asterisku konkurovat, většinou se nové funkcionality (jako např. webRTC) objeví nejdříve v Asterisku
128
11 Asterisk
a až poté u komerčních produktů, pro něž je Asterisk velkou inspirací. Pro ilustraci vývoje si ukážeme
aktuální roadmapu a podporu jednotlivých verzí Asterisku, viz. obr. 4.1. První použitelná verze
s dlouhodobou podporou byla 1.2 uvolněná v roce 2005 následovaná verzí 1.4 z roku 2006, 1.6
z roku 2008 a 1.8 z roku 2010. Další vývoj již vidíme na obr. 7.1, došlo ke změně číslování ve
verzích, verze Asterisk 10 byla uvolněna v roce 2011 a prakticky každý rok přichází další verze.
Rovněž vidíme, že některé verze mají delší podporu (LTS – Long Term Support). Během této
podpory jsou zajišťovány opravy, jednak se korektury (patche) nabízejí přímo ke stažení a jednak se
v rámci hlavní řady uvolňují další podverze (subversioning) a velmi snadno se dá provést upgrade,
protože daná verze zachovává stejnou architekturu, strukturu souborů , notaci v konfiguracích a ve
prakticky zapracovává patche, které vznikají v rámci dané řady, např. verze 1.8.0 je z října 2010 a
verze 1.8.25 z prosince 2013 s řadou oprav. U nové verze jsou změny v architektuře, používají se
jiné knihovny, zásadní změny v kódu již neumožňují záměnu konfiguračních souborů, např. ve verzi
Asterisk 12 je zcela přepracován SIP stack (mimochodem je postaven na knihovně PJSIP) a změnila
se i notace v konfiguračním souboru sip.conf pro SIP kanál. U LTS verzí je podpora ve formě
vydávání dalších podverzí a patchů garantována po dobu alespoň čtyř let a repozitáře verze jsou
udržovány ještě déle [md2].
Obr. 7.1 Roadmapa verzí Asterisku
7.2
Popis Asterisku
Asterisk je open-source softwarová PBX určená pro instalaci na standardních PC a spolu se
správným rozhraním může být použita jako PBX pro domácí uživatele, podniky, poskytovatele VoIP
služeb a telefonní společnosti. Asterisk je rovněž open-source komunita a komerční produkt od firmy
129
11 Asterisk
Digium ™. Systém je navržen tak, aby vytvořil rozhraní mezi telefonním hardwarem či softwarem a
libovolnou telefonní aplikací. S jednotlivými protokoly SIP, IAX, H.323 pracuje Asterisk jako s kanály
navázanými na jádro, DAHDI (Digium Hardware Device Interface) představuje rozhraní směrem k
PSTN, může se jednat o ISDN BRI či PRI karty, FXS, FXO, apod, viz. obr 7.2. Příkazový řádek CLI je
silným nástrojem Asterisku, stejně jako Manager Interface. Srdcem Asterisku je Dialplan, kde je
definováno chování v případě obsluhy požadavku, ať už odchozího či příchozího volání anebo
požadavku na vyvolání služby, viz. obr. architektury Asterisku.
Obr.7.2 Architektura Asterisku
7.2.1
Režimy Asterisku
Jak již bylo naznačeno v úvodu, Asterisk může mimo jiné sloužit jako:
•
•
•
•
•
Různorodá VoIP gateway mezi protokoly (MGCP, SIP, IAX, H.323).
Pobočková ústředna (PBX).
Voicemail služba s adresářem.
Interaktivní hlasový průvodce (IVR server).
Softwarová ústředna (Softswitch).
130
11 Asterisk
•
•
•
•
•
•
•
•
Konferenční server.
Packet voice server.
Šifrovací médium telefonních nebo faxových volání.
Překladač čísel.
Aplikace Calling card,
Prediktivní volič,
Vzdálená „kancelář“ pro existující PBX.
A další...
Asterisk také podporuje služby, které byly dříve součástí pouze pokročilých firemních řešení:
•
•
•
•
•
7.2.2
Hudba pro zákazníky v pořadí čekající ve frontě na hovor, podpora streamování médií a
MP3 souborů.
Fronty volajících, kdy tým agentů může odpovědět na volání a může sledovat fronty
(vhodné pro Call Centra).
Integrace Text-to-speech modulů a rozpoznávání hlasu.
Podrobné záznamy o hovorech jsou převáděny do textových souborů a SQL databází.
Propojení s PSTN sítí skrze digitální a analogové linky.
Kodeky a protokoly Asterisku
Obvykle je snaha, aby bylo možné v dané datové sítí realizovat co nejvíce hlasových spojení.
Kodeky poskytují nové možnosti pro digitální přenos hlasu, včetně komprese, která je jednou z
nejdůležitějších vlastností, mezi další vlastnosti patří detekce hlasové aktivity, vyrovnání paketové
ztráty, a generování výplňového šumu. V Asterisku jsou podporovány následující kodeky s uvedenou
šířkou pásma. Ty mohou být samozřejmě transparentně překládány z jednoho na druhý [md2].
•
•
•
•
•
•
•
•
•
•
•
•
•
G.711 ulaw (USA) - (64 Kbps).
G.711 alaw (Europe) - (64 Kbps).
G.722 (širokopásmový kodek 7 kHz) – (64 Kbps).
G.723.1 – pouze pass-through režim
G.726 - (16/24/32/40kbps)
GSM - (12-13 Kbps)
iLBC - (15 Kbps)
LPC10 - (2.5 Kbps)
Speex - (2.15-44.2 Kbps)
G.729 – nutná licence (8Kbps)
SILK – nutná licence (superwideband – 12 kHz)
Siren7 – nutná licence, G.722.1 , 7 kHz
Siren14 – nutná licence, G.722.1 AnnexC, 14 kHz
Kromě těchto audio kodeků je zde podpora videa h.263 a h.264. Odesílání dat z jednoho
telefonu do druhého by mělo být snadné za předpokladu, že si data samy najdou cestu skrze síť.
V praxi je nutné pro toto směrování využívat signalizační protokoly, dominantním a nejpoužívanějším
signalizačním protokolem je SIP. Přesto existuje stále spousta systémů, které pro signalizaci ve
VoIP síti využívají starších protokolů jako jsou např. H.323. Jiný protokol IAX je zase nativním
131
11 Asterisk
protokolem Asterisku a výborně prochází NATem. Seznam podporovaných signalizačních protokolů
v Asterisku je uveden níže:
•
•
•
•
•
•
•
7.2.3
SIP
H323
IAX2
MGCP
SCCP (Cisco Skinny)
Nortel unistim
Jingle
Služby Asterisku
Asterisk nabízí množství doplňkových služeb, jak klasických, tak i pokročilých, které jsou obvykle
poskytovány pouze špičkovými firemními PBX. Jako doplňkové služby a funkce si uvedeme
následující příklady, výčet nemusí být úplný, ale i tak je docela obsáhlý:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
ACCOUNT CODE, používá se pro účely tarifování. Volající před volbou čísla vloží svůj kód.
Do CDR (Call Detail Recording) se zaznamenávají údaje o délce hovoru, volaném čísle, ceně,
atd...
AUTOMATED ATTENDANT, volající je přepojen na požadovanou pobočku bez účasti
spojovatelky.
AUTOMATIC HOLD, pokud chceme provést hovor druhý hovor, tak můžeme inicializovat bez
zavěšení předchozího a Asterisk první hovor automaticky podrží, přičemž se k němu můžeme
zpětně vrátit.
CALL TRANSFER, jedná se o předání hovoru.
BLACKLIST, seznam nežádoucích čísel, které jsou jako příchozí hovory odmítnuty.
BLIND TRANSFER, je předání hovoru na jinou pobočku bez sledování toho, zda hovor někdo
přijme, hovor je předán i s vyzváněním.
CALL DETAIL RECORD, záznam hovorů uskutečněných v PBX, který obsahuje volající číslo,
volané číslo, datum, délku hovoru a případně další informace.
CALL FORWARDING ON BUSY, příchozí hovor je automaticky přesměrován za podmínky,
že je volané číslo obsazeno.
CALL FORWARDING ON NO ANSWER, příchozí hovor je automaticky přesměrován jen
tehdy, pokud volané číslo neodpovídá, tzn. po určitém čase.
CALL FORWARDING UNCONDITIONALLY, jedná se o okamžité přesměrování bez
podmínek. CALL MONITORING, evidence příchozích, odchozích a zmeškaných volání,
přístup přes web, uživatel po autentizaci vidí seznam volání, které se týkají jeho účtu.
CALL PARKING, odložení hovoru do virtuálního úložiště s možností jeho vyzvednutí stejnou
nebo jinou pobočkou.
CALL QUEUING, umožňuje řadit příchozí hovory do fronty a vyzvedávat je dalším volným
účastníkem konkrétní skupiny.
CALL RECORDING, umožňuje zaznamenávat hovory, zaznamenané hovory jsou uloženy v
požadovaném formátu (např. PCM či GSM) a nabídnuty k přehrání oprávněnému uživateli,
přihlášení probíhá přes https a po zadání hesla jsou nabídnuty pouze hovory týkající se
konkrétní pobočky autentizovaného uživatele.
132
11 Asterisk
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
CALL RETRIEVAL, funkce vyvolá osobu, která může převzít volání.
CALL ROUTING, je provolení na pobočku (DDI – Direct Dialing In, provolba).
CALL SNOOPING, umožňuje odposlouchávat určenou skupinu telefonů.
CALLER ID, je funkce zobrazení čísla volajícího a jména volajícího.
CALLER ID BLOCKING, hovor je odmítnut na základě identifikace volajícího.
CALL WAITING, je upozornění na čekající volání během sestaveného spojení, po jeho přijetí
je možné střídání mezi oběma hovory.
CALL ID ON CALL WAITING, je identifikace dalšího volajícího při probíhajícím hovoru.
CONFERENCE BRIDGING. vytvoří konferenci mezi terminály různých typů jako lokální
pobočkou, vzdálenou linkou, mobilním účastníkem, VoIP spojením, apod...
DATABASE STORE / RETRIEVAL, ukládá informace o hovorech do DB pro pozdější využití.
DATABASE INTEGRATION, Asterisk umožňuje poskytování informací o volajícím účastníkovi
volanému před přijmutím volání nebo během hovoru.
DIAL BY NAME, namísto čísla je možné volit i jméno (jako alias).
DISTINCTIVE RING, jedná se o rozdílný typ vyzvánění založený na identifikaci volajícího.
DUNDI (Distributed Universal Number Discovery), je distribuovaný systém směrování, který
v síti Asterisků umožní jednak rozložení zátěže mezi různé servery a jednak zvýšení odolnosti
při výpadku některého z Asterisk serverů (cluster – několik Asterisků, které se navenek tváří
jako jeden velký softswitch).
DO NOT DISTURB, aktivací funkce nerušit je volání přesměrováno na ohlášení, spojovatelku
nebo jinou pobočku, apod...
ENUM, Asterisk podporuje vyhledávání telefonních čísel přes DNS, kde je realizováno
mapování telefonních čísel na jmenné identifikátory (URI), pokud je spojení na vyhledanou
URI adresu nedostupné, tak se použije další pravidlo (např. směrování přes PSTN).
INTERACTIVE DIRECTORY LISTING, umožňuje volajícímu účastníkovi interaktivní vyhledání
volaného podle jeho jména v korporátním adresáři.
INTERACTIVE VOICE RESPONSE, IVR je pokročilý systém pro obsluhu příchozích
volání,volající prochází hlasovým menu a pomocí volby čísel volí možnosti spojení.
LOCAL AND REMOTE CALL AGENTS, účastník se může pomocí své identifikace přihlásit na
kterékoliv telefonu a používat ho jako svůj vlastní (tzn. s vlastním číslem, nastavením služeb,
atd.)
MUSIC ON HOLD, hudba na přidržené lince, přičemž audio soubory lze vytvářet
jednoduchým způsobem.
PREDICTIVE DIALER, funkce je používaná odchozími centry volání, spojení se sestavuje na
základě statistického modelu, který určuje, kdy bude volaná strana dostupná.
PRIVACY MANAGER, jestliže je kód pro vzdálený přístup zablokován (viz. LOCAL AND
REMOTE CALL AGENTS), potom ručním zadáním čísla Privacy Manager zkontroluje, zda je
číslo na Black listu nebo White listu a podle toho volbu povolí nebo zamítne.
PROTOCOL CONVERSION, umožňuje spojení mezi sítěmi používajícími rozdílné protokoly.
REMOTE CALL PICKUP, umožňuje vyzvednout hovor, který vyzvání na jiné pobočce.
REMOTE OFFICE SUPPORT, umožňuje přihlásit telefon z jiné PBX tak, že má vlastnosti
lokální pobočky.
ROAMING EXTENSIONS, jednotlivé osoby jsou vybaveny číslem pobočky a kódem, pomocí
kterého se mohou přihlásit na kterémkoliv pobočkovém telefonu, tato služba je odlišná od
LOCAL AND REMOTE CALL AGENTS tím, že číslo pobočky, pokud se zrovna nepoužívá,
neexistuje v Dialplan.
133
11 Asterisk
•
•
•
•
•
•
•
•
7.3
ROUTE BY CALLER ID, hovor je směrován na základě čísla volajícího na pobočku, do fronty
nebo do skupiny účastníků (Ring Group). SMS MESSAGING, Asterisk umožňuje pomocí
SMS upozorňovat např. zmeškaná volání a zanechané vzkazy, SMS se posílají přes SMS
bránu (může to být GSM modem lokálně připojený k Asterisku).
SPELL/SAY, funkce umožňuje přečíst text, např. email.
SUPERVISED TRANSFER, je předání volání řízené automatickým zařízením (např. Voice
Response Unit), které vyhodnotí výsledek předání – přijato, obsazeno, nevyzvednuto.
TALK DETECTION, funkce umí detekovat hovor (rozezná záznamník od osoby).
THREE-WAY CALLING, je konference tří účastníků, je možné ovšem dělat i konference o
několika desítkách účastníků (na Asterisku otestováno do 30-ti) s využitím konferenční
místnosti (Meet-Me).
TIME AND DATE, funkce čte čas a datum volajícímu.
TRANSCODING, Asterisk umožňuje konverzi mezi různými kodeky.
TRUNKING, je funkce připojení do klasické telefonní sítě pomocí interní karty v Asterisku.
VOICEMAIL, umožňuje nahrát vzkaz pro volaného, zpřístupnit nahrané vzkazy z telefonu,
přes web anebo odeslat vzkaz do poštovní schránky uživatele jako email.
Instalace
instalace je možná přímo z repozitáře, ověříme si, zda nám vyhovuje verze a nainstalujeme.
root@debian119:~# apt-cache show asterisk
Package: asterisk
Version: 1:11.7.0~dfsg-1
root@debian119:~# apt-get install asterisk
Asterisk ihned běží, samozřejmě můžeme zkompilovat určitou verzi, potom je užitečné se
podívat na požadavky dané verze na https://wiki.asterisk.org/wiki , např. pro Asterisk 11 na Ubuntu je
postup následující.
# sudo apt-get install build-essential subversion libncurses5-dev libssl-dev libxml2-dev libsqlite3-dev
# mkdir -p ~/src/asterisk-complete/asterisk
# cd ~/src/asterisk-complete/asterisk
# wget http://downloads.asterisk.org/pub/telephony/asterisk/ asterisk-11-current.tar.gz
# cd ~/src/asterisk-complete/asterisk/11
# ./configure
# make
# sudo make install
# sudo make config
Můžeme ověřit status asterisku, zastavit je, spustit, restartovat a připojit se na konzoli a ovládat
jej z příkazového řádku. Pokud Asterisk běží, tak se připojíme s přepínačem -r pomocí asterisk –rvvv,
pokud nám neběží, tak přepínačem –c rovnou aplikaci spustíme asterisk –cvvv.
# /etc/init.d/asterisk status
# /etc/init.d/asterisk {start|stop|restart|reload|force-reload}
134
11 Asterisk
root@debian119:~# asterisk -rvvv
Asterisk 11.7.0~dfsg-1, Copyright (C) 1999 - 2013 Digium, Inc. and others.
Created by Mark Spencer <[email protected]>
=========================================================================
Connected to Asterisk 11.7.0~dfsg-1 currently running on debian119 (pid = 5051)
debian119*CLI> help
debian119*CLI> exit
7.4
Globální nastavení asterisk.conf a modules.conf
Globální nastavení Asterisku najdeme v konfiguračním asterisk,.conf umístěném v adresáři
/etc/asterisk stejně jako většina konfiguračních souborů Asterisku. Tento soubor ovlivňuje chování
běhu celého Asterisku. Často není třeba do jeho konfigurace zasahovat, ale je dobré jeho možnosti
znát. Po instalaci nalezneme ve složce /etc/asterisk vzorový soubor asterisk.conf. Pokud bychom
chtěli využívat jiný asterisk.conf soubor, předáme cestu k němu jako parametr při spouštění Asterisku
v příkazové řádce
# asterisk –C /home/voz29/asterisk.conf
Obsahem konfiguračního souboru asterisk.conf je sekce nastavení složek [directories]. Pro
většinu instalací není třeba tuto konfigurace měnit, důvodem ke změně může být běh několika
instancí Asterisku v jednom čase nebo pokud chceme konfigurační soubory ukládat na
nestandardním místě. Tímto způsobem můžeme také ovlivnit ukládání objemnějších dat v případě
nahrávání hovorů apod. Následující tabulka obsahuje název direktivy, její hodnotu a vysvětlení
funkce dané direktivy [mik].
Volba
Hodnota
(Příklad)
Vysvětlení
astetcdir
/etc/asterisk
Umístění konfiguračních souborů Asterisku
astmoddir
/usr/lib/asterisk/modules
Umístění modulů, které je možné načíst
astvarlibdir
/var/lib/asterisk
Základní umístění pro různé stavové informace
používané různými částmi Asterisku. Zároveň sem
Asterisk ukládá při běhu některé informace.
astdbdir
/var/lib/asterisk
Asterisk ukládá svoji vnitřní databázi do soubor
astdb uloženého v tomto umístění.
astkeydir
/var/lib/asterisk
Základní umístění pro klíče používané k šifrování
astdatadir
/var/lib/asterisk
Cesta k pomocných datům, které Asterisk používá
(zvuky apod.)
135
11 Asterisk
astagidir
/var/lib/asterisk/agi-bin
Umístění pro AGI skripty
astspooldir
/var/spool/asterisk
Složka pro ukládání souborů jako záznamy hovorů,
hovory ve hlasové schránce apod.
astrundir
/var/run/asterisk
Uložiště UNIX kontrolních soketů nebo čísla
procesu
astlogdir
/var/log/asterisk
Uložiště log souborů
Tab. 7.1 Directivy v asterisk.conf
Další sekcí jsou volby [options]. V této sekci jsou nastaveny globální proměnné pro běh
programu. V tabulce jsou uvedeny nejvýznamnější z nich.
Volba
Hodnota
(příklad)
Vysvětlení
verbose
3
Nastaví úroveň výpisu v CLI asterisku a v logu. –v
debug
3
Nastaví úroveň ladění. –d
highpriority
yes
Běh s real-time prioritou
dumpcore
yes
Nařídí Asterisku vytvořit dump jádra při spadnutí programu
autosystemnme
yes
Automaticky nastaví instanci název podle hostname počítače
maxcalls
100
Nastaví maximální počet simultánních hovorů, default. Bez
limitu
maxload
0.9
Nastaví maximální zatížení. Pokud je tato hodnota překročena,
nepřijímá již Asterisk nové hovory.
maxfiles
1000
Nastaví maximální počet souborových deskriptorů
minmemfree
1
Nastaví minimální počet MB volné paměti, do které bude
Asterisk přijímat hovory.
cache_record_files
yes
Povolí ukládání hovorů do record_cache_dir již během hovoru.
record_cache_dir
/tmp
složka pro ukládání nahrávaných hovorů během hovoru
Tab. 7.2 Options v asterisk.conf
136
11 Asterisk
Ostatní volby již nejsou tak významné a nemá cenu se jimi v téhle fázi seznamování zabývat.
Nyní si ukážeme, jak je možné v Asterisku pracovat s přídavnými moduly.
Soubor modules.conf není v Asterisk instalaci striktně vyžadován, avšak bez modulů by Asterisk
nebyl schopen dělat téměř nic. Pokud v konfiguračním souboru /etc/asterisk/modules.conf zvolíme
autoload=yes, Asterisk vyhledá všechny moduly v /usr/lib/asterisk/modules složce a načte je při
startu. Ačkoliv většina modulů nevyžaduje příliš systémových prostředků a jsou načteny velmi rychle,
je vhodné načíst pouze ty moduly, které máme v plánu využívat. Moduly, které navíc využívají
síťových prostředků, mohou být z bezpečnostního hlediska zneužity.
Rovněž je možné nechat ze složky načíst všechny moduly, které najde a explicitně říct, které
moduly nechceme načíst použitím noload direktivy. Jedna z možností, jak kontrolovat, které moduly
jsou načteny je jednoduše nekompilovat a neinstalovat je během instalačního procesu. Během něj
provádíme příkaz make menuselect, který zobrazí v prostředí menu dostupné moduly ke kompilaci.
Moduly, které mají před sebou XXX, jsou moduly, které nemohou být zkompilovány protože configure
skript nebyl schopný najít požadované závislosti. Přehled direktiv pro modules .conf je v následující
tabulce
Volba
Hodnota
(příklad)
Vysvětlení
autoload
yes
Asterisk načte všechny moduly, kromě modulů zmíněných
v noload direktivě.
preload
res_odbc.so
Indikuje, že zmíněný modul by měl být načten první v pořadí
load
chan_sip.so
Načte modul (autoload=no)
noload
chan_alse.so
Definuje modul, který nemá být načten
require
chan_sip.so
Stejně jako load, ale Asterisk skončí, pokud dojde k chybě při
načtení modulu
preload-require
res_odbc.so
Stejně jako preload a require dohromady
Tab. 7.3 Moduly v modules .conf
7.5
Konfigurace SIP a IAX uživatelů v sip.conf a iax.conf
V této části se seznámíme s konfigurací SIP a IAX kanálu. Konfigurace SIP a IAX je uložena
v sip.conf a iax.conf. Volání je směrován na pobočku (extension), která je prezentována řetězcem
alfanumerických znaků, čili můžeme např. volat jménem Alice anebo číslem 200.
137
11 Asterisk
7.5.1
SIP uživatel v sip.conf
V následující ukázce je znázorněn příklad rychlé konfigurace SIP účtu. Konfigurační soubor
sip.conf obsahuje jednak obecné nastavení v sekci [general], které je platné, pokud specifická sekce
neobsahuje jinou volbu parametrů ze sekce [general], některé z obecných parametrů můžou být
specifikovány i v sekci uživatele, např. kodeky či kontext. Na konec souboru sip.conf přidáme
následující.
[alice]
type=friend
context=vlastni
language=cz
host=dynamic
username=300
secret=heslo
callerid=Alice <300>
;Definování účtu
;Vyjadřuje skupinu v dialplanu ;(/etc/asterisk/extensions.conf), kde
;hledat v případě volání tohoto čísla
;Povolení registrace účtu na všech IP ;adresách
;Přihlašovací jméno při registraci účtu
;Přihlašovací heslo při registraci účtu
;identifikace volajícího
[bob]
type=friend
context=Asterisk1
language=cz
host=dynamic
username=400
secret=heslo
callerid=Bob <400>
7.5.2
IAX uživatel v iax.conf
Definice IAX účtů používá téměř stejnou syntaxi, jako definice SIP účtů, s jediným rozdílem, že
se provádí v souboru iax.conf, opět umístěném v hlavním adresáři s aplikací /etc/asterisk, níže
uvedené přidáme na konec souboru.
[Klara]
type=friend
context=vlastni
language=cz
host=dynamic
username=500
secret=heslo
callerid=Klara <500>
;Definice účtu
Pokud by se nám objevovala chyba chan_iax2.c:5010 handle_call_token: Call rejected,
CallToken ;Support required, tak přidáme do hlavní sekce [general] následující.
[general]
calltokenoptional=0.0.0.0/0.0.0.0
138
11 Asterisk
Po uložení konfigurace provedeme reload systému anebo pouze SIP či IAX2 modulu a
přesvědčíme se o existenci uživatelů.
# asterisk –rvvv
*CLI> reload
*CLI> sip show peers
*CLI> sip show users
7.5.3
Další možnosti sip.conf a iax.conf
Následující
v iax.conf.
Volba
tabulka obsahuje možnosti nastavení parametrů uživatele jak v sip.conf, tak
Hodnota
[Alice]
Vysvětlení
Název definujíci uživatele
type
friend
Znamená, že ovladač kanálu (channel driver) se bude
snažit nejdříve najít jméno a až potom IP adresu. (Peer =
IP adresa + port. User = hledá název v SIP hlavičce
„From“, který se shoduje s názvem v hranatých závorkách)
host
dynamic
akceptuje se IP adresa uživatele, jinak je možné zadat
statickou adresu, na které bude uživatel dosažitelný
disallow
all
Implicitně zakáže všechny povolené kodeky
allow
alow,ulow
Povolí uvedené kodeky
context
vlastní
Uživatel v dialplanu je obsloužen daným kontextem
callerid
„Alice 200“
Název pobočky pro identifikaci (zobrazení) u volaného
(objeví se v poli FROM)
secret
heslo
Heslo k autorizaci
Tab. 7.4. Parametry uživatele v sip.conf a iax.conf
Uvedeme si podrobnější nastavení sip.conf včetně globálních parametrů a možnosti nastavení
různých typu účtů .
[general]
bindport=5060
srvlookup=yes
qualify=1000
;sekce general určuje společná nastaveni pro všechny účty
;port na kterém naslouchá SIP
;podpora DNS
;monitorování dostupnosti klientů
139
11 Asterisk
disallow=all
allow=alaw
dtmfmode=rfc2833
language=cz
allowguest=yes
context = cizi
;zakazuje všechny kodeky
;povolíme jen vybrané
;způsob přenosu DMTF volby
;výchozí jazyk,např. pro chybové hlášky
;povolení hovorů neregistrovaným klientům
;určuje kontext, „skupinu” do které uživatel patří
;registrace asterisku jako klienta, rovněž musí být definován i účet viz níže
register => user[:secret[:authuser]]@host[:port][/extension]
; „deklarace” účtů
[my_provider]
name= my_provider
secret=heslo_1
type=peer
fromuser=XXXX
fromdomain=YY.com
host=provider.cz
canreinvite=no
context = verejny
;učet k poskytovateli - název
;registrační jméno
;heslo
;ovlivňuje autentizaci, peer – servery, user – klient, friend – oba
;položka fromuser v SIP protokolu (pokud poskytovatel vyžaduje)
;položka fromdomain v SIP protokolu (pokud poskytovatel vyžaduje)
;IP adresa, DNS název (, dynamic - dynamicky přidělená registrací)
;určuje zda mohou RTP pakety „obcházet” Asterisk
;uživatelský účet – název (nejčastěji přímo telefonní číslo)
;registrační jméno
;heslo
;friend – autorizace v obou směrech
;dynamicky získaná IP hosta registrací
[nazev_uctu]
name=nazev_uctu
secret=heslo_2
type=friend
host=dynamic
canreinvite=no
nat=yes
context = vnitrni
;bude klient za NATem?
[general]
port = 2727
bindaddr = 0.0.0.0
; IP adresa (0.0.0.0 - všechny rozhranní)
; IP adresa (0.0.0.0 - všechny rozhranní)
[192.168.10.2]
host = 192.168.10.2
line => aaln/1
line => aaln/2
line => aaln/3
line => aaln/4
dtmfmode=rfc2833
context = mgcp_kon
directmedia = yes
; IP brány
; jednotlivé linky brány
; DTMF mód
; kontext
; může provést re-invite (stejné jako sip)
; ... a řada dalších parametrů
140
11 Asterisk
A obdobně pro iax.conf opět včetně příkladu nastavení trunku.
[general]
bindport=4569
;sekce general určuje společná nastaveni pro všechny účty
;port na kterém naslouchá SIP
calltokenoptional=0.0.0.0/0.0.0.0
maxcallnumbers=512
;ošetření pro klienty nepodporující novou
;metodu zabezpečení „call token validation”
qualify=yes
; monitoruje dostupnost klapky
bandwidth=high
allow=alaw
; povolení kodeků s vyšší rychlostí (G.711), medium – střední, lowdisallow=all
;zakazuje všechny kodeky
;povolíme jen vybrané
language=cz
;výchozí jazyk,např. pro chybové hlášky
;způsoby registrace asterisku jako klienta register => user:heslo@host ; IAX2TRN:[email protected]
; „deklarace” účtů
[120]
username=120
secret=asdf
auth=md5
type=friend
host=dynamic
context=kontext1
[IAX2_TRN]
username=IAX2_TRN
secret=trnk
auth=md5
type=friend
host=147.229.151.125
context=kontext1
trunk=yes
;trunk mod asterisku, je zapotřebí hw časovač (např. digium hw)
Pro zajištění přenosu videa je nutné toto nastavení povolit přidáním příkazu videosupport do
obecného nastavení ([general]) v souboru sip.conf a také povolit podporu kodeků sloužících pro
přenos videa, jako H.261, H.263, H.263+ nebo H.264 nebo jen některé z nich.
[general]
videosupport=yes
allow=h261
allow=h263
allow=h263p
allow=h264
141
11 Asterisk
7.6
Dialplan extensions.conf
Dialplan určuje, jak se zachází s relacemi, které vznikají v Asterisku anebo přicházejí do
Asterisku zvenčí, je srdcem Asterisku a rozhoduje se v něm, jaké činnosti budou vykonány při
odchozím či příchozím volání. Dialplan se vytváří se pomocí skriptovacího jazyka, kterým definujeme
instrukce, které Asterisk provádí při splnění podmínek pro danou sadu instrukcí. Na rozdíl od
tradičních telefonních systémů je dialplan plně přizpůsobitelný. Jeho syntaxe je specifikována
v konfiguračním souboru extensions.conf. Dialplan se dělí do 4 základních koncepcí: na kontexty,
pobočky, priority a aplikace.
7.6.1
Kontexty
Dialplan je rozdělen na sekce zvané kontexty (context). Kontexty oddělují různé části dialplanu
od vzájemné interakce. Pobočka definovaná v jednom kontextu je naprosto izolovaná od pobočky
z jiného kontextu, pokud tak není výslovně povoleno. Všechny instrukce zapsané pod názvem
kontextu jsou jeho součástí, dokud není definován nový kontext. Za začátku dialplanu existují dva
speciální kontexty s názvy [general] a [globals]. První sekce obsahuje seznam obecných nastavení
dialplanu a druhý obsahuje globální proměnné. Kromě těchto dvou kontextů je třeba vyvarovat se
používání kontextu [default]. Pokud v sip.conf definujeme pobočku, určujeme také, k jakému kontextu
se váže.
Obr. 7.3 Funkce kontextu ze sip.conf v dialplan
7.6.2
Pobočky
Ve světě telekomunikací pojem pobočka obvykle značí číselný identifikátor, který, pokud je volán,
rozezvoní telefon (hlasovou schránku, frontu). V Asterisku pobočka pod určitým názvem definuje
jedinečnou posloupnost kroků, přes které Asterisk hovor povede. Uvnitř každého kontextu můžeme
definovat neomezený počet poboček. Syntaxe pro telefonní pobočku je tvořena slovem exten => ,
následuje název (nebo číslo) pobočky (nebo kombinace).
Dále následuje priorita a aplikace (příkaz), který se má v daném kroku provést
exten => název, priorita, aplikace()
142
11 Asterisk
7.6.3
Priority
Každá pobočka má několik kroků nazývané priority. Priority jsou číslovány postupně od čísla 1 a
každý krok spustí specifickou aplikaci. Příkladem může být pobočka, která vyzvedne hovor a vzápětí
jej zavěsí. Mezi těmito kroky bývá samozřejmě obvykle sekvence dalších kroků [md1].
exten => 123,1,Answer()
exten => 123,2,Hangup()
Číslování nemusí být striktní ve všech krocích, pro automatické doplnění čísla s prioritou o 1
vyšší je možné uvést v dalším kroku prioritu n. První priorita však musí začínat číslem 1.
exten
exten
exten
exten
exten
=>
=>
=>
=>
=>
123,1,Answer()
123,n,něco udělej
123,n,ještě něco udělej
123,n,udělej poslední funkci
123,n,Hangup()
Z důvodu zjednodušení syntaxe došlo k zavedení nové proměnné same => Ta doplní slovo
exten => a název pobočky za klíčové slovo same => . Zlepšuje čitelnost a přenositelnost kódu
z jedné pobočky na druhou.
same => n,něco udělej
same => n,ještě něco udělej
same => n,udělej poslední funkci
same => n,Hangup()
Návěští priorit
Umožňují přiřadit název prioritě uvnitř pobočky. Zaručuje to, že můžeme konkrétně odkazovat na
priority něčím jiným než jejím číslem, které obvykle nemusí být ani známé. Jako syntaxe se používá
exten => 123,n(návěští),aplikace()
7.6.4
Aplikace
Každá aplikace provádí specifickou akci s daným kanálem jako přehrání zvuku, čtení DTMF
volby, prohledávání databáze, volání kanálu, zavěšení hovoru atd. Příklady aplikací jsou:
Answer()
Answer() aplikace je používána k vyzvednutí kanálu, který zvoní. Nemá žádné argumenty.
143
11 Asterisk
Progress()
Progress() poskytuje informaci o probíhajícím hovoru původnímu kanálu. Někteří poskytovatelé
mají signalizační problémy, pokud tato aplikace není použita.
Playback()
Slouží k přehrání předem uložené nahrávky. Typickým způsobem využití je hlasový automat.
Jako parametr vyžaduje cestu k přehrávanému souboru. Buďto absolutní nebo relativní.
Playback(/home/john/sounds/filename)
Playback(custom/filename)
Asterisk vybírá nejlepší soubory k přehrání na základě hodnoty překladu – tzn., vybere soubor ve
formátu, který je nejméně náročný na CPU při převodu na nativní audio formát. Pokud chceme zjistit,
jak dlouho zabere převod mezi formáty, můžeme to zjistit příkazem v CLI show translation
Hangup()
Slouží k zavěšení hovoru a nevyžaduje žádný parametr, popř. můžeme použít ISDN cause code
Hangup(16)
Background()
Slouží k přehrávání hovorů a zároveň reaguje na DTMF volbu uživatele
7.6.5
Tvorba dialplanu
Nyní si vytvoříme ukázkový diaplpan, definujeme vlastní kontext [vlastni] a do něj vložíme
pobočku 200. Pokud tuto pobočku vytočíme z klienta, přehraje se nám uložený audio soubor helloworld a po přehrání dojde k zavěšení hovoru. Na konec souboru /etc/asterisk/extensions.conf tento
kontext s obsahem doplníme
[vlastni]
same => n,Playback(hello-world)
same => n,Hangup()
Kontext s názvem [vlastni] již máme svázaný s uživateli Alice a Bob v konfiguračním souboru
/etc/asterisk/sip.conf, takže nyní stačí pouze načíst novou konfiguraci do Asterisku. Po uložení
konfigurace ji načteme do Asterisku reloadem celé konfigurace.
# /usr/sbin/asterisk -rx "dialplan reload"
;nebo z konzole pomocí CLI asterisku
CLI> dialplan reload
144
11 Asterisk
Následuje otestování funkce, jednoduše zavoláme pobočku 200 a ze sluchátka uslyšíme „Hello
World“. Nyní povolíme uživatelům Alice a Bob komunikovat mezi sebou. Do kontextu [vlastni]
vložíme následující pobočky
exten => alice,1,Dial(SIP/alice)
exten => bob,1,Dial(SIP/bob)
Po reloadu Asterisku může Alice volat Bobovi a Bob Alici vytočením jejich jména v softwarových
telefonech a pokud použijeme v dialplan níže uvedené, tak se dovoláme vytočením 300 a 500.
exten => 300,1,Dial(SIP/alice)
exten => 400,1,Dial(SIP/bob)
7.6.6
Vzory – Pattern Matching
V extensions.conf nám vzory pomáhají definovat kombinace několika čísel do jednoho zápisu.
Pokud bychom pracovali se stávajícími znalostmi řešili bychom následující problém následovně.
Pokud někdo zavolá na číslo 100-109 přehraje se mu zpráva hello-world:
[general]
[test]
exten => 100,2,Playback(hello-world)
A tak bychom pokračovali dále až po 109. Pokud použijeme vzor, bude zápis vypadat přehledněji
a lépe:
[general]
[test]
exten => _10X,1,Answer()
exten => _10X,2,Playback(hello-world)
exten => _10X,3,Hangup()
Extension _10X definuje rozsah čísel od 100 do 109. Vzory vždy začínají podtržítkem.
[abc] – znaky a,b,c. Na příklad mohou být nahrazeny čísly 1,2,3. Ve výsledku 31,32,33:
145
11 Asterisk
exten => _3[123],1,NoOp(Test)
[a-b] – jakékoliv znak mezi a-b. Na příklad mohou být nahrazeny čísly 1-5. Ve výsledku 31-35.
Může být také ve tvaru [25-8] pro 32,35-38:
exten => _3[1-5],1,NoOp(Test)
[X] – jakákoliv číslice od 0-9. Například pro jakékoliv číslo od 300 do 399:
exten => _3XX,1,NoOp(Test)
[Z] – jakákoliv číslice od 1-9. Například pro jakékoliv číslo od 31 do 39:
exten => _3Z,1,NoOp(Test)
[N] – jakákoliv číslice od 2-9. Například pro jakékoliv číslo od 32 do 39:
exten => _3N,1,NoOp(Test)
* – stisk tlačítka s hvězdičkou:
exten => _*7,1,NoOp(Test)
# – stisk tlačítka s křížkem:
exten => _#7,1,NoOp(Test)
. – jakékoliv číslo či číslice. Na příklad pro všechna čísla, která začínají 420:
exten => _420.,1,NoOp(Test)
Nepoužívejte vzor _. ! Pokud tento vzor použijete extension vloží speciální pravidlo i,t a h , které
by mohlo vyvolat neočekávané chování. Pro označení celého rozsahu používejte raději _X. Nebo _X.
7.6.7
Offset při práci s řetězcem
Při vytváření číslovacího plánu je výhodné využívat některé předdefinované proměnné Asterisku.
Mezi nejčastěji používané patří CALLERID, CONTEXT, EXTEN. Význam proměnných je patrný
z jejich názvu [sil3]. CALLERID obsahuje řetězec Identifikace volajícího, CONTEXT obsahuje název
kontextu, ze které proměnnou čteme, EXTEN obsahuje volanou klapku. Obsah těchto proměnných, tj.
řetězec znaků, můžeme číst pomocí zápisu:
${název_proměnné:offset:délka}
146
11 Asterisk
Offset nám určuje počátek čtení řetězce, v případě že je negativní počítá se od konce řetězce.
Délka nám určuje délku předaného řetězce. V případě že délka v zápise chybí nebo je negativní, pak
se vrátí část řetězce začínající na hodnotě offsetu až po poslední znak řetězce. Například je-li
v proměnné EXTEN uložen řetězec 123456789:
${EXTEN:1}
${EXTEN:-4}
${EXTEN:0:3}
${EXTEN:2:3}
${EXTEN:-4:3}
7.6.8
- vrátí řetězec 23456789
Vložené kontexty – Include Statements
Vložené kontexty (dále jen includes) jsou velice silným nástrojem pro zjednodušení a organizaci
velkých dialplánů. Vložrním příkazu include , můžeme vkládat kontexty do stávajících kontextů.
Uveďme příklad:
include => název vloženého kontextu
A v dialplánu:
[general]
[prodej]
include => interni
include => externi
[interni]
exten => 2000,1,Dial(SIP/2000)
[externi]
exten => 17005551212,1,Dial(SIP/5551212)
Máme kontext prodej a v něm vložené další kontexty interni a externi.
7.6.9
Časové Vložené kontexty
Pomocí časových vložených kontextů (Time-Conditional Included Statements) můžeme definovat
například dobu, po kterou bude číslo dostupné, a kdy bude například volající odkázán do hlasové
schránky. Příkaz má nasledující syntaxi:
include => kontext|<čas>|<den>|<den v měsíci>|<měsíc>
Názvy dnů a měsíců reprezentují vždy třípismenné zkratky anglických názvů a čas je zadáván ve
24 hodinovém tvaru. Pokud bychom chtěli mít například pracovní číslo dostupné od pondělí do pátku
od 9:00 hodin do 18:00 a v sobotu od 9:00 do 13:00, zápis v dialplánu by vypadal následovně:
147
11 Asterisk
;Den
include => otevreno|09:00-18:00|mon-fri|*|*
include => otevreno|09:00-13:00|sat|*|*
include => zavreno
[otevreno]
[zavreno]
exten => 2000,1,VoiceMail(2000,u)
7.6.10 Proměnná ${EXTEN} a funkce ${CALLERID(num)}
Dříve než bude popsáno dialplánové programování a funkce, je dobré zmínit ještě dva základní a
velice používané prvky: systémovou proměnnou ${EXTEN} a funkci ${CALLERID(num)}.
${EXTEN} – Asterisk automaticky za tuto proměnnou vkládá vytáčené číslo. Narozdíl od:
Použijeme:
exten => 2000,1,Dial(SIP/${EXTEN})
Výsledek je stejný.
${CALLERID(num)} – Tato funkce vrací číslo volajícího. Využívá se převážně ve spojení
s aplikací VoiceMailMain (), kde se přidává jako parametr. Po zavolaní na číslo 99 se volající
dostane do své hlasové schránky:
exten => 99,1,VoiceMailMain(${CALLERID(num)})
V Asterisku mohou být funkce a programy implementovány buď externě pomoci Asterisk
Gateway Interface (AGI) skriptu nebo Asterisk Extension Language (AEL).
7.7
Voicemail
Hlasová schánka (dále jen voicemail) je jednou ze základních služeb, která je Asteriskem
poskytována [vore]. Asterisk již v základní instalaci obsahuje funkční voicemail module. Potřebujeme
ho jen nakonfigurovat skrze soubor etc/asterisk/voicemail.conf. Nejprve opět přeneseme ukázkový
soubor do našeho záložního adresáře:
debian: /etc/asterisk# mv voicemail. conf /var/tmp/asterisk-etc-backup/
Nyní vytvoříme nový soubor etc/asterisk/voicemail.conf a vložíme do něj následující:
148
11 Asterisk
[general]
format = wav
[default]
2000 => 1234,Filip Rezac,[email protected]
2001 => 5678,Miroslav Voznak,[email protected]
Nyní jsou schránky nakonfigurovány. Každý záznam začíná číslem hlasové schránky (2000,
2001), dále pak pokračuje heslem účtu (1234, 5678), poté jmény uživatelů voicemailu (Filip,
Miroslav) a končí jejich e-mailovou adresou ([email protected], [email protected]).
Posledním krokem je přidat několik řádek i do extensions.conf , tak, aby byly voicemaily plně funkční:
[default]
exten => 2000,1,Dial(SIP/2000,20)
exten => 2001,1,Dial(SIP/2001,20)
exten => 2999,1,VoiceMailMain(${CALLERID(num)},s)
V následujícím zápise se v aplikaci Dial () objevuje hodnota 20. Jedná se o dobu vyzvánění v
sekundách, než je uživatel volající přesměrován do hlasové schránky. V aplikaci Voicemail () je dále
uvedena proměnná u, která určuje, jaká hláška se má volajícímu přehrát při vstupu do voicemailu.
Proměnná u reprezentuje hlášku „unavaible“ (nedostupný). Dále ze může být použita proměnná b
„busy“ (obsazeno) a proměnná s, po které se pouze ozve tón ohlašující začátek nahrávání.
Poslední řádek v extensions.conf slouží k přístupu do voicemailu. Pokud si Filip nebo Miroslav
nepřečtou zprávu ve své e-mailové schránce, mohou si jí posledchnout pokud zavolají na číslo 2999.
Funkce ${CALLERID(num)} doplní automaticky číslo volajícícho,ten je přesměrován do své hlasové
schránky. Proměnná s zakazuje použitá hesla pro voicemail.
Nyní máme nakonfigurován základní voicemail a přístup k němu. Rozšířená řešení voicemailu,
jako například podpora hesel, či využití STT (Speech-to-text) modulu není součástí tohoto materiálu.
7.8
IVR – Interactive Voice Response
Hlasové menu (dále jen IVR) je další velice používaná služba v Asterisku. IVR (Interactive Voice
Response) umožňuje hlasovou interakci Vašeho systému s volajícími, kteří se systémem komunikují
pomocí tlačítek a tzv. DTMF volby, nebo klasicky hlasovou interakcí. Mnoho IVR poskytuje výběrové
menu pro směrování hovorů bez potřeby zásahu operátora, moderní IVR však dokážou plnit funkce
kompletních systémů a řídících součástí.
149
11 Asterisk
7.8.1
Jednoduché IVR
Asterisk obsahuje několik nahraných hlasových zpráv. Soubor s názvem marryme.gsm obsahuje
hlášku: „Will you marry me? Press 1 for yes or 2 for no.“ (Vezmeš si mě? Stiskni 1 pro ano, nebo 2
pro ne). Pokud bychom chtěli následující zprávu využít jako IVR vypadalo by to následovně:
exten => 30,2,Background(marryme)
exten => 1,1,Playback(thank-you-cooperation)
exten => 2,1,Playback(sorry)
Pokud volající zavolá na 30, Asterisk přehraje zprávu marryme.gsm. Pro IVR se používá aplikace
Backround () , kde systém čeká na odpověď od volajícího. Pokud zvolí volající číslo 1 je mu přehrána
hláška „Thank you for your cooperation“ (Děkujeme za spolupráci), pokud stiskne 2,Asterisk přehraje
hlášku „Sorry“ (Promiňte) a zavěsí.
7.8.2
Neplatný vstup (extension i)
Neplatný údaj (každý vstup, pro který není v dialplánu záznam) může být spravován pomocí
extension i. V následujícím příkladu, IVR přehraje omluvu volajícímu a zavěsí. (Skutečný IVR by měl
přesměrovat volajícího zpět do hlavního menu v případě neplatného vstupu.)
; Pokud je vloženo jiné než platné číslo
exten => i,1,Background(sorry)
exten => i,2,Hangup()
7.8.3
Pauzy
Nejjednodušší způsob, jak vytvořit pauzy je přehrání prázdných zvukových souborů. Série
tichých zvukových souborů s délkou mezi 1 a 9 sekundami lze nalézt v /var/lib/asterisk/sounds/silenc
eV následujícím příkladu je použita pauza 5 sekund:
150
11 Asterisk
exten => 30,3,Background(silence/5)
exten => i,1,Background(marryme)
exten => i,2,Hangup()
7.8.4
Víceúrovňové IVR
Problém víceúrovňových IVR systémů spočívá v tom, že volající může zadat vstupní jednoduché
číslice několikrát za sebou, ale dostane vždy jinou odpověď v závislosti na úrovni menu. V Asterisku
mohou být čísla v daném kontextu použita pouze jednou, proto pokud chceme využívat víceúrovňové
menu, je nutné vytvořit nový kontext pro další úroveň. V následujícím příkladu přeskakujeme mezi
kontexty pomocí aplikace Goto (). Využijeme následujících fiktivních zvukových souborů, které byly
pro příklad nahrány:
•
•
•
•
hlavni-menu.gsm – „Stiskněte 1 pro prodej, 2 pro služby, 3 pro přístup do restaurace.“
restaurace.gsm - „Stiskněte 1 pro přehrání nabídky pro tento týden nebo 2 pro přehrání
nabídky na příští týden.“
restaurace-nabidka-tento-tyden.gsm – „Pondělí: Nudle se sýrovou omáčkou.Úterý:
Kuře na paprice.......“
restaurace-nabidka-pristi-tyden.gsm – „Pondělí: Domácí bramborák.Úterý: Smažený
sýr s hranolkama.......“
Pokud bude IVR na čísle 30, prodej na čísle 100 , služby na čísle 150 a restaurace na čísle 200
bude IVR systém vypadat následovně:
[ivr]
; Menu je přehráváno stále dokola, dokud volající nevloží vstup.
;
exten => 30,2,Background(hlavni-menu)
exten => 30,4,Goto(2)
; Goto() skočí do dalšího kontextu ([restaurace])
151
11 Asterisk
;
exten => 3,1,Goto(restaurace,200,1)
exten => i,1,Goto(30,2)
[restaurace]
exten => 200,1,Background(restaurace)
exten => 1,1,Playback(restaurace-nabidka-tento-tyden)
exten => 1,2,Wait(2)
exten => 2,1,Playback(restaurace-nabidka-pristi-tyden)
exten => 2,2,Wait(2)
; Špatné zadání pošle volajícího zpět do hlavního menu
exten => i,1,Goto(ivr,30,2)¨
Teoreticky je možné vytvářet nekonečný počet úrovní menu, ale z praktické zkušenosti volající
většinou hovor ukončí po třetím menu.
7.9
DAHDI/ZAPTEL
Jedná se o konfigurační soubor ovladače hardwarových karet Digium a kompatibilních. Ve
verzích Asterisku 1.2 a 1.4 (do verze 1.4.21) byl tento ovladač označován jako ZAPTEL. Od verze
1.4.21 a u všech verzí 1.6, 1.8 a 10 je označen názvem DAHDI (verze jsou číslovány od 2.0.0).
Tento konfigurační soubor slouží ke konfiguraci analogových, E1, ISDN-BRI karet a dalších na úrovni
ovladače [sil3]. Naleznete jej v adresáři /etc/dahdi/system.conf, respektive /etc/zaptel.conf.
V tomto souboru se zejména konfiguruje přidružení signalizací jednotlivým kanálům, povolení
použití potlačení ozvěny a u E1 karet se definují SPANy a rozdělení kanálů signalizačních a
hovorových (B-kanály). Jako znak začátku komentáře se používá #.
U analogových karet, se kterými se můžete ve Vašich počítačích setkat, rozeznáváme dva typy
portů. FXS (Foreign eXchange Subscriber) pro připojení analogového přístroje a port FXO ( Foreign
eXchange Office) pro připojení k nadřazené ústředně. Z pohledu konfiguračních souborů Asterisku je
jejich označení přesně opačné, neboť se zde udává signalizace, nikoliv typ portu. Typ portu je dán
osazeným hardwarovým modulem.
span=1,1,0,ccs,hdb3,crc4
mtp2=1
bchan=2-31
echocanceller=mg2,2-31
# span, zdroj hodiny, délka vedení, typ rámce, kód (,crc4)...
# ..(zdroj hodin 0-vždy master, 1-slave (bez hodin - master), 2, 3
# konfigurace SS7 přenašeče
span=2,0,0,cas,hdb3
152
11 Asterisk
cas=32-46:1101
hardhdlc=47
# konfigurace CAS - R2 přenašeče
cas=48-62:1101
echocanceller=mg2,32-46,48-62
span=3,0,0,ccs,hdb3,crc4
bchan=63-77,79-93
# konfigurace ISDN PRI přenašeče
hardhdlc=78
echocanceller=mg2,63-77,79-93
fxoks=125
echocanceller=mg2,125
# konfigurace analogového FXS portu (pro připojení telefonu)
fxsks=126
echocanceller=mg2,126
# konfigurace analogového FXO portu (pro připojení k ústředně)
# pro FXS port signalizace fxoks, pro FXO fxsks, tedy opačně
loadzone=cz
defaultzone=cz
# určuje konfiguraci HW korespondující s danou
# zemí, ovlivňuje i další věci ... velmi důležité
7.9.1
Chan_dahdi.conf (Zapata.conf)
Konfigurační soubor Asterisku pro konfiguraci kanálu Asterisku DAHDI, tedy karet Digium a jim
kompatibilních. Konfigurace a přidružení kanálů již závisí na definici system.conf. Syntaxe tohoto
souboru je následující. Nejprve jsou nastaveny jednotlivé parametry (ze zvyklosti se používá znak = ).
Poté zápisem channel => číslo kanálu se provede zápis těchto parametrů pro daný kanál či kanály.
Následně můžeme parametry změnit dalšími přiřazeními a povést nový zápis pro jiné kanály.
[trunkgroups]
[channels]
group=1
; svazek v extensions.conf se pak lze odkazovat na všechny okruhy svazku
; E1 - dahdi/g1 např.: exten => _8XX,1,Dial(dahdi/g1/${EXTEN},20)
language=cz
context = kontext1
; kontext
signalling = ss7
; signalizace
ss7type = itu
linkset= 1
pointcode= 2
adjpointcode = 1
defaultdpc = 1
adjpointcodenetworkindicator = national
cicbeginswith= 2
channel => 2-31
sigchan = 1
...
...
group=5
; přidružení okruhů svazku 1
; svazek ... např.: exten => _731,1,Dial(dahdi/g5,20)
153
11 Asterisk
language=cz
context=kontext1
; kontext
signalling=fxo_ks
; signalizace FXS
callerid="731" <731>
usecallerid=yes
echocancel=yes
channel => 125
; přidružení okruhu 125 svazku 5
; lze volat i přímo okruh: exten => _731,1,Dial(dahdi/125,20)
group=6 ; svazek
language=cz
context=kontext1
; kontext
signalling=fxs_ks
; signalizace FXO
echocancel=yes
channel => 126
7.10
; přidružení okruhu 126 svazku 6
Peering mezi dvěma Asterisky
Peering slouží k logickému propojení dvou ústředen stejného typu. V případě, že volám na číslo,
které se nenachází v mé databázi (není registrované na moji ústřednu a není definováno v sip.conf
nebo iax.conf), ale vím, že se nachází na ústředně sousední, mohu využít této funkce a vyvolat
patřičný extension z této ústředny sousední. Jako první ústřednu použijeme tu, kterou jsme si
vytvořili v prvních bodech, včetně nastavení SIP protokolu. U druhé budeme postupovat podobně,
akorát zvolíme jiná čísla účtů. Tedy nastavení sip.conf druhé ústředny:
[general]
context=Asterisk2
port=5060
udpbindaddr=0.0.0.0
srvlookup=yes
disallow=all
allow=alaw
allow=gsm
allow=ulaw
allow=h261
allow=h263
allow=h263p
allow=h264
[201]
type=friend
context=Asterisk2
language=cz
host=dynamic
username=201
154
11 Asterisk
secret=201
callerid=201 <201>
[202]
type=friend
context=Asterisk2
language=cz
host=dynamic
username=202
secret=202
callerid=202 <202>
Podobným způsobem, jako u první ústředny, také potřebujeme vytvořit (resp. upravit) soubor
extensions.conf, abychom zajistili základní spojení v rámci ústředny:
[general]
static=yes
writeprotect=no
[macro-hovor]
exten => s,1,Dial(${ARG1})
exten => s,2,Congestion
exten => s,3,Hangup
[Asterisk2]
exten => _201,1,Macro(hovor,SIP/201)
Ke spojení ústředen bude využit protokol IAX. Nyní je potřeba na každé z ústředen vytvořit účet
ústředny sousední. Parametry tohoto účtu se definují opět v souboru iax.conf. Pro lepší představu je
použitá topologie, včetně o adresování ústředen uvedena na obr. 7.4.
Obr. 7.4 Logická topologie zapojení
Do konfigurace souboru iax.conf první ústředny (Asterisk1) je tedy potřeba vytvořit účet pro
protější ústřednu (Asterisk2):
155
11 Asterisk
[Asterisk2]
;Definice účtu druhé ústředny (Asterisk2)
type=friend
username=Asterisk1
secret=peer
auth=plaintext ;Použité šifrování při autentizaci (také ;podpora MD5)
host=10.0.0.2 ;Přidělení pevné adresy, která bude účet ;využívat – předpokládá se, že PBX svoji ;IP
adresu nemění (nebo alespoň ne často)
context=IAXpeer
peercontext=IAXpeer
qualify=yes
trunk=yes
;Nastavení, že se nejedná o běžný účet, ;nýbrž o peer (trunk) na jinou ústřednu
Podobnou konfiguraci je také potřeba provést i u ústředny druhé (Asterisk2):
[Asterisk1]
type=friend
username=Asterisk2
secret=peer
auth=plaintext
host=10.0.0.1
context=IAXpeer
peercontext=IAXpeer
qualify=yes
trunk=yes
Nyní je ovšem také potřeba upravit číslovací plány na jednotlivých ústřednách, aby v případě
„neznámého“ čísla došlo k přeposlání žádosti k výstavbě spojení na ústřednu druhou. Tedy v případě
Asterisk1:
[general]
static=yes
writeprotect=no
[macro-hovor]
exten => s,3,Hangup
[Asterisk1]
exten => _201,1,Macro(hovor,IAX2/Asterisk2/${EXTEN}) ;Rozšíření ;našeho defaultního ;contextu,
v případě, ;že volám na čísla ;registrované na druhé ;ústředně, kde ;prostřednictvím našho ;IAX účtu
vyvolám ;patřičný EXTEN na ;ústředně Asterisk2
exten => _202,1,Macro(hovor,IAX2/Asterisk2/${EXTEN})
[IAXpeer]
;Vytvoření contextu pro příchozí volání ;z druhé ústředny
156
11 Asterisk
Samozřejmě podobnou úpravu je nutné také provést na straně ústředny Asterisk2:
[general]
static=yes
writeprotect=no
[macro-hovor]
exten => s,3,Hangup
[Asterisk2]
[IAXpeer]
7.11 Použití SRTP a SIPS/TLS
Od verze 1.8 je obsaženo v základní distribuci a SRTP je možné využívat, v dřívějších verzích je
nutné doinstalovat zvlášť.
7.11.1 Zabezpečení médií pomocí SRTP
V /etc/asterisk/sip.conf dodáme do konfigurace příslušných účtů povolení srtpcapable=yes anebo
můžeme dát přímo do sekce [general] a nastavení bude platit pro všechny.
[201]
type=friend
context=Asterisk2
language=cz
srtpcapable=yes
host=dynamic
*** atd ***
Dále upravíme dialplan v /etc/asterisk/extensions.conf tak, že nastavíme použití SRTP jak pro
příchozí, tak pro odchozí volání.
157
11 Asterisk
exten => 201,1,NoOp()
exten => 201,n,Set(_SIPSRTP=${SIPPEER(${EXTEN},srtpcapable)})
exten => 201,n,Set(_SIPSRTP_CRYPTO=enable)
exten => 201,n,Set(_SIP_SRTP_SDES=enable)
exten => 201,n,Answer()
*** atd ***
exten => _1XX,1,NoOp()
exten => _1XX,n,Set(_SIPSRTP=${SIPPEER(${EXTEN},srtpcapable)})
exten => _1XX,n,Set(_SIPSRTP_CRYPTO=enable)
exten => _1XX,n,Set(_SIP_SRTP_SDES=enable)
exten => _1XX,n,Dial(SIP/${EXTEN})
*** atd ***
7.11.2 Zabezpečení signalizace v Asterisku pomocí SIPS
K zabezpečení SIP protokolu využijeme open source SSL/TLS knihovny – openssl. V první řadě
je tedy potřeba ji nainstalovat, kde opět využijeme samoinstalačních balíčků:
root@Asterisk1:/# apt-get install openssl
Samotný postup lze rozdělit do několika kroků. V první řadě je potřeba si pomocí aplikace
openssl vygenerovat vlastní certifikační autoritu (CA). Začneme tedy vygenerováním 4096 bitového
klíče a vytvořením této CA. Tuto naši CA bude ve velkém množství případů potřeba nainstalovat na
naší pracovní stanici nebo telefonu.
root@Asterisk1:/etc/cert# openssl genrsa -des3 -out ca.key 4096
root@Asterisk1:/etc/cert# openssl req -new -x509 -days 365 -key ca.key -out ca.crt
Po vygenerování vlastní CA je potřeba vytvořit certifikát serveru a podepsat jej naší CA. Opět
začneme vygenerováním klíče, tentokrát však pouze 1024 bitového, pokračujeme vygenerováním
certifikátu a v poslední řadě jeho podpisem. Při generování certifikátu serveru je nutné zadat do
položky Common Name doménové jméno vašeho SIP serveru (Asterisku), popř. jeho IP adresu.
root@Asterisk1:/etc/cert# openssl genrsa -out key.pem 1024
root@Asterisk1:/etc/cert# openssl req -new -key key.pem -out asterisk.csr
root@Asterisk1:/etc/cert# openssl x509 -req -days 365 -in asterisk.csr -CA ca.crt -CAkey ca.key set_serial 01 -out asterisk.crt
Asterisk potřebuje ke správné funkcionalitě SIP zabezpečení mít, jak klíč (key.pem), tak samotný
certifikát serveru (asterisk.crt) v jednom souboru. Proto v kořenovém umístění aplikace Asterisk
vytvoříme adresář s názvem např. cert a v něm do souboru, který pojmenujeme, jako asterisk.pem
zkopírujeme náš klíč a certifikát serveru.
root@Asterisk1:/etc/asterisk# mkdir cert
root@Asterisk1:/etc/cert# cat key.pem > /etc/asterisk/cert/asterisk.pem
root@Asterisk1:/etc/cert# cat asterisk.crt >> /etc/asterisk/cert/asterisk.pem
158
11 Asterisk
Nyní na ústředně v konfiguračním souboru SIP protokolu (sip.conf) potřebujeme povolit TLS
šifrování a nastavit cestu k našemu souboru s klíčem a certifikátem serveru (asterisk.pem) a u
vytvořených účtů povolíme pouze šifrovaný přenos:
[global]
tlsenable=yes
tlsbindaddr=0.0.0.0
tlscertfile=/etc/asterisk/cert/asterisk.pem
[101]
transport=tls
[102]
transport=tls
7.12
Asterisk a kalendáře
Jednou z pokročilých služeb, které můžeme s Asteriskem využít, jsou propojení komunikačního
systému s kalendářem, čili chování Asterisku bude ovlivňovat stav uživatele v kalendáři [mik].
Výhody využívaní kalendářů je několik, od rychlého vyhledávání v obsahu, sdílení na webu až po
synchronizaci s jinými kalendáři a aplikacemi jak v PC, tak v mobilních zařízeních. Nejpoužívanějšími
protokoly pro kalendáře jsou CalDAV a Exchange Web Service. Právě tyto protokoly jsou rovněž
podporovány Asteriskem v jeho kalendářovém modulu. Spárování Asterisku s kalendářem nám
umožní následující funkce:
•
•
•
Asterisk si v nastaveném časovém intervalu kontroluje dostupnost uživatele v
událostech kalendáře. V těchto událostech je možné nastavit stav dostupný anebo
nedostupný. Na základě této informace Asterisk dokáže směrovat hovor, např. do
hlasové schránky, na mobil, na zástupce, atd. a směrování volání tak bude
efektivnější.
Asterisk je schopný do kalendáře i zapisovat, typickým příkladem využití je záznam o
realizovaných hovorech, takže uživatel může mít v kalendáři přehled svých volání
(volající a volaný, příchozí č odchozí hovoru, délku hovoru a kdy se uskutečnil, rovněž
i zmeškaná volání).
Pokud do Asterisku naimplementujeme i aplikaci pro převod textu na řeč (TTS – Text
To Speech) a existuje řada placených i otevřených řešení, tak se nám otevřou
možnosti přehrávání textu zapsaného v kalendáři ve formě audia, tím pádem
vytočením určité pobočky se nám přehrají události v kalendáři. Asterisk umožňuje
automatické zavolání v definovaný čas např. před začátkem schůzky poznačené
v kalendáři a přehraje text zapsaný k dané události. TTS open-source řešením je např.
Festival, ve spojení s VoiceGlue a VoiceXML lze vytvářet v Asterisku IVR stromy, ve
kterých bude přehráván kupříkladu text z webových stránek, obdoba RSS čtečky
s hlasovým výstupem
159
11 Asterisk
Abychom funkce kalendáře mohli využívat , musíme si doinstalovat kalendářový server.
Nainstalujme si tedy kalendářový server Davical. Samozřejmě existují i jiné řešení pro správu
kalendářů, ale vybereme si open-source Davical , u kterého oceníme i user-friendly uživatelské
rozhraní a navíc je již v repozitářích většiny linuxových distribucí.
7.12.1 Instalace Davical serveru
Přidáme tedy zvolený kalendářový server do našeho komunikačního systému pomocí
standardního příkazu k instalaci balíčku z repozitáře.
# apt-get install davical
Protože Davical využívá pro správu dat databázi PostgreSQL je nutné ji stáhnout a
nakonfigurovat.
# apt-get install postgresql postgresql-contrib php5-pgsql libapache2-mod-auth-pgsql
V databázi se nám vytvořil uživatel s názvem postgres, kterému musíme nastavit heslo.
# sudo passwd -d postgres
# sudo passwd postgres
Enter new UNIX password: postgres
Retype new UNIX password: postgres
passwd: password updated successfully
root@server:/# /etc/init.d/postgresql-8.4 restart
Nyní nakonfigurujeme databázi Davical.
# su postgres
# nano /etc/postgresql/8.4/main/pg_hba.conf
Tento textový sobor editujeme podle vzoru.
# TYPE DATABASE USER
CIDR-ADDRESS
# "local" is for Unix domain socket connections only
local davical davical_app
trust
local davical davical_dba
trust
# IPv4 local connections:
host all
all
127.0.0.1/32
md5
# IPv6 local connections:
host all
all
::1/128
md5f
METHOD
Takto editovaný soubor uložíme (CTRL+X a Yes) a restartujeme databázi.
# /etc/init.d/postgresql restart
160
11 Asterisk
Nainstalujeme databázi Davical serveru do PostgreSQL databáze.
# /usr/share/davical/dba/create-database.sh/etc/init.d/postgresql restart
Měla by se zobrazit informace o úspěšně instalaci a výzva k zadání přihlašovacího heslo
Davicalu. Předtím než se přihlásíme potřebujeme ještě nakonfigurovat přístup virtualhostu v Apache2.
Odhlásíme uživatele postgres (Ctrl+D) a do defaultního virtualhostu Apache přidáme následující
záznam.
nano /etc/apache2/sites-enabled/000-defaul
# Virtual Host for DAViCal
<VirtualHost 192.168.209.130 >
DocumentRoot /usr/share/davical/htdocs
DirectoryIndex index.php index.html
ServerName 192.168.209.130
ServerAlias 192.168.209.130
Alias /images/ /usr/share/davical/htdocs/images/
<Directory /usr/share/davical/htdocs/>
AllowOverride None
Order allow,deny
Allow from all
</Directory>
AcceptPathInfo On
php_value include_path /usr/share/awl/inc
php_value magic_quotes_gpc 0
php_value register_globals 0
php_value error_reporting "E_ALL & ~E_NOTICE"
php_value default_charset "utf-8"
</VirtualHost>
# /etc/init.d/apache2 restart
Pokud bychom se přihlásili na Davical server, zjistili bychom,
potřebné vykonat ještě poslední editaci přes příkazový řádek.
že vyžaduje editaci. Proto je
# nano /etc/davical/192.168.209.130-conf.php
<?php
// $c->domain_name = "calendar.example.net";
// $c->sysabbr = 'DAViCal';
// $c->admin_email = '[email protected]';
// $c->system_name = "Example DAViCal Server";
// $c->enable_row_linking = true;
$c->pg_connect[] = 'dbname=davical port=5432 user=davical_app';
?>
Nyní se konečně můžeme přihlásit na náš kalendářový server webovým prohlížečem na adrese
http://192.168.209.130, kde se přihlásíme jako uživatel admin a heslem vygenerovaným během
161
11 Asterisk
instalace. V tomto grafickém prostředí si vytvoříme kalendář, který bude sledovaný Asteriskem
pomocí User functions
Create Principal a použijeme níže uvedené nastavení.
User Name:
New Password:
Confirm:
Full Name:
Email:
Active:
User Roles:
CREATE
asterisk
asterisk
asterisk
asterisk
asterisk@localhost
ano
všechny ano
Tento kalendář bude dostupný na adrese http://192.168.209.130/caldav.php/asterisk/home/
s login a password nastaveným výše.
7.12.2 Propojení Asterisku a Davical serveru
Pro komunikaci Asterisku s kalendářem budeme používat program Sunbird nainstalovaný na PC
a nejprve si jej stáhneme z http://www.mozilla.org/projects/calendar/sunbird/ . Po instalaci aplikaci
spustíme a nastavíme podle návodu níže.
File > New calendar > On the Network
Format: CalDAV
Location: http://192.168.209.130/caldav.php/asterisk/home/
Name: asterisk
Show Alarms: ano
Finish
Zadáme požadované přihlašovací údaje pro přístup ke kalendáři: asterisk / asterisk, pokud by
Sunbird přihlášení nevyžadoval a nespojil se s kalendářem, použijeme URL kalendáře ve tvaru:
Location:
http://asterisk:[email protected]/caldav.php/asterisk/home/
Nyní nastavíme Asterisk, aby mohl číst a zapisovat do vytvořeného kalendáře asterisk na caldav
serveru. Na straně Asterisku editujeme soubor calendar.conf.
# nano /etc/asterisk/calendar.conf
[asterisk]
type = caldav
url = http://192.168.209.130/caldav.php/asterisk/home/
user = asterisk
secret = asterisk
refresh = 1
162
11 Asterisk
Uložíme a provedeme restart Asterisku.
# /etc/init.d/asterisk restart
Správnou funkčnost ověříme v CLI Asterisku příkazem:
# server*CLI> calendar show calendars
Calendar
Type
Status
-------------------- ---------asterisk
caldav busy
Pokud máme v kalendáři v daném čase poznačenou schůzku, objeví se status busy. V této
kapitole jsme si ukázali instalaci a nastavení kalendáře.
7.13 Aplikace kalendářových funkcí
V této kapitole se budeme zabývat možnostmi využití kalendáře Asteriskem.
7.13.1 Směrování volání na základě zaneprázdněnosti
CALENDAR_BUSY() funkce nám vrací aktuálně nastavenou zaneprázdněnost, kterou má
uživatel nastavenou v kalendáři. Tento stav kontroluje dle nastaveného limitu v
/etc/asterisk/calendar.conf. Do kontextu vlastní dopíšeme pobočku dostupnost.
exten => dostupnost,1,GotoIf(${CALENDAR_BUSY(asterisk)}?busy:free)
same => n(busy),Dial(SIP/alice)
same => n,Hangup()
same => n(free),Dial(SIP/bob)
same => n,Hangup()
Pokud tedy zavoláme na pobočku dostupnost a účastník bude dle kalendáře dostupný, půjde
hovor na pobočku alice, pokud dostupný nebude, hovor půjde na pobočku bob.
7.13.2 Zapisování do kalendáře
Asterisk umí také do kalendáře zapisovat, jako příklad vytvoříme jednoduché logování hovorů.
Pokud dojde k vytočení pobočky log, volá se pobočka alice a po skončení hovoru se do kalendáře
zapíše, kdo a jaký časový interval volal. Tento log si můžeme zkontrolovat v kalendářovém klientu
Sunbird po reloadu.
exten => log,1,Set(start=${EPOCH})
same =>n,Dial(SIP/alice)
same =>h,1,Set(end=${EPOCH})
163
11 Asterisk
same =>h,n,Set(CALENDAR_WRITE(asterisk,summary,start,end)=Volal
${CALLERID(all)},${start},${end})
7.13.3 Čtení záznamů uložených v kalendáři
K dalším funkcím, které Asterisk nabízí je funkce CALENDAR_QUERY(), který má jako
parametry název kalendáře a čas ve formátu unix time. Vrací ID a pole události (event), které
použijeme ve funkci CALENDAR_QUERY_RESULT. Tato funkce přijímá parametry
CALENDAR_QUERY_RESULT(id z CALENDAR_QUERY, požadovaná informace, pořadí
události)Mezi požadované informace patří:
•
•
•
•
•
•
•
•
•
•
summary – název události
description – úplný popis události
organizer – osoba, která událost organizuje
location – místo události
calendar – název kalendáře, ve kterém je událost zaznamenána
uid – jedinečný identifikátor události
start – začátek události ve formátu unix time (počet sekund od Unix epoch)
end – konec události ve formátu unix time (počet sekund od Unix epoch)
busystate – 0 volný, 1 možná, 2 nepřítomný
attendees – seznam pozvaných účastníků události oddělených čárkou
Pro přehrání informací je třeba nainstalovat na server Text To Speech aplikaci. Asterisk nativně
podporuje aplikaci Festival, ve které najdeme i částečnou českou lokalizaci. Provedeme tedy
instalaci této aplikace.
# apt-get install festival festival-czech festvox-czech-ph
na konec souboru zkopírujeme následující konfiguraci
# nano /usr/share/festival/festival.scm
;; Enable access to localhost (needed by debian users)
(set! server_access_list '("localhost\\.localdomain" "localhost"))
;;(set! voice_default 'voice_pc_diphone)
(require 'czech)
(require 'czech-unisyn)
(set! inhibit-initial-pauses t)
;; (voice_czech_ph)
(set! voice_default 'voice_czech_ph)
;;; Command for Asterisk begin
(define (tts_textasterisk string mode)
(let ((wholeutt (utt.synth (eval (list 'Utterance 'Text string)))))
(utt.wave.resample wholeutt 8000)
(utt.wave.rescale wholeutt 5)
(utt.send.wave.client wholeutt)))
;;; Command for Asterisk end
164
11 Asterisk
Uložíme a propojíme Asterisk s aplikací Festival
# nano /etc/asterisk/festival.conf
[general]
host=localhost
port=1314
usecache=yes
cachedir=/var/cache/asterisk/festival/
festivalcommand=(tts_textasterisk "%s" 'file)(quit)\n
Pro správné čtení české diakritiky je ještě třeba nastavit české locale pro jazyk. Editujte
následující soubor dle návodu a poté provést reboot serveru.
# nano /etc/default/locale LANG
LANG="cs_CZ.UTF-8"
Po restartu spustíme Festival v režimu server.
# festival --server &
Následuje ukázka využití CALENDAR_QUERY() funkce spojenou s Text To Speech aplikací. Po
zavolání na pobočku schuzky se dozvíme události, které máme naplánovány v kalendáři na příštích
60 minut.
# nano /etc/asterisk/extensions.conf
exten => schuzky,1,Answer
same => n,Set(id=${CALENDAR_QUERY(asterisk,${EPOCH},$[${EPOCH}+24*60*60])})
same => n,Set(num=${CALENDAR_QUERY_RESULT(${id},getnum)})
same => n,Set(i=1)
same => n,Festival("Plán na dalších 60 minut je následující")
same => n,Festival(Celkový počet schůzek je ${num})
same => n,While($[${i} <= ${num}])
same => n,Festival(schůzka číslo ${i} má začátek)
same => n,SayUnixTime(${CALENDAR_QUERY_RESULT(${id},start,${i})},,Q 'digits/at' IMp)
same => n,Festival(a konec je v)
same => n,SayUnixTime(${CALENDAR_QUERY_RESULT(${id},end,${i})},,IMp)
same => n,Festival(místo schůzky je: ${CALENDAR_QUERY_RESULT(${id},location,${i})})
same => n,Festival(Schůzka je zapsána v kalendáři:
${CALENDAR_QUERY_RESULT(${id},calendar,${i})})
same => n,Festival(Obsah schůzky je: ${CALENDAR_QUERY_RESULT(${id},summary,${i})})
same => n,Set(i=$[${i} + 1])
same => n,EndWhile
Nyní vložíme přes Sunbird do následující hodiny schůzku, uložíme ji do vzdáleného kalendáře
Asterisku. Poté zavoláme pobočku schůzky a Asterisk nám přečte, co jsme do obsahu schůzky
uložili.
165
11 Asterisk
7.13.4 Upozornění na schůzku
Podobnou funkcí jako CALENDAR_QUERY je funkce CALENDAR_EVENT(). Tuto funkci
použijeme pro hlasové oznámení blížící se schůzky 10 minut před jejím začátkem. Vytvoříme pro
tento účel kontext calendar_event_notify a umístíme jej do dialplanu v souboru
/etc/asterisk/extensions.conf. Na tento kontext se budeme odkazovat ze souboru
/etc/asterisk/calendar.conf.
# nano /etc/asterisk/extensions.conf
[calendar_event_notify]
exten => s,1,Answer
same => n,Festival(za 10 minut máte schůzku\, která se koná v ${CALENDAR_EVENT(location)}\,
obsahem schůzky je ${CALENDAR_EVENT(description)}\, nashledanou)
same =: n,Hangup
# nano /etc/asterisk/calendars.conf
[asterisk]
type = caldav
url = http://192.168.209.130/caldav.php/asterisk/home/
user = asterisk
secret = asterisk
refresh = 1
timeframe = 60
autoreminder = 10
channel = SIP/alice
context = calendar_event_notify
extension = s
Nyní si posuneme začátek schůzky v kalendáři tak, aby začínal za 12 minut od aktuálního času a
za 2 minuty můžeme očekávat hovor na pobočce Alice o blížící se schůzce včetně popisu lokace a
obsahu schůzky.
7.14 XMPP server a Asterisk
XMPP protklo využívá např. Jabber a používá se především pro služby Presence a Instant
Messaging [mik]. Tento protokol je založen na jazyku XML a umožňuje výměnu textových zpráv
anebo informaci o aktuální činnosti uživatelů, tedy podobně jako aplikace ICQ, MSN, Skype či AIM.
Jednou z aplikací, která nabízí funkce XMPP serveru je Openfire. Jedná se tedy o server
poskytující služby online výměny zpráv obdobně jako Instant Messaging (IM). Vlastní XMPP sever
přináší řadu výhod a pro nás je podstatné, že můžeme propojením Asterisku a XMPP serveru
sledovat status uživatelů a podle toho směrovat na ně volání. Správa těchto uživatelů může být
zajištěna LDAP serverem. Openfire rovněž podporuje tvorbu chatovacích místností a může sloužit
jako brána do ostatních sítí pro online výměnu zpráv jako např. do ICQ. Výhodou vlastního IM
(Instant Messaging) systému ve spolupráci s Asteriskem přináší možnost reagovat na status
166
11 Asterisk
uživatele (např. automatická odpověď v případě nepřítomnosti). Asterisk se přihlásí na tento server
jako klient, může zasílat zprávy, přijímat odpovědi, v reálném čase získávat stavy dalších uživatelů
na serveru a patřičně řídit dle těchto informací pravidla směrování.
7.14.1 Instalace Openfire
Než si ukážeme spolupráci Asterisku a XMPP serveru, musíme si jej nejprve nainstalovat
a nakonfigurovat. Instalaci provedeme z balíčku, který si stáhneme.
# mkdir /usr/src/openfire
# cd /usr/src/openfire/
# sudo wget http://www.igniterealtime.org/downloadServlet?filename=openfire/openfire_3.7.0_all.deb
Openfire vyžaduje java6-jre, ten ale není běžnou součástí systému a proto rozšíříme
prohledávané repozitáře o další zdroj a instalujeme.
# apt-get install python-software properties
# add-apt-repository "deb http://archive.canonical.com/ lucid partner"
# apt-get update
# apt-get install sun-java6-jre
Nyní pokračujeme v instalaci Openfire.
# cd /usr/src/openfire
# dpkg –idownloadServlet\?filename\=openfire%2Fopenfire_3.7.0_all.deb
# /etc/init.d/openfire start
# su postgres
# createuser openfire
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) y
Shall the new role be allowed to create more new roles? (y/n) y
postgres@server:/root$ createdb openfire
postgres@server:/root$ psql openfire
openfire=# ALTER USER openfire with password 'openfire';
openfire=# ALTER DATABASE openfire OWNER TO openfire;
Dále pokračujeme ve webovém rozhraní na http://192.168.209.130:9090/setup/index.jsp
Choose lenguage:
Czech (cs_CZ)
Doména:
192.168.209.130
Port admin konzoly:
9090
Zabezpečený port admin. konzoly:
9091
Nastavení databáze:
Štandardní nastavení
Předvolby DB ovladače:
PostgreSQL
URL databáze:
jdbc:postgresql://localhost:
Užívatelské jméno:
openfire
Heslo:
openfire
Nastavení profilu:
výchozí
Administrátorský účet:
root@localhost
167
5462/openfire
11 Asterisk
Nové heslo
Potvrzení hesla:
asterisk
asterisk
Nyní se můžeme přihlásit jako administrátor na http://192.168.209.130:9090/login.jsp
jako
admin s heslem asterisk. V Server
Jazyk a Časové pásmo
Místní nastavení provedeme změnu
časové zóny na Central Europe (GMT+1:00).
7.14.2 instalace XMPP klientů
Pro účely testování zvolíme dva Instant Messaging (IM) klienty s podporou XMPP protokolu.
Prvním je populární Pidgin, jedná se multiplatformní aplikaci dostupnou pro Windows, Linux a Mac
OS X, podporuje řadu komunikačních protokolů a hlavně XMPP. Druhým použitým IM klientem je
Spark. XMPP klient Spark umožňuje i uskutečnění hovoru na uživatele, kteří mají na Openfire
serveru přiřazené číslo pobočky (extension) z Asterisku. Pidgin je možné stáhnout ze stránek
http://www.pidgin.im . Po instalaci zvolíme: Účty>Spravovat účty>Přidat a nastavíme následující
parametry:
•
•
•
•
•
Protokol: XMPP
Meno: alice
Doména: 192.168.209.130
Heslo: alice
Vytvořit tento účet na serveru: ANO
Po přidání uživatele v Pidgin se nám zobrazí výzva na autorizaci ze strany serveru a vyplníme
následující údaje:
•
•
•
•
Username: alice
Full name: alice
Email: alice@localhost
Password: heslo
Obr. 7.5 Vyplnění registrace XMPP klienta Pidgin
168
11 Asterisk
Pokud vše proběhlo korektně, tak dostaneme potvrzení o úspěšné registraci.
Obr. 7.6 Potvrzení úspěšné registrace XMPP klienta Pidgin
Následně v aplikaci Pidgin účet aktivujeme a server si od nás ještě jednou vyžádá heslo k účtu,
které si bude Pidgin již pamatovat.
Stejně jako u klienta Pidgin, musíme nakonfigurovat rovněž klienta Spark. Je k dispozici na
stránkách společnosti: http://www.igniterealtime.org/. Po stažení programu a jeho instalaci vytvoříme
nový účet pomocí Accounts, kde vyplníme následující údaje:
•
•
•
•
Username: bob
Password: heslo
Confirm Password: heslo
Server: 192.168.209.130
Měli bychom následně obdržet potvrzení: New account has been created. Přihlašovací údaje se
nám vyplní automaticky a zvolíme Login. Nyní si přidáme uživatele Alice jako kontakt: Contact>Add
Contact>UserName: Alice. Alice (XMPP Pidgin) obdrží výzvu k autorizaci Boba (XMPP Spark), což
potvrdíme. Teď máme nainstalovaný náš XMPP server a k němu zaregistrované dva uživatele Alice
a Bob prostřednictvím XMPP klientů Pidgin a Spark.
Obr. 7.7 Vyplnění registrace XMPP klienta Spark
169
11 Asterisk
7.14.3 Propojení XMPP a Asterisku
Spojení Openfire a Asterisku umožňuje kontrolovat, který uživatel právě hovoří a není tak plně
dostupný k online komunikaci. Jeho stav XMPP klienta se během hovoru změní na „On Phone“.
Zároveň je možné uživateli Openfire severu přiřadit pobočku z Asterisku a tímto uživatele přímo volat
z XMPP klienta Spark bez znalosti čísla přiřazené pobočky. Pokud se Asterisk přihlásí k XMPP
serveru jako uživatel, je schopen číst stavy spřátelených účtů, psát jim zprávy a přijímat jejich
odpovědi. Na základě těchto funkcí může při-způsobovat své chování.
Vzájemné propojení Asterisku s Openfire serverem probíhá přes AMI (Asterisk Manager
Interface). Na straně Asterisku je třeba přístup povolit a vytvořený účet nastavit do Asterisk-IM
modulu na Openfire serveru. Zde je také nastaveno přiřazení čísla pobočky každému z uživatelů.
Dále je zapotřebí přihlásit Asterisk k XMPP serveru jako uživatele. Nastavení se provádí v souboru
/etc/asterisk/jabber.conf, kde nastavíme běžné údaje k přihlášení k XMPP serveru jako adresa XMPP
serveru, port, status, apod. Důležitá je položka buddy, která určuje spřátelené účty, které bude
Asterisk žádat o autorizaci a které bude poté schopen sledovat. Typickým využitím je informování
uživatele o příchozím hovoru v okně XMPP klienta a následné směrování hovoru na základě jeho
odpovědi také v tomto okně. Konfigurace v /etc/asteris/extensions.conf bude následující.
exten => 333,1,Answer();
exten =>333,n,
JabberSend(asterisk,alice@IP_SERVERU,Prichozi hovor od uzivatele ${CALLERID(name)}, vyber
cilovou pobočku);
exten =>333,n, JabberSend(asterisk,alice@IP_SERVERU,1 :posli na 101);
exten =>333,n, JabberSend(asterisk,alice@IP_SERVERU,2 :posli na 102);
exten => 333,n, Set(OPTION=${JABBER_RECEIVE(asterisk,alice@ IP_SERVERU)});
exten => 333,n, GotoIf($[${OPTION} = 1]?10:20)
exten => 333,10, JabberSend(asterisk,alice@IP_SERVERU,(Calling101...);
exten => 333,n, Dial(SIP/101);
exten => 333,20, JabberSend(asterisk,alice@IP_SERVERU,(Calling102...);
exten => 333,n, Dial(SIP/102);
Další zajímavou funkcí je směrování hovoru na základě aktuálně nastaveného stavu v XMPP
klientu. Stavy, které XMPP server používá jsou následující:
•
•
•
•
•
•
•
Přítomen
Volný k hovoru (Free to chat)
Pryč
Pryč na dlouho
Nerušit
Offline
Odhlášen
Celkem tedy máme 7 stavů, podle kterých můžeme měnit chování ústředny. Příkladem je
jednoduchý skript, který rozlišuje, zdali je uživatel online (stav 1-5) nebo offline (stav 6-7) a podle
toho směruje hovor buďto přímo na uživatele nebo do hlasové schránky. O tomto faktu informuje
volajícího do okna XMPP klienta.
170
11 Asterisk
exten =>555,1,Set(STATUS=${JABBER_STATUS(asterisk,alice@IP_SERVERU)});
exten => 555,2,gotoif($[$[${STATUS}] < 6]?3:10)
exten=>555,3,Dial(SIP/101)
exten =>
555,10,jabbersend(asterisk,${CALLERID(name)}@IP_SERVERU,Ahoj,${CALLERID(name)}, volana
pobočka ${EXTEN} neni dostupna! Smeruji do hlasove-schranky.)
exten => 555,11(unavailable),Dial(SIP/102)
Jako souhrn většiny funkcí byl vytvořen prezenční skript. Cílem tohoto skriptu je směrovat hovor
na základě stavu v kalendáři, XMPP klientu a podle reakce uživatele v okně XMPP klienta. Skript
funguje následovně. Uživatel Bob má veřejnou pobočku pro celou kancelář, svoji privátní linku,
voicemailovou schránku a asistentku Alici, která má také svou privátní linku. Asterisk sleduje Bobův
stav v kalendáři a XMPP klientu. Pokud nemá žádnou schůzku v kalendáři (stav free) a je online,
dostane zprávu do okna XMPP klienta o tom, že mu volá konkrétní uživatel a on má možnost tento
hovor akceptovat nebo předat na asistentku. Pokud hovor příjme, má 30s na vyzvednutí hovoru,
jinak hovor skončí v hlasové schránce. Pokud není Bob dostupný díky kalendáři nebo XMPP klientu,
hovor je směrován na Alici na její privátní pobočku. U Alice se zjišťuje, zdali je přítomna v práci (je
online v XMPP klientu). Pokud ano, zvoní je telefon a má 30s na vyzvednutí hovoru, jinak hovor
končí Bobovi v hlasové schránce. Kompletní schéma chování prezenčního skriptu včetně propojení s
kalendářem a XMPP serverem dle výše uvedeného popisu je zobrazeno na obr. 7.8.
Obr.7.8 Schéma chování prezenčního skriptu
171
11 Asterisk
Níže následuje výpis inkriminované části direktiv a volání funkcí ve skriptu v extensions.conf.
exten => 201,1,GotoIf(${CALENDAR_BUSY(asterisk)}?busy:free)
exten =>201,n(free),Set(STATUS=${JABBER_STATUS(asterisk,bob@IP_SERVERU)});
exten => 201,n,gotoif($[$[${STATUS}] < 7]?5:busy)
exten => 201,5,JabberSend(asterisk,bob@IP_SERVERU,Prichozi hovor od uzivatele
${CALLERID(name)}, vyber cilovou pobočku);
exten =>201,n, JabberSend(asterisk,bob@IP_SERVERU,1 :prevezmi hovor (102));
exten =>201,n, JabberSend(asterisk,bob@IP_SERVERU,2 :posli na Alici 101);
exten => 201,n, Set(OPTION=${JABBER_RECEIVE(asterisk,bob@IP_SERVERU)});
exten =>201,n, GotoIf($[${OPTION} = 2]?busy:10)
exten => 201,10, Jabber-Send(asterisk,bob@IP_SERVERU,(Volam102...);
exten => 201,n, Dial(SIP/102,30);
exten =>201,n, VoiceMail(6001@mailbox-102)
exten =>201,n, Hangup();
exten =>201,n(busy),Set(STATUS=${JABBER_STATUS(asterisk,alice@IP_SERVERU)});
exten => 201,n,gotoif($[$[${STATUS}] < 7]?105:200)
exten => 201,105,JabberSend(asterisk,alice@IP_SERVERU,Bob je nedostupny,prichozi hovor od
uzivatele ${CALLE-RID(name)},vybercilovou pobočku:);
exten => 201,106, JabberSend(asterisk,alice@IP_SERVERU,1: prevezmi hovor (101));
exten => 201,107, JabberSend(asterisk,alice@IP_SERVERU,2: posli na do hlasoveschranky Boba);
exten => 201,108, Set(OPTION=${JABBER_RECEIVE(asterisk,alice@IP_SERVERU)});
exten => 201,109, GotoIf($[${OPTION} = 2]?200:110)
exten => 201,110, Jabber-Send(asterisk,alice@IP_SERVERU,(Volam101...);
exten => 201,n, Dial(SIP/101,30);
exten =>201,n, Hangup();
exten => 201,200, VoiceMail(6001@mailbox-102)
exten =>201,n,Hangup();
Přímé volání účastníka bez znalosti jeho telefonního čísla. V XMPP klientu Spark je možné,
pokud má uživatel v systému přidělenou pobočku, přímo volat daného účastníka. Po zvolení tlačítka
volat ústředna nejprve zavolá volajícímu a po vyzvednutí hovoru dochází ke spojení s požadovanou
pobočkou. Uživatel je v okně obeznámen, že má příchozí hovor a je mu nabídnuta možnost volby
směrování na cílové pobočky. Na základě jeho číselné odpovědi je hovor směrován na jednu z
nabízených poboček. Protokol XMPP je schopen nastavit až 7 různých stavů. Dle těchto stavů se
mění chování Asterisku a hovory se směrují na různé pobočky. Výše uvedený Prezenční skript
představuje modelovou situaci vedoucího, který má asistentku a pokud přichází hovor na vedoucího,
Asterisk zkontroluje jeho stav v kalendáři a XMPP klientu, pokud je dostupný, přijde mu zpráva o
příchozím hovoru a může se rozhodnout, zda-li hovor příjme, pokud není jakákoliv podmínka
splněna, hovor přechází na asistentku, zkontroluje se její stav v XMPP klientu, a hovor je směrován
buď na ni nebo do hlasové schránky.
172
12 Kamailio
8
Kamailio
Kamailio má kořeny v open-source projektu SER (SIP Express Router), který byl vyvinut
v Berlíně ve výzkumném institutu FhG Fokus v roce 2002, byly tím položeny základy kódu jedné
z nevýkonnějších SIP Proxy a řada dalších se v SER inspirovala [igl]. Část týmu přesunula i se
značkou SER do nově založené komerční společnosti iptel.org a jiná část založila v roce 2005
nekomerční opensource projekt OpenSER, tyto části vývojářů pracovaly odděleně.
Obr. 8.1 Logo SER a Kamailio
Kvůli sporům o obchodní značku SER se OpenSER v roce 2008 přejmenoval na Kamailio a
rovněž byla ještě v témže roce vytvořena další větev s názvem OpenSIPS. Následně o několik
měsíců se týmy vývojářů Kamailia a SER dohodly na vzniku projektu SIP Router, který by měl
sjednotit Kamailio a SER.
Obr.8.2 Souvislost mezi projekty vzešlých ze SER
173
12 Kamailio
8.1
Popis modulů Kamailia
Možnosti využití Kamailia jsou rozsáhlé, jedná se o velice výkonnou SIP Proxy, která dokáže
zpracovat stovky tisíc požadavků za sekundu, může rovněž fungovat jako SBC, Presence server či
registr ar anebo jako malá PBX a konkurovat Asterisku. Výhodou je interoperabilita se SIP klienty a
neskutečné možnosti adaptace, čili s určitým úsilím lze integrovat i SIP UA, kteří obsahují
neočekávané vlastnosti.
Nevýhodou je malý rozsah aplikací např. oproti Asterisku, což je dáno tím, že se nejedná o
B2BUA ale SIP Proxy a složitost vynucování kodeků, síla Kamailia je především ve zpracování SIP
signalizace. Kamailio má rovněž odlišný přístup ke konfiguraci než Asterisk, protože konfigurační
soubor Kamailia je skript vyžadující znalosti jazyka C. Neřídí se aplikační logika ale přímo flow SIP
zpráv, je zde možnost nahrávání modulů, lze použít různé DB moduly. Kamailio podporuje iIPv6, TLS,
NAT, skriptovací jazyky Perl, Python, Lua a databáze MySQL, PostgreSQL, UnixODBC, Berkeley DB,
Oracle [roz], [gon].
Obr. 8.3 Modulární architektura Kamailia
Jádro Kamailia poskytuje:
•
•
•
•
Management transportu a paměti
Rozhraní pro moduly
Konfigurace
Uzamykání
Moduly Kamailia poskytují:
•
•
Funkce skriptů
Speciální proměnné
174
12 Kamailio
•
•
Parametry modulů
Managementové funkce
Podporovaných modulů je celá řada, viz. obr 8.4, zmíníme si pouze ty nejdůležitější. Jednak jsou
zde základní moduly kex (sada funkcí), corex (další sada funkcí), tm (pro obsluhu transakcí), tmx
(rozšířený modul obsluhy transakcí), sl (stateless module), rr (Record-Route a Route module), pv
(Modul pseudoproměnných) , maxfwd (Max-Forward processor module) a dialog (modul pro
podporu dialogů).
Obr. 8.4 Moduly Kamailia
Další důležité moduly, které si zmíníme jsou následující:
• db moduly, pro podporu databází jako db_mysql, db_sqlite, db2_ldap (možnost
přistupovat k LDAP jako k DB) a db2_ops
• registrar modul, pro podporu registrací
175
12 Kamailio
•
•
•
•
•
•
•
•
•
•
•
•
8.2
aac moduly, Accounting (vytváření CDR záznamů o hovorech) s podporou různých
backendů včetně DB
auth modul, obecná podpora autorizace jak pro INVITE tak pro REGISTER
enum module, pro podporu ENUM dotazů
ipops module, pro operace nad IPv4 a IPv6 adresami
LDAP module, pro podporu LDAP dotazů přímo ve skriptu
rtproxy a nathelper modul, podpora průchodu NATem pomocí RTP Proxy
mediaproxy modul, podpora pro NAT pomocí Media Proxy
pike modul, pro zabezpečen proti DoS, umožňuje blokovat adresy generující příliš velký
provoz
ratelimit modul, podpora omezení různých částí kódu před zneužitím, např. omezení
počtu registrací za minutu
lcr modul, podpora LCR (Least Cost Routing), optimalizace směrování s nejnižšími
náklady
xlog, vylepšený logovací modul vhodný nejen pro debug
sipcapture modul, modul pro přeposílání vybraných SIP zpráv do DB pro pozdější
analýzu
Instalace o rozběhnutí Kamailia
Nejdříve ověříme pomocí apt-cache search kamailio , že balíček existuje a o kterou verzi se
jedná apt-cache show kamailio .
root@debian119:~# apt-cache search kamailio
kamailio - very fast and configurable SIP proxy
kamailio-berkeley-bin - Berkeley database module for Kamailio - helper program
***
root@debian119:~# apt-cache show kamailio
Package: kamailio
Version: 4.0.4-1
Pokud by balíček nebyl dostupný, tak si stáhneme a přidáme Kamailio GPG key do apt key
seznamu, potom do /etc/apt/sources.list odkazy do repozitáře Kamailia pro danou verzi, např. lenny.
root@debian119:~# wget http://deb.kamailio.org/kamailiodebkey.gpg
root@debian119:~# apt-key add kamailiodebkey.gpg
OK
root@debian119:~# nano /etc/apt/sources.list
deb http://deb.kamailio.org/kamailio lenny main
deb-src http://deb.kamailio.org/kamailio lenny main
Teď můžeme balíček nainstalovat.
root@debian119:~# apt-get install kamailio
Setting up kamailio (4.0.4-1) ...
[FAIL] Kamailio not yet configured. Edit /etc/default/kamailio first. ... failed!
176
12 Kamailio
Processing triggers for libc-bin (2.17-97) ...
Kamailio není nakonfigurováno, musíme nejdříve editovat /etc/default/kamailio., kde povolíme
níže uvedené.
root@debian119:~# nano /etc/default/kamailio
RUN_KAMAILIO=yes
USER=kamailio
GROUP=kamailio
MEMORY=64
DUMP_CORE=yes
Teď můžeme spustit Kamailio server /etc/init.d/kamailio start, který poběží s výchozí konfigurací.
root@debian119:~# /etc/init.d/kamailio start
[....] Starting Kamailio SIP server: kamailio:loading modules under
/usr/local/lib/kamailio/modules_k/:/usr/lib/i386-linux-gnu/kamailio/modules/
Listening on
udp: 192.168.1.119:5060
tcp: 192.168.1.119:5060
Aliases:
tcp: localhost:5060
udp: localhost:5060
Kamailio lze ovládat pomocí shell skriptu kamctl, např. přidávat další uživatele pomocí kamctl
add <username> <password>, restartovat kamct restart, vypisovat stavy přes kamctl monitor, atd.
Provedeme vypsání online uživatelů kamctl ul show. .
root@debian119:~# kamctl ul show
Domain:: location table=512 records=2 max_slot=1
AOR:: 123
Contact:: sip:[email protected]:5060 Q=
Expires:: 131
Callid:: [email protected]
Cseq:: 8
User-agent:: YATE/4.1.0
State:: CS_NEW
Socket:: udp:192.168.1.119:5060
Methods:: 543
Ruid:: uloc-52c369d3-b04-1
Reg-Id:: 0
Last-Keepalive:: 1388540855
Last-Modified:: 1388540855
AOR:: 111
Contact:: sip:[email protected]:43489;transport=udp Q=
Expires:: 3194
Callid:: [email protected]
Cseq:: 1
User-agent:: Sipdroid/3.2 beta/GT-I9505
State:: CS_NEW
Socket:: udp:192.168.1.119:5060
177
12 Kamailio
Methods:: 4294967295
Ruid:: uloc-52c369d3-b07-1
Reg-Id:: 0
Last-Keepalive:: 1388540618
Last-Modified:: 1388540618
root@debian119:~#
Kamailio běží a můžeme registrovat klienty a provést hovor, viz. obr. 8.5, ve kterém je odpověď
s 200 OK na žádost INVITE zachycená na SIP PROXY (Kamailio běží na 192.168.1.119) a obsahuje
v poli Via záznamy, podle kterých je tato odpověď směrována, rovněž vidíme, že Kamailio vložilo do
zprávy pole Record-Route vyžadující zasílání veškerých zpráv v dialogu přes tuto SIP Proxy.
Obr. 8.5 Potvrzení 200 OK na žádost INVITE
178
9
WebRTC a nové směry v IP telefonii
Web Real-Time Communications (WebRTC) přináší novou funkcionalitu do webového prohlížeče,
která umožňuje komunikaci v reálném čase. Vše je realizováno pomocí relativně jednoduchého API
(Application Programming Interface) rozhraní jazyka Javascript a HTML5. WebRTC nabízí
vývojářům webových aplikací schopnost psát multimediální aplikace v reálném čase (video, chat) na
webu bez nutnosti instalace jakýchkoliv pluginů [wie]. Smyslem projektu WebRTC je vybudovat
silnou RTC platformu, která bude pracovat ve většině webových prohlížečů. WebRTC je otevřený
projekt a má rovněž podporu webových prohlížečů: Firefoxu, Chrome a Opery. Audio i video
komunikace probíhá šifrovaně a bez problémů prochází i přes firewally, pro video WebRTC
specifikuje používání kodeku VP8, za kterým stojí Google, ale kompresní formát je otevřený se
zveřejněnými zdrojovým kódy a je implementován v knihovně libvpx (pod BSD licencí). Na konci roku
2013 společnost Cisco oznámila, že zveřejní svůj kodek, respektive implementaci, pro použití video
formátu H.264 ve webových prohlížečích jako openh264 (a obdobně jako Google pod BSD licencí)
s cílem podpořit technologie WebRTC.
Obr. 9.1 Podpora WebRTC v Asterisku
179
Asterisk podporuje WebRTC od verze 11, viz. obr. 9.1, kde byl vytvořen res_http_websocket
modul a podpora pro web sokety přidána do chan_sip. Asterisk tedy umožňuje přes web sokety
transportovat SIP. Rovněž má Asterisk podporu ICE, STUN a TURN v res_rtp_asterisk, což dává
silnou podporu klientům za NATem. WebRTC vyžaduje zabezpečená média, což se řeší přes
SRTP/SRTCP. S Asteriskem jsou možné dva scénáře, jednak komunikace mezi dvěma web
prohlížeči, přičemž uživatelé ve svých prohlížečích vyplní své přihlašovací údaje ke svému účtu na
Asterisku a můžou volat přímo z prohlížeče. Uživatel nic neinstaluje, postačí mu prohlížeč HTML5 a
klient je spuštěn jako javascript při přístupu na webovou stránku, takovýmto prvním klientem
s otevřeným kódem je sipML5 a francouzská společnost Duabango Telecom (založena v v roce
2011) stojící za tímto SIP HTML klientem uvádí funkčnost sipML5 na prohlížečích Chrome, Firefox,
IE, Opera a Safari. Tím pádem lze takovéhoto klienta integrovat i do sociálních sítí (přidáním kódu na
webovou stránku) jako FaceBook, Twitter, Google+ , atd. , přičemž není nutné instalovat žádný
plugin nebo SW [joh].
Obr. 9.2 WebRTC signalizace a média v případě Asterisku
I když obecně WebRTC popisuje komunikaci v tzv. WebRTC Web Triangle, kde pouze
signalizace jde na Web Server s podporou RTC a média již napřímo, tak v případě Asterisku
prochází signalizace i média skrz něj, viz. obr. 9.2.
Výhodou ovšem je kontrola nad médii a zprostředkování GW i do jiných sítí než IP anebo
protokolové GW, např. do Skype anebo Jingle (rozšíření komunikačního protokolu Jabber/XMPP),
viz. obr. 9.3. Pokud jsme u XMPP, tak nepochybně stojí za zmínku, že přes WebRTC lze posílat i
zprávy. WebRTC má velmi slibnou budoucnost, prohlížeč je prakticky ve všech koncových zařízeních,
čili potenciál rozšiřitelnosti je značný, rovněž podpora za NATem a jednoduchost používání, to jsou
atributy, které dávají této nové technologii velké šance na úspěch.
Pro podporu WebRTC v Asterisk u při kompilaci spustíme make menuselect, kde vybereme
res_http_websocket a res_rtp_asterisk a poté make install. Poté povolíme websocket v
/etc/asterisk/http.conf .
enabled=yes
bindaddr=0.0.0.0
180
bindport=8088
Doporučeno je zabezpečit ještě zabezpečit http přístup pomocí TLS, což zajistíme úpravou v
/etc/asterisk/http.conf .
tlsenable=yes
tlsbindaddr=0.0.0.0:8089
tlscertfile=localhost.crt
tlsprivatekey=localhost.key
Obr. 9.3 Asterisk jako WebRTC Gateway
Další konfigurace je v /etc/asterisk/sip.conf , kde povolíme transport přes web sokety.
transport=ws,wss
Přímo v nastavení uživatele ještě povolíme šifrování a podporu ICE protokolu.
[1010]
type=peer
username=1010
host=dynamic
secret=1010
context=default
encryption = yes
avpf = yes
icesupport = yes
; AVPF and SAVPF to be used and the media streams to be accepted
; encryption media encryption is a requirement of rtcweb the following must be added to the peer,
user, or friend to enable it.
181
Literatura
Literatura
[cam] Camp,K. "IP Telephony Demistified." McGraw-Hill, 2003, New York, ISBN 0-07-140670-0.
[col]
Collins, D. “Carrier Grade Voice Over IP.“ New York: McGraw-Hill, 2002. ISBN 00-714-0634-4.
[dor]
Sisalem, D., Floroiu, J., Kuthan, J., Abend, U., Schulzrinne, H. “SIP Security.“ Willey: p. 350.,
2009. ISBN 978-0-470-51636-2.
[gon] Goncalvez, F. Building Telephony Systems with OpenSIPS 1.6, Packet Publishing, p. 274,
2010. ISBN 978-1849510745.
[har]
Hardy, W. "VoIP service quality." McGraw-Hill, 2003, New York, ISBN 0-07-141076-7.
[joh]
Johnston, A., Burnett, D. "WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time
Web." Digital Codex LLC, 2012, ISBN-13: 978-0985978808.
[hro]
Hromek, F. "Optimalizace obsluhy RTP front." Vysoká škola báňská-Technická univerzita
Ostrava. Disertační práce, 2009.
[hos]
Hošek, J. "Nové metody zajištění kvality služeb v datových sítích." Disertační práce FEKT,
VUT v Brně, 2011.
[igl]
Iglo, T. "VoIP ústředna s protokolem SIP." UTB ve Zlíně, Fakulta aplikované informatiky, 2009.
[mac] Machník, P. "Kvalita služby." Prezentace k 9. přednášce v předmětu Širokopásmové sítě.
VŠB-TUO, 2013.
[md1] Madsen, L., Bryant, R. "Asterisk Cookbook." O'Reilly Media, 2011, ISBN-13: 978-1449303822.
[md2] Madsen, L., Bryant, R., Meggelen, J. "Asterisk: The Definitive Guide." Publisher: O'Reilly
Media; Fourth Edition edition, 846 pages, 2013. ISBN-13: 978-1449332426
[mik]
M. Mikulec, M. Voznak Pokročilé služby v podnikové komunikaci, V časopise Elektrorevue,
2012/4, 6. ledna 2012, ISSN: 1213-1539.
182
Literatura
[mol1] Kovář, P., Molnár, K. "Využití protokolu IAX pro spojení mezi ústřednami." Elektrorevue,
2008/42 – 13.11.2008, ISSN 1213-1539.
[mol2] Molnar, K. "Uživatelem ovladatelný mechanismus diferencovaného zajištění kvality služeb."
Disertační práce FEKT, VUT v Brně, 2007.
[roz]
Rozhon, J., Macura, L. „Kamailio.“ Materiály ze školení pro společnost RETIA. 2013.
[rez1] Řezáč, F. “Prezentace k přednášce k aplikaci SIPp.“ 2013. Dostupné přes Moodle
URL http://moodle.kat440.vsb.cz/
[sil1]
Šilhavý, P. "Telekomunikační a informační systémy - Laboratorní cvičení." VŠ skripta FEKT,
VUT v Brně, 2013.
[sil2]
Šilhavý, P. "VoIP Signalizace 2." Přednáška č.7 k předmětu Telekomunikační a informační
systémy. FEKT, VUT v Brně, 2013. Silhavy, prednaska k NAT, P6
[sil3]
Šilhavý, P. "Telekomunikační technika pro integrovanou výuku VUT a VŠB-TUO." VŠ skripta
FEKT, VUT v Brně, 2014.
[sin1] Sinnreich, H., Johnston, A., Sparks, R. “SIP Beyond VoIP.“ VON Publishing LLC, New York,
2005, ISBN: 0974813001.
[sin2] Sinnreich, H. “Internet Communications Using SIP.“ Wiley Computer Publishing, New York,
2001, ISBN 0-471-41399-2.
[sin3] Sinnreich, H., Johnston, A. “Internet Communications Using SIP Delivering VoIP and
Multimedia Services with Session Initiation Protocol Second Edition.“ Wiley Publishing, Inc.,
Indianapolis, Indiana, 2006, ISBN-13: 978-0-471-77657-4.
[sim]
Viagenie, S. "NAT and Firewall Traversal with STUN / TURN / ICE." 2008
URL http://www.viagenie.ca/publications/2008-08-cluecon-stun-turn-ice.pdf
[sir]
Širůček, M. “Návrh autentizačního mechanizmu pro GnuGK.“ Vysoká škola báňská-Technická
univerzita Ostrava, Diplomová práce, 2008.
[v51]
Voznak, M. “Extent of services supported by Q-signaling over IP. “ Communications 4/2004,
p.89-93, Scientific letters of the University of Zilina, december 2004, ISSN 1335-4205.
[v55]
Vozňák, M. “Projekt IP telefonie v síti CESNET2.“ Sborník příspěvků na mezinárodní
konferenci Informatika a kybernetika, str. 273 - 278, Dolny Kubin, 9. - 11.února 2005, FEI STU
Bratislava.
[v50]
Vozňák, M. “Praktický krátký návod na používání GNU GK.“ 2004.
URL http://homel.vsb.cz/~voz29/files/voz50.pdf
183
Literatura
[v67]
Vozňák, M. “Otevřené řešení impementace H.323.“ Connect!, str. 53 - 54, květen 2005,
Computer Press Praha, ISSN 1211-3085.
[v68] Vozňák, M., Machálek, P. “ENUM. “ Connect!, květen 2005, str. 16-18, Computer Press Praha,
ISSN 1211-3085.
[v90]
Vozňák, M. “Signalizace SIP.“Ve sborníku Teorie a praxe IP telefonie, vyd. Sdělovací
technika, ČVUT a ProTel engineering, str. 35-75, v Praze 8.11.2006.
[v92]
Vozňák, M. “Přenos hlasu prostřednictvím datových sítí.“ Kapitolav publikaci Moderní
komunikační technologie, str. 355-414, VŠB-Technická univerzita Ostrava, V Ostravě 2006,
ISBN 80-248-1111-1.
[v111] Halas, M., Kyrbashov, B. ,Voznak, M. “Factors influencing voice quality in VoIP
technology.“ In: 9th International Conference on Informatics‘ 2007, pp. 32-35, Bratislava,
ISBN 978-80-969243-7-0, 21-22.June 2007.
[v120] Nappa, A., Bruschi, D., Rozza, A., Voznak, M. “Analysis and implementation of secure and
unsecure Voice over IP environment and performance comparison using OpenSER.
“ Universita degli studi di Milano, 84 pages, December, 2007.
[v131] Vozňák, M. “Využití DNS v IP telefonii.“ V IT časopise Connect!, str. 12-13 v čísle 5/2008,
Computer Press, ISSN 1211-3085, květen 2008.
[v133] Voznak, M., Rozza, A., Nappa, A. “Performance comparision of secure and insecure VoIP
environments.“ TERENA Networking Conference 2008, TERENA, Brugge, Belgium, 19-22
May, 2008.
[v138] Voznak,M. “Impact of openVPN on Speech Bandwith.“ In proceedings TSP2008, 31th
International conference, 3-4.9 in Paradfurdo, Hungary. Publisher: Asszisztencia Szervező Kft.
Budapest, ISBN 978-963-06-5487-6.
[v188] Voznak, M., Rozhon, J. “SIP Back to Back User Benchmarking.“ Proceedings The Sixth
International Conference on Wireless and Mobile Communications ICWMC 2010, pp. 92-96,
Published by IEEE Computer Society, September 20-25, 2010, University of Valencia ,
Valencia.
[v191] Voznak, M, Rozhon, J. “Methodology for SIP Infrastructure Performance Testing.“ WSEAS
TRANSACTIONS on COMPUTERS, Issue 11, Volume 9, pp. 1012-1021, September 2010,
ISSN: 1109-2750.
[v193] Voznak, M., Rezac, F. “SIP Threats Detection System.“ Advances in Data Networks,
Communications, Computers, pp. 125-130, University of Algarve, Faro, Portugal, November
3-5, 2010,ISBN 978-960-474-245-5, ISSN 1792-6157.
[v194] Voznak, M., Tomes, M., Vaclavikova, Z., Halas,M. “E-model Improvement for Speech Quality
Evaluation Including Codecs Tandeming.“ Advances in Data Networks, Communications,
184
Literatura
Computers, pp. 119-124, University of Algarve, Faro, Portugal, November 3-5, 2010,ISBN
978-960-474-245-5, ISSN 1792-6157.
[v166] Voznak, M., Rezac, F., Halas, M. “Speech Quality Evaluation in IPsec Environment.“ In
Proceedings of the 12th Inter. Conference on Networking, VLSI and Signal Processing ICNVS 2010, pp. 49-53, University of Cambridge, ISBN 978-960-474-162- 5, ISSN 1790-5117,
Cambridge, UK, 2010.
[v229] Voznak, M., Macura, L. “Kamailio Syntax Generator and Configuration File
Parser.“ Proceedings of the 15th WSEAS International Conference on Computers, pp. 308312, July 14-17, 2011, Corfu, Greece. ISBN 978-1-61804-019-0, ISSN 1792-4251.
[vil]
Vilč, J. "ENUM a jiné metody adresace v sítích s VoIP." Diplomová práce FEI VŠB-TU v
Ostravě, 2007.
[vore] Vozňák, M., Řezáč, F. "Asterisk teorie a praxe." VŠB-TU v Ostravě, 2011
URL http://homel.vsb.cz/~voz29/files/Asterisk_teorie_a_praxe_v5.pdf
[wie]
Wiesner, D. "Videokonference v HTML 5." Bakalářská práce FEKT, VUT v Brně, 2013.
185
Rejstřík
Rejstřík
AES
Advanced Encryption Standard
AF
Assured Forwarding
AH
Authentication Header Protocol
BE
Best Effort
C2D
Click to Dial
DES
Data Encryption Standard
DHCP
Dynamic Host Control Protocol
DNS
Domain Name System
DDoS
Distributed Denial of Service
DoS
Denial of Service
DSCP
DiffServe Code Point
EF
Expedited Forwarding
ENUM
E.164 Number Mapping
ESP
Encapsulating Security Payload Protocol
GPL
GNU General Public Licence
HTTP
Hypertext Transfer Protocol
HTTPS
Hypertext Transfer Protocol Security
IPsec
IP security
186
Rejstřík
ISDN
Integrated Services Digital Network
ITU
International Telecommunications Union
MD5
Message-Digest algorithm 5
NAT
Network Address Translation
NAPTR
Name Authority Pointer Record
PA
Presence Agent
PBX
Private Branch eXchange
PHB
Per Hop Behaviour
PSTN
Public Switched Telephone Network
QoS
Quality of Service
RSVP
Resource Reservation Protocol
RTC
Real Time Communications
RTP
Real-time Transport Protocol
RTCP
RTP Control Protocol
S/MIME
Secure/Multipurpose Internet Mail Extensions
SAML
Security Assertion Markup Language
SDP
Session Description Protocol
SHA1
Secure Hash Algorithm 1
SIP
Session Initiation Protocol
SPIT
Spam over Internet Telephony
SRTP
Secure RTP
SRTCP
Secure RTCP
SRV
Service Record (specification in DNS)
TLS
Transport Layer Security
187
Rejstřík
TTS
Text to Speech
UA
User Agent
UAC
User Agent Client
UAS
User Agent Server
UDP
Unified Datagram Protocol
URI
Uniform Resource Identifier.
VLAN
Virtual Local Area Network
VoGW
Voice GateWay
VoIP
Voice over Internet Protocol
VPN
Virtual Private Network
ZRTP
Zimmermann RTP
188
Autor:
Katedra:
Název:
Místo, rok, vydání:
Počet stran:
Vydala:
Náklad
Miroslav Vozňák
Katedra telekomunikační techniky
Technologie a protokoly multimediálních komunikací pro integrovanou výuku
VUT a VŠB-TUO
Ostrava, 2014, 1. vydání
188
Vysoká škola báňská-Technická univerzita Ostrava
CD-ROM, 100 ks
Neprodejné
ISBN 978-80-248-3326-2

Technologie a protokoly multimediálních komunikací pro

Transkript

Podobné dokumenty

zde - Studijní materiály pro 4.A 2007/2008

DVB

H.323 Revisited

útočník mailto

V6 - Telconnect

O službě AIRWEB voice

Závěrečná zpráva CESNET projektu - LIPTEL

Vzdalena_spoluprace

Linksys PAP2T

2005

Sbornik VI. 03/2012 - Evropský polytechnický institut, sro

Přednáška

SMS Brána TriSMS

Techniky spojovaní v komunikačních systémech