Voice over IP - ICT a elektro pro praxi

Výukový program:
ICT a elektrotechnika pro praxi
Voice over IP
Miroslav Vozňák
Filip Řezáč
2010
© Miroslav Vozňák a Filip Řezáč, 2010
Fakulta elektrotechniky a informatiky
Vysoká škola báňská – Technická univerzita Ostrava
17. listopadu 15, 708 00 Ostrava Poruba
Výukový program:
ICT a elektrotechnika pro praxi
Název modulu:
Voice over IP
Název:
Autor:
Vydání:
Místo:
Rok:
Vydavatel:
Počet stran:
Voice over IP
Miroslav Vozňák, Filip Řezáč
první
Ostrava
2010
VŠB – Technická univerzita Ostrava
110
Neprodejné
2
PŘEDMLUVA
Výukový text s názvem Voice over IP reflektuje na současný trend hlasových komunikačních
systémů. 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,
tehdy v prenatálním věku 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 defacto 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. Autorský
kolektiv si je vědom, že nejlepší cestou k pochopení výkladu a souvislostí je experiment, a proto je
třetí část publikace věnována praktickým příkladům.
Na publikaci se podíleli Miroslav Vozňák a Filip Řezáč. Prvně uvedený je garantem publikace a
je na pozici docenta na Fakultě elektrotechniky a informatiky VŠB-Technické univerzity v Ostravě.
Filip Řezáč je asistentem na stejné fakultě, oba autoři působí na Katedře telekomunikační techniky.
Poděkování za pomoc při realizaci publikace patří Martinu Tomešovi, který se jako student
Fakulty elektrotechniky a informatiky v Ostravě podílel na tvorbě obrázků publikace a praktických
příkladech konfigurace Asterisku.
Miroslav Vozňák a Filip Řezáč
V Ostravě, Listopad 2010
3
OBSAH
1 Přenos sítí Internet v reálném čase
7
1.1 Real Time Protocol
7
1.2 Timestamp a rozptyl zpoždění
9
1.3 Stanovení zpoždění z RTP
10
1.4 Řídící protokol RTCP
11
1.5 Zabezpečení přenosu RTP
11
1.5.1 Zabezpečení pomocí SRTP
11
1.5.2 Návrh vylepšení SRTP pomocí ZRTP
16
1.6 Přenos DTMF a jiných tónů přes RTP
17
1.7 Audio v přenosovém řetězci od odesílatele k příjemci
17
1.8 Nároky na přenos audia v IP sítích
19
1.9 Kodeky
20
1.9.1 PCM
21
1.9.2 ADPCM
22
1.9.3 LPC
22
1.9.4 CELP
23
2 Protokol SIP
26
2.1 Základní popis protokolu SIP
26
2.2 Prvky SIP řešení
28
2.2.1 User Agent a Back to Back User Agent
28
2.2.2 SIP Proxy Server
30
2.2.3 SIP Registrar Server
32
2.2.4 SIP Redirect Server
32
2.3 SIP žádosti a odpovědi
33
2.3.1 Základní popis SIP hlavičky typické žádosti
33
2.3.2 SIP metody
35
2.3.3 SIP odpovědi
36
2.3.4 Transakce
39
2.3.5 Dialog
40
2.3.6 Transakce a dialog v příkladu
42
2.3.7 SIP časovače a retransmise
44
2.3.8 Zabezpečení v SIPu
45
2.4 Registrace
46
2.5 Směrování
47
2.5.1 Směrování dle RURI a Via
48
2.5.2 SIP trapezoid
49
2.5.3 Udržení SIP Proxy v signalizační trase
53
4
2.6 SDP- protokol popisu relace
54
2.6.1 Konstrukce položek SDP pro komunikaci SIP/SDP
56
2.6.2 Offer/Answer model
57
3 Asterisk
59
3.1 Popis Asterisku
59
3.1.1 Režimy Asterisku
60
3.1.2 Kodeky a prokoly Asterisku
61
3.1.3 Verze Asterisku
62
3.2 Instalace Asterisku
62
3.2.1 Instalace pomocí balíčku s příponou .deb
63
3.2.2 Instalace pomocí balíčku s příponou .rpm
63
3.2.3 Instalace pomocí kompilace zdrojových kódů
64
3.3 Úvod do konfigurace SIPu a plánu volby
67
3.3.1 Konfigurace Asterisku
68
3.3.2 Spuštění, zavolání „Hello—World“ a zastavení Asterisku
68
3.3.3 Volání „Hello-World“ pomocí SIP telefonu
69
3.3.4 Minimální konfigurace Asterisku se dvěma SIP účty
70
3.3.5 Nastavení práv na základě kontextů
71
3.4 Dialplan
72
3.4.1 Kontexty - Contexts
72
3.4.2 Pravidla - Extensions
72
3.4.3 Priority - Priorities
73
3.4.4 Vzory – Pattern Matching
74
3.4.5 Vložené kontexty – Include Statements
75
3.4.6 Časové Vložené kontexty
75
3.4.7 Proměnná ${EXTEN} a funkce ${CALLERID(num)}
76
3.4.8 Programová struktura
76
3.4.9 Aplikace Set ( )
77
3.4.10 Štítky a Goto ( )
77
3.4.11 Smyčky a While ( )
78
3.4.12 Podmínka a Gotoif ( )
78
3.4.13 Podprogramy a Gosub ( )
79
3.4.14 Proměnné
79
3.4.15 Makra
81
3.5 Asterisk Extension Language (AEL)
82
3.5.1 CLI příkazy pro AEL
82
3.5.2 Aelparse
82
3.5.3 Srovnání extensions.conf s extensions.ael
82
3.5.4 Kontexty, extensions a priority v AEL
83
3.5.5 Vložené kontexty – Include Statements v AEL
83
5
3.5.6 Štítky, goto a přeskakování v AEL
84
3.5.7 Podmínky v AEL
85
3.5.8 Smyčky v AEL
87
3.5.9 Makra
88
3.5.10 Filtrování na základě ID volajícího
89
3.6 Voicemail
89
3.7 IVR – Interactive Voice Reponse
90
3.7.1 Jednoduché IVR
91
3.7.2 Neplatný vstup (extension i)
91
3.7.3 Pauzy
91
3.7.4 Víceúrovňové IVR
92
3.8 Databáze Asterisku
93
3.8.1 Zápis hodnot do databáze
93
3.8.2 Čtení hodnot z databáze
94
3.8.3 Mazání hodnot z databáze
94
3.8.4 Přístup do databáze z CLI
94
3.8.5 Zápis hodnot do databáze pomocí CLI
94
3.8.6 Čtení hodnot z databáze pomocí CLI
94
3.8.7 Mazání hodnot z databáze pomocí CLI
95
3.8.8 Zobrazení obsahu databáze v CLI
95
3.8.9 Přístup do databáze z příkazové řádky
95
3.8.10 Záloha databáze
96
3.8.11 Příklad přesměrování
96
3.9 Služby Asterisku
97
4 Asterisk v praktických příkladech
99
4.1 Nastavení SIP účtů
99
4.2 Nastavení IAX účtů
100
4.3 Dialplan a jeho nastavení
100
4.4 Další užitečná nastavení pro Asterisk
101
4.4.1 Rozšířené nastavení SIP – povolení videopřenosu
101
4.4.2 Peering mezi dvěma Asterisky
101
4.4.3 Zabezpečení médií v Asterisku pomocí SRTP
104
4.4.4 Zabezpečení signalizace v Asterisku pomocí SIPS
105
5 Literatura
107
6 Rejstřík
109
6
Přenos sítí Internet v reálném čase
1
Transportní protokoly Internetu nabízí spolehlivou službu s potvrzováním doručených datagramů
pomocí spojově orientovaného protokolu TCP (Transmission Control Protocol) anebo nespolehlivou
službu na nespojově orientovaném protokolu UDP (User Datagram Protocol). UDP protokol přidává k
IP záhlaví důležitá pole, kterými jsou: zdrojový a cílový port služby, délka přenášených dat včetně
záhlaví a kontrolní součet pseudozáhlaví. Nepochybně stojí za zmínku, že UDP nezaručuje doručení
ve správném pořadí, což některým aplikacím přináší komplikace. Je zřejmé, že u požadavku na realtime přenos není možné použít službu s potvrzováním datagramů, neboť informace pozbývá svou
platnost s časem a pro IP telefonii je nutné použit transportní službu zajišťovanou UDP [voz92]. 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. [voz92].
Obr.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. 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. 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.2 :
•
•
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,
7
•
•
•
•
•
•
•
•
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.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), přičemž portům RTP
jsou přidělována sudá čísla.
port_RTCP=port_RTP+1
(1)
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).
8
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]. 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 (2).
∆t=
timestamp{N+1} − timestamp{N}
(2)
sampling_frequency
Vzorkovací kmitočet je obvykle 8KHz, 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.3. 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 8KHz 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. 3. 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).
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:
Di = (R i − R i −1 ) − (Si − Si −1 ) = (R i − Si ) − (R i −1 − Si −1 )
(3)
Podmínkou platnosti vztahu je, že RTP pakety jsou přijaty z jednoho zdroje synchronizace (SSRC
pole v RTP hlavičce).
9
Obr. 4. 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 [cad]. 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ě.
J i = J i −1 +
1.3
[ Di − J i −1 ]
15 D
= J i −1 ⋅ + i
16
16 16
(4)
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 [voz70], [voz73] a [voz92].
OWPD =
RTD + ESD(A) + ESD(B)
2
(5)
Jednosměrné síťové zpoždění OWPD (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 (5).
10
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:
•
•
•
•
•
1.5
SR (Sender Report) – soubor statistik od odesílatelů, posílá se aktuální identifikace zdroje
synchronizace (SSRC), časová značka (timestamp), počet odeslaných paketů a odeslaných
bajtů,
RR (Receiver Report) – soubor statistik od příjemců, obsahuje jednak podíl ztracených paketů
k celkovému množství očekávaných, počet ztracených paketů, aktuální sekvenční číslo (SN),
jitter, poslední timestamp a čas, který uběhl od poslední zprávy SR,
SDES (Source DEScription) – vlastnosti odesílatelů RTP komunikace (jejich „vizitky“), jednak
je to SSRC a jméno (obvykle URI),
BYE (End message) – signalizuje ukončení relace;
APP – funkce specifické pro jednotlivé aplikace.
Zabezpečení přenosu RTP
Použitím nešifrovaného přenosu pomocí RTP zvyšujeme riziko odposlechu hovoru [voz191],
[voz193]. 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í [voz138], [voz166] a [voz194].
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.
11
Obr. 5. 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á. 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. 10. MKI zvyšuje bezpečnost, protože během jedné relace mohou být klíče
střídány [voz120].
Obr. 6. Obsah polí hlavičky SRTP
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. 7.
12
Obr. 7. Režim šifrování OFB.
První výstupní blok je vytvořen šifrovací funkcí CIPHK z inicializačního vektoru a je zároveň
vstupem do druhého bloku, kde po aplikaci šifrovacího algoritmu získáme druhý výstupní blok, který
je opět vstupem do dalšího.
Obr. 8. CTR režim šifrování.
Š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.
13
Čítačový režim CTR, viz. obr. 8, je zjednodušenou verzi zpětnovazební šifry OFB, kdy při
šifrování je namísto vazby na předchozí blok použita vazba s hodnotou inkrementálního čítače, viz.
obrázek. Opět dochází převodu blokové šifry na proudovou. CTR rovněž využívá inicializační
hodnotu, která se načte do vstupního registru (Counter 1) a po zašifrování funkcí CIPHK dostáváme
první výstupní blok, který se sčítá na členu XOR s otevřeným textem. Poté doje k aktualizaci čítače
(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. 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. 9. Blokové schéma šifrování obsahu RTP
Podívejme se nyní na aplikaci AES-CTR v SRTP, viz. obr. 9. 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 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 (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 ⋅ 2 64 ) ⊕ (i ⋅ 216 )
(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. 10. 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).
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ého přenosu důležitého klíče
master_key uvádíme příklad zachycený při použití MS Messenger, pod obr. 10. Pro přenos klíče bylo
použito kódování base64, což je triviální způsob, 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á.
14
Obr. 10. Odvození klíčů pro šifrovací schéma.
Použití base64 k ochraně hesla je přípustné pouze v případě zabezpečení SIP pomocí TLS
anebo S/Mime, což je vysvětleno v kapitole věnované zabezpečení SIPu.
k=base64:D0c7ni7jtkF+mJJY7bfXioIhnJe6rrckZ46GSTvXElE=
Použití v dalším příkladu je ukázkou správné implementace ochrany master_key v nešifrovaném
SIP protokolu. Pro utajení hlavního klíče během přenosu je použita kryptografická hašovací funkce
HMAC-SHA1. Využívá se způsobu vyjednávání klíčů popsaného v RFC 4568 z roku 2006, jedná se
o SDES (Security Descriptions for Media Streams) .
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
Se způsobem distribuce master_key ovšem nebyl spokojen Philip Zimmermann, který přišel
s dalším vylepšením zabezpečení transportu dat v reálném čase. 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
15
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) 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
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 [voz142]:
•
•
•
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 autentifizace, 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.
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]. 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
16
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 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:
•
•
•
1.7
in-band, v pásmu 300-3400 Hz pomocí PCM (G.711)
out-band, pomocí RFC 2833 (modifikovaný RTP)
out-band, pomocí SIP metody INFO
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. 11 [voz111]:
•
•
•
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).
17
Obr. 11. Cesta audia od odesílatele k příjemci.
Při zpracování audio signálu na straně odesílatele dochází k následujícím operacím [voz111]:
•
•
•
•
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í.
Audio Signal
Voice Encoder
Packetizer
RTP Packets
Obr. 12. 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. 13 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. 12. Následně jsou data z mezipaměti
18
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. 13. Řazení ve frontách směrovačů.
1.8
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
∆t=
kde
∆t
PS
CR
(7)
PS [b] je velikost užitečné zátěže a CR [bit/s] představuje rychlost
[s] je časování,
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). Na aplikační vrstvě můžeme do vztahu (8)
vyjádřit jednak payload PS a velikost RTP hlavičky H RTP , což je 12B.
S AL = H RTP + PS
(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 :
19
M
BWM = ∑
i =1
SFi
∆t i
(9)
Pokud všechny hovory používají stejný kodek,
kodek tak (7) a (8) do vztahu (9)) získáváme pro výpočet
výpo
nároků všech RTP toků (10).
3


H
+
H 

RTP ∑
j
j =1

BWM = M ⋅ C R ⋅  1 +


PS




(10)
Z výše uvedené rovnice můžeme
ůžeme graficky vyjádřit,
vyjád it, jak závisí nárokované pásmo na velikosti
užitečné zátěže v RTP a počtu
čtu hovor
hovorů, obr. 14. V 3D zobrazení vidíme, že s klesající velikostí
užitečné zátěže
že rostou nároky na pásmo, což je způsobeno
sobeno režií hlaviček, jejichž poměr
pom vůči
klesajícímu množství přenášené
enášené informaci roste.
Obr. 14.
1.9
Závislost pásma na velikosti zátěže
zát
a počtu hovorů
Kodeky
Kodek je zařízení
ízení nebo algoritmus, který slouží ke zmenšení jinak zbytečně
zbyteč
zbyte
velkého objemu
audiovizuálních dat. Slovo kodek vzniklo složením slov kodér a dekodér, tj. zařízení
zař
jež je na jedné
straně schopné data zakódovat a na druhé stran
straně opět rozkódovat. Při
ři použití osobního po
počítače je
typicky vstupem kodeku zvuková karta, data získaná z mikrofonního vstupu kodér zpracuje a předá
p
je RTP vrstvě,, vzniklé protokolové datové jednotky se enkapsulují v jednotlivých vrstvách OSI
modelu, až jsou nakonec vyslána příjemci.
př
Přijatá data převede do původní
ůvodní podoby dekodér a pošle
na audio výstup zvukové karty. Kodeky velmi často používají ztrátovou
ou kompresi a proto dekódovaná
data nejsou totožná s daty, která byla zakódována [voz142].
[voz
20
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í:
•
•
•
1.9.1
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í.
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í 8KHz, 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 8KHz 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.
21
1.9.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 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.
MOS
4,2
G.711
4,1
4,0
G.729
3,9
G.726
G.723.1/6,3
3,8
G.729A
3,7
G.723.1/5,3
3,6
3,5
G.728
GSM 06.10
3,4
0
Obr. 15.
1.9.3
10
20
30
40
50
60
70
Rychlost kodeku [kbit/s]
MOS v závislosti na bitové rychlosti kodeků.
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ý
22
signál zpracuje a výsledkem je signál podobný původnímu
p
signálu řřeči.
či. Protože vstupní signál se
mění v závislosti na čase,
ase, je nutné tento proces opakovat pro kratší časové
asové intervaly, tzv. rámce. Pro
rozumnou kvalitu výsledné řeči
ř či se používá 30 až 50 rámc
rámců za vteřinu. Představitelem
ředstavitelem je LPC kodek
s výstupním tokem 4,8 kbit/s nebo kodek LPC-10
LPC
s tokem 2,4 kbit/s.
1.9.4
CELP
Kódování CELP (Code Excited Linear Prediction) zásadně
zásadn vylepšuje LPC. Problém metody LPC je v
tom, že to, co zbude po odfiltrování formantů,
formant není pouze signál bzučáku.
čáku. Dů
Důvodem je, že v řeči se
vyskytují složky reprezentující třeba
eba sykot. Takovéto zvuky nebudou jednoduchým
jednoduch
LPC kodekem
správně aproximovány. Nepřesnosti
řesnosti při
p odhadu formantů způsobí,
sobí, že více informací o signálu
zůstane
stane v reziduu (zbytek po odfiltrování formant
formantů).
). To platí pro zvuky které neodpovídají
jednoduchému LPC modelu, platí to například
nap
pro zvuky generované různou
ůznou pozicí jazyka atd. Tedy
reziduum obsahuje důležité
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ů,
parametrů, frekvence a amplitudy
signálu. Vzniká tedy otázka, jak reziduum zakódovat lépe tak, aby se příliš
příliš nezvýšil nárok na ší
šířku
pásma a tyto důležité
ležité informace se p
přitom neztratily.
Jednou z nejúčinnějších
jších metod je použití codebooku. Kódová kniha je tabulka obsahující typické
průběhy
hy rezidua. Kodér potom porovn
porovnává průběh
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áší.
p enáší. Druhá strana má stejnou tabulku a
po příjmu indexu dokáže průběh
ů ěh
h rezidua z tabulky obnovit, toto reziduum potom slouží jako budič
budi pro
filtr aproximující formanty. Výsledkem je lepší aproximace hlasového signálu než v případě
p
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
průběhy rezidua
ezidua musí být velmi
rozsáhlá, pokud je ale tabulka velká, bude vyhledávání v tabulce trvat rovněž
rovněž velmi dlouho. Dalším
problémem je, že tabulka by musela obsahovat vzorky pro různě
r
vysoký hlas, taková tabulka by však
byla extrémně rozsáhlá. Tento problém se řeší vytvořením
ením dvou tabulek. Jedna tabulka je vytvo
vytvořená
při tvorbě kodeku a obsahuje vzorky pro právě
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
p
vzorky rezidua zpožděnými
ěnými o určitou
ur
hodnotu.
Právě hodnota zpoždění určuje
čuje
uje výšku hlasu, popsaný algoritmus poskytuje dobrou kvalitu p
přenášené
řeči už při šířce pásma 4,8 kbit/s. Typickými představiteli
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
LD
dle G.728 s tokem 16 kbit/s.
Tab. 1 Typ kódování, MOS, rychlost
rych
a náročnost na výpočetní výkon.
23
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ší
nejpoužívan jší kodeky, ty jsou specifikovány v doporučeních
doporu
ITU-T:
•
•
•
•
•
•
•
G.711 je základní kodek PCM,
PCM, který se používá i v klasické telefonní síti. Kvalita přenášeného
p
hlasu je totožná s kvalitou hlasu při
p běžném telefonním
lefonním hovoru, MOS má hodnotu 4,2, rámec
trvá 0,125 ms;
G.723.1 používá buď
ď kódování MP
MP-MLP
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í
ování MP-MLQ
MP
a 3,65 při použití ACELP;
G.726 kodek používá kódování ADPCM, potřebná
pot
šířka
ka pásma je 16, 24, 32 a 40 kbit/s.
Kodek může
že zpracovávat bloky rrůzné
zné délky podle toho, jak velké zpožd
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.
LD
Potřebná šířka
ka pásma je 16 kbit/s, MOS skóre je p
přibližně
3,6;
G.729 Použité kódování je CS-ACELP
CS
- Conjugate Structure Algebraic Code Excited Linear
Prediction. Rámec trvá 10 ms a potřebná
pot
šířka
ka pásma je 8 kbit/s, MOS je hodnocen 3,92;
GSM kodek, šířka
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
ením v roce 1997 byl kodek GSM EFR (Enhanced Full Rate) s rychlostí 12,2
kbit/s a rámcem 20 ms (obsahuje 244 bitů).
bit
V roce 1998 přišlo
išlo další kódovací schéma,
sch
a to
AMR kodek (Adaptive Multi-Rate),
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
tento kodek byl vyvinut firmou Global IP Sound, potřebná
pot
šířka
ka pásma je 13.33 kbit/s, rámec obsahuje úsek trvající 30 ms. Kodek umožňuje
umož
elegantní
snížení kvality přenášeného
řenášeného signálu v p
případě zpoždění
ní nebo ztráty paket
paketů. Použitý
algoritmus je Block Independent
Independent Linear Predictive Coding. Každý rámec je komprimován na
399 bitů,, které se potom př
přenáší.
V tabulce 2 můžeme vidět
ět srovnání nejpoužívanějších
nejpoužívan
kodeků, ve čtvrtém sloupci tabulky je
uvedena typické časování
asování odesílání paket
paketů,, v dalším sloupci je doba trvání rámce a po sečtení s
look-ahead (dopředným výpočetním
četním zpožděním
zpožd
u kodeků pracujících s predikcí) dostaneme celkové
minimální zpoždění,
ní, které lze u kodeku teoreticky dosáhnout.
Tab. 2 Typ kódování, rychlost, typická paketizace, rámec a zpoždění.
zpožd
V posledním řádku
ádku je použit kodek G.729A, což je dodatek ke kodeku G.729, tento dodatek
implementuje G.729 s nižší výpočetní
výpoč
náročností,
ností, G.729A vyžaduje pouze 11 MIPS, klesá ale MOS
24
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.
25
2
Protokol 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.
2.1
Základní popis protokolu SIP
SIP pracuje na aplikační vrstvě, byl navržen tak, aby byl snadno implementovatelný, rozšiřitelný a
dostatečně flexibilní. Protokol je užíván pro sestavení, modifikaci a ukončení spojení s jedním nebo
více účastníky, ale není jediným protokolem, který je potřebný pro audiovizuální komunikaci, ve
spojení se SIPem jsou nejčastěji používány ještě dva další protokoly, RTP (Real-Time Protocol) pro
přenos vlastního obsahu a SDP (Session Description Protocol) pro popis přenášeného obsahu [sin1],
[sin2].
SIP je end-to-end orientovaný signalizační protokol, což znamená, že veškerá logika je uložená v
koncových zařízeních, koncová zařízení znají i jednotlivé stavy komunikace, chování lze popsat
stavovým diagramem, ve kterém se v rámci dialogu (spojení) probíhají jednotlivé transakce (žádosti
a odpovědi). Tím je zvýšena odolnost komunikace proti chybám. Cena, která se musí zaplatit za
decentralizaci a dostupnost služby, je vyšší režie hlaviček zpráv. Nepochybně stojí za zmínku, že
end-to-end koncept SIPu je zásadně odlišný od klasického řešení PSTN (Public Switched Telephone
Network), kde logika je uložena v síti a koncová zařízení jsou primitivní. Jedním z cílů SIPu je zajistit
stejnou funkcionalitu jakou mají klasické PSTN, ale end-to-end návrh umožňuje v SIPu podstatně
snadnější implementaci nových služeb a některé z nich mohou být jen stěží nasazeny v klasických
PSTN.
SIP je textově orientovaný protokol z rysy podobnými HTTP a SMTP protokolu. HTTP a SMTP
jsou nepochybně nejúspěšnějšími a nejpoužívanějšími protokoly v Internetu, volba osvědčeného
modelu komunikace zaručuje SIPu robustnost a nadčasovost. Klient posílá požadavky na server,
který zasílá odpovědi obdobně jako u HTTP, v hlavičkách najdeme položky From, To či Subject jako
u mailové komunikace pomocí SMTP. SIP entita je vázána k doméně obsluhovanou SIP Proxy a
26
mezidoménová komunikace je tedy mezi různými SIP Proxy, výjimkou je multidoménová SIP Proxy.
SIP entity jsou identifikovány použitím SIP URI (Uniform Resource Identifier), řekli bychom
jednoduše jmennými identifikátory, jejich obecný tvar je uveden níže.
sip:user:password@host:port;uri-parameters?headers
SIP URI se skládá jednak z části username identifikující uživatele a jednak z host vztažené k
doméně neboli hostiteli, který poskytuje uživateli určité prostředky k zajištění komunikace, následuje
pole password jehož použití není doporučeno. Port je standardně 5060 na UDP, případné parametry
se oddělují středníkem a pokud je potřebné přímo do URI zadat i nějaké parametry hlavičky, tak se
uvádějí za otazníkem. Většinou ale uvidíme SIP URI v podobě jednoduché konstrukce
sip:user@host , což nápadně připomíná emailovou adresu. Příkladem SIP URI může být:
•
•
sip:[email protected]
sip:[email protected]
SIP tedy pracuje se jmennými identifikátory a číslo můžeme přeložit na URI pomocí DNS, kde
jsou k tomu určeny záznamy NAPTR (Name Authority Pointer) a technika mapování URI na tel. čísla
(standard ITU-T E.164) se nazývá ENUM (E.164 NUmber Mapping). URI je obecně prezentováno
řetězcem znaků, jehož cílem je umožnit interakci se zdrojem pomocí určitého protokolu, tzn. musí
nutně obsahovat název schématu (protokol) a adresu zdroje, za schématem následuje dvojtečka.
URI dle RFC 3986 je definováno následovně:
<scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]
Příklady pro scheme name jsou:
•
•
•
sip, sips, h323, tel, http, https,
ftp, imap, ldap, mailto, telnet, im,
pop, news, atd...
Hierarchical part nese informaci o identifikaci zdroje, obvykle začíná dvojitým lomítkem “ // „ a
následuje např.:
•
•
•
•
domain name,
IP address,
username:password@,
user@host.
Pokud je specifikováno číslo portu, tak se začíná znakem „:“, např. :5060, :8080, :8085, atd...
Query je nepovinná část, která obsahuje doplňující informace, obecná syntaxe není definována,
obvykle se objevuje ve formě <key>=<value>, kde jednotlivé hodnoty jsou odděleny znakem „&“ ,
např. key1=value1&key2=value2&key3=value3 . Fragment je nepovinná část umožňující nepřímo
identifikovat další zdroj a začíná znakem „#”.
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,
27
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í, 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 inaddr.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ů:
•
•
•
•
•
2.2
A (address record) obsahuje IPv4 adresu přiřazenou danému jménu, například neco.vsb.cz
má IP adresu 1.2.3.4, zónový soubor pro doménu vsb.cz bude obsahovat záznam,
neco IN A 1.2.3.4,
CNAME (canonical name record) je alias - jiné jméno pro jméno již zavedené, jeho definice
pomocí přezdívky umožňuje jej později snadno přestěhovat na jiný počítač, např. neco.vsb.cz
má sloužit zároveň jako nic.vsb.cz, v zónovém souboru přibude
nic
IN CNAME neco,
SOA (start of authority record) je zahajující záznam zónového souboru. Obsahuje jméno
primárního serveru, adresu elektronické pošty jejího správce a další údaje (serial, refresh,
retry, expire a TTL).
Prvky SIP řešení
Ačkoliv v nejjednodušší konfiguraci je možné použít dva UA posílající si navzájem SIP zprávy,
typická SIP síť bude obsahovat více než jeden typ prvků.
2.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
28
umožňuje jejich plnou dekompozici, což je výhodou pro velká řešení, distribuovaná architektura vede
ke zvýšení robustnosti.
Koncové body, kde vzniká a je terminována SIP relace, jsou nazývány jako user agents (UA). UA
obvykle jsou představovány koncovými terminály ve formě HW SIP telefonu nebo aplikace, SIP UA
mohou být IP telefony, Smartphones, PSTN brány (GW), IVR systémy, atd. UA jsou vztaženi k User
Agent Server (UAS) a User Agent Client (UAC). UAS a UAC jsou pouze logické entity, každý UA
obsahuje UAC a UAS:
•
•
UAC je část vysílající požadavky a přijímající odpovědi,
UAS je část přijímající požadavky a odesílající odpovědi.
IN
V
IT
E
Žádost a odpověď jsou dva základní typy SIP zpráv. Protože koncové zařízení téměř vždy
obsahuje UAC a UAS, tak používáme pouze označení UA namísto UAC a UAS. Například, volající
UA funguje jako UAC, když odesílá zprávu INVITE (požadavek na sestavení spojení) a přijímá
odpověď na požadavek. Volaný UA se chová jako UAS, když obdrží zprávu INVITE a odesílá
odpověď. Ale tato situace se mění, když volaný se rozhodne zavěsit a odesílá se zpráva BYE a
ukončuje spojení. V tomto případě se volající chová jako UAC a volaný jako UAS.
V
IN
E
IT
Obr. 16.
Rozeslání INVITE více příjemcům.
Obr. 16 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 narozdí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
[voz188] a [voz191].
29
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ů [voz133], [voz146] a [voz191].
2.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í
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.
30
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 [voz90].
Předpokládejme, že jsou dvě firmy A a B a každá z nich má svůj Proxy server. Obr. 17 ukazuje
situaci, kdy Alice z firmy A inicializuje spojení na Boba z firmy B. Uživatel Alice volá Boba a použije
URI adresu sip:[email protected]. UA neví, kam má poslat žádost o sestavení spojení, ale je
nakonfigurován tak, že veškerý odchozí provoz (outbound traffic) posílá na SIP Proxy server své
firmy A s adresou proxy.a.com. Proxy server zjistí, že uživatel sip:[email protected] je v jiné firmě a tak
vyhledá odpovídající SIP Proxy server, kam pošle žádost. Odpovídajícím serverem je proxy.b.com a
je zadán staticky v proxy serveru firmy A anebo bude Proxy vyhledán pomocí záznamu DNS SRV,
kterým je zjištěno, kdo poskytuje službu SIP v doméně b.com. Žádost tedy dorazí na proxy.b.com.
SIP Proxy ví, že Bob je aktuálně ve své kanceláři a dosažitelný na telefonu na svém stole, jež má IP
adresu 1.2.3.4, takže SIP Proxy přeposílá žádost INVITE.
#1
Obr. 17.
#5
TE
VI
IN
Sestavení spojení přes dvě SIP Proxy.
31
IN
VI
TE
2.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).
Obr. 18. Průběh registrace.
V lokalizační databázi v našem případě došlo k namapování adresy User URI sip:[email protected] k
adrese Device URI sip:[email protected]:5060. Lokalizační databáze je pak užívána Proxy serverem.
Když inbound Proxy server obdrží žádost pro sip:[email protected], vyhledá v lokalizační databázi záznam
sip:[email protected]:5060 a na danou IP adresu pošle žádost. Registrar server je velmi často pouze jako
logická část SIP serveru, jelikož je těsně svázán s Proxy serverem. Obr. 18 znázorňuje typickou SIP
registraci. Zpráva REGISTER je vyslána do Registrar serveru a obsahuje adresu záznamu User URI
sip:[email protected] a kontaktní adresu Device URI sip:[email protected]:5060 , kde 1.2.3.4 je IP adresa
telefonu. Registrar zaznamenává tyto informace do lokalizační databáze. Pokud registrace proběhla
správně, tak Registrar server posílá odpověď 200 OK a proces registrace je ukončen. Každá
registrace má limitovanou dobu platnosti, doba platnosti je v hlavičce kontaktu (Expires), do té doby
musí UA obnovit registraci, jinak bude nedostupný.
2.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. 64. 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
32
si #1
p:
bo IN
b@ VIT
vs E
#2
b.
cz
T e 302
m M
po o
ra ved
ri l
y
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. 19 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.
Obr. 19. Průběh přesměrování.
2.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ěď.
2.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ě:
33
Request-Line: INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 158.196.192.32;branch=z9hG4bK9ec4c0248acd48724710d7;rport
From: "SJphone" <sip:[email protected]>;tag=27df31582de
To: <sip:[email protected]>
Contact: <sip:[email protected]>
Call-ID: C317880624584EB9B1443F8B448CC2830x9ec4c020
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: SJphone/1.65.377a (SJ Labs)
Content-Length: 321
Content-Type: application/sdp
(v): 0
(o): - 3428274950 3428274950 IN IP4 158.196.192.32
(s): SJphone
(c): IN IP4 158.196.192.32
(t): 0 0
(m): audio 49162 RTP/AVP 18 3 8 0
(a): rtpmap:18 G729/8000
(a): rtpmap:3 GSM/8000
(a): rtpmap:8 PCMA/8000
(a): rtpmap:0 PCMU/8000
•
•
•
•
•
•
•
První řádek nám říká, že se jedná o zprávu INVITE, jež je užívána k sestavení spojení. URI
na prvním řádku sip:[email protected] se nazývá Request URI a obsahuje URI
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).
34
2.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í (reINVITE);
ACK je metoda potvrzující přijetí konečné odpovědi na žádost INVITE. Sestavení relace
používá „3-way hand-shaking“, volaný periodicky opakuje odpověď (např. 200 OK), dokud
nepřijme ACK, což indikuje, že odpověď byla doručena. Metoda ACK má řadu výjimek v
pravidlech gramatice SIPu, které budou zmíněny později;
BYE je zpráva užívána k ukončení sestaveného spojení;
CANCEL se používá ke zrušení sestavovaného spojení, když není sestaven dialog, volaný
ještě nepotvrdil konečnou odpovědí žádost INVITE a volající chce zrušit sestavování spojení;
REGISTER je žádost registrace anebo odregistrování uživatele, sváže se logická jmenná
adresa uživatele s jeho fyzickým umístěním (IP adresa a port), konkrétně jde o položky
FROM a CONTACT ze SIP hlavičky. Registrace jsou časově limitovány a je nutné je
periodicky obnovovat;
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.
35
2.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
velmi podobné žádostem, kromě prvního řádku [col], [dav]. První řádek odpovědi obsahuje verzi
protokolu (SIP/2.0) a kód odpovědi (reply code). Typická odpověď vypadá následovně:
Status-Line: SIP/2.0 200 OK
Via: SIP/2.0/UDP 158.196.192.32;branch=z9hG4bK9ec4c02048ace1a554;rport=5060
From: "SJphone" <sip:[email protected]>;tag=164235a64f6
To: <sip:[email protected]>;tag=as04503766
Call-ID: 7798248D73F3443CABCD68EE653C791C0x9ec4c020
CSeq: 2 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 312
(v): 0
(o): root 4648 4648 IN IP4 158.196.146.12
(s): session
(c): IN IP4 158.196.146.12
(t): 0 0
(m): audio 14290 RTP/AVP 0 8 3
(a): rtpmap:0 PCMU/8000
(a): rtpmap:8 PCMA/8000
(a): rtpmap:3 GSM/8000
Kód odpovědi je celé číslo z rozsahu 100 až 699 a označuje typ odpovědi. Celkem je definováno
6 tříd odpovědí, buď jsou informativní 1xx anebo finální 2xx-6xx:
•
•
•
1xx jsou dočasné informativní odpovědi, které jsou odesílány na žádosti, které byly přijaty,
ale výsledek zpracování ještě není znám, na základě této odpovědi musí odesílatel zastavit
opakování odesílání dané žádosti. Obvykle SIP Proxy servery odesílají odpovědi s kódem
100 (Trying), jestliže začínají zpracovávat INVITE a UA odesílají odpovědi s kódem 180
(Ringing), které oznamují vyzvánění volaného, kód 183 Session Progress má stejný význam
jako 180, ale je doplněn o popis médií (SDP),
2xx jsou pozitivní finální odpovědi, je to poslední odpověď, kterou odesílatel na svou
žádost dostává, vyjadřuje výsledek zpracování konkrétní žádosti. Odpovědi s kódy 200 až
299 oznamují, že požadavek byl akceptován a úspěšně zpracován, například odpověď 200
OK je vyslána, jestliže uživatel akceptuje žádost INVITE. V případě větvení zprávy INVITE
můžeme dosáhnout několik UAS a každý z nich bude akceptovat žádost. V tomto případě je
každá odpověď rozlišena parametrem tag v poli To. Každá odpověď probíhá v odlišném
dialogu s jedinečným identifikátorem dialogu,
3xx odpovědi jsou užívány k přesměrování. Tyto odpovědi dávají informaci o nové poloze
uživatele nebo alternativní službě, která má být použita. Pokud Proxy přijme žádost a
nezpracuje ji z nějakého důvodu, tak vyšle volajícímu v odpovědi požadavek na přesměrování
a vloží do odpovědi jiné umístění, které má být kontaktováno. Může to být jiná Proxy nebo
36
•
•
•
aktuální umístění volajícího (z lokalizační databáze vytvořené registrar serverem). Volající
následně znovu vyšle žádost na nové umístění, odpovědi 3xx jsou konečné,
4xx jsou negativní konečné odpovědi a znamenají problém na straně klienta. Žádost
nemohla být zpracována, protože obsahuje chybnou syntaxi,
5xx znamenají problém na straně serveru. Žádost je zřejmě v pořádku, ale server selhal při
zpracování, klient by měl obvykle požadavek zkusit znovu,
6xx představuje globální chybu a tento kód je vysílán, pokud žádost nemůže být splněna na
žádném serveru, to je odpověď obvykle vysílaná serverem, když má informaci o konkrétním
uživateli, např. UA vysílá 603 Decline response, když odmítá žádost o sestavení spojení,
Kromě odpovědi odpovídající třídy obsahuje první řádka popis reason phrase, obsažený kód je
určen ke zpracování, což je snadno analyzovatelné a popis jasně oznamuje výsledek. UA může
popis zobrazit uživateli. Přiřazení žádosti k odpovědi je na základě pole CSeq v hlavičce, kromě
pořadového čísla obsahuje také metodu korespondující žádosti, v našem případě to byla žádost
INVITE. Níže je uveden seznam odpovědí, se kterými se můžeme setkat v SIP protokolu:
1xx = informational responses
* 100 Trying
* 180 Ringing
* 181 Call Is Being Forwarded
* 182 Queued
* 183 Session Progress
2xx = success responses
* 200 OK
* 202 accepted: Used for referrals
3xx = redirection responses
* 300 Multiple Choices
* 301 Moved Permanently
* 302 Moved Temporarily
* 305 Use Proxy
* 380 Alternative Service
4xx = request failures
* 400 Bad Request
* 401 Unauthorized: Used only by registrars. Proxys should use proxy authorization 407
* 402 Payment Required (Reserved for future use)
* 403 Forbidden
* 404 Not Found: User not found
* 405 Method Not Allowed
* 406 Not Acceptable
* 407 Proxy Authentication Required
* 408 Request Timeout: Couldn't find the user in time
* 410 Gone: The user existed once, but is not available here any more.
* 413 Request Entity Too Large
* 414 Request-URI Too Long
* 415 Unsupported Media Type
* 416 Unsupported URI Scheme
* 420 Bad Extension: Bad SIP Protocol Extension used, not understood by the server
* 421 Extension Required
* 423 Interval Too Brief
37
* 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
INVITE sip:[email protected] SIP/2.0
SIP/2.0 200 OK
Via: SIP/2.0/UDP here.com:5060
From: AG <sip:[email protected]>;tag=123
To: BG <sip:[email protected]>
Call-ID: [email protected]
Cseq: 1 INVITE
Contact: AG <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 147
Via: SIP/2.0/UDP here.com:5060
From: AG <sip:[email protected]>;tag=123
To: BG <sip:[email protected]>;tag=65a35
Call-ID: [email protected]
Cseq: 1 INVITE
Contact: BG <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 134
v=0
o=UserA 28908 28908 IN IP4 here.com
s=Session SDP
c=IN IP4 100.101.102.103
t=0 0
m=audio 49 172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=UserB 28908 28908 IN IP4 there.com
s=Session SDP
c=IN IP4 110.111.112.113
t=0 0
m=audio 3456 172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Obr. 20. Žádost a odpověď
Na obr. 20 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.
38
2.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. 21. 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. 21. 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ědni za opakování odpovědi 200 OK, dokud nepřijmou ACK.
SIP entity, které sledují tyto transakce, se nazývají stateful, vytvořený stav k žádosti je spojován
s transakcí a je držen po celou dobu trvání transakce. Pokud přichází žádost nebo odpověď, tak je
zkoušeno vždy přiřazení zprávy do probíhající transakce. Aby tato operace byla proveditelná, tak
musí ze zprávy přečíst jednoznačný identifikátor transakce a porovnat jej s identifikátory
probíhajících transakcí. Jestliže takováto transakce existuje, tak dochází k jejímu doplnění o další
informace. V předchozím SIP RFC2543 (SIP 1.0) byl identifikátor transakce odvozován jako hash z
důležitých informací v hlavičce zprávy (zahrnující pole To, From, Request-URI a CSeq), což bylo
komplikované a zpomalovalo zpracování a při testech interoperability bylo zdrojem problémů. V
aktuálně používaném RFC3261 (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é
39
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. 22.
Alice's
UA
Stateful
Proxy
Stateless
Proxy
Stateful
Proxy
Bob's
UA
INVITE
100 TRYING
INVITE
INVITE
100 TRYING
100 TRYING
INVITE
100 TRYING
180 RINGING
180 RINGING
180 RINGING
200 OK
ACK
180 RINGING
200 OK
200 OK
ACK
200 OK
ACK
Media Session
Obr. 22. Rozdílné zacházení se 100 Trying u stavových transakčních strojů.
2.3.5
Dialog
V předchozím kapitole jsme si ukázali dvě transakce, viz. obr. 21, 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.
40
Caller
Callee
INVITE
100 TRYING
Transaction #1
180 RINGING
200 OK
Dialog
ACK
BYE
Transaction #2
200 OK
Obr. 23. 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);
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.
41
2.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. 68, 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: [email protected]
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:[email protected] SIP/2.0
Via: SIP/2.0/UDP 158.196.146.12:5060;branch=z9hG4bK7225f861;rport
From: "5779" <sip:[email protected]>;tag=as396d4fbf
To: <sip:[email protected]>
Contact: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Type: application/sdp
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
(a): rtpmap:0 PCMU/8000
(a): rtpmap:8 PCMA/8000
(a): rtpmap:3 GSM/8000
(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
From: "5779" <sip:[email protected]>;tag=as396d4fbf
To: "SJphone" <sip:[email protected]>
Call-ID: [email protected]
CSeq: 102 INVITE
Content-Length: 0
Server: SJphone/1.65.377a (SJ Labs)
42
#3
180 RINGING
Status-Line: SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 158.196.146.12:5060;branch=z9hG4bK7225f861;rport=5060
From: "5779" <sip:[email protected]>;tag=as396d4fbf
To: "SJphone" <sip:[email protected]>;tag=4227117d4b8
Contact: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 102 INVITE
Content-Length: 0
Server: SJphone/1.65.377a (SJ Labs)
#4
200 OK
Status-Line: SIP/2.0 200 OK
Via: SIP/2.0/UDP 158.196.146.12:5060;branch=z9hG4bK7225f861;rport=5060
From: "5779" <sip:[email protected]>;tag=as396d4fbf
To: "SJphone" <sip:[email protected]>;tag=4227117d4b8
Contact: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 102 INVITE
Content-Length: 274
Content-Type: application/sdp
Server: SJphone/1.65.377a (SJ Labs)
(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
(a): rtpmap:0 PCMU/8000
#5
ACK
Request-Line: ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 158.196.146.12:5060;branch=z9hG4bK57289016;rport
From: "5779" <sip:[email protected]>;tag=as396d4fbf
To: <sip:[email protected]>;tag=4227117d4b8
Contact: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 102 ACK
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Length: 0
#6
BYE
Request-Line: BYE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 158.196.146.12:5060;branch=z9hG4bK011c16dd;rport
From: "5779" <sip:[email protected]>;tag=as396d4fbf
To: <sip:[email protected]>;tag=4227117d4b8
Call-ID: [email protected]
CSeq: 103 BYE
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Length: 0
43
#7
200 OK
Status-Line: SIP/2.0 200 OK
Via: SIP/2.0/UDP 158.196.146.12:5060;branch=z9hG4bK011c16dd;rport=5060
From: "5779" <sip:[email protected]>;tag=as396d4fbf
To: "SJphone" <sip:[email protected]>;tag=4227117d4b8
<sip:[email protected].
Contact: <sip:[email protected]>
Call-ID:
ID: [email protected]
CSeq: 103 BYE
Content-Length: 0
Server: SJphone/1.65.377a (SJ Labs)
2.3.7
SIP časovače
e a retransmise
Jelikož se v SIP signalizaci používá mnohdy nespolehlivý přenos
p enos (UDP), musí být ošet
ošetřeny
retransmise žádostí v transakcích.
Tab. 3 Časovače
e dle RFC 3261.
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é
44
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.
2.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 [voz159], [voz174] a [voz180]..
•
•
•
•
HTTP Basic Authentication je prvním mechanizmem, který zajišťuje autentizaci pomocí
sdíleného hesla. Data nejsou šifrována a není také zaručena integrita zprávy, obsahuje pouze
základní kódování schématem Base64.
HTTP Digest Authentication vychází z předchozí metody s tím rozdílem, že místo přenosu
otevřeného hesla ho šifruje pomocí hashovaní funkce MD5 nebo SHA. Ta funguje tak, že
heslo vytvoří z náhodně generovaného řetězce, loginu a hesla. Tato metoda ověřuje
autenticitu na základě sdíleného hesla. Obsah zprávy se však nijak nešifruje.
Secure MIME (S/MIME) je, jak z názvu vyplývá, zabezpečení tzv. MIME (Multipurpose
Internet Mail Extension). Konkrétně tato metoda zabezpečí obsah zprávy a zaručí i její
integritu. Existuji dva způsoby šifrování obsahu dat MIME. První application/pkcs7-mime
dokáže digitálně podepsat a zašifrovat data. Druhý způsob multipart/signed je podobný
prvnímu s tím rozdílem, že zpráva obsahuje šifrovaná i nešifrovaná data. K ověření
autentizace se používá architektura veřejných klíčů (PKI). Pro utajení obsahu zprávy jsou
využity symetrické kryptografické primitivy (DES, 3DES, AES).
SIPS URI (TLS) využívá architekturu veřejných klíčů pro ověření autentizace. Při použití této
metody se mění prefix identifikační hlavičky na sips. Aby byla zaručena bezpečná
komunikace, používá tato metoda šifrovaný protokol Transfer Layer Security (TLS). Tento
protokol využívá asymetrické šifrování (RSA), symetrické algoritmy (DES, 3DES, AES) a
hashovací funkci. Při použití této metody je kladena podmínka, že protokol TLS je použit na
celé cestě zprávy a pro SIP musí být použit protokol TCP.
Princip používané metody HTTP digest bude prakticky vysvětlen v následující kapitole
zabývající se registrací, u registrace se neautentizovaná zpráva REGISTER odmítá pomocí 401
Unauthorized, v případě INVITE je to 407 Proxy Authentication Required, následně se pošle
REGISTER nebo INVITE s autentizačním řetězcem, který je ověřen. Pokud je použito TLS, tak další
autentizace pomocí HTTP digest je zbytečná a nepoužívá se, neboť už sestavení TLS obsahuje
jeden z kroků, u kterého se klient prokazuje certifikátem a zabezpečení je na mnohem vyšší úrovni.
Řada aplikací volně dostupných na Internetu se dá použít buď ke generování útoků, odposlechu
45
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.
2.4
Registrace
Při registraci se sváže User URI z pole From s Device URI z pole Contact hlavičky SIP. Pokud pole
Contact hlavička žádosti Registrace neobsahuje, tak se z Registrar serveru ve 200 OK vrátí seznam
platných registrací k SIP URI z pole From. Device URI nese IP adresu a port, na kterém je uživatel
se svou SIP URI k dosažení, např. pro SIP URI sip:[email protected] může být device URI
sip:[email protected]:5060 . Doba platnosti registrace je dána parametrem expires v hlavičce,
tento čas je Registrar serverem upravován, pokud UAC v návrhu nezadá čas, který by ležel v
povoleném intervalu mezi minimální a maximální dobou registrace na Registrar serveru. Pokud se
pošle nulová hodnota doby registrace expires=0, tak to znamená zrušení registrace, viz. níže.
Request-Line: REGISTER sip:cesnet.cz SIP/2.0
Via: SIP/2.0/UDP 195.168.1.10;branch=z9hG4bK-d8754zdf2acad8754z-;rport
Max-Forwards: 70
Contact: <sip:[email protected];rinstance=45b13194f4a07bb>;expires=0
To: "voznak"<sip:[email protected]>
From: "voznak"<sip:[email protected]>;tag=9043320d
Call-ID: MjY0YzU5OTdiMDYxNTI4YzgzNTIwYzE2NTUzNzgyZGM.
CSeq: 5 REGISTER
User-Agent: X-Lite release 1100l stamp 47546
Authorization: Digest username="voznak",realm="cesnet.cz", nonce="48ad92308a4f8ee",
uri="sip:cesnet.cz",response="6e6f1ca5803c805ac885f8cb4a8a1df1",algorithm=MD5
Content-Length: 0
Odregistrování všech lokalizací konkrétního URI uživatele se docílí tak, že do pole Contact se
zadá znak * a zároveň s nulovou hodnotu do expirace expires=0.
Registrar
Server
UA
A@
B@
C@
REGISTER
401 UNAUTHORISED
REGISTER with AUTH.
200 OK
Obr. 24. Registrace s autentizací.
46
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. 24 je znázorněna výměna při registraci s autentizací. Žádost INVITE je odeslána bez
autentizačních údajů na SIP Proxy, ta odmítá odpovědí 401 Unauthorized, v odpovědi posílá bližší
informace k autentizaci. Klient akceptuje zaslané informace a vypočte hash, kterou zašle ve zprávě
REGISTER, tentokrát je úspěšně autentizován a dostává 200 OK s potvrzením registrace.
Status-Line: SIP/2.0 401 Unauthorized
Message Header
Via: SIP/2.0/UDP 195.168.1.10:18188;branch=z9hG4bKd8754z-d8754z-;rport=33209
To: "voznak"<sip:[email protected]>;tag=c10ed4fff3e6fb17efd0bfbdcce87ce2.10f8
From: "voznak"<sip:[email protected]>;tag=f861ac5a
Call-ID: Mzg1M2VlZDRkOWQ5NmJlNzA0MTk1OGNhZDE3MjZiNDg.
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="cesnet.cz", nonce="48ad92c"
Server: Sip EXpress router (0.9.6 (i386/linux))
Content-Length: 0
Request-Line: REGISTER sip:cesnet.cz SIP/2.0
Via: SIP/2.0/UDP 195.168.1.10:18188;branch=z9hG4bK-d8bc45e75b347-;rport
Max-Forwards: 70
Contact: <sip:[email protected]:18188;rinstance=8546638886339213>
To: "voznak"<sip:[email protected]>
From: "voznak"<sip:[email protected]>;tag=f861ac5a
Call-ID: Mzg1M2VlZDRkOWQ5NmJlNzA0MTk1OGNhZDE3MjZiNDg.
CSeq: 2 REGISTER
Expires: 3600
User-Agent: X-Lite release 1100l stamp 47546
Authorization: Digest username="voznak",realm="cesnet.cz",nonce="48ad92c",
uri="sip:cesnet.cz",response="1ca1df39a865353b8703343cbdfbb062",algorithm=MD5
Content-Length: 0
Na příkladu výše je odpověď 401 Anauthorized, která obsahuje v odmítnutí výzvu k autentizaci
a podává klientovi realm a nonce pro hashovací funkci. Klient posílá žádost REGISTER znovu, ale
tentokrát již s autentizačními údaji, je použit algoritmus MD5, pro hash se použije username, realm,
nonce a password, což je sdílené tajemství. Výsledný hash je v poli response.
2.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ší
47
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. 25 je znázorněn tok zpráv v rámci jednoho SIP Proxy serveru, ze kterého je čitelná
souslednost konkrétních žádostí a odpovědí. Směrování mezi SIP Proxy servery je obsahem dalších
kapitol.
Obr. 25. Tok SIP zpráv v rámci SIP Proxy
2.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. 26. Alice volá Boba, odesílá se INVITE, původní SIP URI se zapisuje do
pole To , kde je logická adresa příjemce AOR (Address of Record) a neměl by ho po cestě nikdo
změnit. První řádek obsahující RURI (Request URI) může SIP Proxy změnit dle aktuálních
směrovacích informací, INVITE nakonec zastihne Boba na sip:[email protected] . Alicin
UA zapisuje do pole Via na první řádek sám sebe (a.example.com nebo svou IP), každá další Proxy
po cestě udělá to samé, opět se vepíše na první řádek, a tak INVITE, který dostane Bob, bude mít
48
čtyři záznamy ve Via, viz. obr. 26. Jelikož odpověď je směrována dle Via, tak prochází stejnou cestou
jako žádost, každý první záznam je z Via odstraněn ihned po přijetí odpovědi SIP Proxy, a tak je
aktuální informace ve Via vždy první. Jakmile si koncové komunikující strany vymění na sebe
kontakty (pole Contact v hlavičce), tak další žádosti mohou být odesílány napřímo. Ovšem i tato
cesta se dá ovlivnit, viz. další kapitola.
[email protected]
INVITE
Via: a.example.com
Via: a.example.com
[email protected]
[email protected]
Via: y1.yahoo.com
Via: a.example.com
Via: y1.yahoo.com
Via: a.example.com
Via: sip.columbia.edu
Via: y1.yahoo.com
Via: a.example.com
Via: sip.columbia.edu
Via: y1.yahoo.com
Via: a.example.com
Via: cs.columbia.edu
Via: sip.columbia.edu
Via: y1.yahoo.com
Via: a.example.com
[email protected].
columbia.edu
[email protected]
200 OK
Via: cs.columbia.edu
Via: sip.columbia.edu
Via: y1.yahoo.com
Via: a.example.com
Obr. 25. Směrování žádostí a odpovědí.
2.5.2
SIP trapezoid
SIPu trapezoid je typickým příkladem směrování zpráv v SIPu, předpokládáme, že Alice
(sip:[email protected]) volá Boba z jiné domény (sip:[email protected]). INVITE je zaslán na SIP
Proxy domény atlanta.com, která vyhledá SIP Proxy obsluhující doménu biloxi.com a tam INVITE
odešle, SIP Proxy domény biloxi.com zná umístění Boba a přepošle tedy INVITE Bobovi. Odpovědi
jdou stejnou cestou jako žádost dle položky Via. ACK je další žádostí (potvrzení doručení finální
odpovědi) a ta je zaslána přímo Bobovi dle pole Contact. Alice provede hovor s Bobem a relaci
ukončí Bob odesláním žádosti BYE, která odchází na Alici přímo dle pole Contact. Tok zpráv
připomíná geometrický útvar trapezoid, viz. obr. 27. 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
49
zapíše odesílatel a přidá branch pro identifikaci transakce, když se mu vrátí odpověď se stejným
branch , tak ji zařadí do této transakce.
IN
V
TE
VI
IT
E
IN
Obr. 27. 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:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
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
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
50
Content-Length: 0
SIP Proxy atlanta.com najde SIP Proxy, která obsluhuje doménu biloxi.com, ve které je volaný
Bob. Nejdříve zjistí, zda už nemá destinaci ve své lokalizační databázi a pokud ne, tak provede
vyhledání v DNS (DNS lookup), bude se hledat SRV záznam, ten obsahuje identifikaci stroje, který
poskytuje službu SIP v dané doméně. INVITE teď SIP Proxy přepošle na zjištěnou cílovou SIP Proxy,
přičemž připíše parametr received do prvního záznamu ve Via, následně zapíše sebe jako první
záznam ve Via a sníží hodnotu v položce Max-Forwards. Další položky SIP hlavičky zůstávají
nezměněny.
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8;received=192.0.2.1
Max-Forwards: 69
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 142
INVITE byl přijat SIP Proxy biloxi.com, která ihned odesílá 100 TRYING, obdobně
předchozím kroku je přidán parametr received do Via.
jako v
SIP/2.0 100 Trying
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8;received=192.0.2.1
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Content-Length: 0
SIP Proxy biloxi.com vyhledává ve své lokalizační databázi záznam Boba, který byl vložen při
registraci, v lokalizační databázi je device URI z pole Contact svázána s logickou URI
sip:[email protected]. Proxy biloxi.com odesílá INVITE Bobovi, přičemž připíše received do prvního
záznamu ve Via, následně zapíše sebe jako první záznam ve Via a sníží hodnotu v položce MaxForwards, zbytek hlavičky nemění.
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8;received=192.0.2.1
Max-Forwards: 68
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 142
51
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
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8;received=192.0.2.1
To: Bob <sip:[email protected]>;tag=a6c85cf
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sip:[email protected]>
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
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8;received=192.0.2.1
To: Bob <sip:[email protected]>;tag=a6c85cf
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
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ý
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.
52
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: Bob <sip:[email protected]>;tag=a6c85cf
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 ACK
Content-Length: 0
Hovor ukončí Bob, zavěsí a jeho UA odesílá žádost BYE, opět přímo na Alici. Jedná o novou
transakci, takže se zvedne Cseq a zachová se From tag, To tag a Call-ID (patří do dialogu). Po
přijetí finální odpovědi 200 OK na BYE se dialog ukončí.
BYE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
Max-Forwards: 70
From: Bob <sip:[email protected]>;tag=a6c85cf
To: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 BYE
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
From: Bob <sip:[email protected]>;tag=a6c85cf
To: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 BYE
Content-Length: 0
2.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 .
Without record routing
UA1
SIP Proxy
With record routing
UA2
UA1
BYE
SIP Proxy
UA2
BYE
BYE
200 OK
200 OK
Obr. 28. Rozdíl v komunikaci při použití Record-route pole
53
200 OK
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>
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.
2.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.
54
SDP se skládá z řádků obsahující text ve formě položek typ a hodnota oddělených rovnítkem,
položky, u kterých je symbol *, jsou nepovinné:
<type>=<value>
Položky jsou rozděleny do třech skupin:
•
•
•
Session description, popis relace,
Time description, popis časování,
Media description, popis médií.
Následně si projdeme seznam položek SDP dle skupin uvedených RFC 4566. Skupina Session
description obsahuje položky v,o,s,i,u,e,c,b,z,k,a, kde:
•
•
•
•
•
•
•
•
•
•
•
v= (protocol version), vždy je nastaveno v=0,
o= (owner/creator and session identifier), označuje iniciátora relace a má následující syntaxi:
o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
s= (session name), název relace, pole je povinné a nesmí být prázdné, často se do něj
zadává mezera, pomlčka anebo tečka,
i=* (session information), textová informace o relaci,
u=* (URI of description), URI adresa odkazující na dodatečné informace k relaci,
e=* (email address) p=* (phone number), kontaktní e-mail a tel.č.,
c=* (connection information - not required if included in all media), udává informace o
připojovaném koncovém bodu relace ve formátu
c=<nettype> <addrtype> <connectionaddress>,
b=* (bandwidth information), informace o využívaném pásmu,
z=* (time zone adjustments), ošetřuje posuny času, dají se naplánovat opakované přechody
letního a zimního času.
k=* (encryption key), pokud je SDP transportován přes důvěryhodný transportní kanál, tak
může být pole k využito pro zprostředkování výměny klíčů ve formátu
k=<method>:<encryption key>,
a=* (zero or more session attribute lines), rozšiřující atributy ve formátu a=<attribute>:<value>,
např. a=recvonly.
Skupina Time description obsahuje položky t a r, kde :
•
•
t= (time the session is active), řádek specifikuje v relaci časové značky pro start a stop ve
formátu t=<start-time> <stop-time>, pokud jsou značky nastaveny 0 0, tak jde o permanentní
přehrávání relace,
r=* (zero or more repeat times), časy opakování relace ve tvaru r=<repeat interval> <active
duration> <offsets from start-time>,
Skupina Media description obsahuje položky m, c, b, k, a, kde:
•
•
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),
55
•
•
•
2.6.1
b=* (bandwidth information) ,
k=* (encryption key) ,
a=* (zero or more media attribute lines).
Konstrukce položek SDP pro komunikaci SIP/SDP
Povinnými položkami hlavičky SDP jsou řádku v, o, s, t, m :
v=0
o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-addr.>
s= název relace
t= 0 0
m=m=<media> <port> <proto> <fmt>
Popis médií v m řádku se obvykle doplňuje nepovinnými atributy, tyto atributy jsou specifikovány v
dalších RFC a jde o tyto atributy:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
a=ptime:<packet time>, [RFC4566]
a=rtpmap:<payload type> <encoding name>/<clock rate> <encoding parameters>, [RFC4566]
a=orient:<orientation>, [RFC4566]
a=framerate:<frame rate>, [RFC4566]
a=quality:<quality>, [RFC4566]
a=fmtp:<format> <format specific parameters>, [RFC4566]
a=maxptime:<maximum packet time>, RFC3267, RFC4566
a=curr:<precondition-type> <status-type> <direction-tag>, [RFC3312]
a=des:<precondition-type> <strength-tag> <status-type> <direction-tag>,[RFC3312]
a=conf:<precondition-type> <status-type> <direction-tag>, [RFC3312]
a=mid:<identification-tags> , [RFC3388]
a=rtcp:<port> , [RFC3605]
a=crypto:<tag> <crypto-suite> <key-params> [<session-param>] , [RFC4568]
a=label:<pointer> , [RFC4574]
a=floorctrl:<role> ,[RFC4583]
a=confid:<conference-id> , [RFC4583]
a=floorid:<token> ,
[RFC4583]
a=content:<mediacnt-tag> , [RFC4796]
Uvedené atributy jsou použity výhradně pro média, dále existují atributy relace, které neuvádím,
neboť v SIP/SDP se s nimi nepotkáme, ale ještě máme atributy používané na obou úrovních, jak pro
popis médií, tak i relace, a ty si uvedeme:
a=recvonly , [RFC4566]
a=sendrecv , [RFC4566]
a=sendonly , [RFC4566]
a=inactive , RFC3108, RFC4566 (and used in RFC3264)
a=sdplang:<language tag> , [RFC4566]
a=lang:<language tag> , [RFC4566]
a=maxprate:<packet-rate> , [RFC3890]
a=setup:<role> , [RFC4145]
a=connection:<conn-value> , [RFC4145]
56
a=key-mgmt:<prtcl-id> <keymgmt-data> , [RFC4567]
a=source-filter:<filter-mode> <filter-spec> , [RFC4570]
a=fingerprint:<hash-func> <fingerprint> , [RFC4572]
Níže je uveden příklad obsahu SDP připojeného k SIP žádosti INVITE, ve kterém jsou nabídnuty
dva RTP toky. První je audio s preferencí kodeků PCM µ-law, A-law, GSM, iLBC a G.729, GSM,
očekávaný na portu 13226 a druhý tok je video H.263 na portu 15014, oba toky mají být zakončeny
na IP 158.196.196.146.12.
INVITE sip:[email protected] SIP/2.0 (SIP hlavička, volný řádek a SDP)
v=0
o=root 3177 3177 IN IP4 158.196.146.12
s=session
c=IN IP4 158.196.146.12
t=0 0
m=audio 13226 RTP/AVP 0 8 3 97 18
a=rtpmap: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
Odpověď přišla v SDP připojeného k odpovědi 200 OK na INVITEN. 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
2.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,
57
•
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 RetryAfter s náhodně zvolenou hodnotou v rozsahu 0 až 10. Jestliže UAS dostane INVITE v dialogu, v
rámci kterého má nevyřízený INVITE (před chvíli sám INVITE odeslal a dosud nedostal odpověď),
tak musí na přijatý INVITE vrátit odpověď 491 Request Pending.
Nabídka buď neobsahuje žádný nebo obsahuje jeden anebo více média toků a každý je popsán
v jednotlivém m řádku s přiřazenými atributy. Pokud neobsahuje žádný, tak si strana nabízející SDP
přeje komunikovat později a až získá odpověď na nabídku, tak bude svou nabídku modifikovat (zašle
novou). Pokud obsahuje více m řádků, tak každý musí popisovat jiný typ toku, neboť nelze žádat o
vícenásobný tok stejného typu (paralell stream), typ toku je určen portem, profilem a kodeky, takže
např. můžu si nechat poslat jeden šifrovaný tok a druhý nešifrovaný RTP či poslat jeden tok audio a
druhý video.
Na nabídku jednotlivých toků druhá strana odpovídá tak, že v odpovědi uvede na základě
nabídky své typy toků (port, kodeky), v odpovědi je uveden stejný počet m řádků obsažených v
nabídce a to i ve stejném pořadí. Nabídka toku může být odmítnuta z jakéhokoliv důvodu
(nepodporovaný tok – např. video), odmítá se konkrétní m řádek a to tak, že v odpovědi se v m
řádku nastaví port na hodnotu 0.
58
3
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. Dnes je vývoj Asterisku z větší části záležitostí open-source
komunity a díky tomu má aktuální vývoj asi 400 přispěvovatelů, což je velká síla, do poslední verze
přispěli více než dvěmi třetinami. Pro ilustraci vývoje uvádíme, že verze Asterisku 1.4 byla uvolněna
v prosinci roku 2006, verze Asterisku 1.6 v roce 2008 a verze 1.8 v roce 2010.
3.1
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
59
služeb a telefonní společnosti. Asterisk je rovněž open-source komunita a komerční produkt od firmy
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. 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. 29. Architektura Asterisku
3.1.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).
Konferenční server.
Packet voice server.
Šifrovací médium telefonních nebo faxových volání.
Překladač čísel.
Aplikace Calling card,
Prediktivní volič,
60
•
•
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í:
•
•
•
•
•
3.1.2
Hudba pro zákazníky v pořadí čekající ve frontě na hovor, podpora streamování médií a
MP3 souborů.
Fronty volajících, kdy tým agentů může odpovědět na volání a může sledovat fronty
(vhodné pro Call Centra).
Integrace Text-to-speech modulů a rozpoznávání hlasu.
Podrobné záznamy o hovorech jsou převáděny do textových souborů a SQL databází.
Propojení s PSTN sítí skrze digitální a analogové linky.
Kodeky a protokoly Asterisku
Obvykle je snaha, aby bylo možné v dané datové sítí realizovat co nejvíce hlasových spojení.
Kodeky poskytují nové možnosti pro digitální přenos hlasu, včetně komprese, která je jednou z
nejdůležitějších vlastností, mezi další vlastnosti patří detekce hlasové aktivity, vyrovnání paketové
ztráty, a generování výplňového šumu. V Asterisku jsou podporovány následující kodeky s uvedenou
šířkou pásma. Ty mohou být samozřejmě transparentně překládány z jednoho na druhý.
•
•
•
•
•
•
•
•
•
•
G.711 ulaw (USA) - (64 Kbps).
G.711 alaw (Europe) - (64 Kbps).
G.722 (širokopásmový kodek) – (64 Kbps).
G.723.1 – pouze pass-through režim
G.726 - (16/24/32/40kbps)
G.729 – nutná licence (8Kbps)
GSM - (12-13 Kbps)
iLBC - (15 Kbps)
LPC10 - (2.5 Kbps)
Speex - (2.15-44.2 Kbps)
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 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
61
3.1.3
Verze Asterisku
První oficiální funkční
ní verze Asterisku pod ozna
označením
ením 1.0 vyšla 23. zář
září 2004. O rok později,
konkrétně 15. Listopadu 2005 byla p
představena verze 1.2 , která přinášela
inášela oproti verzi 1.0 více než
3000 vylepšení a oprav. Mezi ty největší
nejv
patřily: vylepšení funkcí
nkcí hlasové schránky (voicemail),
přidání
idání DUNDi (Distributed Universal Number Discover) protokol, jednodušší konfigurace Asterisku,
větší
tší podpora pro SIP protokol, využití hudby pro čekání
ekání na hovor, podpora ISDN PRI a mnoho
dalších. Jak už se u firmy Digium
gium stalo zvykem, další verze přišla
p
opětt po roce a to 26. prosince 2006.
Jednalo se o verzi 1.4 a tato se stala nejvíce rozšířenou
rozší enou a používanou i dlouho poté, co byla 2. října
2008 představena
edstavena verze 1.6. Verze 1.6 má již nativn
nativně plně implementovanou podp
podporu pro šifrování
SIPu, podporuje signalizaci SS7 a obsahuje spoustu dalších nových vylepšení. Momentálně
Momentáln je
dostupná verze 1.8, která byla uvolněna
uvoln
na podzim 2010, je označována
čována jako LTS (Long Term
Supported), přibyla v ní především
ředevším SRTP a kalendá
kalendářů.
Obr.30. Loga jednotlivých distribucí
Veškeré výše uvedené verze představují
představují tzv. „klasický“ Asterisk, který se instaluje v podobě
softvérového programu na linuxové distribuce a veškerá jeho nastavení či konfigurace se provádí
přes příkazovou řádku operačního
čního
ního systému tzv. shell, neboli interpret p
př
příkazů. Existují však i
distribuce Asterisku určeny
eny pro za
začínající
ínající uživatele, které jsou instalovány z ISO souboru a
představují celý operační
ní systém založen na Linuxové distribuci a obsahující Asterisk, všechny
vše
potřebné balíčky k jeho provozu a hlavně
hlavn webový server a grafické webové rozhraní (založené na
FreePBX), pomocí něhož
hož se ústředna
ústř
konfiguruje. Těchto distribucí je několik,
ěkolik, společnost
spole
Digium
podporuje vývoj AsteriskNOW v současnosti
souč
dostupné ve verzi 1.7. Verze 1.7 obsahuje Asterisk 1.6
tzn. služby podporované v této verzi jsou dostupné i v AsteriskNOW. Další z grafických distribucí je
například
íklad Trixbox. Jedná se opět
opě o kompletní operační
ní systém velice podobný AsteriskNOW,
používá však vlastní webové rozhraní.
ozhraní. Momentálně
Momentáln je dostupný ve verzi 2.8 a používá taktéž
Asterisk ve verzi 1.6.
Tento text se primárně
ě zaměř
ěřuje
uje na popis konfigurace „klasického“ Asterisku pomocí p
příkazové
řádky a konfiguračních souborů,
ů, jelikož grafické nástavby nakonec využívají právě
p
tento klasický
Asterisk a pouze automatizují proces konfigurace. Pokud tedy budeme znát problematiku
konfigurace „klasického“ Asterisku, budeme znát i způsob
zp sob konfigurace pomocí grafických distribucí.
3.2
Instalace Asterisku
Následující kapitola popisuje instalaci „klasického“ Asterisku ve verzi 1.6 přímo
př
pomocí balíčku
pro jednotlivé linux distribuce a také pomocí kompilace.
62
3.2.1
Instalace pomocí balíčku s příponou .deb
Tato instalace je určena pro Linuxové distribuce, které využívají balíčkovací systém deb. Jedná
se například o distribuce Debian či Ubuntu a jeho deriváty. Ke správě systému využívají nástroj apt
nebo aptitude. Níže popsaná instalace je vyzkoušena na distribucích Debian Squeeze a Ubuntu
10.04(10.10). Pozn.: Starší verze distribucí nemusí mít aktualizované repozitáře a mohou obsahovat
starší verzi Asterisku, například 1.4). Instalace je velice jednoduchá. Do příkazového řádku pod
uživatelem root napište:
apt-get install asterisk
Potvrďte instalaci stiskem klávesy Y a do formuláře vyplňte mezinárodní telefonní předvolbu
české republiky 420 . Po instalaci je jíž ústředna plně funkční a připravena k použití. Zda je Asterisk
funkční můžete otestovat příkazem:
asterisk -vvvgci
Obr.31. Vyplnění mezinárodní předvolby
3.2.2
Instalace pomocí balíčku s příponou .rpm
Tato instalace je určena pro Linuxové distribuce, které využívají balíčkovací systém rpm. Jedná
se například o distribuce Fedora, RedHat,CentOS či Gentoo. K správě systému využívají nástroj yum.
Níže popsaná instalace je vyzkoušena na distribucích CentOS 5 a RedHat Enteprise Linux 5. Před
samotnou instalací je nutno aktualizovat repozitáře systému o nové zdroje. Pomocí textového editoru
dle Vašeho výběru vytvořte nový soubor:
centos-asterisk.repo
v adresáři:
/etc/yum.repos.d
a do vytvořeného souboru vložte následující text:
[asterisk-tested]
name=CentOS-$releasever - Asterisk - Tested
63
baseurl=http://packages.asterisk.org/centos/$releasever/tested/$basearch/
enabled=0
gpgcheck=0
#gpgkey=http://packages.asterisk.org/RPM-GPG-KEY-Digium
[asterisk-current]
name=CentOS-$releasever - Asterisk - Current
baseurl=http://packages.asterisk.org/centos/$releasever/current/$basearch/
enabled=1
gpgcheck=0
#gpgkey=http://packages.asterisk.org/RPM-GPG-KEY-Digium
Uložte soubor a vytvořte další nový s názvem:
centos-digium.repo
a vložte do něj následující text:
[digium-tested]
name=CentOS-$releasever - Digium - Tested
baseurl=http://packages.digium.com/centos/$releasever/tested/$basearch/
enabled=0
gpgcheck=0
#gpgkey=http://packages.digium.com/RPM-GPG-KEY-Digium
[digium-current]
name=CentOS-$releasever - Digium - Current
baseurl=http://packages.digium.com/centos/$releasever/current/$basearch/
enabled=1
gpgcheck=0
#gpgkey=http://packages.digium.com/RPM-GPG-KEY-Digium
Nyní je systém aktualizovaný pro instalaci Asterisku z nových repozitářů. Pro samotnou instalaci
potřebných balíčků i samotné Asterisku zadejte do příkazové řádky:
yum install asterisk16
dahdi-tools libpri
asterisk16-configs
asterisk16-voicemail
dahdi-linux
V průběhu instalace bude potřeba dvakrát potvrdit pokračování klávesou Y. Po instalaci je jíž
ústředna plně funkční a připravena k použití. Zda je Asterisk funkční můžete otestovat příkazem:
asterisk –vvvgci
3.2.3
Instalace pomocí kompilace zdrojových kódů
Instalace pomocí kompilace zdrojových kódů je určena převážně pro zkušenější uživatele,
umožňuje však nainstalovat Asterisk na různé distribuce operačních systémů, bez potřeby určitých
správců systémů typu apt či yum. Níže popsaná instalace je vyzkoušena na distribucích Debian.
Samotná kompilace vyžaduje přítomnost některých balíčků v systému. Ty je nutné nejprve
doinstalovat. Nejdříve se provede instalace kernel hlaviček:
64
apt-get install linux-headers-`uname –r`
ln -s /usr/src/kernel-headers-`uname -r` /usr/src/linux
Poté instalace samotných balíčků potřebných pro kompilaci:
apt-get install bison openssl libssl-dev libusb-dev fxload libasound2-dev libc6-dev libnewt-dev
libncurses5-dev zlib1g-dev gcc g++ make doxygen libxml2-dev
Nyní stáhneme zdrojové kódy z repozitářů Asterisku do adresáře /usr/src. Zkontrolujte prosím
aktuálnost verzí:
cd /usr/src
wget http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-1.6.2.5.tar.gz
wget http://downloads.asterisk.org/pub/telephony/libpri/releases/libpri-1.4.10.2.tar.gz
wget http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-addons-1.6.2.0.tar.gz
Dále je nutné stáhnout zdrojové kódy DAHDI. Projekt DAHDI vznikl jako následník projektu
Zapata. Projekt Zapata založil Jim Dixon, který byl také zodpovědný za vývoj tohoto revolučního
hardwaru pro použití s Asteriskem. Cílem produktu Zapata byla architektura nazývána Zaptel
(nedávno přejmenována na Digium Asterisk Hardware Driver Interface - DAHDI).
Jednou z hlavních výhod této architektury je schopnost používat procesor počítače pro
zpracování streamovaných médií, eliminaci ozvěny a kódování. Do té doby všechny karty používaly k
plnění těchto úkolů digitální signálové procesory (DSP). Používání CPU místo DSP rapidně snížilo
cenu hardwaru a spousta výrobců začala karty s DAHDI architekturou vyrábět. Na druhou stranu tyto
karty vyžadují velké výpočetní prostředky na CPU a to může při větším zatížení negativně ovlivnit
kvalitu hlasu.
wget http://downloads.asterisk.org/pub/telephony/dahdi-linux/releases/dahdi-linux-2.2.1.tar.gz
wget http://downloads.asterisk.org/pub/telephony/dahdi-tools/releases/dahdi-tools-2.2.1.tar.gz
Všechny stažené soubory dekomprimujeme příkazem:
tar xzvf název_souboru.tar.gz
Po dekomprimaci zkompilujeme DAHDI moduly:
cd /usr/src/dahdi-linux-2.2.1
make
make install
cd /usr/src/dahdi-tools-2.2.1
./configure
make menusect (volitelné, můžete zvolit několik možností)
make
make install
make config (volitelné, nainstaluje inicializační skripty)
Pokud je zadáno make menuselect je možno vybrat pouze nutné moduly pro instalaci.
65
Obr. 32. Volba modulů pomocí DAHDI menuselect
Po zadání make config jsou nainstalovány inicializační skripty a spustí se detekce hardwarové
karty a jejího ovladače. Výpis, který se zobrazí obsahuje informaci o detekovaném hardware a
informaci o změně konfiguračního souboru. V našem případě jsme použili kartu Digium TE121: PCIExpress single-port T1/E1/J1 a závěr výpisu vypadá následovně:
the DAHDI hardware you have on your system is:
pcie:004/002 wcte12xp e2e1:1150 Digium-single no-firmware
Systém kartu detekoval správně a nyní je nutné povolit ovladač wcte12xp v souboru
/etc/dahdi/modules.Ten si otevřeme pro editaci a okomentujeme příslušný řádek s označením
ovladače:
# Contains the list of modules to be loaded / unloaded by #/etc/init.d/dahdi.
#
# NOTE: Please add/edit /etc/modprobe.d/dahdi or /etc/modprobe.conf if you
# would like to add any module parameters.
#
# Format of this file: list of modules, each in its own line.
# Anything after a '#' is ignore, likewise trailing and leading
# whitespaces and empty lines.
# Digium TE205P/TE207P/TE210P/TE212P: PCI dual-port T1/E1/J1
# Digium TE405P/TE407P/TE410P/TE412P: PCI quad-port T1/E1/J1
# Digium TE220: PCI-Express dual-port T1/E1/J1
# Digium TE420: PCI-Express quad-port T1/E1/J1
#wct4xxp
# Digium TE120P: PCI single-port T1/E1/J1
# Digium TE121: PCI-Express single-port T1/E1/J1
# Digium TE122: PCI single-port T1/E1/J1
wcte12xp
# Digium T100P: PCI single-port T1
# Digium E100P: PCI single-port E1
#wct1xxp
66
Restartujte počítač a zkontrolujte, zda se ovladač nainstaloval správně. Nyní již můžeme
zkompilovat samotný Asterisk:
cd /usr/src/libpri-1.4.10.2
make
make install
cd /usr/src/asterisk-1.6.2.5
./configure
make menuselect (volitelné, můžete zvolit několik možností)
make
make install
make samples (volitelné, při zadání vytvoří ukázkové soubory Asterisku)
make config (volitelné, při zadání nastaví startování Asterisku při bootování počítače)
Obr.33. Volba modulů pomocí Asterisk menuselect
Pokud se při kompilaci nevyskytly žádné chyby je jíž ústředna plně funkční a připravena k použití.
Zda je Asterisk funkční můžete otestovat příkazem:
asterisk –vvvgci
3.3
Úvod do konfigurace SIPu a plánu volby
Po úspěšné instalaci by měl adresář /etc/asterisk/ obsahovat potřebné soubory ke konfiguraci a
provozu Asterisku. Pro jednoduchou ukázku konfigurace si vybere jeden: extension.conf. Pokud jsme
prováděli instalaci přes kompilaci, je nutné při kompilaci zadat make samples,aby se daný ukázkový
soubor vytvořil. Veškeré zde uváděné konfigurace jsou prováděny na operačním systému Linux
Debian.
67
3.3.1
Konfigurace Asterisku
Než provedeme základní ukázku konfigurace, je dobré si soubor extensions.conf zálohovat do
vytvořeného adresáře /var/tmp/asterisk-etc-backup:
debian:/usr/src# cd /etc/asterisk
debian:/etc/asterisk# mkdir -p /var/tmp/asterisk-etc-backup
debian:/etc/asterisk# mv extensions.* /var/tmp/asterisk-etc-backup/
debian:/etc/asterisk#
Pomocí oblíbeného textového editoru vytvoříme nový soubor /etc/asterisk/extension.conf a
vložíme do něj následující text:
[default]
exten => 1001,1,Answer()
exten => 1001,2,Playback(hello-world)
exten => 1001,3,Hangup()
3.3.2
Spuštění, zavolání „Hello—World“ a zastavení Asterisku
Nyní spustíme Asterisk příkazem:
asterisk –cvvvvv
Asterisk se spustí a my můžeme zadávat příkazy do jeho příkazové konzole – CLI. Parametr –c
definuje otevření konzole, parametr –v definuje úroveň podrobnosti výpisu. Například pomocí příkazu
console dial 1001 zavoláme na číslo 1001, které jsme si vytvořili v souboru extensions.conf.
Přehraje se nám zvukový soubor hello-world.gsm z adresáře /var/lib/asterisk/sounds.
*CLI> console dial 1001
== Console is full duplex
*CLI> -- Executing [1001@default:1] Answer("Console/dsp", "") in new
stack
<< Console call has been answered >>
-- Executing [1001@default:2] Playback("Console/dsp", "hello-world") in
new stack
-- <Console/dsp> Playing ’hello-world’ (language ’en’)
*CLI> -- Executing [1001@default:3] Hangup("Console/dsp", "") in new
stack
== Spawn extension (default, 1001, 3) exited non-zero on ’Console/dsp’
<< Hangup on console >>
*CLI>
Pravidla pro jednotlivé účty se nazývají extensions. Jedná se o programovou jednotku
v číslovacím plánu. Každá programová jednotka se skládá minimálně z jednoho řádku zapsaného
v následujícím formátu:
exten => název_extension,priorita,aplikace
V našem příkladě má tedy extension název 1001, má tři priority (1,2,3) a používá tři aplikace:
68
•
•
•
Answer() – otevírá nový kanál na Asterisku,
Playback() – přehraje daný zvukový soubor,
Hangup() – zavěsí hovor a uzavře kanál.
Pro zastavení Asterisku zadáme do konzole příkaz:
*CLI> core stop now
debian:/etc/asterisk#
3.3.3
Volání „Hello-World“ pomocí SIP telefonu
Jakmile jsme otestovali extension 1001 pomocí Asterisk konzole, je dalším logickým krokem
otestovat volání pomocí SIP telefonu. Pokud nemáte k dispozici hardwarový SIP telefon, můžete
využít softwarové řešení, například SIP klient X-lite. Pokud chcete předejít možným problémům, tak
instalujte SIP softwarový telefon na jiný počítač,než je nainstalována samotná ústředna Asterisk.
Než však použijeme SIP telefon s Asteriskem, musíme pro něj vytvořit na Asterisku účet. K tomu
použijeme konfigurační soubor /etc/asterisk/sip.conf , který si opět před použitím zálohujeme do
adresáře /var/tmp/asterisk-etc-backup podobně jako extensions.conf.
Pomocí oblíbeného textového editoru opět vytvoříme nový soubor /etc/asterisk/sip.conf a
vložíme do něj následující text:
[general]
port=5060
bindaddr=0.0.0.0
[2000]
type=friend
secret=1234
host=dynamic
Na SIP telefonu poté nastavíme tyto hodnoty:
• Uživatel: 2000
• Heslo: 1234
• SIP registrar: IP adresa počítače, kde je nainstalován Asterisk
• SIP proxy: IP adresa počítače, kde je nainstalován Asterisk
Opět spustíme Asterisk již známým příkazem:
asterisk –cvvvvv
Poté spustíme SIP telefon a zadáme do něj příslušné údaje uvedené výše. Měli bychom vidět,
jak se SIP telefon zaregistruje na Asterisk:
*CLI> -- Registered SIP ‘2000’ at 47.6.3.4 port 5060
expires 120 -– Unregistered SIP ‘2000’
Nyní zavoláme ze SIP telefonu na číslo 1001, přehraje se nám zpráva hello-world.gsm . Pokud
bychom chtěli z Asterisk konzole zavolat na SIP telefon, je nutné přidat do
/etc/asterisk/extensions.conf řádek:
69
exten => 2000,1,Dial(SIP/2000)
Aby se námi provedené změny v číslovacím plánu projevili, musíme restartovat Asterisk, nebo
znovu načíst číslovací plán. Restartování asterisku se provede v CLI Asterisku příkazem:
*CLI> core restart now
Restartování číslovacího plánu se provede:
*CLI> dialplan reload
Nyní můžeme zavolat SIP telefon pomocí:
*CLI> console dial 2000
Aplikace Dial() v číslovacím plánu sestavuje spojení na telefon. Používá parametr složený se
dvou částí: první SIP určuje technologii, která bude využita pro sestavení spojení, v našem případě
tedy SIP VoIP protokol. Druhý parametr definuje cílové zařízení, čili 2000. Pokud je použita aplikace
Dial, aplikace Answer či Hangup se už nepoužívají, jelikož nevíme, zda je cílový účastník dostupný.
V našem případě koresponduje extension 2000 s cílovým zařízením 2000. Můžeme však do
číslovacího plánu zapsat například:
exten => 55,1,Dial(SIP/2000)
Potom bychom SIP telefon volali příkazem:
*CLI> console dial 55
3.3.4
Minimální konfigurace Asterisku se dvěma SIP účty
Nejjednodušší možná konfigurace Asterisku obsahuje dva SIP telefony a jeden Asterisk server.
Nejprve si vytvoříme druhý účet s číslem
2001 pro druhý SIP telefon. Opět editujeme
/etc/asterisk/sip.conf:
[general]
port=5060
bindaddr=0.0.0.0
[2000]
type=friend
secret=1234
host=dynamic
[2001]
type=friend
secret=1234
host=dynamic
Poté je ještě nutné editovat /etc/asterisk/extensions.conf a vytvořit nový řádek pro účet 2001:
70
exten => 2001,1,Dial(SIP/2001)
exten => 2000,1,Dial(SIP/2000)
Zadáme do druhého SIP telefonu příslušné údaje, restartujeme Asterisk a vyzkoušíme volání
z jednoho SIP telefonu na druhý.
3.3.5
Nastavení práv na základě kontextů
Každá pobočková ústředna musí mít možnost nastavovat jednotlivým pobočkám oprávnění, kam se
mohou dovolat. V Asterisku se tyto pravidla definují pomocí kontextů – contexts. Každý kontext
reprezentuje kategorii, která definuje pravidla co může být voláno. K přístupu k pravidlům musí být
telefon součástí kategorie – musí mít přiřazený odpovídající kontext. Pokud nemá účet definován
kontext je automaticky zařazen do kategorie [default]. Pokud mu chceme context definovat v
/etc/asterisk/sip.conf u příslušného účtu zadáváme:
context = Název kontextu
Uveďme příklad. Firma ESF Co. Má SIP telefony 10,11,12 a 20. Telefony 10-12 jsou
standardními telefony firmy s kontextem [esf], telefon 20 je volně dostupný telefon na recepci
s kontextem [navstevnik]. V /etc/asterisk/sip.conf bude zápis vypadat následovně:
[general]
port=5060
bindaddr=0.0.0.0
context=esf ; <-- kontext
[10]
type=friend
secret=1234
host=dynamic
[11]
type=friend
secret=1234
host=dynamic
[12]
type=friend
secret=1234
host=dynamic
[20]
type=friend
secret=1234
host=dynamic
context=visitor ; <-- kontext
Poté v /etc/asterisk/extensions.conf definujeme pravidla pro jednotlivé kontexty:
[default]
exten => 1001,1,Answer()
exten => 1001,2,Playback(hello-world)
71
exten => 1001,3,Hangup()
[esf]
exten => 10,1,Dial(SIP/10)
exten => 11,1,Dial(SIP/11)
exten => 12,1,Dial(SIP/12)
[navstevnik]
exten => 1001,1,Answer()
exten => 1001,2,Playback(hello-world)
exten => 1001,3,Hangup()
3.4
Dialplan
Číslovací plán (dále jen Dialplán) je srdcem Asterisku, a všechno zde začíná.V Asterisku 1.6, tvoří
dialplan dva důležité soubory. První z nich je extensions.conf, který používá originální doporučený
model od firmy Digium. Druhým je extensions.ael, který používá novější jazyk tzv. Asterisk
Extensions Language - AEL, o kterém pojednává samostatná kapitola. V této kapitole probereme
tradiční model priorit, jelikož jak ve verzi 1.4, tek i ve verzi 1.6 je extensions.ael při startu Asterisku
převeden na tradiční formát priorit a přidán do extensions.conf .
3.4.1
Kontexty - Contexts
Již jsme se zmínili o kontextech, pomocí kterých můžeme definovat práva pro jednotlivé telefony na
daném Asterisk serveru. Pokud je danému zařízení přidělen kontext, Asterisk hledá v dialplánu, zda
existují pro tento kontext pravidla – extensions. Pokud máme například v /etc/asterisk/sip.conf
následující zápis:
[2000]
type=friend
context=test
secret=1234
host=dynamic
tak telefon s číslem 2000 bude vždy iniciovat hovory v kontextu test. Pokud bude například chtít
vytočit nějaké číslo, Asterisk projde kontext test v dialplánu /etc/asterisk/extensions.conf a bude
hledat pravidlo pro dané číslo. Pokud pravidlo nenajde nic se nestane. Kontexty jsou ohraničeny
závorkami, pod kterými následují pravidla.
3.4.2
Pravidla - Extensions
Již bylo řečeno, že jednotlivé položky v souboru extensions.conf se nazývají extensions – pravidla.
Jednotlivé extensions jsou prováděny pokaždé, když je vytvořeno volání pro tuto extension, ale
soubor extensions.conf je Asteriskem načítán pouze jednou při startu. Proto je nutné po každé
72
změně dialplánu, restartovat Asterisk,nebo dialplán. Bylo také uvedeno, že každá extension se
skládá z názvu extension, priority a aplikace.
Základní aplikace :
•
•
•
•
•
•
•
3.4.3
Answer ( ) – tato aplikace je popsána svým názvem. Pouze vyzvedává hovory. Otevírá kanál
pro hovor.
Hangup ( ) – jedná se o protiklad k Answer. Aktivní spojení je zrušeno a kanál je uzavřen.
Playback (zvukový soubor) – tato aplikace přehrává definovaný zvukový soubor. Nepřidává
se žádná přípona souboru, jelikož adresář může obsahovat soubor ve více formátech.
Asterisk vybere ten nejvhodnější.
Wait (number) – definuje pauzu v sekundach.
NoOp (řetězec) – tato aplikace nedělá nic. Doslova znamená No Operation. Používá se pro
testování, či při hledání chyb v dialplánech. Namísto řetězce se vyplňuje text,který se
zobrazuje v CLI, ale pouze tehdy,pokud je verbosity úroveň nastavena na 3 a více.
VoiceMail (mailováschránka,u) – volající zanechá hlasovou zprávu pro nastavenou
schránku. Více v kapitole 1.8.
VoiceMailMain () – vstupní aplikace do hlasové schránky. Maijitel schránky využivá tuto
aplikaci pro přístup ke svým hlasovým zprávám.
Priority - Priorities
Klasická extension je tvořena několika řádky. Každý řádek má nastavenou prioritu a Asterisk
podle této priority vykonává jednotlivé extensions. Uveďme příklad. Následující extensions se
provedou pokud uživatel s kontextem test zavolá na číslo 8888. Asterisk vyzvedne hovor, přehraje
zvukový soubor hello-world a hovor ukončí:
[test]
exten => 8888,1, Answer()
exten => 8888,2, Playback(hello-world)
exten => 8888,3, Hangup()
Pokud bychom měli extensions na několik řádků, můžeme využít vlastnosti,které Asterisk nabízí
a to automatické číslování priorit. Namísto čísla priority zadáme písmeno – n. Asterisk bude
postupovat po jednotlivých řádcích extensions a vždy přidá k n+1. V našem případě by to vypadalo
následovně:
[test]
exten => 8888,1, Answer()
exten => 8888,n, Playback(hello-world)
exten => 8888,n, Hangup()
Písmeno n můžeme dosadit v libovolném řádku:
[test]
exten => 8888,1, Answer()
exten => 8888,2, Playback(hello-world)
exten => 8888,n, Hangup()
73
3.4.4
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,1,Answer()
exten => 100,2,Playback(hello-world)
exten => 100,3,Hangup()
exten => 101,1,Answer()
exten => 101,2,Playback(hello-world)
exten => 101,3,Hangup()
exten => 102,1,Answer()
exten => 102,2,Playback(hello-world)
exten => 102,3,Hangup()
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.
Základní vzory :
Diaplánové 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:
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 3135. 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)
74
•
* – 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.
3.4.5
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.
3.4.6
Č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ě:
75
;Den
include => otevreno|09:00-18:00|mon-fri|*|*
include => otevreno|09:00-13:00|sat|*|*
include => zavreno
[otevreno]
exten => 2000,1,Dial(SIP/2000)
[zavreno]
exten => 2000,1,VoiceMail(2000,u)
3.4.7
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:
exten => 2000,1,Dial(SIP/2000)
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 interně přes funkce a aplikace v dialplánu. Další kapitoly budou
pojednávat převážně o interním programování. AGI není součástí tohoto textu. Dialplán je definován
v extensions.conf a administrátor Asterisku do něj může implementovat funkce, tak jako by se
jednalo o skriptovací jazyk. K pochopení následujících kapitol je potřeba mít alespoň základy
programování v libovolném programovacím jazyce.
3.4.8
Programová struktura
Každá extension pro dané číslo je v podstatě krátký program, který definuje, jak bude hovor probíhat.
Proto, když jsme například definovali přehrání hello-world pro číslo 1001, psali jsme v podstatě
program:
exten => 1001,1,Answer()
exten => 1001,n,Playback( hello-world)
exten => 1001,n,Hangup()
76
3.4.9
Aplikace Set ( )
Aplikace Set ( ) se využívá k vytvoření a změně proměnných:
exten => 1002,1,Set(Oblibenezvire = "Tygr")
exten => 1002,n,Set(Oblibenecislo = 23)
Pro čtení a tisk proměnných na obrazovku se používá funkce ${VARIABLENAME}. Pro
zobrazení proměnných v CLI Asterisku zadáme například:
exten => 1003,1,NoOp(${Oblibenezvire})
exten => 1003,n,NoOp(${Oblibenecislo})
Definujeme několik typů proměnných:
•
Globální proměnné – Platná kdekoliv v dialplánu, vytváří se či edituje pomocí:
Set(<proměnná>=<obsah>,g):
exten => 1004,1,Set(READABLEANYWHERE = 23,g)
exten => 1004,n,NoOp(${READABLEANYWHERE})
•
Kanálové proměnné – Platná pouze v daném kanálu (kanál je například spojení mezi
dvěma volajícími), vytváří se či edituje pomocí:
Set(<proměnná>=<obsah>) (bez g):
exten => 1005,1,Set(READABLEANYWHERE = 42)
exten => 1005,n,NoOp(${READABLEANYWHERE})
•
Systémové proměnné – Jedná se o dynamické proměnné, které jsou definovány
Asteriskem a mohou být použity v dialplánu bez předchozího vytvoření. Nejčastěji
používaná systémová proměnná je:
${EXTEN}:
exten => 1006,n,NoOp(Vytáčené číslo: ${EXTEN})
3.4.10 Štítky a Goto ( )
Goto ( ) umožňuje přeskočit z jedné řádky dialplánu na jinou. Toto může být problematické, pokud
používáme n priority. Řešením je použití štítků k označení specifického řádku a poté volání tohoto
názvu štítku za pomocí Goto ( ) . Aplikace Goto ( ) může být využit uvnitř extension, mezi extensions
nebo mezi kontexty.
Uvnitř extension:
exten => 1007,1,Answer()
exten => 1007,n(Start),Wait(1)
exten => 1007,n,Playback(hello-world)
exten => 1007,n,Goto(Start)
77
Mezi extensions:
exten => 1008,1,Answer()
exten => 1008,n,Goto(1009,Ping)
exten => 1009,1(Ping),Playback(hello-world)
exten => 1009,n,Wait(2)
exten => 1009,n,Goto(1010,Pong)
exten => 1010,1(Pong),Playback(tt-weasels)
exten => 1010,n,Wait(2)
exten => 1010,n,Goto(1009,Ping)
Mezi kontexty:
[vedeni]
exten => 1011,1,Answer()
exten => 1011,n,Playback(hello-world)
exten => 1011,n,Goto(prodej,1012,1)
[prodej]
exten => 1012,1,Playback(hello-world)
exten => 1012,n,Hangup()
3.4.11 Smyčky a While ( )
Smyčky umožňují provádět operace v dialplánu opakovaně. K použití smyček v dialplánu se používá
aplikace While ( ) :
exten => 1013,1,Answer()
exten => 1013,n,Set(i=1)
exten => 1013,n,While($[${i} < 10])
exten => 1013,n,SayNumber(${i})
exten => 1013,n,Wait(1)
exten => 1013,n,Set(i=$[${i} + 1])
exten => 1013,n,EndWhile()
exten => 1013,n,Hangup()
3.4.12 Podmínka a Gotoif ( )
Pomocí aplikace Gotoif ( ) můžeme skočit do jiné části dialplánu, pokud je splněna definovaná
podmínka:
exten => 1014,1,Answer()
exten => 1014,n,Set(Favoritestation = 0815)
exten => 1014,n,NoOp(ověření zda se volá ${Favoritestation})
exten => 1014,n,GotoIf($[${CALLERID(num) = ${Favoritestation}]?yes,no)
exten => 1014,n(yes),Playback(hello-world)
exten => 1014,n,Hangup()
78
exten => 1014,n(no),Playback(tt-monkeys)
exten => 1014,n,Hangup()
3.4.13 Podprogramy a Gosub ( )
Pomocí aplikace Gosub ( ) je hovor přesměrován do podprogramu, může být navrácen do původní
priority pomocí aplikace Return ( ):
exten => 1015,1,Gosub(cid-set)
exten => 1015,n,Dial(SIP/${EXTEN})
exten => 1015,n(cid-set),Set(CALLERID(all) = Firma s.r.o <8005551212>)
exten => 1015,n,Return()
3.4.14 Proměnné
Pomocí proměnných můžeme ukládat aktuální hodnoty. V Asterisku můžeme ukládat čísla,
písmena a celé řetězce. Proměnné jsou důležité jelikož nám umožňují definovat lépe pravidla podle,
kterých je poté prováděn specifický hovor. Proměnné v Asterisku také nejsou závislé na velikosti
písma. Mohou být definovány malými písmeny či velkými (${BARVA}, ${barva}), jediná výjimka je u
systémových proměnných, ty jsou vždy zadávány velkými písmeny (${EXTEN}). Pokud definujeme
pomocí aplikace Set ( ) proměnnou tvořenou slovem, z pravidla se toto slovo dává do uvozovek,ale
není to nutná podmínka.
Pokud bychom chtěli do názvu proměnné volit znaky, které mají v syntaxi Asterisku jiný význam,
je nutné před ně vložit oddělovač. V extensions.conf se používá oddělovač \ . Znaky, které je potřeba
takto oddělit jsou například:
[]$“\_
Uveďme příklad:
exten => 1234,1,Set(castka="\$10.00")
Pokud budeme chtít použít samotný znak \ , musíme opět použít oddělovač:
exten => 1234,1,Set(cislopokoje="48\\10")
Co se týče omezení velikosti proměnné, maximální délka je 18 znaků. Při větším zadání je
generována chyba.
Následující seznam obsahuje nejpoužívanější systémové proměnné:
•
•
•
•
•
$ {ANSWEREDTIME} – celkový čas aktivního spojení v sekundách
${BLINDTRANSFER} – název kanálu na druhé straně spojení
${CHANNEL} – název aktuálního kanálu
${CONTEXT} - název aktuálního kontextu
${EPOCH} - aktuální UNIX čas (počet sekund, které uběhly od startu UNIX epochy – půlnoc,
1. Ledna, 1970)
79
•
•
•
•
•
•
•
$ EXTEN} – akutálně volané číslo
${HANGUPCAUSE} - důvod ukončení hovoru
${INVALID_EXTEN} - používá se v i extension a obsahuje volané číslo
${PRIORITY} – aktuální priorita aktuální extension
${TRANSFER_CONTEXT} – kontext přenášeného hovoru
${UNIQUEID} – jedinečné ID číslo pro dané spojení
${SYSTEMNAME} - název systému. Je definován v /etc/asterisk/asterisk.conf
Speciální proměnné:
•
Proměnná h – h je standardní extension pro ukončení hovoru. Pokud je definovaná, je
volána jakmile colající ukončí hovor. Představme si, že chceme například definovat globální
proměnnou SPOJENI, která bude reflektovat počet aktuálních spojení. Pokud se spojení
naváže zvýší se hodnota, pokud ukončí,zase se sníží:
[global]
SPOJENI=0
[from-internal]
exten => _X.,1,Set(SPOJENI=$[${SPOJENI} + 1]|g)
exten => _X.,2,Dial(SIP/${EXTEN})
exten => h,1,Set(SPOJENI=$[${SPOJENI} - 1]|g)
•
Proměnná i – abychom v dialplánu resp. v kontextu dokázali vždy řešit i nečekáné situace,
využiváme proměnnou i. Tato proměnná spravuje včechny vytáčená čísla, která nejsou
explicitně zadány v kontextu. V souvislosti s proměnnou i se používá systémová proměnná
${INVALID_EXTEN}. V konkrétním případě mohou zaměstnanci Firmy s.r.o. volat pouze čísla
100-199. Pokud zavolají na jiné, přehraje se jim zvuková informace o neplatném čísle:
[firmasro]
exten => _1XX,1,Dial(${EXTEN})
exten => i,1,NoOp(Nesprávné číslo ${INVALID_EXTEN} bylo vytočeno.)
exten => i,2,Answer( )
exten => i,3,Playback(invalid)
exten => i,4,Hangup( )
•
Proměnná o a a – pokud v souboru pro nastavení hlasové schránky voicemail.conf povolíme
volbu operator=yes , bude hovor směrován na extension o(abort) jakmile stiskne volající
nulu. Po stisknutí hvězdičky, bude hovor směrován na extension a (abort).
[firmasro]
exten => _1XX,1,Dial(${EXTEN})
exten => i,1,NoOp(Nesprávné číslo ${INVALID_EXTEN} bylo vytočeno.)
exten => i,2,Answer( )
exten => i,3,Playback(invalid)
exten => i,4,Hangup( )
80
•
Proměnná t a T – jedná se o proměnné pro srpávu časových intervalů v kontextech. Pokud
například využíváme IVR (kapitola 1.10) a od volajícího nepříjde žádný vstup pomocí DTMF
volby, je hovor ukončen:
[hlavnimenu]
exten => 10,1,Answer()
exten => 10,n,Background(marryme)
;"vezmeš si mě? Stiskni 1 pro
ano, 2 pro ne.”
exten => 1,1,Playback(thank-you-cooperation) ;1 => "Díky."
exten => 1,n,Hangup( )
exten => 2,1,Playback(hangup-try-again)
exten => 2,n,Hangup( )
exten => t,1,Hangup( )
;2 => "Ukončete a zkuste znovu.“
;žádná odpověď => zavěs.
Velké T se volá tehdy, kdy byl překročen maximální definovaný čas. Ten se dá nastavit pomocí:
Set(TIMEOUT(absolute)=<sekundy>)
•
Proměnná s – prvním údajem každé extension je volané číslo či jméno. Pokud však přichází
hovor na Asterisk například ze sítě PSTN, Asterisk nemá informace, jaké číslo bylo voláno, či
na koho se chce volající dovolat. V tomto případě se používá proměnné s, která nahrazuje
volaé číslo v extension. V následujícím příkladě se všem volajícím z PSTN na Asterisk
přehraje zvuk opic.
exten => s,1,Answer()
exten => s,2,Wait(1)
exten => s,3,Play(tt-monkeys)
exten => s,4,Wait(1)
exten => s,5,Hangup()
3.4.15 Makra
Makra jsou druhem podprogramu. Mohou obsahovat kompletní programy a funkce,ale jsou
volány skrze jednoduchý řádek. To umožňuje zachovávat přehledný dialplán. Jednoduchý příklad
makra vypadá následovně:
[macro-prichozi]
exten => s,1,Dial(SIP/${MACRO_EXTEN},10)
exten => s,n,VoiceMail(${MACRO_EXTEN})
Toto makro může být voláno:
[prodej]
exten => _2XXX,1,Macro(prichozi)
[building-mgr]
exten => _2XXX,1,Macro(prichozi)
81
3.5
Asterisk Extension Language (AEL)
Již jsme se zmínili, že existují dvě cesty jak sestavovat dialplán. První, kterou jsme si již popsali,
tzn. pomocí extension.conf a novější metoda pomocí rozšířeného jazyka Asterisku tzv. AEL jazyka.
V tomto případě pracujeme se souborem extensions.ael , který je umístěn opět v adresáři
/etc/asterisk. AEL může být užitečný pro ty, kterým dělá problémy orientace v rozsáhlých dialplánech
psaných klasickou metodou a jsou spíše zastánci vzhledu skriptovacího programu. AEL totiž velice
skriptovací jazyk připomíná. Lze používat i obě metody dohromady, čili i klasickou i AEL.
3.5.1
CLI příkazy pro AEL
Nejdůležitějším příkazem v CLI pro AEL je příkaz ael reload . Znovu načte extensions.ael do
paměti a po každé změně konfiguračního souboru, je nutné tento příkaz provést pro aktualizaci.
*CLI> ael reload
3.5.2
Aelparse
Od verze 1.4 obsahuje Asterisk nástroj pro konvertování extensions.ael skriptů do klasické podoby
extensions.conf. Tento nástroj je využíván hlavně pro odstraňování chyb a pro ověření validity kódu
napsaného v extensions.ael. Aelparse obsahuje několik parametrů, v následujícím příkladě je
uveden parametr –w , který ukládá překonvertovaný obsah do souboru extensions.conf.aeldump a
parametr-q pro výstup na obrazovku, který oznamuje pouze varování a chyby.
asterisk: /etc/asterisk# aelparse -q -w
LOG: lev: 4 file: ael2_parse line: 543 func: main 19 contexts, 25 extensions,
62 priorities
3.5.3
Srovnání extensions.conf s extensions.ael
Následující příklad znázorňuje stejný zápis extensions, v prvním příkladě v extensions.conf v druhém
případě v extensions.ael. Jak již bylo řečeno, zápis v AEL jazyce připomíná spíše klasický skriptovací
jazyk. Nejprve zápis v extensions.conf:
[my-phones]
exten => 20,1,Answer()
exten => 20,n,Playback(beep)
exten => 20,n,Hangup()
Podobně jako v jiných programovacích jazycích je nutné každý AEL příkaz ukončit středníkem.
Funkčně totožný zápis v extensions.ael:
context my-phones {
20 => {
Answer();
Playback(beep);
82
Hangup();
}
}
3.5.4
Kontexty, extensions a priority v AEL
Na dalším příkladu si uvedeme, jak jsou v případě AEL definovány kontexty, extensions a
priority. Číslování priorit již není v AEL podporováno, kontext je definován před složenými závorkami,
které uzavírají samotné extensions a aplikace. Opět klasický zápis:
[internal-users]
exten => 21,1,Dial(SIP/anna)
exten => 21,n,VoiceMail(anna)
exten => 22,1,Dial(SIP/lisa)
exten => 22,n,VoiceMail(lisa)
exten => _3X,1,Dial(SIP/${EXTEN})
A AEL zápis:
context internal-users {
21 => {
Dial(SIP/anna);
VoiceMail(anna);
}
22 => {
Dial(SIP/lisa);
VoiceMail(lisa);
}
_3X => {
Dial(SIP/${ EXTEN});
}
}
3.5.5
Vložené kontexty – Include Statements v AEL
Vložené kontexty se zapisují v AEL následovně. Opět klasický zápis:
[sales]
exten => 2001,1,Dial(SIP/anna)
exten => 2002,1,Dial(SIP/brock)
[warehouse]
exten => 3001,1,Dial(SIP/lisa)
[day]
include => sales
include => warehouse
83
A AEL zápis:
context sales {
2001 => {
Dial(SIP/anna);
}
2002 => {
Dial(SIP/brock);
}
}
context warehouse {
3001 => {
Dial(SIP/lisa);
}
}
context day {
includes {
sales;
warehouse;
}
}
3.5.6
Štítky, goto a přeskakování v AEL
V rozsáhlejších diaplánech je programátor nucen přeskakovat jednotlivé řádky v dialplánech
pomocí aplikací Goto (), Gotoif (), Gosub () a Gosubif ():
[priklad]
; skoky v extension
;
exten => 10,1(begin),NoOp()
exten => 10,n,Wait(1)
exten => 10,n,SayNumber(1)
exten => 10,n,NoOp(endlessloop)
exten => 10,n,Goto(begin)
; skoky mezi extensions
; se stejnym kontextem
exten => 20,1,SayNumber(20)
exten => 20,n,Goto(10,begin)
; skoky mezi ruznymi kontexty
exten => 30,1,SayNumber(30)
exten => 30,n,Goto(cntxt2,40,forty)
[cntxt2]
exten => 40,1(forty),NoOp()
exten => 40,n,SayNumber(40)
exten => 50,1,Goto(40,1)
exten => 60,1,Goto(example,10,1)
84
V AEL jazyce je štítek vždy uvnitř extension a na svém řádku:
context priklad {
// skoky v extension
//
10 => {
begin:
Wait(1);
SayNumber(10);
NoOp(endlessloop);
goto begin;
}
//skoky mezi extensions
//se stejnym kontextem
//
20 => {
SayNumber(20);
goto 10|begin;
}
// skoky mezi ruznymi kontexty
//
30 => {
SayNumber(30);
goto cntxt2|40|forty;
}
}
context cntxt2 {
40 => {
forty:
SayNumber(40);
}
50 => jump 40;
60 => jump 10@example;
}
V uvedeném příkladě můžeme vidět rozdílnou syntaxi aplikace „goto“:
extensions.conf Goto([[kontext,]extension,]štítek)
extensions.ael goto[[kontext|]extension|]štítek
3.5.7
Podmínky v AEL
Podmínky jsou struktury, které nám umožňují kontrolovat průběh programu. AEL jazyk obsahuje
oba příkazy – if i switch. To je velká výhoda, jelikož se tím stává AEL dialplán daleko více čitelným.
•
IF - V extensions.conf musíme štítkovat cíle explicitně:
exten => 90,1,Dial(SIP/anna)
exten => 90,n,GotoIf($["${DIALSTATUS}" = "BUSY"]?b:n)
85
exten => 90,10(b),Answer()
exten => 90,11,Playback(hello-world)
exten => 90,12,Voicemail(anna,b)
exten => 90,13,Goto(end)
exten => 90,20(n),Dial(SIP/lisa)
exten => 90,21,Playback(beeperr)
exten => 90,22,Goto(end)
exten => 90,30(end),NoOp(done)
V extensions.ael má příkaz if jednodušší strukturu:
90 => {
Dial(SIP/anna);
if ("${DIALSTATUS}" = " BUSY") {
Answer();
Playback(hello-world)
Voicemail(anna,b);
}
else {
Dial(SIP/lisa);
Playback(beeperr);
}
NoOp(done);
}
•
SWITCH - V AEL jazyce nám umožňuje příkaz switch jednoduše tvořit kód, který
dokáže pracovat s více možnostmi. Pokud bychom chtěli napodobit funkcionalitu příkazu
switch v extensions.conf vznikne nepřehledný zmatek:
exten => 70,1,Dial(SIP/anna)
exten => 70,n,Goto(70-${DIALSTATUS},10)
exten => 70 n(end),NoOp(done)
exten => 70-BUSY,10,NoOp(busy)
exten => 70-BUSY,11,Goto(end)
exten => 70-NOANSWER,10,NoOp(no answer)
exten => 70-NOANSWER,11,Goto(end)
exten => _70-.,10,NoOp(something else)
exten => _70-.,11,Goto(end)
V extensions.ael je výsledek snadno čitelný a elegantní:
70 => {
Dial(SIP/anna);
switch ("${DIALSTATUS}") {
case "BUSY":
NoOp(busy);
break;
case "NOANSWER":
NoOp(no answer) ;
break;
86
default:
NoOp(something else) ;
}
NoOp(done) ;
}
•
IFTIME - V AEL jazyce tato funkce nahrazuje aplikaci GotoIfTime () v extensions.conf:
20 => {
ifTime (08:00-18:00|mon-fri|*|*) {
Dial(SIP/20);
} else {
Playback(announcement-closed);
Voicemail( 20,s);
}
}
•
RANDOM - Tato funkce může dosahovat hodnot 1-99. Jedná se o vyjádření procentní
šance, že bude daný blok kódu proveden:
20 => {
random (42) {
NoOp(42 % Chance);
} else {
NoOp(58 % Chance);
}
}
3.5.8
Smyčky v AEL
Stejně jako podmínky, smyčky umožňují spravovat struktury. AEL obsahuje klasické smyčky for a
while.
•
WHILE - Příkaz while v AEL jazyce se používá podobně jako aplikace While () a
EndWhile () v extensions.conf :
exten => 40,1,Set(x=5)
exten => 40,n,While($[${x} <= 9])
exten => 40,n,NoOp(x is ${x})
exten => 40,n,ExecIf($[${x} > 5] , ExitWhile)
exten => 40,n,Playback(beep)
exten => 40,n,Set(x=$[${x} + 1])
exten => 40,n,EndWhile()
exten => 40,n,NoOp(done)
V extensions.ael jsou použity příkazy break a continue. Příkaz break skáče na konec bloku
smyčky, continue naopak na začátek. V následujícím příkladě je použit break:
30 => {
x=0;
while (${x} <= 9) {
87
NoOp(x is ${x} );
if (${x} > 5) {
break;
}
Playback(beep);
y=${x} + 1;
}
NoOp(done);
}
•
FOR - AEL jazyk nabízí také vytváření smyček pomocí příkazu for. Tento příkaz nemá
ekvivalent v extensions.conf , jelikož každá smyčka pomocí for lze realizovat pomocí
while:
exten => 40,1,Set(x=5)
exten => 40,n,While($[${x} <= 5])
exten => 40,n,NoOp(x is ${x})
exten => 40,n,Playback(beep)
exten => 40,n,Set(x=$[${x} + 1])
exten => 40,n,EndWhile()
exten => 40,n,NoOp(done)
Stejná funkce pomocí for v extensions.ael:
40 => {
for (x=0; ${x}<=5; x=${x}+1) {
NoOp( x is ${x} ) ;
Playback(beep) ;
}
NoOp(done) ;
}
3.5.9
Makra
V extensions.conf jsou makra realizována pomocí aplikací Macro () nebo Gosub (). Příklad ukazuje
použití Macro ():
[macro-countdown]
exten => s,1,Set(c=${ARG1})
exten => s,n,While($[ ${c} > 0])
exten => s,n,SayNumber(${ c})
exten => s,n,Set(c=$[ ${c} - 1 ])
exten => s,n,EndWhile()
[default]
exten => 123,1,Macro(countdown,3)
exten => 124,1,Macro(countdown,5)
Kompilátor AEL jazyka konvertuje automaticky příkaz macro do Gosub (). V AEL jazyce nemáme
na výběr. AEL používáme pro práci s makry příkaz macro:
88
macro countdown( count ) {
for (c=${count}; ${c} >0; c=${c} -1) {
SayNumber(${c});
}
}
context default {
123 => {
&countdown(3);
}
124 => &countdown(5);
}
3.5.10 Filtrování na základě ID volajícího
V extensions.conf tato velice populární tzv. funkce „ex-přítelkyně“ vypadá následovně:
exten => 10/6135303122,1,NoOp(ex-girlfriend)
exten => 10/6135303122,n,Busy()
exten => 10,1,Dial(SIP/david)
exten => 10,n,Voicemail(david)
V extensions.ael by výše uvedená funkce vypadala takto:
10/6135303122 => {
NoOp(ex-girlfriend);
Busy();
}
10 => {
Dial(SIP/david);
Voicemail(david);
}
Pokud přichází telefonní hovor od osoby s ID 6135303122, je mu automaticky přehrán
obsazovací tón, všechny ostatní příchozí hovor jsou směrovány na telefon Davida.
3.6
Voicemail
Hlasová schánka (dále jen voicemail) je jednou ze základních služeb, která je Asteriskem
poskytována. 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í:
[general]
format = wav
89
[default]
2000 => 1234,Filip Rezac,[email protected]
2001 => 5678,Miroslav Voznak,[email protected]
Nyní jsou schránky nakonfigurovány. Každý záznam začíná číslem hlasové schránky (2000,
2001), dále pak pokračuje heslem účtu (1234, 5678), poté jmény uživatelů voicemailu (Filip,
Miroslav) a končí jejich e-mailovou adresou ( [email protected], [email protected]).
Posledním krokem je přidat několik řádek i do extensions.conf , tak, aby byly voicemaily plně funkční:
[default]
exten => 1001,1,Answer()
exten => 1001,2,Playback(hello-world)
exten => 1001,3,Hangup()
exten => 2000,1,Dial(SIP/2000,20)
exten => 2000,2,VoiceMail(2000,u)
exten => 2001,1,Dial(SIP/2001,20)
exten => 2001,2,VoiceMail(2001,u)
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.
3.7
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í.
90
3.7.1
Jednoduché IVR
Asterisk obsahuje několik přednahraný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,1,Answer()
exten => 30,2,Background(marryme)
exten => 30,3,Hangup()
exten => 1,1,Playback(thank-you-cooperation)
exten => 1,2,Hangup()
exten => 2,1,Playback(sorry)
exten => 2,2,Hangup()
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í.
3.7.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.)
exten => 30,1,Answer()
exten => 30,2,Background(marryme)
exten => 30,3,Hangup()
exten => 1,1,Playback(thank-you-cooperation)
exten => 1,2,Hangup()
exten => 2,1,Playback(sorry)
exten => 2,2,Hangup()
; Pokud je vloženo jiné než platné číslo
exten => i,1,Background(sorry)
exten => i,2,Hangup()
3.7.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říkladě je použita pauza 5 sekund:
exten => 30,1,Answer()
91
exten => 30,2,Background(marryme)
exten => 30,3,Background(silence/5)
exten => 30,4,Hangup()
exten => 1,1,Playback(thank-you-cooperation)
exten => 1,2,Hangup()
exten => 2,1,Playback(sorry)
exten => 2,2,Hangup()
exten => i,1,Background(marryme)
exten => i,2,Hangup()
3.7.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říkladě 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,1,Answer()
exten => 30,2,Background(hlavni-menu)
exten => 30,3,Background(silence/3)
exten => 30,4,Goto(2)
exten => 1,1,Dial(SIP/100)
exten => 2,1,Dial(SIP/150)
; Goto() skočí do dalšího kontextu ([restaurace])
;
exten => 3,1,Goto(restaurace,200,1)
exten => i,1,Goto(30,2)
92
[restaurace]
exten => 200,1,Background(restaurace)
exten => 200,2,Background(silence/3)
exten => 200,3,Goto(1)
exten => 1,1,Playback(restaurace-nabidka-tento-tyden)
exten => 1,2,Wait(2)
exten => 1,3,Goto(1)
exten => 2,1,Playback(restaurace-nabidka-pristi-tyden)
exten => 2,2,Wait(2)
exten => 2,3,Goto(1)
; Š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.
3.8
Databáze Asterisku
Problém užívání proměnných v dialplánu Asterisku spočívá v jejich zranitelnosti vůči nečekaným
restartům či haváriím systému, kde je Asterisk nainstalován. Pokud taková situace nastane, jsou data
ztracena,nebo nastavena do výchozích hodnot. Navíc služby jako přesměrovaní hovorů vyžadují
uložení dat pro další použití například po restartu Asterisku. K uložení dat a proměnných se
v Asterisku využívá tzv. AstDB – Asterisk databáze.
Naskýtá se otázka, kdy je vhodné Asterisk databázi využít? Pro malé systémy, kde systém
nepracuje s velkým množstvím dat, je využití databáze zbytečně složité, naopak pro velké a
komplexní systémy je vhodnější využít externí databáze, například SQL serveru. Pokud však
chceme znát co nejvíce možností, které nám Asterisk nabízí, je dobré vědět, jak Asterisk databázi
použít.
V základní instalaci obsahuje Asterisk databázi založenou Berkley databázi – BDB. BDB je
jednoduchá, výkonná databáze. Nepodporuje SQL či jiný dotazovací jazyk a povoluje přístup pouze
skrze procesové API volání. Data jsou uložena ve formě klíč/hodnota, kde klíče jsou sdružovány do
rodin.
3.8.1
Zápis hodnot do databáze
Funkce DB () se volá skrze aplikaci Set (). Vložení zápisu jablko do rodiny ovoce s hodnotou 20 se
provede následujícím zápisem extension:
exten => 1234,1,Set(DB(ovoce/jablko)=20)
93
3.8.2
Čtení hodnot z databáze
Hodnoty z databáze mohou být volány opět funkcí DB () ve formátu ${DB(rodina/klíč)}. K výpisu
obsahu jablko v rodině ovoce do konzole zadejte následující příkaz:
exten => 1234,1,NoOp(ovoce/jablko má hodnotu ${DB(ovoce/jablko)})
Hodnotu z databáze můžeme vložit do extensions následujícím způsobem:
exten => 1234,1,Set(pocetjablek=${DB(ovoce/jablko)})
3.8.3
Mazání hodnot z databáze
Aplikace DBdel () a DBdeltree () se využívají k mazání záznamů v databázi.
•
DBdel() a ${DB_DELETE()} – v Asterisku verze 1.2 se jednotlivé záznamu v databázi
mazaly pomocí DBdel (). Smazání klíče jablko z rodiny ovoce se provede následovně:
exten => 1234,1,DBdel(ovoce/jablko)
V Asterisku verze 1.4 a vyšší je již DBdel () zastaralá. K smazání stejného záznamu jako
v předchozím případě využijeme funkci DB_DELETE ():
exten => 1234,1,NoOp(${DB_DELETE(ovoce/jablko)})
•
DBdeltree() – pokud potřebujeme smazat celou rodinu využijeme aplikace DBdeltree().
Rodina ovoce se smaže následujícím způsobem:
exten => 1234,1,DBdeltree(fruit)
3.8.4
Přístup do databáze z CLI
Systémový administrátor může přistupovat k databázi Asterisku skrze CLI. Pokud zadáváme do
databáze hodnotu oddělenou mezerou, musí být vždy v uvozovkách („Hello world“).
3.8.5
Zápis hodnot do databáze pomocí CLI
K zápisu do databáze slouží příkaz database put rodina klíč hodnota:
*CLI> database put ovoce jablko 20
Updated database successfully
3.8.6
Čtení hodnot z databáze pomocí CLI
Pro načtení hodnoty slouží příkaz database get rodina klíč:
94
*CLI> database get ovoce jablko
Value: 20
3.8.7
Mazání hodnot z databáze pomocí CLI
Příkazy database del rodina klíč a database deltree rodina mažou záznamy z databáze.
•
database del – Pro smazání klíče jablko z rodiny ovoce použijeme:
*CLI> database del ovoce jablko
Database entry removed.
•
database del tree – Pro smazání celé rodiny ovoce použijeme:
*CLI> database deltree ovoce
Database entrie removed.
3.8.8
Zobrazení obsahu databáze v CLI
Příkazy database show a database showkey zobrazují obsah databáze v CLI:
*CLI> database put nakupniseznam vejce 2
Updated database successfully
*CLI> database put nakupniseznam maslo 250
Updated database successfully
*CLI> database put nakupniseznam cukr 500
Updated database successfully
*CLI> database show
/nakupniseznam/cukr
: 500
/nakupniseznam/maslo
: 250
/nakupniseznam/vejce
:2
*CLI> database showkey maslo
/nakupniseznam/maslo
: 250
*CLI> database deltree nakupniseznam
Database entries removed.
3.8.9
Přístup do databáze z příkazové řádky
Příkazem asterisk –rx ‘příkaz’ můžeme provádět CLI příkazy přímo z příkazové řádky našeho OS:
asterisk -rx ’database put test hodnota1 23’
Updated database successfully
asterisk -rx ’database put test hodnota2 42’
Updated database successfully
asterisk -rx ’database show test’
/test/hodnota1
: 23
/test/hodnota2
: 42
asterisk -rx ’database get test hodnota2’
Value: 42
95
asterisk -rx ’database deltree test’
Database entries removed.
3.8.10 Záloha databáze
Databáze Asterisku je nativně uložena v /var/lib/asterisk/astdb. Tento soubor lze zkopírovat poté, co
je Asterisk zastaven. Pomocí příkazu v příkazovém řádku lze databázi zálohovat například takto:
asterisk -rx "database show" > /tmp/backup-asterisk-database.txt
3.8.11 Příklad přesměrování
V následujícím příkladě bude v Asterisku nastaveno přesměrování hovorů na jiné číslo uvnitř firmy.
Pro aktivaci přesměrování je využito interní číslo 44 následované číslem, kam má být hovor
směrován. Pro deaktivaci přesměrování je opět zadána 44, tentokrát již bez čísla:
[from-internal]
; aktivace
exten => _44X.,1,Answer()
exten => _44X.,n,Set(DB(CF/${CALLERID(num)})=${EXTEN:2})
exten => _44X.,n,SayDigits(${EXTEN:2})
exten => _44X.,n,NoOp(Přesměrování z ${CALLERID(num)} na ${EXTEN:2}
> aktivováno.)
exten => _44X.,n,Hangup()
; deaktivace
exten => 44,1,Answer()
exten => 44,n,DBdel(CF/${CALLERID(num)})
exten => 44,n,Playback(auth-thankyou)
exten => 44,n,NoOp(Přesměrování čísla ${CALLERID(num)} deaktivováno.)
exten => 44,n,Hangup()
[from-external]
exten => _X.,1,NoOp(Hovor z ${CALLERID(num)} na ${EXTEN})
exten => _X.,n,GotoIf($[foo${DB(CF/${EXTEN})} != foo]?normal:forward)
exten => _X.,n(normal),Dial(SIP/${EXTEN})
exten => _X.,n(forward),NoOp(Hovor pro ${EXTEN} bude spojen s
˃ ${DB(CF/${EXTEN})})
exten => _X.,n,Dial(local/${DB(CF/${EXTEN})})
96
3.9
Služby Asterisku
Asterisk nabízí veliké 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.
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.
97
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
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.
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.
98
4
Asterisk v praktických příkladech
Pro instalaci Asterisku využijeme samoinstalačních balíčků. Je potřeba být přihlášen pod
uživatelem s právy správce systému. Samotná instalace se provede:
# apt-get install asterisk
4.1
Nastavení SIP účtů
Veškerá konfigurace v oblasti SIP protokolu a registrace SIP účtů se provádí v souboru sip.conf
umístěném v hlavním adresáři systému Asterisk (/etc/asterisk/). V následující ukázce je znázorněna
základní SIP konfigurace, včetně vygenerování dvou účtů.
[general]
context=Asterisk1
;Default context pro příchozí volání
port=5060
;Použitý port pro SIP signalizaci
udpbindaddr=0.0.0.0 ;IP adresa pro navázání spojení (0.0.0.0 ;pro všechny IP adresy)
srvlookup=yes ;Povolení DNS SRV lookup pro odchozí ;volání
disallow=all
allow=alaw
allow=gsm
allow=ulaw
;Implicitní zakázání všech kodeků
;Povolení kodeku PCM A-law
;Povolení kodeku GSM
;Povolení kodeku PCM µ-law
[101] ;Definování účtu s číslem 101
type=friend
context=Asterisk1
;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=101
;Přihlašovací jméno při registraci účtu
secret=101
;Přihlašovací heslo při registraci účtu
callerid=101 <101>
[102]
type=friend
context=Asterisk1
language=cz
99
host=dynamic
username=102
secret=102
callerid=102 <102>
4.2
Nastavení IAX účtů
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í.
[general]
bindport=4569
bindaddr=0.0.0.0
;Nastavení portu IAX signalizace
;Stejná funkcionalita jako udpbindaddr u ;SIP protokolu
disallow=all
allow=alaw
allow=ulaw
allow=gsm
jitterbuffer=no
forcejitterbuffer=no
[1001] ;Definice účtu s číslem 1001
type=friend
context=Asterisk1
language=cz
host=dynamic
username=1001
secret=1001
callerid=IAX1 <1001>
4.3
Dialplan a jeho nastavení
Veškeré nastavení číslovacího plánu se provádí v konfiguračním souboru extensions.conf. Jedná se
de-facto o základní soubor systému Asterisk a právě zde je definováno, jakým způsobem budou
ovládána jednotlivá volání. Následující ukázka zobrazuje příklad číslování pro námi výše definované
účty.
[general]
static=yes
writeprotect=no
;Zamezení přepisování dialplanu z CLI
[macro-hovor] ;Definování makra „hovor“, který nám ;usnadní vytváření dialplanu a vyhneme ;se tak
neustálému přepisování stejných ;příkazů
exten => s,1,Dial(${ARG1}) ;Začne výstavbu spojení za ;pomocí protokolu a na číslo ;uvedeného
v proměnné ARG1, ;která je do makra předána ;jako argument
exten => s,2,Congestion
;V případě nedostupnosti ;koncového terminálu ;poskytne signalizaci
;obsazení
exten => s,3,Hangup
;Ukončení hovoru
100
[Asterisk1]
;Context (skupina), která byla nastavena ;u SIP a IAX účtů
exten => _101,1,Macro(hovor,SIP/101)
;V případě volání ;čísla 101 se použije ;naše makro
„hovor“ ;s argumentem SIP/101, ;tedy je použita SIP ;signalizace a je ;volán účet definovaný
;v sip.conf jako [101]
exten => _102,1,Macro(hovor,SIP/102)
exten => _1001,1,Macro(hovor,IAX2/1001)
Nyní by již měla být zajištěna základní nastavení postačující pro registraci účtů např. na
některém ze SIP softwarových klientů a možnost zavoláním mezi těmito účastníky.
4.4
Další užitečná nastavení pro Asterisk
V dalších podkapitolách budou uvedeny příklady pro použití videa, propojování Asterisků a jejich
zabezpečení.
4.4.1
Rozšířené nastavení SIP – povolení videopřenosu
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
4.4.2
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
101
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
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)
exten => _202,1,Macro(hovor,SIP/202)
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ázku č. 34.
102
Obr. 34. 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):
[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
103
[macro-hovor]
exten => s,1,Dial(${ARG1})
exten => s,2,Congestion
exten => s,3,Hangup
[Asterisk1]
exten => _101,1,Macro(hovor,SIP/101)
exten => _102,1,Macro(hovor,SIP/102)
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
exten => _101,1,Macro(hovor,SIP/101)
exten => _102,1,Macro(hovor,SIP/102)
Samozřejmě podobnou úpravu je nutné také provést na straně ústředny Asterisk2:
[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)
exten => _202,1,Macro(hovor,SIP/202)
exten => _101,1,Macro(hovor,IAX2/Asterisk1/${EXTEN})
exten => _102,1,Macro(hovor,IAX2/Asterisk1/${EXTEN})
[IAXpeer]
exten => _201,1,Macro(hovor,SIP/201)
exten => _202,1,Macro(hovor,SIP/202)
4.4.3
Zabezpečení médií v Asterisku pomocí SRTP
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ášť. 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 ***
104
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í.
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 ***
4.4.4
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
105
root@Asterisk1:/etc/cert# cat key.pem > /etc/asterisk/cert/asterisk.pem
root@Asterisk1:/etc/cert# cat asterisk.crt >> /etc/asterisk/cert/asterisk.pem
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
106
5
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.
[har]
W. Hardy.VoIP service quality, McGraw-Hill, 2003, New York, ISBN 0-07-141076-7.
[meg]
Meggelen, J. Asterisk The Future of Telephony, O REILLY, 2006, ISBN 0596009623.
[sin1]
H. Sinnreich. SIP Beyond VoIP. VON Publishing LLC, New York, 2005, ISBN: 0974813001.
[sin2]
H. Sinnreich.Internet Communications Using SIP, Wiley Computer Publishing, New York, 2001,
ISBN 0-471-41399-2 .
[voz70]
Voznak,M., Zukal,D. Assessment of VoIP Quality , p.641-645, 6th International Conference
RTT 2005, 12-14.9.2005, Hradec nad Moravici, FEI VSB-TUO, ISBN 80-248-0897-8.
[voz72]
Vozňák, M., Zukal, D., Wija,T. Asterisk a jeho použití, Technická zpráva 12/2005 , Cesnet
z.s.p.o., říjen 2005, URL: http://www.cesnet.cz/doc/techzpravy/
[voz73]
Vozňák, M., Zukal, D. Analýza VoIP aplikací Surveyor 7.0 Technická zpráva 13/2005 , Cesnet
z.s.p.o., listopad 2005, http://www.cesnet.cz/doc/techzpravy/
[voz90]
Vozňák, M.: Signalizace SIP, str. 35-75 ve sborníku Teorie a praxe IP telefonie, vyd. Sdělovací
[voz92]
Diviš, Z., Vozňák, M., Blunár, K., Vašinek, V., Mer, P., Šebesta, R.: Moderní Komunikační
[voz111]
Halas M., Kyrbashov B., Voznak M.: Factors influencing voice quality in VoIP technology, In:
technika, ČVUT a ProTel engineering, v Praze 8.11.2006
Technologie. VŠB-TUO. Ostrava. 2006. skripta 413 stran. ISBN 80-248-1111-1.
9th International Conference on Informatics‘ 2007, pp. 32-35, Bratislava, 21-22.June 2007,
ISBN 978-80-969243-7-0.
[voz120]
Nappa,A.-Bruschi,D.-Rozza,A.-Voznak,M. Analysis and implementation of secure and
unsecure Voice over IP environment and performance comparison using OpenSER. Technical
report, 84 pages, published at Universita degli studi di Milano, December, 2007.
[voz133]
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.
[voz138]
Voznak,M: Ipmact of openVPN on Speech Bandiwth. In proceedings TSP2008, 31th
International conference, 3-4.9 in Paradfurdo, Hungary. Publisher: Asszisztencia Szervező Kft.
Budapest, ISBN 978-963-06-5487-6.
[voz142]
Vozňák,M.Voice over IP. Vysokoškolská skripta, 176 stran. Vydavatel: VŠB-TU Ostrava, 1.
vydání, v Ostravě, září 2008, ISBN 978-80-248-1828-3.
[voz146]
Nappa,A.,Voznak,M.Scapy: the definitive tool to manage and troubleshoot your
network.Publisher: Piscopo Editore Srl.,Italy. In Magazine Linux&C, p.51-58, No.66 , issued in
November 2008, ISSN 1129-2296.
107
[voz159]
Voznak,M.,Rezac,F. The implementation of SPAM over Internet telephony and a defence
against this attack. Publisher: Asszisztencia Szervező Kft. Budapest, 32nd International
Conference TSP , August 26th-27th 2009, Dunakiliti, Hungary, ISBN 978-963-06-7716-5.
[voz166]
Voznak,M.,Rezac,F., Halás,M. Speech Quality Evaluation in IPsec Environment, p. 49-53, In
Proceedings of the 12th Inter. Conference on Networking, VLSI and Signal Processing - ICNVS
2010, University of Cambridge, ISBN 978-960-474-162- 5, ISSN 1790-5117, Cambridge,
February 20-22,2010.
[voz174]
Voznak,M.,Rezac,F. Zdralek,J. Danger Alert Communication System, The 17th International
Conference IWSSIP 2010 , p.231-234, June 17-19, 2010, Rio de Janeiro, Brazil, ISBN 978-85228-0565-5.
[voz180]
Voznak,M.,Rezac,F., Tomala, K. SIP Penetration Test System, In Conference Proceedings
TSP 2010 ,p.504-508, August 17th-20th 2010, Baden near Vienna, Austria, ISBN 978-96388981-0-4.
[voz188]
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, Spain, ISBN 978-0-7695-4182-2.
[voz191]
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.
[voz193]
Voznak,M.,Rezac, F. Threats Detection System, Advances in Data Networks, Communications,
Computers, pp. 125-130, University of Algarve, Faro, Portugal, November 2010,ISBN 978-960474-245-5, ISSN 1792-6157.
[voz194]
Voznak,M.,Tomes, M., Vaclavikova, Z., Halas,M. E-model Improvement for Speech Quality
Evaluation Including Codecs Tandeming, Advances in Data Networks, Communications,
Computers, pp. 119-124, University of Algarve, Faro, Portugal, November 2010,ISBN 978-960474-245-5, ISSN 1792-6157.
[zph]
Web Zphone project, online:http://zfoneproject.com/zrtp_ietf.html
108
6
Rejstřík
AES (Advanced Encryption Standard) - Metoda šifrování dat.
AH (Authentication Header Protocol) – Protokol využívaný v IPsec.
ARP (Address Resolution Protocol) – Protokol pro mapování MAC adres na IP adresy.
DES (Data Encryption Standard) - Metoda šifrování dat.
DHCP (Dynamic Host Control Protocol) – Protokol pro dynamické přidělování IP adres.
DNS (Domain Name Service) - Doménový systém jmen.
DdoS (Distributed Denial of Service) – Distribuované odmítnutí služby.
DoS (Denial of Service) - Odmítnutí služby.
ENUM (E.164 Number Mapping) – Mapování E.164 čísel na URI adresy.
ESP (Encapsulating Security Payload Protocol) – Protokol využívaný v IPsec.
GPL (GNU General Public Licence)- Všeobecná veřejná licence GNU.
H.225 - Protokol pro signalizaci volání a sestavení komunikace pro H.323.
H.235 - Protokol pro definici bezpečnostních profilů pro H.323.
H.245 - Protokol k řízení multimediálního přenosu pro H.323.
H.323 - Signalizační protokol používaný ve VoIP.
HTTP (Hypertext Transfer Protocol) - Internetový protokol používaný pro přenos informací.
HTTPS (Hypertext Transfer Protocol Security) – Zabezpečený Internetový protokol používaný pro přenos informací.
IPsec. (IP security) - bezpečnostní rozšíření IP protokolu.
ISDN (Integrated Services Digital Network) – Digitální síť integrovaných služeb.
ITU (International Telecommunications Union) – Mezinárodní telekomunikační unie
109
MD5 (Message-Digest algorithm 5) - Hashovací funkce
NAT (Network Address Translation) - Překlad síťových adres.
PBX (Private Branch eXchange)- Pobočková telefonní ústředna.
PSTN (Public Switched Telephone Network) - Veřejná telefonní síť.
RTP (Real-time Transport Protocol) - Protokol přenosu v reálném čase.
RTCP (RTP Control Protocol) - Řídící protokol pro RTP.
S/MIME (Secure / Multipurpose Internet Mail Extensions) - Bezpečnostní rozšíření pro odesílání e-maiových zpráv.
SAML (Security Assertion Markup Language) - Systém pro výměnu bezpečnostních informací.
SDP (Session Description Protocol) - Protokol k řízení multimediálního přenosu pro SIP.
SHA1 (Secure Hash Algorithm 1) - Hashovací funkce.
SIP (Session Initiation Protocol) - Signalizační protokol používaný ve VoIP.
SPIT (Spam over Internet Telephony) - Označení pro spam ve VoIP.
SRTP (Secure RTP) - Zabezpečený protokol přenosu v reálném čase.
SRTCP (Secure RTCP) - Zabezpečený řídící protokol pro RTP.
TLS (Transport Layer Security) - Protokol poskytující zabezpečenou komunikaci .
TTS (Text to Speech) – Technologie pro přenos textu na hlas.
UA (User Agent)- Koncové zařízení v SIP infrastruktuře.
UAC (User Agent Client) - Koncové zařízení v SIP infrastruktuře na straně klienta.
UAS (User Agent Server- Koncové zařízení v SIP infrastruktuře na straně server.
UDP (Unified Datagram Protocol) – datagramový protokol používaný pro přenos v IP sítích.
URI (Uniform Resource Identifier)- Řetězec znaků pro identifikování či pojmenování zdroje.
VLAN (Virtual Local Area Network) – Virtuální lokální síť.
VoGW (Voice GateWay) – Hlasová brána.
VoIP (Voice over Internet Protocol) - Technologie pro přenos digitalizovaného hlasu pomocí paketů v počítačové síti.
VPN (Virtual Private Network) – Virtuální privátní síť, propojení důvěryhodných sítí skrze nedůvěryhodnou.
ZRTP (Zimmermann RTP) - Nástavbový protokol pro SRTP.
110