OPVK VoIP 2014 Skripta Rev32

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: Miroslav Vozňák

Katedra: Katedra telekomunikační techniky
Název: Technologie a protokoly multimediálních komunikací pro integrovanou výuku
VUT a VŠB-TUO
Místo, rok, vydání: Ostrava, 2014, 1. vydání
Počet stran: 252
Vydala: Vysoká škola báňská-Technická univerzita Ostrava
Náklad CD-ROM, 500 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 70 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: voznak@ieee.org
OBSAH
1 Přenos sítí Internet v reálném čase 1
1.1 Real Time Protocol 1
1.2 Timestamp a rozptyl zpoždění 4
1.3 Stanovení zpoždění z RTP 5
1.4 Řídící protokol RTCP 6
1.5 Zabezpečení přenosu RTP 6
1.5.1 Zabezpečení pomocí SRTP 7
1.5.2 Návrh vylepšení SRTP pomocí ZRTP 11
1.6 Přenos DTMF a jiných tónů přes RTP 13
1.7 SCTP Stream Control Transmission Protocol 15
1.8 Audio v přenosovém řetězci od odesílatele k příjemci 16
1.9 Nároky na přenos audia v IP sítích 18
1.10 Kodeky 19
1.10.1 PCM 20
1.10.2 ADPCM 20
1.10.3 CELP 21
2 Standard ITU-T H.323 25

2.1 Rodina protokolů H.32x 26
2.2 Verze H.323 26
2.3 Koncepce komunikace v H.323 28
2.3.1 Protokolový model H.323 29
2.3.2 Prvky H.323 a jejich vlastnosti 29
2.3.3 Signalizace RAS 31
2.3.4 Signalizace Q.931 36
2.3.5 Signalizace H.245 38
2.3.6 Modely spojení DRC a GRC 39
2.4 Vybrané scénáře toku zpráv H.323 41
3 Hlasové brány 43
Signalizace v PSTN 43
3.1.1 Siťová signalizace v digitálních sítích 44
3.1.2 Účastnická signalizace v digitálních sítích 45
3.2 Vlastnosti hlasové brány 46
3.2.1 Modul FXS 48
3.2.2 Modul FXO 48
3.2.3 Modul EM 49
i
3.2.4 Moduly ISDN 49
3.3 Konfigurace ISDN modulů v Cisco směrovačích 50
3.3.1 Globální parametry nastavení 51
3.3.2 Příklad nastavení BRI 51
3.3.3 Příklad nastavení PRI 52
3.3.4 Pravidla volby čísel a směrů 53
3.3.5 Třídy kodeků 54
3.3.6 Chybějící kontrolní vyzváněcí tón 55
3.4 Diagnostika na hlasové bráně 56
4 GNU Gatekeeper 59
4.1 Instalace a konfigurace GnuGK 60
4.1.1 Základní konfigurace po instalaci 60
4.1.2 Registrace EP 61
4.1.3 Propojení GnuGK s jiným GK 63
4.1.4 Statická registrace GW v GnuGK 63
4.1.5 Autentizace v GnuGK 64
4.1.6 Autorizace v GnuGK 66
4.2 Návrh sítě s konfigurací GnuGK 67
4.2.1 Nastavení GK a mezizónové propojení 68
8.2.2 Nastavení VoGW a dynamické registrace na GK 69
5 Základy protokolu SIP 73

5.1 Základní popis protokolu SIP 73
5.2 Prvky SIP řešení 75
5.2.1 User Agent a Back to Back User Agent 76
5.2.2 SIP Proxy Server 77
5.2.3 SIP Registrar Server 79
5.2.4 SIP Redirect Server 80
5.3 SIP žádosti a odpovědi 81
5.3.1 Základní popis SIP hlavičky typické žádosti 81
5.3.2 SIP metody 82
5.3.3 SIP odpovědi 83
5.3.4 Transakce 87
5.3.5 Dialog 89
5.3.6 Transakce a dialog v příkladu 90
5.3.7 SIP časovače a retransmise 92
5.3.8 Zabezpečení v SIPu 93
5.4 Registrace 94
5.5 Směrování 96
ii
5.5.1 Směrování dle RURI a Via 97
5.5.2 SIP trapezoid 98
5.5.3 Udržení SIP Proxy v signalizační trase 102
5.6 SDP- protokol popisu relace 104
5.6.1 Konstrukce položek SDP pro komunikaci SIP/SDP 105
5.6.2 Offer/Answer model 107
6 Další metody rozšiřující SIP 109

6.1 Metoda PRACK (Provisional Response Acknowledgement) 109
6.1.1 Použití PRACK při volání do PSTN 110
6.1.2 Early Media 111
6.2 Metoda UPDATE 111
6.3 Metoda REFER 113
6.4 Metoda MESSAGE (Instant Messaging) 114
6.5 Metody SUBSCRIBE,NOTIFY,PUBLISH (Event/Notification) 115
6.6 Realizace vybraných doplňkových služeb v SIPu 118
6.7 Síťování SIP s PSTN 119
6.8 Paralelní vyzvánění - Forking 120
6.9 Přidržení hovoru - Call hold 121
6.10 Hudba při přidržení – Music on Hold 122
6.11 Předání hovoru - Call transfer 122
6.12 Přesměrování volání - Call forwarding 124
6.13 Indikace zprávy - Message waiting indication 125
6.14 Vytočení kliknutím - Click to dial 126
6.15 Zpětné volání – Call Back 128
6.16 Metoda INFO 129
7 Využití DNS pro IP telefonii 131

7.1 SRV záznamy 131
7.2 NAPTR záznamy 132
7.3 ENUM – mapování E.164 a URI 133
7.4 Prostory ENUMu 135
7.5 Sestavení spojení s využitím DNS 136
7.6 Konfigurace DNS pro účely ENUMu 137
7.7 Budoucnost ENUMu 138
8 SIPp a jeho použití k emulaci SIP relací 139

8.1 Instalace 140
8.2 Scénáře pro SIPp 141
8.2.1 SIPp v příkazovém řádku 141
iii
8.2.2 Vytváření XML schémat 142
8.2.3 Vkládání hodnot z externích souborů 147
8.2.4 Ovládání SIPp za běhu 149
8.2.5 Další tipy pro SIPp 150
9 NAT vs. IP telefonie 152

9.1 Terminologie 152
9.2 Popis problému s průchodem SIP zpráv přes NAT 153
9.3 Klasifikace typů NAT 154
9.4 Provozování IP telefonie přes NAT 155
9.4.1 STUN server 156
9.4.2 Překonání NATu pomocí TURN, ICE a rport 157
10 MGCP a IAX2 protokol 161

10.1 Media Gateway Control Protocol 161
10.1.1 Architektura a základní rysy MGCP 161
10.1.2 MGCP zprávy 162
10.1.3 Příklad komunikace pomocí MGCP 163
10.2 Inter Asterisk Exchange Protocol 164
10.2.1 Formát rámce IAX2 165
10.2.2 Adresace v IAX2 166
10.2.3 Zprávy IAX2 166
10.2.4 Registrace pomocí IAX2 167
10.2.5 Příklad sestavení hovoru pomocí IAX2 168
10.2.6 Rozpad spojení v IAX2 170
11 Asterisk 171
11.1 Verze Asterisku 171
11.2 Popis Asterisku 172
11.2.1 Režimy Asterisku 173
11.2.2 Kodeky a protokoly Asterisku 174
11.2.3 Služby Asterisku 175
11.3 Instalace 177
11.4 Globální nastavení asterisk.conf a modules.conf 178
11.5 Konfigurace SIP a IAX uživatelů v sip.conf a iax.conf 180
11.5.1 SIP uživatel v sip.conf 181
11.5.2 IAX uživatel v iax.conf 181
11.5.3 Další možnosti sip.conf a iax.conf 182
11.6 Dialplan extensions.conf 185
11.6.1 Kontexty 185
iv
11.6.2 Pobočky 185
11.6.3 Priority 186
11.6.4 Aplikace 186
11.6.5 Tvorba dialplanu 187
11.6.6 Vzory – Pattern Matching 188
11.6.7 Offset při práci s řetězcem 189
11.6.8 Vložené kontexty – Include Statements 190
11.6.9 Časové Vložené kontexty 190
11.6.10 Proměnná ${EXTEN} a funkce ${CALLERID(num)} 191
11.7 Voicemail 191
11.8 IVR – Interactive Voice Response 192
11.8.1 Jednoduché IVR 193
11.8.2 Neplatný vstup (extension i) 193
11.8.3 Pauzy 193
11.8.4 Víceúrovňové IVR 194
11.9 DAHDI/ZAPTEL 195
11.9.1 Chan_dahdi.conf (Zapata.conf) 196
11.10 Peering mezi dvěma Asterisky 197
11.11 Použití SRTP a SIPS/TLS 200
11.11.1 Zabezpečení médií pomocí SRTP 200
11.11.2 Zabezpečení signalizace v Asterisku pomocí SIPS 201
11.12 Asterisk a kalendáře 202
11.12.1 Instalace Davical serveru 203
11.12.2 Propojení Asterisku a Davical serveru 205
11.13 Aplikace kalendářových funkcí 206
11.13.1 Směrování volání na základě zaneprázdněnosti 206
11.13.2 Zapisování do kalendáře 206
11.13.3 Čtení záznamů uložených v kalendáři 207
11.13.4 Upozornění na schůzku 209
11.14 XMPP server a Asterisk 209
11.14.1 Instalace Openfire 210
11.14.2 instalace XMPP klientů 211
11.14.3 Propojení XMPP a Asterisku 213
12 Kamailio 216
12.1 Popis modulů Kamailia 217
12.2 Instalace o rozběhnutí Kamailia 219
13 Aspekty kvality IP telefonie 222

13.1 Kvalita služby (QoS) 222
v
13.2 IntServ 223
13.2.1 IntServ Architektura a protokol RSVP 223
13.3 DiffServ 224
13.3.1 Architektura DiffServ 225
13.3.2 DSCP značka 227
13.4 Nástroje QoS 230
13.5 Obsluha paketových front 230
13.5.1 Metoda FIFO 230
13.5.2 Metoda CQ 231
13.5.3 Metoda WFQ 231
13.5.4 Metoda PQ 232
13.5.5 Metoda CBWFQ 232
13.5.6 Metoda PQ/WFQ 232
13.5.7 Metoda LLQ 233
13.5.8 Řízení toku a zahlcení 233
13.5.9 Komprese RTP a fragmentace 234
13.6 Kvalita řeči 235
13.7 Vliv zabezpečení na kvalitu hovoru 237
13.7.1 RTP přes TLS 237
13.7.2 RTP přes IPsec 240
14 WebRTC a nové směry v IP telefonii 242
Literatura 246
Rejstřík 250
vi
1 Přenos sítí Internet v reálném čase

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 real-
time 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.
1.2 Timestamp a rozptyl zpoždění
RTP pakety jsou odesílány obvykle v pravidelných intervalech Δt [s]. Pokud zachytíme RTP tok,
tak tento interval zjistíme z časových značek (timestamp). Pro timestamp platí, že údaje v políčku
jsou odvozeny od lineárního časového zdroje. Interval odesílání (timing) se z RTP paketů vypočte ze
dvou po sobě jdoucích časových značek dle rovnice (1.2).
timestamp{N+1}  timestamp{N}
t= (1.2)
sampling_frequency
Vzorkovací kmitočet je obvykle 8 kHz, na obrázku níže jsou zachyceny RTP pakety s PCM
kódováním G.711-Alaw. Rozdíl dvou po sobě jdoucích údajů zachycených na obr.1.4. v položce
Time úplně vpravo (timestamp) je 160, pochopitelně odcházejících ze stejné IP adresy (source). Po
vydělení vzorkovacím kmitočtem 8 kHz dostáváme 20 ms, což je časování odesílání paketů ze
zdroje. V uvedeném případě můžeme očekávat tedy 50 paketů za sekundu.
Obr. 1.4. Inkrementace hodnoty pole timestamp.
Ačkoliv datagramy byly odeslány v intervalech 20 ms, tak pokud bychom určili rozdíly mezi
vyslanými na straně odesílatele a srovnali je s rozdíly mezi přijatými datagramy na straně příjemce,
zjistili bychom, že se liší. Jelikož pakety neměly stejné podmínky přenosu, způsobené především
odlišným časem stráveným ve frontách na směrovačích, tak došlo k rozdílu mezi časem skutečného
a očekávaného příchodu, tento rozdíl označujeme jako rozptyl (jitter).
4
Označme Si jako hodnotu časové značky v i-tém RTP paketu (timestamp) a Ri čas skutečného
doručení paketu i příjemci, potom pro dva dva pakety i a i-1 bude platit pro výpočet rozptylu jejich
doručení příjemci rovnice (1.3):
Di  (R i  R i 1 )  (Si  Si 1 )  (R i  Si )  (R i 1  Si 1 ) (1.3)
Podmínkou platnosti vztahu je, že RTP pakety jsou přijaty z jednoho zdroje synchronizace (SSRC
pole v RTP hlavičce).
Obr. 1.5. Rozptyl zpoždění zjištěný při příjmu RTP toku.
Zatímco Di [ms] představuje okamžitý jitter, tak v praxi se využívá k sledování rozptylu klouzavý
průměr, který reflektuje jeho dosavadní průběh, na druhé straně je ale potřebnost rychlé
konvergence k aktuálním hodnotám. Pro tento účel se nejčastěji používá následující vztah pro
výpočet sledované hodnoty rozptylu Ji, přičemž empiricky získaná hodnota 16 zahrnující průměr 16-ti
předchozích rozptylů reflektuje vlastnosti zmíněné v předchozí větě.
[ Di  J i 1 ] 15 D
Ji  Ji 1   Ji 1   i (1.4)
16 16 16
1.3 Stanovení zpoždění z RTP
RCTP XR definuje rozšířené posílání zpráv XR (Extended Reports) v rámci dohledu nad RTP
tokem, které zajišťuje protokol RTCP (Real Time Control Protocol). RTCP XR je obsažen v
doporučení RFC 3611 z konce roku 2003, XR pakety jsou složeny z jednotlivých bloků oznámení
(report blocks) a jedním z těchto bloků je i VoIP Metrics Report Block, který uceleně informuje o
kvalitativních parametrech VoIP.
RTD  ESD(A)  ESD(B)

OWPD  (1.5)
2
5
Jednosměrné síťové zpoždění OWPD (1.5) může být stanoveno z RTD (Round Trip Delay) [ms],
což je doba oběhu zprávy od odesílatele k příjemci a zpět neboli odezva. Jelikož je nutné vyjádřit
celkové E2E zpoždění, tak RFC 3611 zavádí parametr odhadu systémového zpoždění ESD
(Estimated System Delay) [ms], který je definován součet všech přírustků zpoždění na zařízení.
RTCP-XR stanovuje, že na straně vysílací je v ESD(A) zahrnuto celkové zpoždění vzniklé
kódováním a paketizací, na straně přijímací je ESD(B) tvořenou součtem nastavené doby
mezipaměti vyrovnání rozptylu (de-jitter buffer) a zpožděním při dekódování. Je zaveden parametr
jednosměrného symetrického zpoždění hlasové cesty OWPD (one way symmetric voice path delay),
který je vyjádřen vztahem (1.5).
1.4 Ří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:
 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.
1.5 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].
6
1.5.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.6. 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.7. Obsah polí hlavičky SRTP
7
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.7. MKI zvyšuje bezpečnost, protože během jedné relace mohou být klíče střídány [v120].
Obr. 1.8. 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í CIPH K 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.9, 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í CIPH K 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
8
(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.9. 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.10. Blokové schéma šifrování obsahu RTP
Podívejme se nyní na aplikaci AES-CTR v SRTP, viz. obr. 1.10. 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
9
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.11. 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.11. 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.
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
10
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.5.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
11
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.12. Princip DH algoritmu.
Princip DH algoritmu je znázorněn na obrázku 1.12, 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
12
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.6 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ů:
13
 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |1 0| 10 | 2000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |0 0| 20 | 400 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Obr. 1.13. RTP paket dle RFC 2833 po volbě čísla 112
14
1.7 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.14.
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.14. 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)
15
1.8 Audio v přenosovém řetězci od odesílatele k příjemci
V řetězci cesty audia od odesílatele k příjemci nacházíme tři podstatná místa, viz. obr.1.15 [v111]:
 u odesílatele dochází k paketizaci audia a odeslání RTP paketů,

 IP sítí probíhá přenos RTP v Internetu,
 a nakonec u příjemce se opětovně získávají hlasové informace z RTP paketů.
Místa výše uvedená jsou zdrojem zpoždění, které může zásadním způsobem ovlivnit výslednou
kvalitu řeči. Komponenty zpoždění v souladu s jejich umístěním můžeme klasifikovat následovně:
 paketizační zpoždění (packetization) a zpoždění v kodéru (coder),

 zpoždění čekáním ve frontách (queuing), serializační (serialization) způsobené odesíláním
přes rozhraní síťových zařízení a propagační (propagation) způsobené šířením signálu
přenosovým prostředím
 nakonec zpoždění v mezipaměti přijímače (De-jitter) a zpoždění při zpracování přijaté
informace na dekodéru (decompression).
Obr. 1.15. Identifikace míst komunikačního řetězce, kde vzniká zpoždění.
Při zpracování audio signálu na straně odesílatele dochází k následujícím operacím [v111]:
 audio je kódováno na kodéru (např. do formátu PCM),

 bitový tok z kodéru je doslova naporcován do balíčků o konstantní velikosti (u PCM jsou to
balíčky o velikosti 160B),
 k užitečné zátěži s audio informací dochází k přidání RTP hlavičky (12B) a UDP hlavičky (8B)
a IP hlavičky (20B), audio je enkapsulováno napříč jednotlivými protokolovými vrstvami ,
 nakonec dojde k vytvoření rámce (doplnění fyzických adres a kontrolního součtu) a jeho
odeslání.
16
Obr. 1.16. Cesta audia od odesílatele a jeho zpracování u příjemce.
Při přenosu audia IP sítí dochází k časovému posunu mezi RTP pakety především vlivem jejich
řazení ve frontách na směrovačích, viz. obr. 1.17 a vzniká jitter, což bylo již vysvětleno v kapitole 1.2.
Na tento problém bylo pamatováno při návrhu standardu RFC 1889 pro RTP protokol a v hlavičce
paketu je přenášena položka Timestamp vyjadřující vzorkovací značku v RTP paketu odvozenou od
lineárního časovače. Díky této značce je možné jitter přesně rozpoznat a jeho vliv eliminovat. Na
straně příjemce je přijatý paket zařazen do vyrovnávací mezipaměti (de-jitter buffer neboli playout
buffer), tím je minimalizován vliv rozptylu zpoždění, viz. obr. 1.16. Následně jsou data z mezipaměti
předávány k dekódování, mezipaměť je vhodné nastavit na násobky dob trvání kódovaných
hlasových fragmentů při paketizaci (např. 60 ms je nejvhodnější, neboť vyhovuje pro kódování G.711,
G.729 i G.723.1.), některá zařízení umožňují samokorekci velikosti mezipaměti a pomocí adaptivních
algoritmů přizpůsobují její hodnotu aktuální situaci.
Obr. 1.17. Řazení ve frontách směrovačů.
17
1.9 Nároky na přenos audia v IP sítích
Základními kroky předcházející odeslání hlasu v RTP paketu je kódování určitým typem kodeku
a paketizace. RTP pakety jsou odesílány v dedikovaných intervalech a načasování odeslání bude
záviset jednak na velikosti užitečné zátěže a jednak rychlosti výstupního toku z kodéru. Základní
rovnice, která vyjadřuje časování odesílání RTP je vyjádřena jako
PS
t= (1.7)
CR
kde t [s] je časování, PS [b] je velikost užitečné zátěže a C R [bit/s] představuje rychlost
proudu bitů z kodéru. Informace o časování jsou uloženy v RTP paketech v časových značkách
(timestamp) a mohou být zpětně získány, viz. vztah (1.1). Na aplikační vrstvě můžeme do vztahu (1.8)
vyjádřit jednak payload PS a velikost RTP hlavičky H RTP , což je 12B.
SAL  HRTP  PS (1.8)
Nyní je důležité vyjádřit velikost dalších hlaviček v jednotlivých vrstvách OSI modelu, což je
3
provedeno jako suma H
j 1
j . Jednak se jedná o 8B na UDP, 20B na IP poté 26B v případě
Ethernetu jako velikost polí v rámci IEEE 802.3. Nyní můžeme vyjádřit hodnotu BW M nárokovaného
pásma RTP toků pro M hovorů jako sumu jednotlivých příspěvků velikosti rámců SFi , které je nutné
přenést v intervalu t :
M
SFi
BWM   (1.9)
i 1 t i
Pokud všechny hovory používají stejný kodek, tak (1.7) a (1.8) do vztahu (1.9) získáváme pro
výpočet nároků všech RTP toků (1.10).
 3

 H  
RTP j 1 H j 
BWM  M  CR  1   (1.10)
 P 
 S 
 
Z výše uvedené rovnice můžeme graficky vyjádřit, jak závisí nárokované pásmo na velikosti
užitečné zátěže v RTP a počtu hovorů, obr. 1.18. Ve 3D zobrazení vidíme, že s klesající velikostí
užitečné zátěže rostou nároky na pásmo, což je způsobeno režií hlaviček, jejichž poměr vůči
klesajícímu množství přenášené informaci roste.
18
Obr. 1.18. Závislost pásma na velikosti zátěže a počtu hovorů
1.10 Kodeky
Kodek je zařízení nebo algoritmus, který slouží ke zmenšení jinak zbytečně velkého objemu
audiovizuálních dat. Slovo kodek vzniklo složením slov kodér a dekodér, tj. zařízení jež je na jedné
straně schopné data zakódovat a na druhé straně opět rozkódovat. Při použití osobního počítače je
typicky vstupem kodeku zvuková karta, data získaná z mikrofonního vstupu kodér zpracuje a předá
je RTP vrstvě, vzniklé protokolové datové jednotky se enkapsulují v jednotlivých vrstvách OSI
modelu, až jsou nakonec vyslána příjemci. Přijatá data převede do původní podoby dekodér a pošle
na audio výstup zvukové karty. Kodeky velmi často používají ztrátovou kompresi a proto dekódovaná
data nejsou totožná s daty, která byla zakódována.
Tato kapitola je věnována popisu kodeků, které se v IP telefonii nejčastěji vyskytují. Zdrojem
hovorového signálu jsou řečové orgány, které se skládají z hlasivek, hrdelní dutiny, ústní dutiny,
nosní dutiny, měkkého a tvrdého patra, zubů a jazyka. Zdrojem buzení této soustavy jsou plíce ve
spolupráci s dýchacími svaly. Vlivem tlaku proudu vzduchu vycházejícího z plic dochází k jeho
modulaci hlasivkami. Kmitočet závisí na tlaku vzduchu na svalovém napětí hlasivek. Kmitočet
hlasivek je charakterizován základním tónem lidského hlasu, který tvoří základ znělých zvuků.
Kmitočet základního tónu je různý u dětí, dospělých, mužů i žen, pohybuje se většinou v rozmezí 150
až 400 Hz. V klidu je štěrbina hlasivek otevřena a proud vzduchu volně prochází hlasivkami.
Vytvářený zvuk je po průchodu hlasivkami formován ústní dutinou a je vyřazován do volného
prostoru. Sdělení zprostředkované řečovým signálem je diskrétní, tzn. může být vyjádřeno ve tvaru
posloupnosti konečného počtu symbolů. Každý jazyk má vlastní množinu těchto symbolů - fonemů,
většinou 30 až 50. Lidská řeč je souvislý časově proměnný proces, z toho plyne i náročnost popisu
lidské řeči a jejího modelování. Hovorový signál snímáme mikrofonem, který převádí modulovaný
proud vzduchu na elektrický signál. Přístupy ke kódování jsou následující:
19
 kódování vlny (waveform coding), zpracování vychází z přeměny hovorového signálu ve tvaru
elektrického signálu. Tento signál je vzorkován, kvantován a následně kódován,
 kódování parametrů zdroje hovorového signálu (Source Coding),
 a hybridní, do této kategorie patří kodeky založené na adaptivních predikčních metodách, na
metodách vektorové kvantizace, složkovém kódování anebo adaptivním transformačním
kódování.
1.10.1 PCM
Nejznámější a nejpoužívanější kodek je PCM ITU-T G.711, výstupem kodéru je bitový tok 64
kbit/s. Kódování PCM (Pulse Code Modulation) se sestává ze tří kroků:
 vzorkování 8 kHz, hodnoty spojitého analogového signálu ve frekvenční oblasti 300-3400Hz

se odečítají v diskrétním čase,
 kvantování, ke každému vzorku získanému v předchozím kroku se přiřadí bitová sekvence z
možných diskrétních úrovní,
 a nakonec kódování.
Vzorkuje se 8 kHz a jednotlivé vzorky jsou reprezentovány osmibitovými sekvencemi. Při

kvantování ovšem vzniká kvantizační zkreslení, protože každému vzorku je přiřazen jemu nejbližší
kvantizační stupeň a počet hodnot je omezený. Kodér přiřadí každému kvantizačnímu stupni
číselnou kódovou kombinaci a kvantovaný vzorek do ní zakóduje. Příčinou kvantizačního zkreslení je
rozdíl mezi nekonečným počtem vstupních a konečným počtem výstupních hodnot, nižší hodnoty
budou u lineární stupnice více zkresleny. Proto se u digitálních modulací používá komprese, výšky
malých vzorků se zvýrazní a výšky velkých vzorků se ponechají tak, aby útlum kvantizačního
zkreslení byl konstantní. Pomocí expanze v přijímači se vzorkům vrátí původní rozsah a poměr
jednotlivých výšek. Pro zajištění rovnoměrné hodnoty odstupu kvantizačního zkreslení se v
pracovním rozsahu kodéru PCM používají logaritmické křivky A-law a µ-law (Severní Amerika).
Použítí logaritmické kvantizační stupnice namísto lineární nízké hodnoty vzorků se na vysílací straně
zesílí a vysoké naopak zeslabí. Na přijímací straně proběhne inverzní proces.
1.10.2 ADPCM
Kódování ADPCM (Adaptive Differential Pulse Code Modulation) vychází z DPCM. Kódování
DPCM (Differential Pulse Code Modulation) je modifikací PCM kódování, nekódují se navzorkovaná
data, ale jejich rozdíl oproti odhadnutému průběhu signálu, průběh signálu je možné částečně
odhadnout, navzorkovaný průběh a odhadnutý průběh jsou si podobné, výsledný rozdíl má mnohem
menší dynamický rozsah a je možné ho zakódovat pomocí menšího počtu bitů, tedy množství
přenášených dat se snižuje. ADPCM je vylepšeno tak, že generátor srovnávacího průběhu je
adaptivní a přizpůsobuje se konkrétní řeči, která se kóduje. Výsledkem je ještě menší dynamický
rozsah než v případě DPCM a tedy opět menší počet bitů nutný k zakódování. Kromě toho se mění i
vlastnosti kvantifikace pro charakteristiku konkrétní řeči. Nejznámějším představitelem ADPCM je
ITU-T G.726 (32 kbit/s), ale jsou možné i jiné rychlosti výstupního toku z kodéru v závislosti na
20
použitém adaptivním algoritmu, G.726 a G.727 umožňují 40, 32, 24 a 16 kbit/s. Vůbec prvním
standardem ADPCM bylo doporučení ITU-T G.721 pro 32 kbit/s. LPC
LPC (Linear Predictive Coding) je způsob kódování založený na úplně jiném principu než PCM
nebo ADPCM, ty vycházely z kvantifikace průběhu signálu. Metoda LPC vychází naopak ze znalostí
o mluvícím traktu (tj. hlasivkách a krku). Tato metoda se snaží vytvořit model hlasového ústrojí
člověka. LPC využívá předpokladu že hlasový signál je generován bzučákem na konci trubky,
štěrbina mezi hlasivkami produkuje bzukot, který je charakterizován hlasitostí a frekvencí. Mluvící
ústrojí (krk, ústa) vytváří trubku, která je charakterizována svými rezonancemi nazývanými formanty.
LPC analyzuje řeč aproximováním formantů, odstraněním jejich působení z hlasového signálu a
odhadem intenzity a frekvence zbývajícího signálu, který je generován hlasivkami. Proces
odstranění formantů se nazývá inverzní filtrování. LPC vytváří signál řeči obráceným procesem,
vygeneruje se signál s příslušnou hlasitostí a frekvencí a z formantů se vytvoří filtr. Tímto filtrem se
potom vygenerovaný signál zpracuje a výsledkem je signál podobný původnímu signálu řeči. Protože
vstupní signál se mění v závislosti na čase, je nutné tento proces opakovat pro kratší časové
intervaly, tzv. rámce. Pro rozumnou kvalitu výsledné řeči se používá 30 až 50 rámců za vteřinu.
Představitelem je LPC kodek s výstupním tokem 4,8 kbit/s nebo kodek LPC-10 s tokem 2,4 kbit/s.
Obr. 1.19. MOS v závislosti na bitové rychlosti kodeků.
1.10.3 CELP
Kódování CELP (Code Excited Linear Prediction) zásadně vylepšuje LPC. Problém metody LPC
je v tom, že to, co zbude po odfiltrování formantů, není pouze signál bzučáku. Důvodem je, že v řeči
se vyskytují složky reprezentující třeba sykot. Takovéto zvuky nebudou jednoduchým LPC kodekem
správně aproximovány. Nepřesnosti při odhadu formantů způsobí, že více informací o signálu
zůstane v reziduu (zbytek po odfiltrování formantů). To platí pro zvuky které neodpovídají
21
jednoduchému LPC modelu, platí to například pro zvuky generované různou pozicí jazyka atd. Tedy
reziduum obsahuje důležité informace o tom, jak má řeč znít, tyto informace se zakódováním pomocí
LPC ztratí, protože reziduum se zakóduje pouze pomocí dvou parametrů, frekvence a amplitudy
signálu. Vzniká tedy otázka, jak reziduum zakódovat lépe tak, aby se příliš nezvýšil nárok na šířku
pásma a tyto důležité informace se přitom neztratily.
Jednou z nejúčinnějších metod je použití codebooku. Kódová kniha je tabulka obsahující typické
průběhy rezidua. Kodér potom porovnává průběh rezidua s hodnotami v tabulce a použije tu, která
odpovídá nejvíc, index této hodnoty z tabulky se potom přenáší. Druhá strana má stejnou tabulku a
po příjmu indexu dokáže průběh rezidua z tabulky obnovit, toto reziduum potom slouží jako budič pro
filtr aproximující formanty. Výsledkem je lepší aproximace hlasového signálu než v případě
jednodušší metody LPC. Tato metoda se nazývá Code Excited Linear Prediction, zkratka CELP. Aby
metoda CELP správně fungovala, tabulka obsahující typické průběhy rezidua musí být velmi
rozsáhlá, pokud je ale tabulka velká, bude vyhledávání v tabulce trvat rovněž velmi dlouho. Dalším
problémem je, že tabulka by musela obsahovat vzorky pro různě vysoký hlas, taková tabulka by však
byla extrémně rozsáhlá. Tento problém se řeší vytvořením dvou tabulek. Jedna tabulka je vytvořená
při tvorbě kodeku a obsahuje vzorky pro právě jednu výšku hlasu. Druhá tabulka je adaptivní, ze
začátku je prázdná a průběžně se plní předešlými vzorky rezidua zpožděnými o určitou hodnotu.
Právě hodnota zpoždění určuje výšku hlasu, popsaný algoritmus poskytuje dobrou kvalitu přenášené
řeči už při šířce pásma 4,8 kbit/s. Typickými představiteli jsou ACELP dle G.723.1 s tokem 5,3 kbit/s,
CS-ACELP dle G.729 s tokem 8kbit/s anebo LD-CELP dle G.728 s tokem 16 kbit/s.
Tab. 1.1 Typ kódování, MOS, rychlost a náročnost na výpočetní výkon.
Mezi modifikace CELP patří ACELP (Algebraic Code Excited Linear Prediction), LD-CELP (Low
Delay Code Excited Linear Prediction) a CS-ACELP (Conjugate Structure Algebraic Linear Code
Prediction). Následně si popíšeme nejpoužívanější kodeky, ty jsou specifikovány v doporučeních
ITU-T:
 G.711 je základní kodek PCM, který se používá i v klasické telefonní síti. Kvalita přenášeného
hlasu je totožná s kvalitou hlasu při běžném telefonním hovoru, MOS má hodnotu 4,2, rámec
trvá 0,125 ms;
22
 G.723.1 používá buď kódování MP-MLP nebo ACELP. První typ kódování vyžaduje šířku
pásma 6,3 kbit/s, druhý typ 5,3 kbit/s. Jeden rámec obsahuje úsek trvající 30 ms a MOS
skóre je 3,9 při použití kódování MP-MLQ a 3,65 při použití ACELP;
 G.726 kodek používá kódování ADPCM, potřebná šířka pásma je 16, 24, 32 a 40 kbit/s.
Kodek může zpracovávat bloky různé délky podle toho, jak velké zpoždění je požadováno,
pro 32 kbit/s se uvádí MOS=3,85;
 G.728 používá kódování LD-CELP. Potřebná šířka pásma je 16 kbit/s, MOS skóre je přibližně
3,6;
 G.729 Použité kódování je CS-ACELP - Conjugate Structure Algebraic Code Excited Linear
Prediction. Rámec trvá 10 ms a potřebná šířka pásma je 8 kbit/s, MOS je hodnocen 3,92;
 GSM kodek, šířka pásma je 13 kbit/s (Full Rate GSM FR). Kodek je založen na kódování LPC.
Dalším rozšířením v roce 1997 byl kodek GSM EFR (Enhanced Full Rate, GSM 06.60) s
rychlostí 12,2 kbit/s a rámcem 20 ms (obsahuje 244 bitů). V roce 1998 přišlo další kódovací
schéma, a to AMR kodek (Adaptive Multi-Rate), který je používán i v UMTS. AMR používá
ACELP techniku kódování a rychlosti se pohybují od 4,75 (AMR 4,75) do 12,2 kbit/s (AMR
12,2). AMR 12,2 je kompatibilní s GSM EFR.
 iLBC - internet Low Bit Rate Codec, tento kodek byl vyvinut firmou Global IP Sound, potřebná
šířka pásma je 13.33 kbit/s, rámec obsahuje úsek trvající 30 ms. Kodek umožňuje elegantní
snížení kvality přenášeného signálu v případě zpoždění nebo ztráty paketů. Použitý
algoritmus je Block Independent Linear Predictive Coding. Každý rámec je komprimován na
399 bitů, které se potom přenáší.
 G.722 je wideband hlasový kodek z roku 1988 pracující se šířkou pásma 50Hz-7 kHz
s typickým výstupním proudem 64 kbit/s., technologie je postavena na SB-ADPCM (sub-band
ADPCM). Dalšími 7 kHz wideband kodeky jsou G.722.1 a G.722.2, tyto kodeky nejsou
deriváty původní G.722, ale využívají jiné kompresní algoritmy. G.722.1 (Siren codec) se
vyznačuje výkonnou kompresí s typickým proudem 24 nebo 32 kbit/s. Novější G.722.2 známá
jako AMR-WB (Adaptive Multirate Wideband) vychází z ACELP kódování a vyznačuje se
jednak silnou kompresí (až 6,6 kbit/s) a schopností adaptovat kompresní algoritmus na
aktuální situaci.
Tab. 1.2 Typ kódování, rychlost, typická paketizace, rámec a zpoždění.
V tabulce 1.2 můžeme vidět srovnání nejpoužívanějších kodeků, ve čtvrtém sloupci tabulky je
uvedena typické časování odesílání paketů, v dalším sloupci je doba trvání rámce a po sečtení s
23
look-ahead (dopředným výpočetním zpožděním u kodeků pracujících s predikcí) dostaneme celkové

minimální zpoždění, které lze u kodeku teoreticky dosáhnout.
V posledním řádku je použit kodek G.729A, což je dodatek ke kodeku G.729, tento dodatek
implementuje G.729 s nižší výpočetní náročností, G.729A vyžaduje pouze 11 MIPS, klesá ale MOS
na 3,6. Dalším používaným dodatkem G.729 je implementace detekce ticha VAD s označením
G.729B, často najdeme i kodek s oběma dodatky s označením G.729AB.
Implementace VAD do G.723.1 je označována jako G.723.1A. VAD (Voice Activity Detection)
nebo taky někdy označována jako SS (Silence Suppression) je funkce potlačení ticha, ticho během
hovoru se nepřenáší, neboť nenese žádnou informaci. V průměrném hovoru ticho tvoří 40-60%
celkové doby spojení. Během ticha se tedy nebudou přenášet RTP pakety a u příjemce se zapne
generování šumu CNG (Comfort Noice Generator). Princip aktivace a deaktivace SS je založena na
překročení prahových úrovní odstupu signálu od šumu, pokud se detekuje úroveň signálu
setrvávající stanovený čas pod či nad prahovou úrovní, tak se aktivuje či deaktivuje SS. V praxi je
ovšem zkušenost taková, že funkce VAD může způsobovat ořezávání prvních slabik slov po
odmlkách, jelikož aktivace je záležitostí typicky cca 20 ms, funkce VAD proto není používána při
broadband konektivitě. Cisco IOS má pro aktivaci a deaktivaci jednoduché příkazy , a to VAD a no
VAD, pokud ovšem není použita G.729B či G.723.1, potom je VAD součástí kodeku a funkce se
nedá řídit.
24
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.
25
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:
 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ě vyvíjený standard.
2.2 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),
26
 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,
27
 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.
28
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ředešlé 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
29
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
30
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é
31
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
32
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
33
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
34

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
definovány zprávy BRQ/BCF/BRJ, což je Bandwidth Request/Confirm/Reject. Pro ukončení hovoru
35
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
36
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).
37
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.
38
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.
39
Tab. 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.
Signalizace v módu GRC může být tedy provozována následovně:
40
 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.
41
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.
42
3 Hlasové brány
3 Hlasové brány
Ideálním stavem pro IP telefonii by bylo využívání pouze VoIP technologie, ale jelikož v roce
2013 bylo na světě IP telefonie přes 7 mld. telefonních čísel fungujících na jiné technologiee (v roce
2000 to bylo 2,5 mld.), tak j nutné zajistit interoperabilitu se stávajícími telefonními sítěmi. Například
v roce 2013 bylo v ČR cca 500 tis. IP telefonů, 13 mil. mobilních telefonů a cca 3 mil. telefonních
čísel na pevných linkách (převážně podniková telefonie).
Signalizace v PSTN
Signalizace se dělí na účastnickou, síťovou a vnitřní, rozdělení je dle místa použití, viz. obr. 3.1,
S postupem vývoje se sjednotila nejdříve vnitřní se síťovou signalizací (u SS7 se je vnitřní a síťová
identická) a následně i účastnická (pokud je používána IP telefonie jak pro trunk tak pro účastníka,,
tak veškerou signalizaci může přenášet jeden protokol, např. SIP) a dělení je již pouze logické. V
současné době jsou používány v sítích s propojováním kanálů následující typy signalizací:
 smyčková (loop) na analogových přípojkách,

 digitální účastnický signalizační systém č.1 (DSS1) na ISDN účastnických přípojkách,
 signalizační systém č.7 (SS7) na ISDN propojích spojovacích systémů.
 SIP u IP telefonů a u SIP trunků
Obr 3.1 Dělení signalizace dle místa použití.
43
3 Hlasové brány
V sítích pobočkových ústředen jsou používány navíc ještě další typy signalizací, se kterýma se
setkáme v podnikových sítích:
 Q-signalizace (QSIG) se používá pro vzájemné ISDN propojení pobočkových ústředen [v44] ,
 EM signalizace se používá pro analogové propojení PBX různých výrobců.
 u IP telefonie v případ PBX Asterisk se může použít IAX trunk při propojení PBX a rovněž pro
IAX IP telefon
3.1.1 Siťová signalizace v digitálních sítích
Ve veřejné síti je od roku 1997 pro propojení spojovacích systémů použit signalizační systém č.7.
Architektura sítě signalizačního systému č.7 (SS7) se skládá ze třech základních komponentů:
 SSP (Signal Switching Point),

 STP (Signal Transfer Point),
 SCP (Signal Control Point).
Obr 3.2 Signalizační síť SS7.
SSP jsou koncové body sítě, ve kterých vznikají požadavky na spojení a kam jsou zároveň tyto
požadavky terminovány. STP jsou tranzitní body, které směrují zprávy SS7 a rozdělujeme je do třech
úrovní:
 National Signal Transfer Point (národní),

 International Signal Transfer Point (mezinárodní),
 Gateway Signal Transfer Point (protokolové brány).
Jednotlivé komponenty SS7 sítě jsou propojeny do struktury vytvářející signalizační síť, viz.
obrázek níže.
44
3 Hlasové brány
Uvedeme si vybrané vybrané signalizační zprávy SS7:
 IAM (Initial Address Message) – Tato zpráva se používá pro inicializaci hovorového spojení.
Mimo informace o čísle volaného obsahuje další parametry týkající se např. typu spojení, zda
je použito potlačení echa,
 ACM (Address Complete Message) – Zpráva je posílána v opačném směru
 než IAM a indikuje, že hovor je zpracováván, například účastník je vyzváněn.
 ANM (Answer Message) – Zpráva indikující přijmutí hovoru,
 CPG (Call Progress Message) – Tato zpráva slouží k informování vzdálené
 strany (ústředny) o nějaké události týkající se hovoru,
 REL (Release Message) – Zpráva informující o ukončení hovoru,
 RLC (Release Komplete Message) – Tato zpráva se posílá jako potvrzení o ukončení hovoru
a uvolnění spojovací cesty.
3.1.2 Účastnická signalizace v digitálních sítích
Jako účastnická signalizace se v ISDN používá DSS1, a to jak pro připojení koncových terminálů,
tak pro připojení pobočkových ústředen pomocí BRI či PRI přípojek. Základní přístup je označován
jako BRI (Basic Rate Interface) a má sktrukturu 2B + D, kde B je informační kanál s užitečnými daty o
rychlosti 64 kbit/s a D je signalizační kanál 16 kbit/s. Primární přístup je označován jako PRI (Primary
Rate Interface) a má strukturu 30B + D, kde D má rychlost 64 kbit/s a používá se klasický 32
kanálový multiplex s připojením na metalickém rozhraní dle ITUT G.703 (2.048 kbit/s).
Uvedeme si vybrané signalizační zprávy DSS1:
 SETUP (Sestavování volání), žádost o sestavení spojení. Při blokové volbě obsahuje zpráva
všechny potřebné informace pro spojení, při postupném vysílání volaného čísla zpráva
obsahuje jen část nebo žádné adresné informace,
 SETUP ACKNOWLEDGE (Potvrzení sestavování volání), potvrzení zprávy SETUP, pokud je
volba neúplná,
 CALL PROCEEDING (Sestavování spojení), ústředna již nepotřebuje další informace pro
spojení, probíhá sestavování spojení,
 ALERTING (Vyzvánění), spojení bylo vybudováno k požadovanému cíli, volaný terminál je ve
stavu přijmout volání, tj. vyzvání
 CONNECT (Propojení), příchozí volání bylo volaným terminálem přijato (vyzvednutí), B kanál
byl propojen,
 CONNECT ACKNOWLEDGE (Potvrzení propojení), potvrzení zprávy CONNECT, spojení
bylo navázáno,
 DISCONNECT (Rozpojení), výzva k rozpadu spojení (zavěšení),
 RELEASE (Vybavení), odpověď na DISCONNECT, uvolnění B kanálu a požadavek na
uvolnění Call Reference,
 RELEASE COMPLETE (potvrzení vybavení), potvrzení RELEASE, uvolňuje se Call
Reference, což je jedinečný identifikátor spojení,
 INFORMATION (Informace), pomocí této zprávy se přenášejí informace mezi terminálem a
ústřednou (např. volba),
45
3 Hlasové brány
 PROGRESS (Sestavování spojení s jiným účastníkem), označuje určitou fázi výstavby

spojení a oznamuje, že další signalizace je již v B kanále realizována (např. oznamovací tón),
 FACILITY (Schopnost), terminál nebo ústředna vyžaduje pro existující spojení doplňkovou
službu.
3.2 Vlastnosti hlasové brány
Hlasová brána VoGW (Voice Gateway) je klíčovou částí služeb IP telefonie, neboť umožňuje
spojení mezi telefonní a paketovou sítí, to znamená, že provádí veškerý nezbytně nutný fyzický
překlad a hlasovou kompresi a tím dovoluje volání mezi těmito dvěma prostředími. Brány s
analogovým rozhraním mohou obsahovat jednak rozhraní U s moduly FXS a FXO a jednak rozhraní
EM. Digitální brány budou mít většinou jeden z ISDN přístupů, a to BRI nebo PRI, výjimečně se
může vyskytnout i některá starší CAS signalizace na PCM 30/32. Uveďme si charakteristiku brány:
 počet současně realizovatelných hovorů s daným kodekem, tato výkonnost je ovlivněna nejen
SW, ale hlavně typem a počtem DSP, některé GW mají modulární koncepci DSP (dají se
přidávat),
 podporovaná rozhraní a jejich počet,
 podporované signalizace na straně telefonní sítě a IP sítě,
 způsob konfigurace brány a její dohled (např. podpora CLI, webový přístup, dohled SNMP,
podpora RADIUS, atd...),
 zábrana echo (výkonnější je pochopitelně HW implementace echo-cancellation).
Echo v hovoru vzniká nežádoucím odrazem hovorového signálu zpět k hovořícímu účastníkovi a
negativně ovlivňuje kvalitu, jelikož ozvěny vlastních slov působí pro hovořícího rušivě. Echo vzniká
ze dvou základních příčin, které jsou i důvodem pro rozdělení na akustické a elektrické echo.
Akustické echo vzniká částečným přenosem signálu ze sluchátka zpět do mikrofonu na straně
naslouchajícího účastníka a nejčastěji vzniká u mobilních, bezdrátových telefonů a při hlasitém
příposlechu. Typicky je známé zavazbení signálu, které vede až k rozpískání, pokud je IP telefon
tvořen počítačem s reproduktory a stojánkovým mikrofonem. Tento typ echa není tak významný,
jelikož se s ním velmi dobře vypořádají echokancelátory (potlačovače echa), které pracují s algoritmy
eliminujícími jeho vliv.
Elektrické echo vzniká nevyvážeností telefonní vidlice přechodu 4-dr. vedení na 2-dr., typicky je
to v místech napojení analogových telefonních přístrojů. Na vyvážení telefonní vidlice se podílí
kvalita řešení vidlice a vyvažovače, vlastnosti přípojného vedení (účastnické vedení může mít i pár
metrů, ale i přes deset km) a impedance přístroje (teoreticky 600 Ω). Echo vzniká na straně
naslouchajícího účastníka, ale negativně se projeví u hovořícího, teoreticky je možné i echo echa
(druhý odraz hovoru), který ovšem v praxi není znám. Elektrické echo nemůže vznikat na částech
spojení, které mají povahu 4-dr.
Pokud se odražený signál vrací do 25 ms, tak hovor neovlivňuje a pro člověka se zdá přirozené,
se vzrůstajícím časem se zvyšuje negativní vliv na hovor, který závisí pochopitelně i na úrovni
46
3 Hlasové brány
vracejícího se signálu TELR, což je míra hlasitosti ozvěny na straně hovořícího (Talker Echo
Loudness Rating).
Většina GW umí generovat záznamy o spojení CDR a předávat je (např. pomocí RADIUS
protokolu), vždyť přes GW odchází hovory do veřejné telefonní sítě, kde je spojení spojeno s
nějakým poplatkem. Call Detail Record (CDR) je detailní záznam volání obsahující nejčastěji tyto
informace:
 identifikace volajícího,
 identifikace volaného,
 začátek hovoru,
 délka hovoru,
 identifikace vedení či poskytovatele (operátora).
Případně mohou CDR obsahovat další informace, kterými jsou:
 identifikace tranzitu spojení (přes které body spojení šlo),

 bližší identifikace vedení (adresa pro trunk),
 počet použitých kanálů,
 délka vyzvánění,
 identifikace služby (voice, fax, data),
 kód volání(soukromý, služební),
 identifikace PINem,
 typ PINu,
 autorizace,
 délka vyzvánění,
 příčina rozpadu spojení.
CDR záznamy se obvykle ukládají v databázích, jejich zpracování je závislé na typu použité
technologie, v případě klasických PBX jsou dočasně uchovávány v pamětech (flash, HDD ...) a
vyčítány v intervalech přes sériové rozhraní nebo pomocí IP.
Jelikož se pomocí GW realizuje propojení často s veřejnými telekomunikačními sítěmi, tak je

nutné splňovat pravidla číslování, ty jsou stanovena číslovacím plánem a v digitálních sítích se řídí
dle ITU-T E.164. V ITU–T E.164 (The international public telecommunication numbering plan) je
doporučení obsahující specifikaci mezinárodního veřejného číslovacího plánu telekomunikační sítě.
Struktura geografických čísel má následující části:
 CC: Country Code (kód země),

 NDC:National Destination Code (směrové číslo oblasti),
 SN:Subscriber Number (účastnické číslo).
CC může být 1-3 místné číslo a CC + NDC + SN může být max. 15-ti místné číslo. Struktura
geografických čísel má dvě možnosti:
47
3 Hlasové brány
 první možnost, oddělené NDC a SN,

 druhá možnost, spojené NDC a SN, což znamená že národní účastnické číslo obsahuje obě
části.
3.2.1 Modul FXS
Modul FXS (Foreign Exchange Station) poskytuje připojení na účastnickém rozhraní U se

smyčkovou signalizací, umožňuje DTMF volbu dle doporučení ITU-T Q.23. Modul FXS pracuje v
režimu analogové účastnické sady, na rozhraní lze připojit přímo telefonní přístroj. V případě
připojení pobočkové ústředny (dále jen PBX) se linka přivádí na port karty státního přenašeče
standardně používaného pro připojení státní linky. Provozovat modul lze i obousměrně, ale v
příchozím směru není možné provolení do ústředny až na pobočku, což je dáno typem použité
signalizace.
Pokud konkrétní PBX umožňuje DISA provolbu, lze pomocí pseudoprovolby dosáhnout až
provolení na konkrétní pobočku ústředny. V případě potřeby je možné modifikovat řadu parametrů,
např. impedanční přizpůsobení, generování šumu, zisk na vstupu, útlum na výstupu, potlačení
ozvěny, dobu čekání na volbu čísla, čas mezi volbou čísel apod.. V případě připojení PBX je odchozí
provoz z PBX bez omezení, v případě příchozího volání je možné předat hovor na konkrétní
pobočkovou linku např. přes spojovatelské pracoviště. DISA se někdy se označuje jako
"pseudoprovolba". Umožňuje automatické vyzvednutí příchozího hovoru a výběr volané pobočky
pokračováním ve volbě čísla. Po vyzvednutí hovoru je obvykle volajícímu přehrána hlasová zpráva a
nabídnuta možnost přepojení. DISA se používá v PBX, které nemají DDI (Direct Dialing In - provolba)
a jsou připojeny analogovou státní linkou. V těchto PBX je při příchozím volání možnost buď nechat
vyzvánět volání na určené pobočce a nebo použít DISA provolbu.
Obr. 3.3 Modul VIC/FXS ve směrovači Cisco.
3.2.2 Modul FXO
Modul FXO (Foreign Exchange Office) pracuje v režimu analogového přístroje. Na rozhraní lze
připojit např. státní tel. linku nebo analogovou linku pobočkové ústředny. Problémy s ukončením
hovoru, např. u prvních FXO modulů Cisco, mohou vzniknout při připojení většiny evropských
48
3 Hlasové brány
ústředen. Komplikace způsobuje signalizační značka Kewl-start (označováno taky jako Power denial
nebo Battery drop), jedná se o přerušení napájení při ukončení hovoru inicializované účastnickou
sadou. Zmiňovaná značka není v ČR a ve většině evropských zemích vyžadována a řešení problému
při zavěšení spočívá ve vyhodnocení kontrolních tónů modulem FXO.
3.2.3 Modul EM
V případě VoIP brány s modulem E&M se jedná o analogové rozhraní pro připojení PBX s
oddělenou hovorovou a signalizační částí. Pro hovor se používá dvoudrátová nebo i čtyřdrátová
cesta s možností odděleného nastavení přijímacích/vysílacích útlumů/zesílení na delších trasách. Z
nabízených signalizačních zapojení na straně GW je vzhledem k univerzálnosti nejvhodnější vybrat
verzi č. 5. (negativní logika). Rozhraní pracuje s trvalou EM linkovou signalizací a je doplněné DTMF
registrovou signalizací. Pro vlastní EM linkovou signalizaci je nejvhodnější zvolit signalizaci US-WINK
doplněnou o DTMF volbu, neboť s touto signalizací jsou nejlepší zkušenosti. US-WINK má
následující výhody:
 rychlé a spolehlivé navázání spojení mezi GW a PBX,

 při zahájení komunikace se posílá značka WINK, po které následuje DTMF volba,
 značka přihlášení je přijata po přihlášení volaného a následně se propojují hovorové cesty a
nedochází k tarifování před přihlášením, což je důležité u tranzitních volání.
Výhoda E&M modulu oproti FXS spočívá v možnosti technicky neomezené obousměrné
komunikace, tzn. provolení na pobočku ústředny v příchozím volání a na rozdíl od FXS je přenášena
IP sítí značka přihlášení, tzn. u tranzitního hovoru nemůže dojít k zahájení tarifování během
vyzvánění.
Doporučené nastavení:
 signalizační zapojení č. 5 , mezinárodní varianta,

 signalizace US WINK (případně Delay dial nebo Immediate-start),
 pro volbu DTMF (případně pulzní),
 zapojení hovorové části 2-drát (případně čtyřdrát).
V příchozím i odchozím provozu je spojení bez omezení s možností provolení až na pobočkovou

linku, přičemž identifikaci volajícího rozhraní neumožňuje.
3.2.4 Moduly ISDN
Modul BRI/ISDN a PRI/ISDN umožňuje obousměrný provoz s provolbou a identifikací čísla

volajícího CLIP (Calling Line Identification Presentation). Číslo volajícího bude transparentně
přeneseno sítí IP a na digitálních přístrojích zobrazeno během vyzvánění. Provoz v odchozím i
příchozím směru je při připojení PBX bez omezení s možností zobrazení CLIP a zachycení
identifikace volajícího. Pro odchozí provoz do sítě PSTN/ISDN veřejného telekomunikačního
operátora postačí konfigurace BRI/ISDN v režimu TE [v51].
49
3 Hlasové brány
Doporučené nastavení PRI/ISDN:
 Layer 1, Slave (případně Master), CRC4;

 Procedurou CRC4 (v kanálovém intervalu KI č.0) se kontroluje správné doručení obsahu
rámců a způsobuje automatickou blokaci portů při překročení mezních hodnot chybovosti, pro
hlas je standardní mez BER=10-3. Bez procedury CRC4 dochází k blokaci vedení až při
rozpadu synchronizace (alarmový signál AIS);
 Layer 2, TEI=0;
 Layer 3, signalizace DSS1 (případně QSIG).
Doporučené nastavení BRI/ISDN v režimu NT:
 Layer 1, Master,
 Layer 2, TEI=0, L1/2permanent active,
Doporučené nastavení BRI/ISDN v režimu TE:
 Layer 1, Slave,
 Layer 2, L1/2permanent active,
Signalizační systém QSIG je založen na využití principu komunikačních funkcí a protokolů, které
odpovídají hierarchické struktuře modelu OSI (Open System Interconnection). Je to varianta ISDN
signalizace D kanálu. Základním principem modelu je členění na vrstvy. Funkce jednotlivých vrstev
jsou definovány ve standardech ETS. Pro fyzickou vrstvu L1 platí standard ETS 300 011, pro
linkovou vrstvu standard ETS 300 125 s úpravou pro QSIG ETS 300 170. Pro síťovou a aplikační
vrstvu platí více standardů ETS.
3.3 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.
50
3 Hlasové brány
[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
3.3.1 Globální parametry nastavení
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
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
3.3.2 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).
51
3 Hlasové brány
# interface BRI0/0 /*identifikace rozhraní

# no ip address
# isdn switch-type basic-net3 /* basic-net3 znamená BRI s DSS1
/* basic-qsig znamená BRI s QSIG
# isdn overlap-receiving /* schopnost přijímat číslo po čísle
# isdn protocol-emulate network /* L3 v režimu strany poskytovatele
# isdn layer1-emulate network /* L1/L2 v režimu poskytovatele
# isdn incoming-voice modem /* s příchozím volání je nakládáno jako s modemem
# isdn send-alerting /* bude posílat ALERTING
# isdn sending-complete /* pošle volbu v bloku
# isdn static-tei 0 /* TEI=0 pro konfiguraci Point to Point
# isdn skipsend-idverify /* 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 /* L3 je provozován v režimu strany uživatele

# isdn layer1-emulate user
# no skipsend-idverify /* zašle TEI verifikaci v režimu PMP
3.3.3 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 /* L1 – synchronizace hodin z PCM traktu
anebo # clock source internal /* interní zdroj časování
# pri-group timeslots 1-31
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 /* primary-net5 znamená PRI s DSS1
# isdn overlap-receiving
# isdn not-end-to-end 64 /* přepsání rychlosti, kterou avizuje síť
# isdn protocol-emulate network
# isdn incoming-voice modem
# isdn send-alerting
# isdn sending-complete
A pro stranu uživatele postačí změnit jednu položku.
# isdn protocol-emulate user /* interface operates in user side mode

52
3 Hlasové brány
Č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 /* T302 timer (v ms) vypršení volby

# isdn overlap-receiving terminating-char # /* znak konce volby
# isdn t306 /* časovač rozpadu spojení po odeslání zprávy disconnect

# isdn timer t309 /* 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
3.3.4 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
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 /* použij tento kodek
# session target ras /* v případě GK
nebo # session target ipv4:195.113.222.2 /* cíl je specifikován IP adresou (jiná GW)

53
3 Hlasové brány
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, viz. kapitola 7.3. 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 /* přepsání CPN
nebo # translate-outgoing calling 1 /* 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.
# voice-port 1/0:15 /* the rule placed as a global into voice-port

# translate calling 2
# translate called 4
3.3.5 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
54
3 Hlasové brány
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
3.3.6 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.
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
55
3 Hlasové brány
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
3.4 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
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'
56
3 Hlasové brány
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#
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
57
3 Hlasové brány
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.
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.
58
4 GNU Gatekeeper
4 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 4.1 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.
59
4 GNU Gatekeeper
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
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].
4.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
4.1.1 Základní konfigurace po instalaci
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ý
60
4 GNU Gatekeeper
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
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
4.1.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
61
4 GNU Gatekeeper
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
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
62
4 GNU Gatekeeper
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
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
4.1.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.
4.1.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.
63
4 GNU Gatekeeper
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
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.....
4.1.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:
64
4 GNU Gatekeeper
 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
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ů
65
4 GNU Gatekeeper
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.
 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.
Ukázka syntaxe konfigurace autentizačního pravidla může vypadat následovně:
[Gatekeeper::Auth]
FileIPAuth=required;RRQ,LRQ,Setup
[FileIPAuth]
192.168.1.240=reject
192.168.1.0/24=allow
any=reject
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.
4.1.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

66
4 GNU Gatekeeper
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.*
Obr 4.2 Příklad řešení mechanizmu autentizace a autorizace.
 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.
4.2 byl realizován jako diplomová práce [sir] a řešení přes RADIUS bylo zvoleno z důvodu
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.
4.2 Návrh sítě s konfigurací GnuGK
Návrh topologie je v obr. 4.3, 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. 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. 4.3 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.
67
4 GNU Gatekeeper
Obr 4.3 Návrh topologie H.323 sítě.
# 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
4.2.1 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
68
4 GNU Gatekeeper
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 (*).
[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 7.3. 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
69
4 GNU Gatekeeper
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
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, jedná se opět o popsané nastavení z třetí kapitoly.
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
!
70
4 GNU Gatekeeper
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. 4.4 zobrazuje příklad
mezizónové mezizónovou komunikace (IP adresy jsou odlišné).
Obr 4.4 Mezizónová komunikace.
GK na levé straně obr. 4.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 4.5.
Obr 4.5 Obsah zprávy LRQ.
Odpověď LCF, viz. obr. 4.6 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.
71
4 GNU Gatekeeper
Obr 4.6 Zpráva LCF v mezizónové komunikaci.
72
5 Základy protokolu SIP

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.
5.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
73
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
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:voznak@cesnet.cz
 sip:234680468@cesnet.cz
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 „#”.
74
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 in-
addr.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ů:
 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).
5.2 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ů.
75
5.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.
Žá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.
Obr. 5.1 Rozeslání INVITE více příjemcům.
76
Obr. 5.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].
5.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í
77
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.
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í
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. 5.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:bob@b.com. 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:bob@b.com 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.
78
Obr. 5.2. Sestavení spojení přes dvě SIP Proxy.
5.2.3 SIP Registrar Server
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).
V lokalizační databázi v našem případě došlo k namapování adresy User URI sip:bob@b.com k
adrese Device URI sip:bob@1.2.3.4:5060. Lokalizační databáze je pak užívána Proxy serverem.
Když inbound Proxy server obdrží žádost pro sip:bob@b.com, vyhledá v lokalizační databázi záznam
sip:bob@1.2.3.4:5060 a na danou IP adresu pošle žádost. Registrar server je velmi často pouze jako
logická část SIP serveru, jelikož je těsně svázán s Proxy serverem. Obr. 5.3 znázorňuje typickou SIP
registraci. Zpráva REGISTER je vyslána do Registrar serveru a obsahuje adresu záznamu User URI
sip:bob@biloxi.com a kontaktní adresu Device URI sip:bob@1.2.3.4: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ý.
79
Obr. 5.3. Průběh registrace.
5.2.4 SIP Redirect Server
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. 5.4
Obr. 5.4. Průběh přesměrování.
80
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. 5.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.
5.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ěď.
5.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:0738331699@asterisk.vsb.cz SIP/2.0

Via: SIP/2.0/UDP 158.196.192.32;branch=z9hG4bK9ec4c0248acd48724710d7;rport
From: "SJphone" <sip:7002@asterisk.vsb.cz>;tag=27df31582de
To: <sip:0738331699@asterisk.vsb.cz>
Contact: <sip:7002@158.196.192.32>
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
81
(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:0738331699@asterisk.vsb.cz se nazývá Request URI a obsahuje URI
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).
5.3.2 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í (re-
INVITE);
 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
82
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;
 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í:
 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.
5.3.3 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
83
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:7002@asterisk.vsb.cz>;tag=164235a64f6
To: <sip:1194@asterisk.vsb.cz>;tag=as04503766
Call-ID: 7798248D73F3443CABCD68EE653C791C0x9ec4c020
CSeq: 2 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:1194@158.196.146.12>
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
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é,
84
 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ě
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
85
* 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
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
Obr 5.5 Žádost a odpověď.
86
Na obr. 5.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.
5.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.
Obr. 5.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. 5.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
87
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.
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. 5.7.
Obr. 5.7. Rozdílné zacházení se 100 Trying u stavových transakčních strojů.

88
5.3.5 Dialog
V předchozím kapitole jsme si ukázali dvě transakce, viz. obr. 5.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.
Obr. 5.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);

89
 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í 101-199, 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.
5.3.6 Transakce a dialog v příkladu
Určení transakce a dialogu si můžeme ukázat v následujícím příkladu, který odpovídá obr. 5.9,
jde tedy o žádost INVITE s odpověďmi 100 TRYING, 180 RINGING, 200 OK, dále žádost ACK a
nakonec BYE s odpovědí 200 OK. První zpráva #1 INVITE obsahuje branch=z9hG4bK7225f861 ,
který najdeme ve zprávách #1 INVITE, #2 100 TRYING, #3 180 RINGING a #4 200 OK, tím je
určena první transakce. Zpráva #5 ACK obsahuje branch=z9hG4bK57289016 , čili do první
transakce nepatří a ani novou transakci nevytváří, neboť na tuto žádost není odpověď. Druhá
transakce obsahuje branch=z9hG4bK011c16dd a je tvořena #6 BYE a #7 200 OK. Dialog je určen:
 pomocí tag=as396d4fbf z pole From,

 tag=4227117d4b8 z pole To,
 řetězcem v Call-ID: 1c068e57440c89084bf549466dddfea0@158.196.146.12
Early dialog je vytvořen přijetím #3 180 RINGING a dialog je sestaven přijetím #4 200 OK. Pole
Cseq se v rámci dialogu inkrementuje s každou novou žádostí (výjimkou je ACK), všechny odpovědi
k žádosti mají stejný Cseq, čili lze jednoduše určit, ke které žádosti odpověď patří a rovněž se
snadno rozpoznají retransmise.
#1 INVITE
Request-Line: INVITE sip:7002@158.196.192.32 SIP/2.0
Via: SIP/2.0/UDP 158.196.146.12:5060;branch=z9hG4bK7225f861;rport
From: "5779" <sip:5779@158.196.146.12>;tag=as396d4fbf
To: <sip:7002@158.196.192.32>
Contact: <sip:5779@158.196.146.12>
Call-ID: 1c068e57440c89084bf549466dddfea0@158.196.146.12
CSeq: 102 INVITE
Max-Forwards: 70
Content-Length: 422
(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 14252 RTP/AVP 0 8 3 18
90

(a): rtpmap:18 G729/8000
#2 100 TRYING
Status-Line: SIP/2.0 100 Trying
Via: SIP/2.0/UDP 158.196.146.12:5060;branch=z9hG4bK7225f861;rport=5060
To: "SJphone" <sip:7002@158.196.192.32>
CSeq: 102 INVITE
Content-Length: 0
Server: SJphone/1.65.377a (SJ Labs)
#3 180 RINGING
Status-Line: SIP/2.0 180 Ringing
To: "SJphone" <sip:7002@158.196.192.32>;tag=4227117d4b8
Contact: <sip:7002@158.196.192.32>
CSeq: 102 INVITE
Content-Length: 0
#4 200 OK
Contact: <sip:7002@158.196.192.32>
CSeq: 102 INVITE
Content-Length: 274
(v): 0
(o): - 3428314846 3428314846 IN IP4 158.196.192.32
(s): SJphone
(c): IN IP4 158.196.192.32
(t): 0 0
(m): audio 49152 RTP/AVP 0
#5 ACK
Request-Line: ACK sip:7002@158.196.192.32 SIP/2.0
Via: SIP/2.0/UDP 158.196.146.12:5060;branch=z9hG4bK57289016;rport
To: <sip:7002@158.196.192.32>;tag=4227117d4b8
Contact: <sip:5779@158.196.146.12>
91
CSeq: 102 ACK

Max-Forwards: 70
Content-Length: 0
#6 BYE
Request-Line: BYE sip:7002@158.196.192.32 SIP/2.0
Via: SIP/2.0/UDP 158.196.146.12:5060;branch=z9hG4bK011c16dd;rport
To: <sip:7002@158.196.192.32>;tag=4227117d4b8
CSeq: 103 BYE
Max-Forwards: 70
Content-Length: 0
#7 200 OK
Via: SIP/2.0/UDP 158.196.146.12:5060;branch=z9hG4bK011c16dd;rport=5060
Contact: <sip:7002@158.196.192.32>
CSeq: 103 BYE
Content-Length: 0
5.3.7 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 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á.
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.
92
Tab. 5.1 Časovače dle RFC 3261.
5.3.8 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
93
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.
5.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:voznak@vsb.cz může být device URI
sip:voznak@158.196.81.205: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
94
Contact: <sip:voznak@195.168.1.10;rinstance=45b13194f4a07bb>;expires=0
To: "voznak"<sip:voznak@cesnet.cz>
From: "voznak"<sip:voznak@cesnet.cz>;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.
Obr. 5.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á
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. 5.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:voznak@cesnet.cz>;tag=c10ed4fff3e6fb17efd0bfbdcce87ce2.10f8
From: "voznak"<sip:voznak@cesnet.cz>;tag=f861ac5a
95
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:voznak@195.168.1.10:18188;rinstance=8546638886339213>
To: "voznak"<sip:voznak@cesnet.cz>
From: "voznak"<sip:voznak@cesnet.cz>;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.
5.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.
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. 5.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.
96
Obr. 5.10. Tok SIP zpráv v rámci SIP Proxy
5.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. 5.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:bob@pc42.cs.columbia.edu . 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
čtyři záznamy ve Via, viz. obr. 5.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.
97
Obr. 5.11. Směrování žádostí a odpovědí.
5.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:alice@atlanta.com) volá Boba z jiné domény (sip:bob@biloxi.com). 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. 5.12. Následně se podíváme do hlaviček SIP zpráv
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.
98
Obr. 5.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).
INVITE sip:bob@biloxi.com SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
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).
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
99
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.
INVITE sip:bob@biloxi.com SIP/2.0

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ě jako v
předchozím kroku je přidán parametr received do Via.
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:bob@atlanta.com. 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 Max-
Forwards, zbytek hlavičky nemění.
INVITE sip:bob@192.0.2.4 SIP/2.0

Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
Max-Forwards: 68
CSeq: 314159 INVITE
100
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:bob@biloxi.com>;tag=a6c85cf
Contact: <sip:bob@192.0.2.4>
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
Contact: <sip:bob@192.0.2.4>
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
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ý
101
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:bob@192.0.2.4 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:alice@pc33.atlanta.com SIP/2.0

Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
Max-Forwards: 70
From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
To: Alice <sip:alice@atlanta.com>;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:bob@biloxi.com>;tag=a6c85cf
To: Alice <sip:alice@atlanta.com>;tag=1928301774
CSeq: 314160 BYE
Content-Length: 0
5.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 .
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>
102
Obr. 5.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
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.
103
5.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> <connection-
address>,
 b=* (bandwidth information), informace o využívaném pásmu,
 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>,
104
 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:
 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).
5.6.1 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]
 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]
105
 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:7002@158.196.192.32 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:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:97 iLBC/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=silenceSupp:off - - - -
m=video 15014 RTP/AVP 34
a=rtpmap:34 H263/90000
106
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
5.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
odpověď 500 Server Internal Error na přijatý druhý INVITE a do hlavičky odpovědi přidat pole Retry-
After s náhodně zvolenou hodnotou v rozsahu 0 až 10. Jestliže UAS dostane INVITE v dialogu, v
107
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.
108
6 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í.
6.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. 6.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 non-
100 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.
109
6.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. 6.1 Uplatnění PRACK při propojení s PSTN.
110
6.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.
6.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.
111
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. 6.2 Příklad použití UPDATE.
V příkladu, viz. obr. 6.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.
112
6.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. 6.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:alice@atlanta.example.com
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. 6.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.
113
Message One (F1)

REFER sip:b@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK2293940223
To: <sip:b@atlanta.example.com>
From: <sip:a@atlanta.example.com>;tag=193402342
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 93809823 REFER
Max-Forwards: 70
Refer-To: (whatever URI)
Contact: sip:a@atlanta.example.com
Content-Length: 0
Message Two (F2)

SIP/2.0 202 Accepted
Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK2293940223
To: <sip:b@atlanta.example.com>;tag=4992881234
From: <sip:a@atlanta.example.com>;tag=193402342
CSeq: 93809823 REFER
Contact: sip:b@atlanta.example.com
Content-Length: 0
Message Three (F3)

NOTIFY sip:a@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9922ef992-25
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
CSeq: 1993402 NOTIFY
Max-Forwards: 70
Event: refer
Subscription-State: active;expires=(depends on Refer-To URI)
Contact: sip:b@atlanta.example.com
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.
6.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
114
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. 6.4 je příklad
odeslání žádosti MESSAGE přes Proxy.
Obr. 6.4 Použití žádosti MESSAGE.
Obsah žádosti MESSAGE je zobrazen níže, zpráva je zaslána jako text.
MESSAGE sip:user2@domain.com SIP/2.0

Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse
Max-Forwards: 70
From: sip:user1@domain.com;tag=49583
To: sip:user2@domain.com
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 18
Watson, come here.
6.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:
115
 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).
Obr. 6.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
116
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. 6.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.
Obr. 6.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)

presentity@example.com s expirací 3600 sekund, což je první zpráva M1.
SUBSCRIBE sip:presentity@example.com SIP/2.0

Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds7
To: <sip:presentity@example.com>
From: <sip:watcher@example.com>;tag=12341234
Call-ID: 12345678@host.example.com
CSeq: 1 SUBSCRIBE
Max-Forwards: 70
Expires: 3600
Event: presence
Contact: sip:user@host.example.com
Content-Length: 0
EPA posílá aktualizaci informací na PA pomocí PUBLISH, což je zpráva M5.
PUBLISH sip:presentity@example.com SIP/2.0

Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge
To: <sip:presentity@example.com>
From: <sip:presentity@example.com>;tag=1234wxyz
Call-ID: 81818181@pua.example.com
117
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:user@host.example.com SIP/2.0

Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK4cd42a
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@host.example.com
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.
6.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,
118
 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.
6.7 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. 6.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. 6.7 by se dala pochopitelně vylepšit o
PRACK, který byl už rozebrán v předchozích kapitolách.
119
6.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. 6.8
Obr. 6.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. 6.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í
120
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.
6.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.
INVITE sip:alice@u1.atlanta.ex.com SIP/2.0

From: Bob <sip:bob@biloxi.ex.com>;tag=b-tag
To: Alice <sip:alice@atlanta.ex.com>;tag=a-tag
Call-ID: ab-cid
CSeq: 1 INVITE
Contact: <sip:bob@u2.biloxi.ex.com>
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:bob@biloxi.ex.com>;tag=b-tag
To: Alice <sip:alice@atlanta.ex.com>;tag=a-tag
Call-ID: ab-cid
CSeq: 1 INVITE
Contact: <sip:alice@u1.atlanta.com>
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
121
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í.
6.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. 6.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. 6.9 Přidržení hovoru s hudbou
6.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.
122
Obr. 6.10 Předání hovoru pomocí INVITE
Na obr. 6.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. 6.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.
123
Obr. 6.11 Předání hovoru pomocí REFER
6.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).
124
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. 6.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.
Obr. 6.12 Přesměrování při obsazení - CFWB
6.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. 6.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
125
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.
Obr. 6.13 Oznámení o zanechání vzkazu - MWI
6.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
rd
( 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
126
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. 6.14.
Obr. 6.14 Vytočení kliknutím – CTD
127
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í.
6.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. 6.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:bob@example.org SIP/2.0

To: <sip:bob@example.org>;
From: <sip:alice@example.org>;tag=2222
Call-ID: 123456@phone.example.org
CSeq: 1 SUBSCRIBE
Contact: <sip:alice@example.org >
Event: call-completion
Expires: 3601
128
Obr. 6.15 Zpětné volání při obsazení
6.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:poynting@mason.edu.uk SIP/2.0

Via: SIP/2.0/UDP cavendish.kings.cambridge.edu.uk
;branch=z9hG4bK24555
Max-Forwards: 70
To: John Poynting <sip:nting@mason.edu.uk> ;tag=3432
From: J.C. Maxwell <sip:james.maxwell@kings.cambridge.edu.uk>
;tag=432485820183
Call-ID: e71facaa7f7c0a29276054fe4951a9b6
Content-Type: application/ISUP
129
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.
130
7 Využití DNS pro IP telefonii

Jak už napovídá název kapitoly, budeme se zabývat využitím systému doménových jmen (DNS)
pro IP telefonii, popíšeme si používané typy záznamů a jejich funkci. V předchozí kapitole jsme se
věnovali SIP protokolu, obsahuje-li cílová URI adresu mimo vlastní doménu a INVITE byl odeslán na
domácí SIP Proxy, tak existují dvě možnosti, jak tato SIP Proxy zjistí, kam má INVITE odeslat. První
možností je existence záznamu pro daný cíl v lokalizační databázi, tzn. má staticky mapovanou
cílovou doménu na konkrétní stroj, na němž cílová SIP Proxy běží. Druhá možnost spočívá v dotazu
do DNS a pro tento účel se používají SRV záznamy specifikující umístění služby.
7.1 SRV záznamy
DNS obsahuje specifické informace o dostupných službách ve formátu dle RFC 2782 z roku
2000. SRV záznamy umožňují pro jednu doménu použít několik serverů pro konkrétní službu. SRV
obsahuje informace o specifické službě pro doménu a umožňuje nastavit i prioritu. SRV záznam
poskytuje následující informace:
 Service, symbolické jméno požadované služby,

 Protocol, obvykle TCP nebo UDP,
 Domain name, název domény pro níž je záznam platný,
 TTL, doba života záznamu, např. 43200 sec. (cache drží záznam 12 hod. ),
 Class: pole pro třídu (vždy IN),
 Priority: priorita pro cíl, nižší číslo bude dřív vybráno,
 Weight: váha priority záznamu, při více spojení se stejnou prioritou je brána dříve v potaz
vyšší váha,
 Port: TCP nebo UDP port, na kterém je služba dostupná,
 Target: název stroje FQDN poskytujícího službu.
_sip._udp.cesnet.cz 43200 IN SRV 100 10 5060 cyrus.cesnet.cz
Výše uvedený příklad záznamu dostaneme, pokud se dotážeme na stroj, který poskytuje službu
SIP na UDP v doméně cesnet.cz, v Linuxu zadáme příkaz:
host -t SRV _sip._udp.cesnet.cz
131
Z odpovědi se dozvíme, že SIP na UDP v doméně cesnet.cz je to stroj cyrus.cesnet.cz na portu

5060. Pochopitelně obdobný záznam můžeme mít pro TCP. Nakonec pro jednu službu můžeme mít i
více záznamů s různou prioritou, což je užíváno pro zvýšení dostupnosti a zachování funkčnosti
služby v případě poruchy některého z poskytovatelů služby, jedním slovem survivability. SRV
záznam můžeme použít i pro UA, aby našel poskytovatele služby v doméně, což nám zjednoduší
konfiguraci SIP telefonu, zadáme uživatelské jméno, heslo a doménu, poskytovatele služby si UA
najde sám v DNS.
_sip._tcp.biloxi.com IN SRV 10 0 5060 ser.biloxi.com.

_sip._udp.biloxi.com IN SRV 10 0 5060 ser.biloxi.com.
_sips._tcp.biloxi.com IN SRV 10 0 5061 ser.biloxi.com.
_sip._tls.biloxi.com IN SRV 10 0 5061 ser.biloxi.com.
7.2 NAPTR záznamy
NAPTR (Naming Authority Pointer Record) je poměrně novým typem záznamu. Původní RFC
2915 (The Naming Authority Pointer DNS Resource Record) je z roku 2000 a novější RFC je 3404
(The Uniform Resource Identifiers Resolution Application) z roku 2002. NAPTR je typ DNS záznamu,
který podporuje regulární výrazy, mohou být tak použity sofistikované přepisovací pravidla.
Odpovídající záznam v DNS pro ENUMU je předepsán ve tvaru:
IN NAPTR order pref “u“ “E2U+enumservice“ “regexp replacement“ .
Tvar obsahuje pořadí (order), upřednostnění (pref), označení „u“ (flag) znamená, že výstupem
bude URI požadované služby a nakonec aplikující se regulární výraz (regexp) a nahrazení
(replacement). Výsledkem aplikace regulárního výrazu je URI adresa pro konkrétní službu.
NAPTR mohou být použity i pro směrování servisních záznamů SRV, viz. RFC 3263 (Locating
SIP Servers). NAPTR záznamy nasměrují SIP požadavek pro doménu iptel.biloxi.com na záznamy
SRV, kde protokol TCP má vyšší prioritu (menší číslo znamená vyšší prioritu).
iptel.biloxi.com. IN NAPTR 90 50 "s" "SIP+D2T" _sip._tcp.iptel.biloxi.com.

iptel.biloxi.com. IN NAPTR 100 50 "s" "SIP+D2U" _sip._udp.iptel.biloxi.com.
SRV záznamy už ukazují na konkrétní SIP server.
_sip._tcp.iptel.biloxi.com. IN SRV 0 1 5060 sip.iptel.biloxi.com.

_sip._udp.iptel.biloxi.com. IN SRV 0 1 5060 sip.iptel.biloxi.com.
SRV nám vyřeší lokalizaci služby v doméně, ale problém máme s telefonními čísly, protože SIP
URI je vázáno na doménu a pokud bychom nahradili položku username telefonním číslem, tak stále
řešíme, jak se dovolat mimo svou doménu anebo přesněji, jak zjistit, která SIP Proxy obslouží volání
na žádané číslo. S tímto úkolem si výtečně poradil mechanizmus ENUM (tElephone NUmber
132
Mapping) . Standard ENUM přináší mapování telefonních čísel E.164 na jmenné identifikátory URI. V
jmenném serveru může záznam vypadá následovně:
$ORIGIN 5.3.4.2.2.0.2.4.e164.arpa.
IN NAPTR 100 50 "u" "E2U+h323" "!^\\+420(.*)$!h323:\\1@cesnet.cz!" .
IN NAPTR 200 50 "u" "E2U+sip" "!^\\+420(.*)$!sip:\\1@cesnet.cz!" .
IN NAPTR 300 50 "u" "E2U+smtp" "!^(.*)$!mailto:info@cesnet.cz!“ .
Odpověď je rozdělena do dvou polí oddělených vykřičníky, v ukázce je :
 Regulární výraz. který je odstartován symbolem ^ a ukončen $, výraz v prvním poli mezi
dvěma vykřičníky \\+420(.*) představuje všechna čísla nacházející se za +420
 nahrazení (replacement) je v druhém poli vyjádřen dosazením získaného výrazu z prvního
pole \\1 do URL, v případě třetího záznamu se vždy vrátí mailto:info@cesnet.cz
Dotazující SIP UA převede +420224352979 na 9.7.9.2.5.3.4.2.2.0.2.4.e164.arpa a odešle do

DNS, pro tento dotaz v DNS odpovídá zóna 5.3.4.2.2.0.2.4.e164.arpa , z odpovědí si SIP UA vybere
službu si E2U+sip a aplikováním regulárního výrazů získá SIP URI sip:224352942@cesnet.cz,
pomocí SRV záznamů zjistí, že stroj obsluhující SIP v doméně cesnet.cz je cyrus.cesnet.cz a na ten
bude odeslán INVITE.
Posledním krokem v DNS by bylo dohledání A nebo AAAA záznamu odpovídající danému
doménovému jménu. Vidíme, že pro SIP běžně využijeme v DNS následující záznamy : NAPTR,
SRV, A a AAA.
ENUM definuje E2U pro službu, která je očekávána pro:
 SIP jako E2U+sip, např. s URI sip: voznak@cesnet.cz,

 H.323 jako E2U+h323, např. s URI h323:voznak@cesnet.cz,
 Internet FAX jako E2U+ifax, např. s URI mailto:fax@fax.vsb.cz,
 Telephone jako E2U+tel, např. s URI tel:+596991699:svc=voice,
 Fax jako E2U+fax:tel, např. s URI tel:+596991699:svc=fax,
 Email jako E2U+email:mailto, např. s URI mailto:miroslav.voznak@vsb.cz,
 Web jako E2U+web:http, např. s URI http://www.vsb.cz .
7.3 ENUM – mapování E.164 a URI
ENUM je most mezi číselnými identifikátory telefonních sítí definovaných v ITU-T E.164 a
jmennými identifikátory URI uloženými v záznamech DNS a užívanými v Internetu. V roce 2000 byl
ENUM poprvé popsán v RFC 2916, jeho autorem byl švédský inženýr Patrik Fältström, novější verze
je v RFC 3761 z dubna roku 2004. Pro ENUM se užívá TLD doména e164.arpa a ta je delegována
se souhlasem zástupce státu v ITU-T na organizaci, která se stává správcem národní domény. V
případě ČR je to doména 0.2.4.e164.arpa a správcem této domény je od roku 2003 sdružení CZ.NIC.
První část služby ENUM tvoří čísla ITU-T doporučení E.164, za tímto účelem byla v ITU-T založena
133
studijní skupina (SG2), která pracuje na administrativních postupech týkajících se služby ENUM.
Druhou část vytváří organizace IETF, kde tato služba vznikla a spočívá v začlenění tohoto standardu
do struktury systému doménových jmen DNS. V souvislosti s IP telefonní je hlavním cílem ENUM
zprostředkovat identifikaci a adresovat klienta služby přes internet na základě univerzálního
identifikátoru, kterým je telefonní číslo.
Pro tento účel se v DNS používají záznamy NAPTR (Naming Authority Pointer) a dotaz do DNS
musí přijít ve vhodném formátu
 z čísla v mezinárodním formátu se odstraní nenumerické znaky,

 mezi číslice se vloží tečky,
 celý řetězec se zapíše v opačném pořadí,
 a nakonec se přidá .e164.arpa.
Uživatel vytočí 596991699 a odesílá se řetězec 9.9.6.1.9.9.6.9.5.0.2.4.e164.arpa, o

naformátování se postaral buď sipový klient (SIP UA)anebo SIP Proxy. Teď potřebujeme
odpovídající záznam v DNS:
$ORIGIN 9.9.6.1.9.9.6.9.5.0.2.4.e164.arpa.
IN NAPTR 100 50 "u" "E2U+sip" "!^\\+(.*)$!sip:\\1@cesnet.cz!" .
IN NAPTR 200 50 "u" "E2U+h323" "!^\\+(.*)$!h323:\\1@cesnet.cz!" .
Použití regulárních výrazů v DNS dotazech je postaveno na exaktních pravidlech.
 .* odpovídá libovolné řadě znaků a číslic,

 ˆ znamená začátek regulárního výrazu,
 $ znamená konec regulárního výrazu,
Ukázky použití pravidel:
 ˆ123.* , každý záznam začínající 123,

 *1234$ každý záznam končící 1234,
 ˆ123(.*)567$ všechny záznamy začínající 123 a končící 567.
Aplikací regulárního výrazu dostaneme URI adresy sip:420596991699@cesnet.cz a

h323:420596991699@cesnet.cz . Vykřičníky slouží jako oddělovače jednotlivých částí výrazu,
podívejme se na příklad regulárního výrazu „!ˆ.*$!sip:voznak@cesnet.cz!“ , řetězec mezi prvními
dvěma vykřičníky říká, že se má označit celý řetězec (aplikuje se na dotazované tel. č.), druhá část
říká, čím se bude nahrazovat, aplikací regulárního výrazu dostaneme SIP URI sip:
voznak@cesnet.cz. Existenci NAPTR záznamu k tel. č. 420596991699 ověříme příkazem:
host -t naptr 9.9.6.1.9.9.6.9.5.0.2.4.e164.arpa .
Pokud bychom výše uvedený záznam nezapsali do zóny e164.arpa našeho DNS serveru, ale
vytvořili si svou privátní zónu , do které bychom se dotazovali, tak by se jednalo o privátní strom,
příkladem může být například e164.org, e164.info anebo akademickou komunitou používaný
134
nrenum.net. Tyto stromy většinou zakládají skupiny s určitým cílem a stanovují individuální pravidla.
Veřejný strom e164.arpa má jasně daná pravidla, viz. obr. 7.1, používají se veřejná čísla dle ITU-T
E.164, je zde role ITU-T udělující souhlas s delegací na úrovni domény identifikující konkrétní stát,
např. delegace 0.2.4.e164.arpa na sdružení CZ.NIC na základě požadavku zastoupení ČR v ITU-T.
Obr. 7.1 Příklad procházení stromu e164.arpa
7.4 Prostory ENUMu
ENUM je v ČR v ostrém provozu od ledna 2007, registraci telefonních čísel zajišťuje zhruba
dvacet registrátorů, jejich seznam je uveden na stránkách http://enum.nic.cz. Koncem roku 2008
bude spuštěn DNSSEC pro domény 0.2.4.e164.arpa a cz, což je rozšíření umožňující ověřit pravost
informací získaných z DNS, ty budou podepsány, zabezpečené DNS bude tak sloužit pro uvedené
stromy jako úložiště certifikátů [v131].
Základní myšlenka, na které ENUM vznikl, byla dovolit uživatelům čísel vkládat za vymezených
podmínek stávající telefonní čísla do DNS a umožnit vyhledávání těchto čísel. Tento ENUM se
nazývá uživatelský ENUM, ale tento přístup nemusí vyhovovat všem, například operátorům určitě
nesedí, že o vložení čísla do DNS rozhoduje jeho uživatel. ISP většinou preferují federace
135
postavených na bilaterálních či uliterálních dohodách, a tak vzniká ENUM s přívlastky User, Private,
Operator, Enterprise, Federation, Carrier, Infrastructure a snad někoho napadne ještě další.
Příklady ENUM stromů se zařazením typu jsou v tabulce níže. Aktuálně se diskutuje veřejný
operátorský strom, který operátorům chybí a jako nejreálnější se jeví paralelní veřejný strom ke
stávajícímu uživatelskému, tlak ovšem není dostatečně silný a tak se dosud tento návrh nepodařilo v
IETF prosadit.
Tab. 7.1 Příklady prostorů ENUMu
7.5 Sestavení spojení s využitím DNS
Do DNS je odeslán dotaz s naformátovaným číslem E.164, předpokládejme, že se bude

vyhledávat ve veřejném stromu e164.arpa a bude nalezen odpovídající NAPTR záznam. Dokážeme
si ovšem představit, že dotaz může být paralelně odeslán i do více stromů.
Obr. 7.2 Příklad využití DNS při sestavení spojení

136
Aplikací regulárního výrazu je získána adresa SIP URI, která identifikuje uživatele v doméně
cesnet.cz. V dalším kroku je pomocí SRV v cílové doméně zjištěno, že službu SIP poskytuje
cyrus.cesnet.cz. Domácí SIP Proxy tak získává SIP URI volaného a adresu stroje, na který může
odeslat INVITE, čili žádost o inicializaci spojení.
7.6 Konfigurace DNS pro účely ENUMu
Nejdříve nastavíme SIP server, aby se dotazoval do name serveru, který budeme konfigurovat.
Změnu provedeme v souboru /etc/resolv.conf , kde nastavíme jako nameserver 195.113.113.147
[v68],[vil].
;soubor /etc/resolv.conf
nameserver 195.113.113.147
Nyní upravíme konfiguraci DNS serveru. K implementaci DNS použijeme BIND, který je součástí
většiny linuxových distribucí. V souboru named.conf vytvoříme novou zónu e164.arpa odkazující se
na db.arpa. Zónu přidáme do souboru /etc/bind/named.conf.
;část souboru /etc/bind/named.conf

zone "e164.arpa" IN {
type master;
file "/etc/bind/db.arpa";
};
Pro rychlé otestování vytvoříme soubor /etc/bind/db.arpa s následujícím obsahem.
;soubor /etc/bind/db.arpa
$TTL 86400
@ IN SOA 195.113.113.147. root.195.113.113.147. (
2006112801 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS 195.113.113.147.
9.0.0.0.3.0.0.5.9.0.2.4.e164.arpa. IN NAPTR 10 100 "u"

"sip+E2U" "!^.*$!sip:950030009@195.113.113.145!" .
NAPTR záznam říká, že pro dotazu na číslo +420950030009 dostaneme SIP URI
sip:950030009@195.113.113.145. Po dokončení konfigurace musíme BIND restartovat.
/etc/init.d/bind restart
137
Než nakonfigurujeme SIP server pro volání přes ENUM je vhodné si funkčnost NAPTR záznamu
otestovat a nesmíme zapomenout, jaký nameserver máme nastavený pro DNS.
host -t naptr 9.0.0.0.3.0.0.5.9.0.2.4.e164.arpa .
7.7 Budoucnost ENUMu
Pomalá implementace ENUMu je organizačně politickým problémem nikoliv technickým. Pro

prosazení užívání mechanizmu ENUM se jeví jednak jako potřebné dosáhnout určitého kritického
množství a jednak zapojení telekomunikačních operátorů (telco). Ti ovšem přistupují k ENUMu
odmítavě z jasného důvodu, za kterým stojí peníze. Pokud by došlo k masovému nasazení ENUMu,
znamenalo by to snížení zisků telco společností, neboť směrování přes ENUM v Internetu je levnější
než v klasických PSTN.
Řada publikací popisující ENUM tvrdí, že se jedná o technologii pro telefonování zadarmo, ale s
tím není možné souhlasit. Model zpoplatňování hovorů závisí na poskytovateli hlasové služby, nikoliv
na tom, zda číslo uživatele je v DNS. Konkrétní tel.č. může být v DNS propagováno, ale není nikde
zaručeno, že příchozí SIP Proxy volání přijme. Každopádně lze očekávat, že používání ENUMu by
mělo příznivý dopad na cenu hovorů, což nevylučuje, že hovor může být i zdarma. Pravděpodobně
lze očekávat model, že náklady poskytovatele služby budou ukryty v paušálním poplatku a jednotlivé
hovory nebudou zpoplatňovány. Pro tento princip se užívá názvu flat rate a tento koncept se bude v
tarifech poskytovatelů používat nejčastěji.
138
8 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. 8.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.
-------- Scenario Screen --------

Port Total-time Total-calls Transport
5060 200.47 s 1814 UDP
10 new calls during 1.002 s period 1 ms scheduler resolution

40 calls Peak was 42 calls, after 158 s
0 Running, 371 Paused, 24 Woken up
0 dead call msg (discarded)
3 open sockets
Messages Retrans Timeout Unexpected-Msg
----------> INVITE 1814 0 0 0
<---------- 180 1814 0

<---------- 200 1814 0 0
----------> ACK E-RTD1 1814 0 0 0
----------> BYE 1814 0 0 0

<---------- 200 1814 0
[ 4000ms] Pause 1814 0
-------- Sipp Server Mode --------
Obr. 8.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í.
139
8.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.
# 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 --with-
openssl a PCAP --with-pcap.
# tar -xvzf sipp-xxx.tar.gz

# cd sipp
# ./configure --with-pcap --with-openssl
# make
# make install
140
8.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

# 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 8.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. 8.2.
Obr. 8.1. Výchozí scénář SIPp
8.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
141
 -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
 -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.
# ./ sipp -sf uac_sipuri.xml –s 6543 -r 500 -rp 1000 iptel.org
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.
8.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).
142
 <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">

<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>
143
<![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
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>
144
</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.
# sipp -sf uac_basic.xml 192.168.1.119
Zachytíme relaci např. pomocí tcpdump anebo ngrep a zachycenou SIP relaci můžeme
analyzovat Wiresharkem.
# tcpdump -w /home/voz29/trace8.pcap
Ověříme, že XML scénář se chová dle předpokladů, viz. obr. 8.3
Obr. 8.3 Výměna SIP zpráv v sestavené relaci
Nyní se podíváme ještě na obsah žádosti INVITE, viz. obr. 8.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. 8.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á
145
[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]
[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.
146
<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
[last_Via:]
[last_From:]
[last_To:]
[last_Call-ID:]
[last_CSeq:]
Content-Length: 0
]]>
</send>
</scenario>
8.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
147
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. 8.5. CSV soubor může obsahovat komentované
řádky (ty se neberou v potaz a začínají symbolem "#").
Obr. 8.5 Vazba klíčového slova v argumentu konkrétního pole SIP hlavičky na řádek v CSV souboru
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])
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).
148
<![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ěď.
<recv response="407" auth="true">

</recv>
8.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 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
c Enter command mode
q Quit SIPp (after all calls complete, enter a second time to quit immediately)
Q Quit SIPp immediately
s Dump screens to the log file (if -trace_screen is passed)
p Pause traffic
1 Display the scenario screen
2 Display the statistics screen
3 Display the repartition screen
4 Display the variable screen
5 Display the TDM screen
6-9 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.
149
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 rate-
scale 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
8.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.
150
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í.
151
9 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
Rozsah IP adres: 10.0.0.0 – 10.255.255.255, CIDR blok: 10.0.0.0/8
9.1 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é
152
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ž
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.
9.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. 9.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.
153
Obr. 9.1. SIP zprávy přes NAT
9.3 Klasifikace typů NAT
Obr. 9.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í.
154
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í.
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. 9.2. Mapování v NAT
9.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,

155
- 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).
- 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.
9.4.1 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. 9.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.
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
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).
156
Obr. 9.3. Mapování vnější veřejné IP a portu pomocí STUN protokolu
9.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. 9.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
157
Obr. 9.4. Průchod IP telefonie s pomocí TURN serveru
Adresa alokovaná TURN serverem se nazývá Relayed address, viz. obr 9.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
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
158
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
# 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.
INVITE sip:user@example.com SIP/2.0

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.
INVITE sip:user@example.com SIP/2.0

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
159
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).
160
10 MGCP a IAX protokol
10 MGCP a IAX2 protokol

Ve světě VoIP je používána řada signalizačních protokolů, zpočátku byl dominantním protokol
H.323, cca od roku 2005 již nikdo nepochyboval o budoucnosti SIP protokolu, což souviselo i s jeho
využitím ve veřejných sítích. Specifikace IMS z roku 2005, za kterou stojí 3GPP otevřela protokolu
SIP cestu do mobilních sítí a v jádru sítě se SIP stal klíčovým protokolem pro poskytování IP
multimediálních služeb. Řada výrobců promptně zareagovala a jejich vývoj byl směrován především
do oblasti koncových SIP SW klientů a zařízení. Dnes tedy dominuje světu IP telefonie SIP, ale
kromě těchto dvou protokolů jsou ještě další, ze kterých si zmíníme velmi důležité protokoly, MGCP a
IAX. Zatímco MGCP nachází uplatnění především ve veřejných sítích, tak doménou IAX jsou sítě
privátní, svět pobočkových ústředen.
10.1 Media Gateway Control Protocol
MGCP (Media Gateway Control Protocol) je master/slave protokol pro řízení brány (slave). Tento
IETF protocol, který byl vydán v roce 1999 jako informativní RFC 2705 a dotažen do finální podoby
standardního doporučení byl až v roce 2003 v RFC 3435. Z MGCP vychází protokol Megaco/H.248,
přičemž Megaco je označení IETF a H.248 je značení ITU-T pro stejný standard. První verze H.248
byla uvolněna v roce 2000, nyní je třetí verze z roku 2005.
10.1.1 Architektura a základní rysy MGCP
Prvky MGCP architektury jsou následující:
 Media Gateway (MGW) konvertuje média na formát vyžadovaný jinou sítí,

 MGWC (Media Gateway Controller) řídí prvky MGCP architektury, používají se i termíny Call
Agent (CA) nebo Softswitch, entita zajišťuje zpracování volání, řízení komunikace a ovládá
veškeré dalších prvky, se kterými má vztah Master/Slave,
 Signaling Gateway (SGW) umožňuje připojení do signalizační sítě SS7.
Základní rysy MGCP:
 MGCP je textově orientovaný protokol vycházející z HTTP,

 pro přenos signalizace používá UDP, nebo TCP
161
 standardní port brány (MGW) je 2427

 standardní port Call Agenta (CA) je 2727
 správa multimediální relace tunelovaným protokolem SDP,
 real-time multimediální přenos protokolem RTP nebo šifrovaným SRTP,
10.1.2 MGCP zprávy
Formát protokolu MGCP je příkaz – odpověď, command/response (CMD/ACK). Příkaz začíná

slovem se čtyřmi znaky: AUEP, AUCX, CRCX, DLCX, EPCF, MDCX, NTFY, RQNT, RSIP. Odpověď
začíná třemi čísly tzv. kódu odpovědi, např. 200 (OK), podobně jako SIP. V protokolu MGCP má
každý příkaz transakční ID, které obsahuje i odpověď.
Příkazy protokolu MGCP jsou následující:
 EPCF (Endpoint Configuration), CA>MG, dává GW instrukce k nastavení kódování na

straně linkového rozhraní (směrem do PSTN, ISDN, ...),
 RQNT (Notification Request), CA>MG, dává GW instrukce k dohledu specifických
událostí a instruuje jak k těmto událostem generovat signály,
 CRCX (Create Connection), CA>MG, CA požaduje vytvořit spojení přes GW mezi dvěma
endpointy,
 MDCX (Modify Connection), CA>MG, CA vyžaduje změnit parametry týkající se
sestaveného spojení,
 DLCX (Delete Connection), CA>MG a MG>CA, umožňuje zrušit existující spojení, ACK
vrací statistiky volání,
 AUEP (Audit EndPoint), CA>MG, monitoruje status endpointu,
 AUCX (Audi Connection), CA>MG, monitoruje status spojení,
 RSIP (RestartInProgress), MG>CA, MG sděluje CA o stavu v provozu a mimo provoz.
 NTFY (Notify), MG>CA, MG dává CA instrukce k dohledu specifických událostí,
Každý příkaz musí být zodpovězen, odpověď vrací návratový kód indikující stav vyřízení příkazu.
Tyto kódy jsou součástí RFC 3661 a mají rozsah 000-999:
 000-099 Response acknowledgement, potvrzení odpovědi, (např. 000 - jde o potvrzení po

přijetí dočasné odpovědi, je použit 3-way handshake),
 100-199 Provisional response, dočasná neboli prozatímní odpověď informující o průběhu
vyřizování požadavku (např. 100 – transaction in progress oznamující vyřizování anebo
101 – transaction has been queued oznamující zařazení požadavku do fronty),
 200-299 Successful completion je úspěšné dokončení, tuto odpověď vidíme nejraději,
 400-499 Transient error, jedná se o přechodnou chybu, kterou může být např. 401 –
phone allready off-hook oznamující stav obsazeno anebo 404 – insufficient bandwith
indikující nedostatek pásma,
 500-599 Permanent error, trvalá chyba např. 500 – unknown endpoint oznamující
neznámý cíl anebo 504 – unknown or unsupported command indikující neznámý či
nepodporovaný příkaz,
 800-899 Package specific response codes oznamuje specifické kódy (nestandardní),
162
 900-999 Reason codes, jedná se o důvody chyb např. 901 – endpoint taken out of
service oznamující, že koncový terminál je mimo provoz anebo 903 – QoS resource
reservation was lost indikuje nemožnost garantovat kvalitu.
10.1.3 Příklad komunikace pomocí MGCP
Na obr. 10.1 je zachycena výměna zpráv mezi CA a MGW [sil2]. První zprávou je obsazení
CRCX (SDP) s popisem médií v SDP, následuje odpověď 100 potvrzující doručení CRCX a následně
200 (SDP) jako finální odpověď na CRCX včetně popisu médií přicházející při vyzvednutí volaným a
sestavení hovoru, média jsou přenášeny standardně v RTP (G711Alaw), následuje zavěšení
volaným DLCX a jeho potvrzení 250.
Obr. 10.1 Výměna zpráv mezi CA a MGW
MGCP protokol je podporován řadou výrobců jako je např. Cisco, Nortel, Ericsson a rovněž je
podporován v Asterisku. V PBX Asterisk je implementován pouze Call Agent (CA). Gateway je
implementována zpravidla hardwarově, ale najdeme ji např. v PBX YATE.
# less /etc/asterisk/mgcp.conf:
[general]
port = 2727 ; IP adresa (0.0.0.0 - všechny rozhranní)
bindaddr = 0.0.0.0 ; IP adresa (0.0.0.0 - všechny rozhranní)
[192.168.10.2]
host = 192.168.10.2 ; IP brány
line => aaln/1 ; jednotlivé linky brány

line => aaln/2
line => aaln/3
line => aaln/4
dtmfmode=rfc2833 ; DTMF mód
163
context = mgcp_kon ; kontext

directmedia = yes ; může provést re-invite (stejné jako sip)
; ... a řada dalších parametrů
Příklad pravidla volání v dial plan Asterisku může vypadat následovně.
v /etc/asterisk/extensions.conf
exten => _841,1,Dial(MGCP/aaln/1@192.168.10.2,20)
V případě mapování SIP a MGCP, kdy volání je iniciováno ze strany MGCP s terminací do SIP,
se využívá modifikace spojení MDCX (SDP), když jsou média vyjednána a doručen ve 200 OK., viz.
obr. 10.2.
Obr. 10.2. Komunikace přes protokolovou bránu MGCP/SIP
10.2 Inter Asterisk Exchange Protocol
Protokol IAX byl navržen s ohledem na maximální jednoduchost a snadnost implementace.

Jedná se o binární protokol, který sdružuje signalizaci i hlasová data v jenom kanálu a umožní tak
lépe využít šířku pásma a snadno prochází přes NAT. Uplatnění nachází především při propojení
164
ústředen Asterisk, i když jeho použití je ovšem i pro koncové klienty, ale vzhledem k široké podpoře
SIPu v koncových zařízeních je portfolio IAX SW klientů a zařízení o poznání menšího rozsahu než
SIP. Asterisku bude věnována následující kapitola.
IAX je zaveden do ústředny Asterisk od samého počátku vývoje [mol1]. Od Asterisk 0.5 začala
být podporována vylepšená verze protokolu, nazývaná IAX2, ta je využívána v současnosti a je
specifikována v IETF RFC 5456 (IAX: Inter-Asterisk eXchange Version 2) z roku 2010.. IAX je
orientován na přenos peer-to-peer a je určen jak pro přenos signalizace, tak i médií. U protokolů SIP
a H.323 je přenos médií zabezpečen pomocí RTP. Protokol IAX2 využívá jeden kanál pro přenos
signalizace i samotných multimediálních dat a navíc umožňuje i multiplex více hovorových i
signalizačních dat do jednotného datového toku, tzn. že snižuje overhead hlaviček a na rozdíl od SIP
či H.323 s RTP, kde při dvaceti současných hovorech se stejným kodekem je celkový tok dán
násobkem dvaceti jednotlivých toků, tak u IAX2 to nebude jednoduchým násobkem, ale méně
vzhledem k multiplexování.
10.2.1 Formát rámce IAX2
Pro přenos je využíván pouze jeden UDP port, obvykle port 4569, základní komunikační
jednotkou protokolu IAX je IAX rámec, viz. obr 10.3. Základní rámec nesoucí hovorová i signalizační
data se nazývá „Full Frame“ a pro přenos multimediálních dat bez signalizace je využit tzv. „Mini
Frame“, jehož hlavička má pouhé 4B.
Obr. 10.3 Rámec Full Frame a Mini Frame protokolu IAX
MiniFrame hlavička obsahuje posledních 16 bitů časové značky, zdrojové číslo volajícího
(Source call number) a bit F, který rozlišuje typ rámce. Full Frame má hlavičku 12B bajtovou stejně
jako RTP. Obsahuje identické informace jako MiniFrame, včetně plné časové značky TimeStamp a
navíc obsahuje číslo volaného (Destination Call Numer), OSeqno (OutBound stream sequence
number), které udává číslo odchozích rámců a ISeqno (InBound stream sequence number)
obsahující stejnou informaci pro příchozí rámce. Frame Type určuje typ rámce (DTMF signalizace,
165
Hlasová data, Video, řídící rámec, IAX řízení, atd...). Pole C určuje jak bude interpretováno pole
nazývané Subclass. Pokud je C rovno nule, potom Subclass je interpretován jako mocnina dvou,
když je C jedna, Subclass je interpretován jako 7bitová hodnota. Pokud je pro přenos DTMF použit
úplný rámec, Subclass obsahuje aktuální přenesenou číslici. Pokud je přenášeno video, hlas nebo
obraz, pole Subclass udává typ komprese [mol1].
10.2.2 Adresace v IAX2
Protokol IAX využívá pro adresaci standardních formátů typu URI (Uniform Resource Identifiers).
Základní schéma URI protokolu IAX je následující:
iax2:[uživatelské_jméno@ ]host[: port][/identifikátor[?kontext]]
Jednotlivé položky mají následující význam:
 iax2 Označení protokolu, povinný údaj

 uživatelské_jméno Uživatelské jméno, vyžadováno pro registraci a autentizaci
 host Identifikace systému v síti. Akceptovány jsou IP adresy ve tvaru IPv4 nebo IPv6
nebo doménové jméno.
 port Určuje port protokolu UDP.
 identifikátor Číslo nebo jméno identifikující zdroj na konkrétním systému
 kontext Určení části systému, na kterém je služba provozována
Příklady použití formátu:
iax2:alice@192.168.1.115:4569/200?vlastni
10.2.3 Zprávy IAX2
Zprávy protokolu IAX2 se dělí na dvě základní skupiny: spolehlivé (reliable) a negarantované
(non-guaranteed). Mezi spolehlivé se řadí všechny ty, které využívají Full Frame [mol1].
Negarantované zprávy jsou označovány všechny informace, které jsou zaslány pomocí Mini Frame.
IAX2 obsahuje následující zprávy:
 REGREQ Registration Request Message

 REGAUTH Registration Authentication Response Message
 REGACK Registration Acknowledgment Message
 REGREJ Registration Rejection Message
 REGREL Registration Release Request Message
 NEW Request Message

 AUTHREQ Authentication Request Message
 AUTHREP Authentication Reply Message
 ACCEPT Response Message
166
 RINGING Response Message

 ANSWER Response Message
 HANGUP Request Message
 REJECT Response Message

 ACK: Acknowledgement Message
 FLASH Request Message

 HOLD Request Message
 TXREQ Transfer Request Message
 TXCNT Transfer Connectivity Response Message
 TRANSFER Request Message
 UNHOLD Request Message
 PROCEEDING Response Message
 INVAL: Invalid Response Message
 VNAK: Voice Negative Acknowledgement Message
 MWI: Message Waiting Indicator Request Message
 UNSUPPORT Unsupported Response Message
 DTMF Media Message
 Voice Media Message
 Video Media Message
 Text Media Message
 Image Media Message
 HTML Media Message
 Comfort Noise Media Message
 LAGRQ Lag Request Message
 LAGRP Lag Response Message
Pomocí LAGRQ se zjišťuje zpoždění mezi komunikujícími stranami, žádost LAQRQ obsahuje
timestamp, který musí být vrácen (identický) v odpovědi LAQRP, tím pádem je zjištěn RTT. Zpráva
Voice obsahuje typ kodeku a obsah přenášeného vzorku pomocí FULL Frame a tedy je potvrzena a
jinak se přenáší obsah hovoru v Mini Frame rámcích. Ze znalosti protokolu SIP je debug IAX2
intuitivní a ukážeme si registraci, sestavení hovoru a ukončení.
10.2.4 Registrace pomocí IAX2
Při registraci je nejprve zaslána zpráva REGREQ (Registration Request Message) s

uživatelským jménem a dobou vypršení registrace. Jestliže je vyžadována autentizace, tak Asterisk
odpoví pomocí zprávy REGAUTH (Registration Authentication Response Message), která obsahuje
podporované autentizační metody. Na obr. 10.4 je znázorněna celá výměna při úspěšné registraci,
zároveň v obr. 10.5 vidíme, že autentizace byla možná pomocí MD5/RSA.
167
Obr. 10.4. IAX2 zprávy při registraci s autentizací
IAX2 klient odpoví opět zprávou REGREQ, přičemž tentokrát již zpráva obsahuje i autentizační
údaje v potřebném formátu. Jestliže nelze registraci akceptovat, stav vzdáleného sytému bude
„neautorizovaný“ a žádné další akce nejsou nutné. Pokud je registrace akceptována, Asterisk odpoví
zprávou REGACK (Registration Acknowledgment Message), která musí obsahovat IP adresu
Asterisku a dobu vypršení registrace. Pokud tomu tak není, obě strany musí nastavit shodnou dobu
vypršení registrace na 60 vteřin. Pokud je registrace odmítnuta, je zaslána zpráva REGREJ
(Registration Reject Message). Každá registrace je platná jen po omezenou časovou periodu
(standardně 60 sekund, jak již bylo uvedeno výše). IAX2 klient může tuto dobu prodloužit pomocí
opakování registračního procesu nebo naopak zkrátit pomocí zprávy REGREL (Registration Release
Request Message).
Obr. 10.5 IAX2 zpráva REGAUTH
10.2.5 Příklad sestavení hovoru pomocí IAX2
Inicializace hovoru začíná zasláním zprávy NEW klientem na Asterisk, viz. obr. 10.6. a Asterisk
odpoví pomocí zpráv AUTOREK, pokud vyžaduje autorizaci, respektive ACCEPT nebo REJECT pro
schválení nebo zamítnutí požadavku na sestavení hovoru.
168
Obr 10.6 Počáteční fáze sestavení hovoru pomocí IAX2
Následuje vyzvánění indikované zprávou RINGING a protože je přenášená pomocí FULL Frame,
tak zpráva je potvrzena pomocí ACK. Pokud je volaným IAX2 klientem hovor vyzvednut, tak je
odeslána zpráva ANSWER, viz obr. 10.7.
Obr. 10.7 Vyzvánění a přijetí hovoru v IAX2.
Obr. 10.8 zobrazuje obsah NEW včetně seznamu podporovaných i nepodporovaných kodeků.
169
Obr. 10.8 Obsah zprávy NEW inicializující spojení v IAX2
Během hovoru se v IAX2 může vyskytnout požadavek na vyvolání služby pomocí zprávy FLASH
(FLASH Request Message) anebo přidržení spojení HOLD (HOLD Request Message), předání
spojení TRANSFER (TRANSFER Request Message) a požadavek na pokračování po přidržení
UNHOLD Request Message).
10.2.6 Rozpad spojení v IAX2
Rozpad spojení se uskutečňuje odesláním zprávy HANGUP, viz. obr. 10.9, který nepotřebuje
další komentář.
Obr. 10.9 Rozpad spojení v IAX2
170
11 Asterisk
11 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.
11.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
171
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. 8.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. 11.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. 11.1 Roadmapa verzí Asterisku
11.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
172
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 11.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.11.2 Architektura Asterisku
11.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).
173
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í:
 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.
11.2.2 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
174
11 Asterisk
protokolem Asterisku a výborně prochází NATem. Seznam podporovaných signalizačních protokolů

v Asterisku je uveden níže:
 SIP
 H323
 IAX2
 MGCP
 SCCP (Cisco Skinny)
 Nortel unistim
 Jingle
11.2.3 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.
175
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.
176
11 Asterisk
 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.
11.3 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}
177
11 Asterisk
root@debian119:~# asterisk -rvvv

Asterisk 11.7.0~dfsg-1, Copyright (C) 1999 - 2013 Digium, Inc. and others.
Created by Mark Spencer <markster@digium.com>
=========================================================================
Connected to Asterisk 11.7.0~dfsg-1 currently running on debian119 (pid = 5051)
debian119*CLI> help
debian119*CLI> exit
11.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 Vysvětlení

(Příklad)
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.)
178
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. 11.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.

(příklad)
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. 11.2 Options v asterisk.conf

179
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

(příklad)
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. 11.3 Moduly v modules .conf
11.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.
180
11 Asterisk
11.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] ;Definování účtu

type=friend
context=vlastni ;Vyjadřuje skupinu v dialplanu ;(/etc/asterisk/extensions.conf), kde
;hledat v případě volání tohoto čísla
language=cz
host=dynamic ;Povolení registrace účtu na všech IP ;adresách
username=300 ;Přihlašovací jméno při registraci účtu
secret=heslo ;Přihlašovací heslo při registraci účtu
callerid=Alice <300> ;identifikace volajícího
[bob]
type=friend
context=Asterisk1
language=cz
host=dynamic
username=400
secret=heslo
callerid=Bob <400>
11.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] ;Definice účtu

type=friend
context=vlastni
language=cz
host=dynamic
username=500
secret=heslo
callerid=Klara <500>
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
181
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
11.5.3 Další možnosti sip.conf a iax.conf
Následující tabulka obsahuje možnosti nastavení parametrů uživatele jak v sip.conf, tak
v iax.conf.
[Alice] 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. 11.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] ;sekce general určuje společná nastaveni pro všechny účty

bindport=5060 ;port na kterém naslouchá SIP
srvlookup=yes ;podpora DNS
qualify=1000 ;monitorování dostupnosti klientů
182
11 Asterisk
disallow=all ;zakazuje všechny kodeky

allow=alaw ;povolíme jen vybrané
dtmfmode=rfc2833 ;způsob přenosu DMTF volby
language=cz ;výchozí jazyk,např. pro chybové hlášky
allowguest=yes ;povolení hovorů neregistrovaným klientům
context = cizi ;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] ;učet k poskytovateli - název
name= my_provider ;registrační jméno
secret=heslo_1 ;heslo
type=peer ;ovlivňuje autentizaci, peer – servery, user – klient, friend – oba
fromuser=XXXX ;položka fromuser v SIP protokolu (pokud poskytovatel vyžaduje)
fromdomain=YY.com ;položka fromdomain v SIP protokolu (pokud poskytovatel vyžaduje)
host=provider.cz ;IP adresa, DNS název (, dynamic - dynamicky přidělená registrací)
canreinvite=no ;určuje zda mohou RTP pakety „obcházet” Asterisk
context = verejny ;určuje kontext, „skupinu” do které uživatel patří
[nazev_uctu] ;uživatelský účet – název (nejčastěji přímo telefonní číslo)

name=nazev_uctu ;registrační jméno
secret=heslo_2 ;heslo
type=friend ;friend – autorizace v obou směrech
host=dynamic ;dynamicky získaná IP hosta registrací
canreinvite=no
nat=yes ;bude klient za NATem?
context = vnitrni ;určuje kontext, „skupinu” do které uživatel patří
[general]
port = 2727 ; IP adresa (0.0.0.0 - všechny rozhranní)
bindaddr = 0.0.0.0 ; IP adresa (0.0.0.0 - všechny rozhranní)
[192.168.10.2]
host = 192.168.10.2 ; IP brány
line => aaln/1 ; jednotlivé linky brány
line => aaln/2
line => aaln/3
line => aaln/4
dtmfmode=rfc2833 ; DTMF mód
context = mgcp_kon ; kontext
directmedia = yes ; může provést re-invite (stejné jako sip)
; ... a řada dalších parametrů
183
11 Asterisk
A obdobně pro iax.conf opět včetně příkladu nastavení trunku.
[general] ;sekce general určuje společná nastaveni pro všechny účty

bindport=4569 ;port na kterém naslouchá SIP
calltokenoptional=0.0.0.0/0.0.0.0 ;ošetření pro klienty nepodporující novou

maxcallnumbers=512 ;metodu zabezpečení „call token validation”
qualify=yes ; monitoruje dostupnost klapky
bandwidth=high ; povolení kodeků s vyšší rychlostí (G.711), medium – střední, lowdisallow=all

;zakazuje všechny kodeky
allow=alaw ;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:anca@147.229.151.125
; „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
184
11 Asterisk
11.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.
11.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.
sip.conf extensions.conf
[alice] [general]
context=vlastni [globals]
[vlastni]
exten => alice,1,Dial(SIP/alice)
Obr. 11.3 Funkce kontextu ze sip.conf v dialplan
11.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()
185
11 Asterisk
11.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 => 123,n,něco udělej
exten => 123,n,ještě něco udělej
exten => 123,n,udělej poslední funkci
exten => 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()
11.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.
186
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
11.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 hello-
world 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
187
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)
11.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:
188
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.
11.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}
189
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} - vrátí řetězec 23456789

${EXTEN:-4} - vrátí řetězec 6789
${EXTEN:0:3} - vrátí řetězec 123
${EXTEN:2:3} - vrátí řetězec 345
${EXTEN:-4:3} - vrátí řetězec 678
11.6.8 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.
11.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ě:
190
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)
11.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).
11.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í:

191
11 Asterisk
[general]
format = wav
[default]
2000 => 1234,Filip Rezac,filip.rezac@vsb.cz
2001 => 5678,Miroslav Voznak,miroslav.voznak@vsb.cz
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 (filip.rezac@vsb.cz, miroslav.voznak@vsb.cz).
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.
11.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í.
192
11 Asterisk
11.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í.
11.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()
11.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:
193
11 Asterisk

exten => 30,3,Background(silence/5)


exten => i,1,Background(marryme)

exten => i,2,Hangup()
11.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])

194
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.
11.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 # span, zdroj hodiny, délka vedení, typ rámce, kód (,crc4)...
mtp2=1 # ..(zdroj hodin 0-vždy master, 1-slave (bez hodin - master), 2, 3
bchan=2-31 # konfigurace SS7 přenašeče
echocanceller=mg2,2-31
span=2,0,0,cas,hdb3
195
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 # konfigurace analogového FXS portu (pro připojení telefonu)

echocanceller=mg2,125
fxsks=126 # konfigurace analogového FXO portu (pro připojení k ústředně)

echocanceller=mg2,126 # pro FXS port signalizace fxoks, pro FXO fxsks, tedy opačně
loadzone=cz # určuje konfiguraci HW korespondující s danou

defaultzone=cz # zemí, ovlivňuje i další věci ... velmi důležité
11.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 ; přidružení okruhů svazku 1

sigchan = 1
...
...
group=5 ; svazek ... např.: exten => _731,1,Dial(dahdi/g5,20)
196
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 ; přidružení okruhu 126 svazku 6
11.10 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
197
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. 11.4.
Obr. 11.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):
198
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

199
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]
11.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ášť.
11.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í.
200
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 ***
11.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
201
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
11.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
202
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í.
11.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 METHOD

# "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
Takto editovaný soubor uložíme (CTRL+X a Yes) a restartujeme databázi.
# /etc/init.d/postgresql restart
203
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, že vyžaduje editaci. Proto je
potřebné vykonat ještě poslední editaci přes příkazový řádek.
# nano /etc/davical/192.168.209.130-conf.php
<?php
// $c->domain_name = "calendar.example.net";
// $c->sysabbr = 'DAViCal';
// $c->admin_email = 'admin@example.net';
// $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
204
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: asterisk

New Password: asterisk
Confirm: asterisk
Full Name: asterisk
Email: asterisk@localhost
Active: ano
User Roles: všechny ano
CREATE
Tento kalendář bude dostupný na adrese http://192.168.209.130/caldav.php/asterisk/home/

s login a password nastaveným výše.
11.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:asterisk@192.168.209.130/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
205
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.
11.13 Aplikace kalendářových funkcí
V této kapitole se budeme zabývat možnostmi využití kalendáře Asteriskem.
11.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.
11.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})
206
11 Asterisk
same =>h,n,Set(CALENDAR_WRITE(asterisk,summary,start,end)=Volal
${CALLERID(all)},${start},${end})
11.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
207
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.
208
11 Asterisk
11.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.
11.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
209
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í.
11.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: 5462/openfire
Užívatelské jméno: openfire
Heslo: openfire
Nastavení profilu: výchozí
Administrátorský účet: root@localhost
210
11 Asterisk
Nové heslo asterisk

Potvrzení hesla: 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).
11.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. 11.5 Vyplnění registrace XMPP klienta Pidgin
211
11 Asterisk
Pokud vše proběhlo korektně, tak dostaneme potvrzení o úspěšné registraci.
Obr. 11.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. 11.7 Vyplnění registrace XMPP klienta Spark

212
11 Asterisk
11.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.
213
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. 11.8.
BOB ALICE
Kalendář Ne
dostupný?
Ano
Ne
Ne
XMPP online? XMPP online?
Ano Ano
XMPP zpráva Ne XMPP zpráva

přijmout přijmout
hovor? Ne hovor?
Ano Ano
Vyzvánění Ne Vyzvánění
30s Ne 30s
HLASOVÁ
Přijetí hovoru SCHRÁNKA Přijetí hovoru
J J
Obr.11.8 Schéma chování prezenčního skriptu
214
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.
215
12 Kamailio
12 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. 12.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.12.2 Souvislost mezi projekty vzešlých ze SER
216
12 Kamailio
12.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. 12.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ů
217
12 Kamailio
 Speciální proměnné
 Parametry modulů
 Managementové funkce
Podporovaných modulů je celá řada, viz. obr 12.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.
12.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í
218
12 Kamailio
 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
12.2 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!
219
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:123@192.168.1.117:5060 Q=
Expires:: 131
Callid:: 1935439451@192.168.1.119
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:111@192.168.1.111:43489;transport=udp Q=
Expires:: 3194
Callid:: 888451300809@192.168.1.111
Cseq:: 1
User-agent:: Sipdroid/3.2 beta/GT-I9505
State:: CS_NEW
Socket:: udp:192.168.1.119:5060
220
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. 12.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. 12.5 Potvrzení 200 OK na žádost INVITE
221
13 Aspekty kvality IP telefonie

Aplikace pracujících v IP síti v reálném čase kladou nároky na QoS (Quality of Service), což
znamená snahu o dodržení předem stanovených parametrů při přenose dat. Zajištění QoS je
důležité například při interaktivním přenosu hlasu či videa přes internet. V poslední době dochází k
rozvoji těchto síťových aplikací, jejichž úspěšnost z pohledu uživatele významně závisí na časových
charakteristikách přes danou síť. Definované parametry, jejichž určitou hodnotu je třeba během
přenosu zajistit, slouží k tomu, aby koncové aplikace byly schopné správné činnosti a poskytly tak
uživateli požadovanou službu [hos], [mol2].
Existují různé typy řešení a návrhy architektur, které zavádějí úrovně kvality služeb a seřazují
datové jednotky přicházejícího provozu podle priorit. Kvalita služeb v referenčním modelu počítačové
sítě může být implementována v různých vrstvách. Nejčastěji se používá implementace na úrovni
linkové (802.1.p – pole User priority v VLAN značce 802.1Q) nebo síťové vrstvy (DSCP kód v ToS).
Při implementaci na úrovni IP protokolu existuje několik metod, avšak dva nejčastější způsoby řešení
jsou Integrované služby (Integrated Service, IntServ) a Diferencované služby (Differentiated services,
DiffServ).
13.1 Kvalita služby (QoS)
Kvalitou služby (QoS) rozumíme schopnost sítě poskytovat lepší zacházení vybranému síťovému
provozu při použití různých technik pro přenos dat. Internet byl vybudován s cílem poskytovat
přenosovou službu bez zajištění parametrů spojení. V současnosti se však velice rychle rozvíjí
aplikace pracujících v reálném čase, jako jsou například videokonferenční hovory nebo IP telefonie.
A právě pro tyto síťové aplikace je třeba klást velký důraz na zajištění kvality, neboť každá z těchto
aplikací má vlastní specifické požadavky na přenos sítí. Na základě těchto požadavků proto
byly definovány tyto základní QoS parametry:
 ztrátovost paketů (packet loss)

 zpoždění paketů (latency, delay)
 kolísání zpoždění (jitter)
 propustnost, přenosová rychlost, pásmo (throughput, transmission rate, bandwith)
222
Každý typ provozu je citlivější na jiný parametr, proto je důležité síťový provoz třídit a následně
zajišťovat specifickou kvalitu služeb pro konkrétní třídy. Hlavním úkolem QoS je tedy minimalizovat
nežádoucí vlastnosti přenosu a snažit se zajistit požadované hodnoty QoS parametrů. Toho lze však
dosáhnout pouze za podpory všech síťových prvků podílejících se na přenosu.
13.2 IntServ
Technologie Integrovaných služeb byla první technologie používanou v IP sítích, která

umožňovala klasifikaci datových toků a přidělování síťových zdrojů podle typu služby a splnila tak
oba výše popsané základní úkoly obecného QoS mechanizmu. Koncept Integrovaných služeb byl
definován v roce 1994 v dokumentu RFC 1633 . Základní myšlenka architektury IntServ vychází z
okruhově-spínaného typu komunikace, kdy jsou síťové zdroje alokovány zvlášť pro každý vybraný
tok dat. Aby aplikace získala požadované parametry přenosu, musí před samotným přenosem
dat proběhnout proces rezervace. Rezervace síťových zdrojů se skládá z několika kroků.
Nejprve musí aplikace definovat charakter odesílaných dat a také požadavky na síťové zdroje.
Síť poté použije směrovací protokol pro nalezení vhodné trasy, která umožní uspokojení požadavků
uživatelské aplikace. Následně je použit rezervační protokol pro vytvoření tzv. rezervačního stavu,
který zajištuje garanci síťových zdrojů na všech zúčastněných uzlech podél celé trasy. Je tedy
nutné vyjednat, zda jsou všechny prvky sítě schopné garantovat požadované parametry přenosu..
Jestliže poskytnuté síťové zdroje nejsou na některém z uzlů dostačující, spojení bude odmítnuto a
zdrojová aplikace se může rozhodnout, zda se spokojí s mírnějšími požadavky, nebo odloží přenos.
Pokud je však proces rezervace jednou schválen a řádně dokončen, aplikace může začít vysílat
svoje data po rezervované trase.
K zajištění informovanosti prvků sítě a tím pádem k rezervaci prostředků v síti slouží u
mechanizmu IntServ tzv. rezervační protokoly. V praxi je používán především protokol RSVP
(Resource Reservation Protocol). RSVP protokol poskytuje mechanizmus pro vytváření a správu
rezervačního stavu podél celé trasy mezi zdrojem a cílem datového toku. Samotné rozhodnutí,
která trasa bude pro přenos dat vybrána, je však provedeno směrovacím protokolem.
13.2.1 IntServ Architektura a protokol RSVP
IntServ architektura definuje tři třídy:
 Best-effort class, základní třídu,

 Controlled-Load Class, třídu řízené zátěže, nabízí lepší službu než best effort
 Guaranteed Class, garantovanou třídu, garantuje zpoždění, pásmo, ztráty
a dva popisovače provozu (traffic descriptors):
 TSpec (Traffic Specification), popisuje vlastnosti provozu,

 RSpec (Requirements Specification) popisuje požadavky na kvalitu služby jako end-to-
end zpoždění, jitter, zráty paketů
223
Referenční model technologie IntServ je možné rozdělit na dvě základní části - řídící rovinu a
datovou rovinu. Řídící rovina zajišťuje proces rezervace síťových zdrojů a datová rovina provádí
předávání datových paketů na základě vytvořeného rezervačního stavu. Hlavními bloky
referenčního modelu IntServ, viz. obr. 13.1, jsou:
 Reservation Agent, rezervační agent,

 Admission Control, řízení přístupu,
 Classfifier, klasifikátor,
 Packet Scheduler, plánovač paketů,
Obr. 13.1 Boky řešení IntServ
Protokol RSVP zajišťuje rezervací zdrojů na trase pomocí dvou klíčových typů zpráv:
 PATH, odesíláno stranou inicializující spojení, popisuje vlastnosti provozu, jako objekty
jsou tyto informace ukládány v každém uzlu trasy spojení,
 RESV, odesílá vzdálená strana příjemce zpět straně inicializující spojení zprávy, zpráva
obsahuje datové objekty identifikující požadavky na zdroje (kvalitu služby).
13.3 DiffServ
DiffServ oproti IntServ používá odlišný způsob zajištění kvality služeb v IP sítích. Základní
myšlenka je velmi jednoduchá. Jednotlivé datové toky jsou sdruženy do několika tříd podle
224
základního charakteru služeb, takže síťové prvky (s výjimkou hraničních) se nemusí starat o každý
datový tok zvlášť]. Každý IP paket vstupující do datové sítě je označen značkou, která říká, jak
má být s paketem zacházeno - neboli určuje třídu přenosu poskytnutou paketu. Toto značení
paketů probíhá pouze na vstupu do datové sítě. Během přenosu paketů datovou sítí další
směrovače pouze přečtou značku každého paketu a dle této značky se řídí při zacházení s
paketem. Značka je uložena přímo v hlavičce IP paketu, takže není potřeba žádný signalizační
protokol pro vytvoření rezervačního stavu. Dále, jelikož je síťový provoz sdružován a následně
zpracováván v rámci tříd, odpadá potřeba složitého třídění a plánování síťových zdrojů pro
jednotlivé datové toky, jako je tomu u IntServ.
13.3.1 Architektura DiffServ
Architektura definuje třídy služeb založené na klasifikaci toků. Označení paketů je

provedeno pomocí vzorků v oktetu ToS u IPv4 nebo nastavením parametru třídy provozu u IPv6
(Traffic Class Octet). Z pohledu mechanizmu diferencovaných služeb se rozsáhlé datové sítě dělí
na menší oblasti, které se nazývají DiffServ domény. Každá DS doména je spravována jedním
poskytovatelem připojení ISP a probíhá v ní jednotná administrace, která zajišťuje vyhodnocování
oprávněnosti požadavků, přiřazení toků do jednotlivých tříd a označování paketů. V rámci DS
domény jsou rozlišovány dva typy směrovačů: hraniční a páteřní.
Obr. 13.2 Typy směrovačů v DiffServ doméně
Edge Router - hlavní směrovač leží mezi dvěma DS doménami nebo na rozhraní mezi DiffServ
doménou a částí sítě, která nepodporuje mechanizmus DiffServ. Tento směrovač tedy provádí
klasifikaci vstupních toků a následné označování paketů, které jsou pak dále posílány do
DiffServ domény.
Core Router - páteřní směrovač se nachází uvnitř DiffServ domény. Nároky na tento prvek
jsou podstatně menší v porovnání s hraničním směrovačem. Páteřní směrovač neprovádí žádnou
klasifikaci paketů, zajišťuje pouhé předávání označených paketů a garantuje určitou kvalitu služby
definovanou značkou v hlavičce paketu.
225
V rámci každé DS domény musí být jasně definována úroveň služby, kterou může koncový
uživatel očekávat od sítě, respektive od ISP. K tomuto účelu slouží dohoda o úrovni poskytované
služby Service Level Agreement (SLA). Dohoda SLA je aplikována na rozhraních mezi uživatelem
a DS doménou nebo dvěma DS doménami spravovanými různými ISP a jasně vymezuje povolené
profily síťového provozu, podmínky zacházení s datovými toky, konkrétní síťové parametry pro
jednotlivé třídy provozu atd.
Referenční model technologie DiffServ je definován v RFC 2475, model diferencovaných služeb
se skládá z několika bloků, viz. obr. 13.3 a je možné jej rozdělit na dvě základní části. Na část
klasifikace, kde probíhá měření a značkování a část pro úpravu provozu (zacházení), která na
základě parametrů provozu a značek přidělených jednotlivým paketům rozhoduje o jejich dalším
zpracování.
Obr. 13.2 Referenční model DiffServ
Třídič (Classifier) provádí identifikaci přicházejících paketů a jejich následné dělení do několika
skupin podle předem definovaných pravidel.
Měřič (Meter) provádí měření pro každý datový tok od zákazníka a poté výsledky porovná
s konkrétním datovým profilem.
Přeznačovač (Remaker) provádí přeznačkování, ke kterému může dojít na základě nesplnění

kritérií pro jejich definovanou třídu provozu. Většinou se jim proto nastaví vyšší priorita zahození
při případném zahlcení sítě v dalších směrovačích. Dalším důvodem k přeznačení paketů může
být jejich přechod mezi dvěma DS doménami, které používají odlišného způsobu třídění provozu.
Tvarovač (Shaper) má za úkol přenést datový tok do souladu se sjednaným datovým profilem.
Rozdíl mezi tvarovačem a značkovačem je v tom, že značkovač jednoduše označí paket a nechá jej
projít do sítě. Zatímco tvarovač zabrání paketům projít sítí do té doby, dokud se datový tok
nepřizpůsobí danému profilu. Tvarování je méně náročná forma zacházení s pakety než značení.
Stejně jako přeznačení, tak i tvarování je důležité v hraničním uzlu mezi dvěma DiffServ doménami.
226
Zahazovač (Dropper) realizuje jednodušší metodu zpracování paketů než tvarovač. Příchozí
pakety, které nevyhovují jejich definovanému profilu provozu, jsou vyřazeny z provozu jejich
zahozením. Proto zahazovač nepotřebuje vyrovnávací paměť.
Značkovač (Marker) přiděluje každému toku dat určitou značku, která definuje způsob, jak se s
ním bude zacházet v síti – tzv. Per Hop Behavior index (PHB index). Jsou definovány tři typy PHB:
 Expedited Forwarding (EF) – urychlené doručení,

 Assured Forwarding (AF) – zaručené doručení, celkem 12 možností, viz. tab. 13.1
 Best Effort (BE) – základní služba bez prioritizace
Expedited Forwarding nabízí absolutní záruku velikosti kolísání zpoždění pro danou třídu
provozu. Tento typ je proto velmi složitý na zajištění a tím pádem neefektivní. Poskytnutí EF danému
toku znamená vyhrazení téměř všech síťových prostředků pro tento tok, což pak vede k
neefektivnímu využívání prostředků sítě. Urychlené doručení je tedy možné používat pouze v
omezené míře.
Služba Assured Forwarding je navržena tak, aby zajistila přenos garantovanou rychlostí. AF
zajišťuje nižší garance QoS než EF a používá se především pro transportní protokol TCP. AF
pracuje na základě stanovení priorit pro různé kategorie provozu.
Best Effort představuje základní službu, která je vhodná pro přenos dat nenáročných na
zajištění QoS parametrů. U služby BE není žádná garance QoS, síť se pouze snaží doručit pakety
nejlepším možným způsobem s využitím aktuálně dostupných síťových prostředků.
Mechanizmus DiffServ je postaven na předpokladu odlišného zacházení pro jednotlivé

pakety. Aby to bylo možné, je třeba pakety nějakým způsobem od sebe odlišit. K tomu slouží
jedinečný identifikátor, značka, označovaný jako DSCP (DiffServ Code Point). Tato značka je
uložena v hlavičce IP paketu v poli označovaném jako DS pole, viz. obr 13.3. Velikost DS pole je 8
bitů, avšak pro uložení DSCP značky se používá pouze prvních 6 bitů, zbylé dva jsou momentálně
nevyužité.
0 1 2 3 4 5 6 7
DSCP unused
Obr. 13.3 DSCP pole
13.3.2 DSCP značka
Značka DSCP definuje konkrétní třídu provozu a na ni je navázán definovaný způsob

zacházení s pakety patřícími do dané třídy. V rámci architektury Diferencovaných služeb se
způsob zacházení s pakety označuje zkratkou PHB (Per Hop Behaviour). PHB nedefinuje přímo
konkrétní mechanizmy nebo způsob jejich implementace, ale obsahuje spíše obecný popis způsobu
zacházení s pakety (v závislosti na DSCP) nebo specifikaci parametrů požadované služby v rámci
227
dané DS domény . Pro dosažení stejné úrovně zacházení v rámci konkrétního PHB je tedy možné
použít různé fyzické implementace metod řízení front a plánování odesílání paketů.
Velikost DSCP je 6 bitů, první 3 bity odpovídají IP Precedenci. Pole v IP hlavičce, které
umožňuje rozlišení provozu do několika tříd, nutných pro odlišný způsob obsluhy, může obsahovat
hodnotu DSCP (Differentiated Services Code Point) kód, viz. obr. 13.3 anebo IP precedence, viz.
obr. 13.4. Zatímco DSCP používá šest bitů, tak IP precedence tři bity
0 1 2 3 4 5 6 7
Precedence TOS MBZ
Obr. 13.4. IP precedence
Hodnota IP precedence obsahuje tříbitovou informaci sloužící k rozlišení toku. Ta umožňuje

definovat až osm rozdílných provozních tříd. To je poměrně dostatečný počet pro rozlišování
jednotlivých toků, není to však dostačující počet pro přesné nastavení odlišných politik pro
zacházení s více typy provozu. Výchozí hodnotou pole IP precedence je nula. Vyšší hodnota tohoto
pole značí vyšší přednost.
DSCP umožňuje vhodnější značkování provozu, DSCP obsahuje šestibitovou informaci sloužící
k rozlišení toku. Ta umožňuje definovat až 64 jednotlivých provozních tříd. To je dostatečný počet
nejen pro standardní, ale i pro specifičtější třídy provozu. Standardně je definováno pouze 14 tříd
(kromě EF a BE je možné rozlišit 12 kategorií pomocí AF. Čím hodnota pole, tím větší je priorita
daného provozu. Pro PHB AF, viz. tab. 13.1, se doplňuje toto číslo do názvu (např. AF4x). Další
dva bity určují pravděpodobnost zahození, čím větší číslo, tím spíše dojde k zahození provozu
(AFx1 – nízká pravděpodobnost zahození, AFx2 – střední pravděpodobnost zahození, AFx3 –
vysoká pravděpodobnost zahození). Poslední bit je 0.
Drop Precedence Class #1 Class #2 Class #3 Class #4
AF11 AF21 AF31 AF41

Low Drop Prec
001010 010010 011010 100010
AF12 AF22 AF32 AF42

Medium Drop Prec
001100 010100 011100 100100
AF13 AF23
High Drop Prec AF33 011110 AF43 100110
001110 0010110
Tab. 13.1 PHB typu Assured Forwarding
228
Následující tabulka 13.2 ukazuje doporučené hodnoty IP Precedence (IPP) a k nim odpovídající
PHB třídy spolu s hodnotou DSCP (binárně, v závorce decimálně).
Per Hop Behavior index / DSCP
nízká pst. zahození střední pst. zahození vysoká pst. zahození
BE
000000 (0) – –
AF11 AF12 AF13

001010 (10) 001100 (12) 001110 (14)
AF21 AF22 AF23

010010 (18) 010100 (20) 010110 (22)
AF31 AF32 AF33

011010 (26) 011100 (28) 011110 (30)
AF41 AF42 AF43

100010 (34) 100100 (36) 100110 (38)
EF
101110 (46) – –
Tab. 13.2 Index PHB
Plánované odesílání paketů umožňuje prioritní zacházení pro vybrané třídy síťového
provozu, což je základní myšlenka téměř všech technologií pro zajištění kvality služeb. Proto je
plánované odesílání paketů srdcem každého QoS mechanizmu, neboť právě tento proces má
zásadní vliv na výslednou úroveň kvality uživatelské aplikace. Pojmem plánované odesílání paketů
jsou většinou označeny dva úzce související procesy - proces řazení paketů do front a proces
řízeného odesílání, který rozhoduje, který paket bude odeslán na výstupní rozhraní síťového
prvku. Plánované odesílání paketů je u technologie DiffServ prováděno na základě DSCP značky a
k ní přidruženému způsobu zacházení PHB. Mezi nejpoužívanější mechanizmy plánovaného
odesílání paketů například patří FIFO (First In First Out), PQ (Priority Queuing), WFQ
(Weighted Fair Queuing), jejichž bližší popis je v další kapitole.
229
13.4 Nástroje QoS
Pakety, které mají být poslány ven ze směrovače přes určité rozhraní, se dočasně umístí do
paketové fronty, pokud je v daném okamžiku příslušné rozhraní zaměstnáno vysíláním jiného paketu.
Paketových front může být na určitém rozhraní i více (např. pro různé druhy provozu). V takovém
případě je nutno definovat metodu obsluhy těchto front, tj. způsob a pořadí, v jakém budou pakety
vybírány z jednotlivých front a posílány přes rozhraní ven ze směrovače. Také uvnitř každé fronty je
definován určitý mechanizmus, který seřazuje pakety. Ve většině případů se jedná o metodu FIFO.
Paketové fronty mají vliv na všechny přenosové parametry. Čím delší je paketová fronta, tím
větší je zpoždění a variabilita zpoždění paketů, ale tím menší je ztrátovost paketů. Pokud dojde na
delší dobu k zahlcení daného rozhraní, tj. počet paketů vkládaných do fronty je delší dobu větší než
počet paketů vybíraných z fronty, je ztrátovost vysoká bez ohledu na délku fronty. Kromě dříve
popsaných softwarových front, existuje v každém rozhraní i malá hardwarová fronta, kam se umisťují
pakety těsně před vysláním ze směrovače. Důvodem její existence je, aby vysílání paketu nebylo
zdrženo procesem vybírání paketu ze softwarových front [mac], [hos], [mol2].
13.5 Obsluha paketových front
Metody obsluhy paketových front patří mezi QoS nástroje pro řízení stavů zahlcení sítě
(congestion management). Modely řazení paketů do front nám popisují vřazení jednotlivých typů
informace do příslušné fronty a způsob její obsluhy [hro]. Základní modely řazení provozu do front
jsou:
 Základní řazení FIFO (First In First Out)

 Vážené řazení do front WFQ ( Weighted Fair Queuing)
 Vlastní řazení do front CQ (Custom Queuing)
 Prioritní řazení do front PQ (Priority Queuing)
Druhou skupinou modelů řazení paketů do front jsou modely složitější, odpovídající zejména
kombinacím modelů základních. Z možných kombinací se nejčastěji můžeme setkat s těmito modely:
 Vážené řazení do front na základě třídy CBWFQ (Class-Based Weighted Fair Queuing)
 Prioritní řazení do front / Vážené řazení do front PQ/WFQ (Priority Queuing / Weighted Fair
Queuing)
 Řazení do front s nízkou latencí LLQ (Low Latency Queuing)
13.5.1 Metoda FIFO
Nejzákladnějším typem obslužné fronty je FIFO (First In First Out). Tato fronta je základním
prvkem většiny modelů. FIFO používá jen jednu frontu, ze které se pakety vybírají v tom pořadí, ve
kterém byly do ní vloženy. Není zde nutná žádná klasifikace paketů.
230
13.5.2 Metoda CQ
CQ pracuje také na principu rozdělení toku do více obslužných front. U metody CQ není
přenosové pásmo rozděleno ve vyváženém poměru. Přidělené pásmo pro danou frontu může být
nastaveno konkrétní hodnotou, nebo procentem z celkově poskytované šířky pásma. V případě
vyprázdnění obslužné fronty, je její přidělené pásmo v příslušném poměru rozděleno mezi fronty
zbývající.
CQ používá až 16 uživatelem definovaných paketových front. Paketové fronty jsou cyklicky

obsluhovány jedna za druhou. Z každé fronty se vybírají pakety, dokud není překročen limit počtu
bytů pro danou frontu nebo dokud zbývá ve frontě nějaký paket. Poté se stejným způsobem obslouží
další fronta. Tímto způsobem lze garantovat jednotlivým frontám určité procento z celkové přenosové
rychlosti příslušného rozhraní. Pokud jsou některé fronty dočasně bez paketů, zbývající fronty si
automaticky přerozdělí nevyužitou část přenosové rychlosti rozhraní.
Obsluha
Klasifikace fronty
Přidělené
pásmo 15%
Přidělené
pásmo 30%
Přidělené
pásmo 55%
Obr. 13.5 Ilustrace obsluhy v režimu CQ
13.5.3 Metoda WFQ
WFQ pracuje na principu rozdělení toku do více obslužných front na základě jejich klasifikace.
Klasifikace bývá provedena nejčastěji na základě typu datového toku nebo na základě zdroje toku.
Celé dostupné přenosové pásmo je rozděleno ve vyváženém poměru mezi jednotlivé obslužné fronty.
Obslužné fronty využívají k obsluze svých požadavků přidělené pásmo. V případě že dojde
k vyprázdnění konkrétní obslužné fronty, je její přidělené pásmo dynamicky rozděleno mezi fronty u
nichž dochází k obsluze. V případě příchodu požadavku do prázdné fronty je ostatním frontám
naopak pásmo odebráno. V tomto modelu tak nevzniká situace, při které by jeden typ datového toku
zahltil celé přenosové pásmo a tím zabránil obsluze ostatních toků.
Obsluha
Klasifikace
fronty
Obr. 13.6 Ilustrace obsluhy v režimu WFQ
WFQ používá pro každý datový tok (data z určité IP adresy a portu aplikace na určitou IP adresu
a port aplikace) samostatnou frontu. Počet front se rychle mění, každá fronta má přiděleno určité
231
vážené procento z celkové přenosové rychlosti rozhraní v závislosti na počtu datových toků v daném
okamžiku. Váha je odvozena od hodnoty IP precedence.
13.5.4 Metoda PQ
PQ pracuje na principu rozdělení datového toku do front s různou prioritou. Je-li požadavek na
základě své klasifikace přiřazen do fronty s vyšší prioritou, je obsloužen dříve, než požadavek
přiřazený do fronty s prioritou nižší. Obsluha fronty s vyšší prioritou probíhá do momentu, než je tato
fronta kompletně vyprázdněna. Po jejím vyprázdnění začíná obsluha fronty s nižší prioritou. Celý
proces se opakuje až do obslužné fronty nejnižší priority. V okamžiku příchodu požadavku do fronty
s vyšší prioritou, než je priorita fronty obsluhované, je v případě obsluhy „bez přerušení“ obsloužen
stávající požadavek a až poté nově příchozí požadavek s vyšší prioritou. Nevýhodou této obslužné
metody je, že v případě stálého zaplnění fronty s vyšší prioritou nemusí být požadavky s nižší
prioritou v požadované době obslouženy. Tento model je díky svým obslužným parametrům,
dostupným zejména požadavkům zařazeným ve vyšší prioritní frontě, vhodný pro aplikace
s vysokými nároky na zpoždění přenosu, které mají nízké požadavky na přenášenou šířku pásma.
Tento obslužný model je tedy vhodný pro obsluhu provozu generovaného aplikacemi pracujícími
v reálném čase.
Obsluha
Klasifikace fronty
Prioritní
třída 1
Prioritní
třída 2
Prioritní
třída 3
Obr. 13.7 Ilustrace obsluhy v režimu PQ
13.5.5 Metoda CBWFQ
CBWFQ kombinuje vlastnosti CQ a WFQ, provoz je rozdělen do front (až 64) jako u CQ s tím, že
na rozdíl od CQ je každé frontě garantováno určité procento z přenosové rychlosti rozhraní. V rámci
jednotlivých front se používá buď FIFO nebo WFQ. V praxi se obvykle vyčlení fronty pro typy provozu,
kterým chceme garantovat určitou přenosovou rychlost. Tyto fronty používají metodu FIFO. Zbytek
provozu se umístí do zvláštní fronty, která používá metodu WFQ.
13.5.6 Metoda PQ/WFQ
PQ/WFQ je založena na kombinaci dvou jednodušších front. Fronty PQ a fronty WFQ. Principem
tohoto modelu je upřednostnění obslužné fronty PQ před frontami WFQ. WFQ v tomto modelu
zastupuje PQ frontou s nižší prioritou. Tímto obslužným modelem zajistíme jednak upřednostnění
informací citlivých na zpoždění a zároveň i obsluhu dalších informací pomocí front typu WFQ.
PQ/WFQ je tedy z hlediska obsluhy v reálného provozu výhodnější než obslužný model PQ.
232
Klasifikace Obsluha
fronty
Obr. 13.8 Ilustrace obsluhy v režimu PQ/WFQ
13.5.7 Metoda LLQ
LLQ je metoda vycházející z metody PQ/WFQ a CBWFQ. Oproti metodě PQ/WFQ zavádí
možnost rozdělení jednotlivých toků do několika tříd, u kterých je možné přiřadit specifickou část
systémových prostředků. Možné je přiřazení systémových prostředků celé prioritní frontě. Jelikož je
oproti metodě PQ/WFQ přidána možnost specifikace systémových prostředků, můžeme se setkat i
s označením PQ/CBWFQ. Z hlediska obsluhy reálného provozu je, z výše uvedených modelů, tento
model nejvhodnějším pro obsluhu provozu generovaného aplikacemi pracujícími v reálném čase.
Aby provoz z LLQ fronty neznemožnil přenos i jiných typu dat, jako se to může stát u PQ,
definuje se pro LLQ určitá maximální přenosová rychlost, po jejímž překročení se přebývající pakety
zahazují.
Klasifikace Obsluha
fronty
Obr. 13.9 Ilustrace obsluhy v režimu LLQ
13.5.8 Řízení toku a zahlcení
Jestliže totiž dojde ve směrovači k úplnému zaplnění výstupní fronty směrovače, jsou všechny
další pakety určené pro tuto linku zahazovány (mluvíme o tzv. tail drop, jelikož se zahazují pakety
na konci fronty, resp. za ním).
Pokud přes takovéto rozhraní prochází větší množství TCP spojení, budou ze všech těchto
spojení zahazovány pakety a odesílatel neobdrží několik následných potvrzení. To se projeví u
odesílatele poklesem intenzity vysílání. U TCP se používá mechanizmus oken, který reguluje, kolik
segmentů lze odeslat vysílačem bez čekání na potvrzení o jejich doručení do cíle. Čím větší je toto
„okno“, tím více segmentů se přenese za jednotku času. Naopak snížením velikosti okna se dosáhne
snížení množství vysílaných segmentů, protože se častěji čeká na potvrzení o přijetí dříve poslaných
segmentů.
233
Obr. 13.10 Využití fronty u Tail drop.
Dalším mechanizmem je algoritmus Random Early Detection (RED), který je postaven na

inteligentním zahazováním paketů, dříve než se zaplní fronta a zpomaluje tok v TCP relace.
Odesílající strana TCP reaguje na zahozené pakety zpomalením. Dochází ke globálně
synchronizovaným vlnám zahlcení, při zahlcení se začne zahazovat veškerý provoz, všechna TCP
spojení tedy zpomalí, což má za následek, že v součtu se opět část pásma uvolní a rychlost
jednotlivých TCP relací začne opět narůstat.
Důmyslnější variantou RED je Weighted Random Early Detection ( WRED), ve které jsou
různé profily dle váhy, důležitější toky zahazuje méně na základě IP Precedence a DSCP.
Další variantou je Class Based Weighted Random Early Detection (CBWRED) s rozšířením
na třídy
13.5.9 Komprese RTP a fragmentace
Efektivním nástrojem pro snížení RTP režie je použití komprese cRTP (Compressed Real-Time
Protocol) a dosáhnout snížení ze 40 Bytes RTP hlavičky na 2-3 Bytes cRTP. Použití cRTP je
omezeno na link-by-link, tzn. např. mezi dvěma směrovači.
LFI (Link Fragmentation and Interleaving) je technika, která rozdělí velké rámce na menší o
stejné velikosti a vysílá je prokládaně (dovolí mezi ně vložit jiné rámce). Výhodou je, že se jiné malé
pakety jako např. VoIP dostanou rychle na rozhraní k odeslání na linku a nemusí čekat, než se
odešle nějaký velký rámec. Zmenší se serializační zpoždění (odesílání přes výstupní rozhraní
směrovače). LFI se používá hlavně na pomalých linkách, kde je může být velké serializační
zpoždění,, např. odeslání 1500B přes linku 64kbps trvá 187,5 ms.
234
13.6 Kvalita řeči
Při přenosu hlasu pomocí nespojově orientovaného přenosu v IP síti má na výslednou kvalitu
hlasového provozu vliv více faktorů, než tomu bylo v případě přenosu hlasu klasickými
telekomunikačními technologiemi [har]. Jednotlivými faktory, které mají v prostředí VoIP vliv na
kvalitu hovoru jsou zpoždění, kolísání zpoždění, ztráta paketů, posloupnost paketů, použitý kodek a
nakonec i echo (ozvěna). Hodnocení kvality hovoru, na který má vliv řada různých faktorů, není zcela
triviálním úkolem. Pro komplexní hodnocení kvality je vhodné použít jednotný parametr, pomocí
něhož jsme schopni kvalitu vyjádřit. V prvé řadě je nutné provést základní klasifikaci kvality, kterou si
rozdělíme na:
 poslechovou LQ (Listening Quality),

 konverzační CQ (Conversational Quality),
 a očekávanou EQ (Estimated Quality).
Kvalita hovoru CQ je v telefonii klíčovou záležitostí a definovat její úroveň je úkol velmi obtížný,
protože kvalita je individuální. Je vysoce pravděpodobné, že kvalita jednoho hovoru bude různými
osobami posuzována rozdílně a je rovněž pravděpodobné, že při opakovaném posuzování stejného
vzorku hovoru jednou osobou dojdeme k různým výsledkům.
Při hodnocení kvality se používá stupnice MOS (Mean Opinion Score). Při subjektivním
hodnocení posluchači používají hodnoty 1 až 5, kde 5 odpovídá nejlepší kvalitě a 1 nejhorší kvalitě.
Z jednotlivých hodnocení je určen aritmetický průměr – MOS.
 5 - vynikající kvalita, neznatelné rušení,

 4 - dobrá kvalita, rušení lze rozpoznat, ale není obtěžující,
 3 - kvalita je průměrná, rušení lze rozpoznat a mírně obtěžuje,
 2 - kvalita je nízká, rušení obtěžuje, je nutno vyvinout úsilí při snaze porozumět.
 1 - špatná kvalita, rušení velmi obtěžuje, řeč je nesrozumitelná.
Pro hodnocení kvality hovoru je vhodnější použití objektivního hodnocení, které poskytne MOS
co nejvíce korelující se subjektivním názorem. Hodnotící model, který byl vyvíjen s ohledem na VoIP,
je specifikován v doporučení ITU-T G.107 a nazývá se E-model [har]. Jedná se o výpočetní model,
který patří mezi neintrusivní přístupy. Myšlenka je následující, na základě znalostí přenosové trasy
lze pomocí E-modelu vypočíst míru degradace řečového signálu průchodem přenosovou trasou a
spočíst očekávaný MOS (resp. R-faktor, odpovídá konverzační kvalitě a lze přepočíst na MOS).
Výsledkem E-modelu je skalár, R-faktor nabývající hodnoty 0 až 100 (pro úzkopásmové kodeky
0 až 94 a pro širokopásmové 0 až 129), slovní prezentace je uvedena v tab. 13.3 a lze nalézt tyto
kritické hodnoty:
 R<50 , telefonii s takovouto hodnotou R není doporučeno používat,

 50<R<70, hovory jsou problémové, uživatelé jsou nespokojeni,
 R>70, převládá spokojenost.
235
Tab. 13.3 Hodnocení kvality R-faktorem a MOS.
Rozsah Rozsah
Kvalita hovoru Spokojenost uživatelů
R - faktoru MOS
90 ≤ R < 100 >4,3 Nejlepší (Bust) Velmi spokojení
80 ≤ R < 90 4,0-4,3 Vysoká (High) Spokojení
70 ≤ R < 80 3,6-4,0 Střední (Medium) Někteří uživatelé nespokojení
60 ≤ R < 70 3,1-3,6 Nízká (Low) Mnoho uživatelů je nespokojených
50 ≤ R < 60 2,6-3,1 Špatná (Poor) Skoro všichni jsou nespokojení
Principem E-modelu je sčítání jednotlivých faktorů ovlivňujících celkovou kvalitu, a proto je

hodnotící faktor R kombinací sčítání a odečítání jednotlivých komponent, což prezentuje rovnice
(13.1).
R = R 0 - IS  ID  Ie-eff  A (13.1)
V této rovnici Ro představuje úroveň odstupu signálu od šumu SNR zahrnující jak zdroj rušení el.
obvody, tak i hluk v místnosti.
Faktor Is zahrnuje vliv snížení kvality hovoru působící víceméně souběžně s vlastním hlasovým
signálem, jde tedy o změnu úrovně signálu.
Faktor Id představuje vlivy, které jsou způsobeny zpožděním
Ie-eff je efektivní faktor zařízení, který zahrnuje nejen vliv zařízení (vliv použitého kodeku –
původní faktor zařízení) ale i ztrátovost. Tento faktor v revizi E-modelu z roku 2002 nahradil faktor Ie
používaný v dřívějším E-modelu z roku 2000, každopádně Ie-eff zahrnuje ve svém výpočtu i Ie, který
tvoří jednu z komponent efektivního faktoru zařízení. Hodnoty Ie jsou publikovány jako dodatky
doporučení ITU-T G.113 a je proto vhodnější použít aktuální hodnoty Ie přímo ze stránek ITU-T
[G113]. Například pro kodek G.711 je hodnota Ie=0 a pro G.729 Ie=10.
Posledním parametrem je faktor zvýhodnění A umožňující kompenzaci nepříznivých faktorů.

Faktor zvýhodnění A nemá žádnou souvislost k ostatním přenosovým parametrům a zvýhodňuje
určité typy terminálů, které svým charakterem mají vliv na vynaložení úsilí porozumění při jejich
použití.
236
13.7 Vliv zabezpečení na kvalitu hovoru
V kapitole 1.5 je vysvětlen způsob zabezpečení pomocí SRTP a ZRTP. Formát paketu přináší
minimální overhead, který je v poli authentication tag (80 bitů nebo 32 bitů), vlastní šifrování AES v
CM režimu má vlastnosti proudové šifry a nedochází k vkládání dalších výplňových bitů. Významný
overhead je především v souvislosti s TLS a IPsec, kde jsou používány blokové šifry.
13.7.1 RTP přes TLS
Transport Layer Security (TLS) je protokol umožňující zabezpečenou komunikaci v IP sítích, data
na aplikační vrstvě jsou šifrovány. Při sestavování TLS spojení se obě strany nejdříve dohodnou na
podporovaných algoritmech, vymění si klíče a autentizují se se na základě certifikátu, při autentizaci
se používá asymetrická kryptografie. Šifrování provozu se již provádí symetrickou šifrou. Jestliže
předpokládáme navýšení RTP toku vlivem šifrování v TLS, tak můžeme vyloučit proudové šifry,
neboť zde jednak nedochází k doplňování bloků užitečné zátěže a jednak se v TLS prakticky
nepoužívají.
Obr. 13.11 Zpracování RTP paketu v CBC módu
Blokové šifry mají několik schémat, ze kterých je TLS provozováno v CBC módu, viz. obr. 13.11
(resp. 1.8 v kapitole 1.5). Jedná se režim řetězové blokové šifry (Cipher Block Chaining), inicializační
vektor se sečte na členu XOR s prvním blokem užitečné zátěže, následně jsou data šifrována
vhodným kryptografickým algoritmem a zároveň slouží jako vstup do dalšího bloku, takto dochází k
237
řetězení označovaného jako CBC. Obr. 13.11 znázorňuje rozdělení jednoho RTP paketu do N bloků,
každý blok má stejnou velikost, která v případě šifrovacího algoritmu AES má 128 bitů. Zde pozor na
záměnu s vlastní klíčem v AES algoritmu, ten může mít jinou velikost (128, 192 nebo 256 bitů), blok
má ale stejnou délku 128 bitů. Pokud se aplikují jiné algoritmy, tak v případě DES, 3DES a Blow Fish
je velikost bloku 64 bitů.
Základními kroky předcházející odeslání hlasu v RTP paketu je kódování určitým typem kodeku
a paketizace. RTP pakety jsou odesílány v dedikovaných intervalech a načasování odeslání bude
záviset jednak na velikosti užitečné zátěže a jednak rychlosti výstupního toku z kodéru. Základní
rovnice, která vyjadřuje časování odesílání RTP je vyjádřena v rovnici 1.7 v kapitole 1.9 a aplikací
vztahů 1.8 a 1.9 dospějeme k vyjádření hodnoty nárokovaného pásma RTP tok (13.2).
M
SFi
BWM   (13.2)
i 1 t i
3
Velikost rámce SF je dána součtem hlaviček na linkové, síťové a transportní vrstvě H
j 1
j
s velikostí zprávy na aplikační vrstvě (13.3) a t [s] je časování (timing odesílání RTP).
3
SF  SAL   H j (13.3)
j 1
Ačkoliv TLS protokol nese v názvu označení transportní, tak ve skutečnosti je umístěn mezi
transportní a aplikační vrstvou, což je v TCP/IP modelu poněkud zavádějící. TLS šifruje data
aplikační vrstvy, ale transportní vrstva je nedotčena. Nebudeme tedy zasahovat do rovnic vyjadřující
velikost na transportní vrstvě, ale nahradíme velikost zprávy na aplikační vrstvě za parametr
vyjadřující velikost zprávy po aplikaci TLS. Substituce odpovídá výše uvedenému popisu umístění
TLS v TCP/IP modelu a její vyjádření je provedeno následovně:
S 
STLS  C0   AL   BS (13.4)
 BS 
Symbol  x  označuje ceiling funkci pro kterou platí  x   min n   

x  n ,což znamená, že
ceiling funkce pro x vrátí nejbližší celé číslo, které je větší nebo rovno x. Ceiling funkci definoval
poprvé M. Schroeder [schr] v roce 1991 a symbol byl označen K. Iversonem v roce 1994. Parametr
představuje velikost bloku ve režimu CBC, jehož vytvoření bylo již vysvětleno. Užívané hodnoty 64 a
128 bitů závisí na použitém kryptografickém algoritmu (AES, DES, Triple DES, Blow Fish).
Jelikož implementace OpenVPN přidává další blok konstantní velikosti, tak byla zavedena
konstanta C 0 a výchozí hodnota TLS je pro C0  0 , v případě různých implementací TLS ve VPN
může nabývat různých hodnot, např. pro OpenVPN a CBC s velikostí bloků 64 bitů je C0  600 bitů a
C0  664 bitů pro OpenVPN v CBC režimu s šifrou používající bloky 128 bitů.
238
Tab. 13.4 Srovnání RTP vs. TLS a TLS/OpenVPN
∆t RTP TLS TLS/OpenVPN
Kodek [ms] [kbps] [kbps] [kbps]
G.711 PCM 20 90,40 96,80 130,00
G.729 CS-ACELP 20 34,4 39,2 72,4
G.723.1 ACELP 30 22,93 26,13 48,27
Údaje v tabulce byly vypočteny pro 802.3 Ethernet rámce a TLS v CBC s AES-128. Typická
paketizace RTP je u G.729 ∆t = 20 ms, je zde vidět markantní rozdíl mezi RTP nešifrovaným
BW=34,4 kbit/s a šifrovaným TLS/OpenVPN s více než dvojnásobnými nároky BW=72,4 kbit/s.
Obr. 13.12 Závislost pásma na časování u G.711 v TLS s AES šifrou
Obdobně můžeme konstatovat, že u G.711 kodeku, viz. obr. 13.12, kde rovněž typické
rozestupy RTP paketů jsou ∆t = 20 ms, vychází v OpenVPN BW=130 kbit/s oproti BW=90,4 kbit/s
239
nešifrovaného RTP. Typické časové odstupy RTP paketů u G.723.1 kodeku jsou ∆t = 30 ms. Zjištěné
údaje se pochopitelně musí zohlednit při plánování síťových kapacit VoIP provozu poskytovateli IP
telefonie.
Zajímavé by mohlo býti použití protokolu DTLS (Datagram TLS) RFC 4347 Jedná se o obdobu
TLS, která je upravena pro spolupráci s protokolem UDP, v DTLS může nalézt zabezpečení řada
aplikací vyžadující nízké zpoždění za cenu možné ztrátovosti paketů a VoIP mezi ně určitě patří.
13.7.2 RTP přes IPsec
Šifrování na síťové vrstvě IPsec se oproti TLS používá v menším měřítku. IPsec umožňuje
zabezpečit komunikaci přes IP protokol a to autentizací a šifrováním každého datagramu toku.
Obsahuje protokoly pro výměnu vzájemné autentizace mezi komunikujícími agenty a výměnu
šifrovacích klíčů. Zabezpečení je provedeno pomocí dvou protokolů AH (Authentication Header) dle
RFC 4302 a ESP (Encapsulation Security Payload) dle RFC 4303. AH implementuje autentizaci pro
datový tok a můžeme analyzovat tyto situace:
 V AH transportním módu je IP paket pouze modifikován přidáním AH hlavičky mezi IP

hlavičku a a zbytek TCP paketu. V původní IP hlavičce je přepsán protocol code , tak, aby
došlo k propojení IP hlavičky s AH hlavičkou.
 V tunelovém módu se na rozdíl od transportního módu enkapsuluje celý paket včetně IP
hlavičky, to umožňuje, aby nový paket měl jinou zdrojovou a cílovou IP adresu než má
původní neenkapsulovaný paket. Tato vlastnost umožňuje vytvoření virtuálního tunelu.
Pokud IPsec pracuje v tunelovém módu, tak v poli next header hlavičky AH bude hodnota
IP.
ESP dokáže data nejenom autentizovat,ale také šifrovat. Zatímco AH přidává k zabezpečenému
paketu novou hlavičku, ESP obklopí množství užitečné informace IP paketu. Tím je šifrování pomocí
ESP komplikovanější než autentizace pomocí AH. Kromě polí, které jsou obsaženy i v AH hlavičce,
obsahuje ESP hlavička navíc pole padding, které slouží k doplnění do odpovídající velikosti paketu
při využití blokových šifer (opět převažuje CBC). A opět můžeme uvést dvě situace, a to pro
transportní a tunelový mód:
 transportní mód, stejně jako u AH, enkapsuluje pouze užitečnou informaci, v datagramu,
tzn. od síťové vrstvy nahoru, původní IP hlavička je v datagramu zachována, zdrojová ani
cílová IP adresa se nemění,
 ESP v tunelovém módu je velice podobné tradičnímu VPN, enkapsuluje celý IP datagram,
viz. obr 13.13.
Obr. 13.13 Formát datagramu IPsec v tunelovaném módu ESP+AH

240
U AH autentizace bylo možné podle obsahu pole next header v nově vytvořené IP hlavičce určit,
zda se jedná o transportní či tunelový mód. U ESP je totiž toto pole součástí zašifrovaného obsahu.
Prakticky se používá v drtivé většině tunelový mód ESP pro realizaci VPN kombinovaný s AH
autentizací a proto se budeme zabývat pouze tunelovým módem, viz. obr 13.13.
Pro výpočet lze využít rovnici, kde je nutné k velikosti užitečné zátěže SAL vyjádřit celkový
3
příspěvek hlaviček jednotlivých vrstev H
j 1
j . Empiricky bylo zjištěno, že výpočet může být podstatně
zjednodušen a přitom poskytne relevantní výsledky, byl prověřen vzorek tří set hovorů přes IPsec.
Pro tunelový ESP mód vložený do AH zavedeme konstanty IPsec pro typické velikosti užitečné
zátěže:
 G.711, HIPsec=704 b
 G.729, HIPsec=672 b
 G.723.1 (5,3 kbit/s), HIPsec=672 b
Do rovnice dosazujeme výše uvedené hodnoty pro IPsec jako H2.
 3

 H RTP 
 H 
j
BWM  M  CR  1  
j 1
(13.5)
 P 
 S 
 
Tab. 13.5 Srovnání RTP vs. SRTP a IPsec
∆t RTP SRTP IPsec
Kodek [ms] [kbps] [kbps] [kbps]
G.711 PCM 20 90,40 94,4 117,6
G.729 CS-ACELP 20 34,4 38,4 60
G.723.1 ACELP 30 22,93 25,6 40
241
14 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. 14.1 Podpora WebRTC v Asterisku
242
Asterisk podporuje WebRTC od verze 11, viz. obr. 14.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. 14.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. 14.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. 14.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 .
243
enabled=yes
bindaddr=0.0.0.0
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. 14.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

244
; encryption media encryption is a requirement of rtcweb the following must be added to the peer,
user, or friend to enable it.
245
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.
246
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
247
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,
248
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. 308-
312, 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.
249
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
250
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

251
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
252
Autor: Miroslav Vozňák
Katedra: Katedra telekomunikační techniky
Název: Technologie a protokoly multimediálních komunikací pro integrovanou výuku
VUT a VŠB-TUO
Místo, rok, vydání: Ostrava, 2014, 1. vydání
Počet stran: 252
Vydala: Vysoká škola báňská-Technická univerzita Ostrava
Náklad CD-ROM, 500 ks
Neprodejné
ISBN 978-80-248-3326-2

OPVK VoIP 2014 Skripta Rev32

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OPVK VoIP 2014 Skripta Rev32

Uploaded by

Copyright:

Available Formats

VYSOKÁ ŠKOLA BÁŇSKÁ–TECHNICKÁ UNIVERZITA OSTRAVA

Fakulta elektrotechniky a informatiky

Technologie a protokoly multimediálních

Vznik těchto skript byl podpořen projektem č. CZ.1.07/2.2.00/28.0062

Vznik skript byl podpořen projektem č. CZ.1.07/2.2.00/28.0062 Evropského sociálního fondu a

Tato publikace neprošla redakční ani jazykovou úpravou.

© Miroslav Vozňák, 2014, VŠB-Technická univerzita Ostrava

Autor: Miroslav Vozňák

V Ostravě, leden 2014 Miroslav Vozňák

Miroslav Vozňák, nar. 1971, je docentem Fakulty elektrotechniky a

2 Standard ITU-T H.323 25

5 Základy protokolu SIP 73

6 Další metody rozšiřující SIP 109

7 Využití DNS pro IP telefonii 131

8 SIPp a jeho použití k emulaci SIP relací 139

9 NAT vs. IP telefonie 152

10 MGCP a IAX2 protokol 161

13 Aspekty kvality IP telefonie 222

14 WebRTC a nové směry v IP telefonii 242

1 Přenos sítí Internet v reálném čase

Obr.1.1. Struktura zprávy pro real-time přenos.

1.1 Real Time Protocol

 V je verze. Určuje verzi RTP,

Obr.1.2. Jednotlivá pole RTP dle specifikace RFC 1889.

Obr. 1.3. Formát pole Payload Type.

V současné době prošel Real-Time protokol třemi verzemi, a to:

1.2 Timestamp a rozptyl zpoždění

Obr. 1.4. Inkrementace hodnoty pole timestamp.

Obr. 1.5. Rozptyl zpoždění zjištěný při příjmu RTP toku.

1.3 Stanovení zpoždění z RTP

RTD  ESD(A)  ESD(B)

1.4 Řídící protokol RTCP

 SR (Sender Report) – soubor statistik od odesílatelů, posílá se aktuální identifikace zdroje

1.5 Zabezpečení přenosu RTP

1.5.1 Zabezpečení pomocí SRTP

Obr. 1.6. HMAC-SHA1 funkce

Obr. 1.7. Obsah polí hlavičky SRTP

Obr. 1.8. Režim šifrování OFB.

Obr. 1.9. CTR režim šifrování.

Obr. 1.10. Blokové schéma šifrování obsahu RTP

IV  (k s  216 )  (SSRC  264 )  (i  216 ) (1.6)

Obr. 1.11. Odvození klíčů pro šifrovací schéma.

Session Description Protocol Version (v): 0

1.5.2 Návrh vylepšení SRTP pomocí ZRTP

 detekce, zda-li účastníci podporují ZRTP implementaci,

 AES Counter Mode s délkou klíče 128 bit,

 3072 bit Diffie - Hellman hodnoty,

Obr. 1.12. Princip DH algoritmu.

1.6 Přenos DTMF a jiných tónů přes RTP

 in-band, v pásmu 300-3400 Hz pomocí PCM (G.711)

 první pro přenos DTMF čísel, kontrolních tónů a signálů trunku

 rozdělení dlouhých událostí do segmentů,

1.7 SCTP Stream Control Transmission Protocol

Obr. 1.14. 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é

 Ověřovací a potvrzovací mechanizmy - SCTP má vyšší rezistenci oproti DoS útokům,

1.8 Audio v přenosovém řetězci od odesílatele k příjemci

 u odesílatele dochází k paketizaci audia a odeslání RTP paketů,

 paketizační zpoždění (packetization) a zpoždění v kodéru (coder),

Obr. 1.15. Identifikace míst komunikačního řetězce, kde vzniká zpoždění.

 audio je kódováno na kodéru (např. do formátu PCM),

Obr. 1.16. Cesta audia od odesílatele a jeho zpracování u příjemce.

Obr. 1.17. Řazení ve frontách směrovačů.