Multimediální přenosy. IP telefonie.

Transkript

1 Multimediální přenosy. IP telefonie. Petr Grygárek rek 1

2 Alternativy použití a související prvky S W I P t e l e f o n ( S I P / H / I A X ) S I P I P t e l e f o n S W I P t e l e f o n ( S I P / H / I A X ) f i r e w a l l H t e l e f o n N A T / P A T S W I P t e l e f o n ( S I P / H / I A X ) S W P B X S I P s e r v e r, H g a t e k e e p e r P B X + g a t e w a y b ě ž n ý t e l e f o n 2

3 Požadavky na paketovou síť pro provoz multimediálních aplikací v reálném čase Podpora mechanismů QoS Diffserv nebo IntServ (rezervace zdrojů pomocí RSVP) Priorizace určitého typu provozu (L3 i L2) Malá latence (zpoždění při přenosu) + + malá á variance zpoždění (jitter) řešení: priorizace ve frontách, Link Fragmentation and Interleaving Malá ztrátovost paketů aplikace v reálném čase nemohou použít potvrzování a retransmisi 3

4 Přenos multimediálních relací v reálném čase Signalizační protokoly Navazování a rušení relací mezi koncovými body Pro mobilní uživatele nebo uživatele používající více zařízení nutný mechanismus vyhledání aktuálního umístnění uživatele v síti (registr uživatelů) Podpora autorizace, autentizace a účtování prováděných akcí mnohdy centralizovanyých řešení pomocí podpůrných serverů Řídící protokoly dohoda na oboustranně podporovaných formátech proudu multimediálních dat (kodeky atd.) dohoda logických kanálů koncové transportní í body komunikace adresy a porty Přenosové protokoly přenos multimediálních dat dohodnutého formátu v reálném čase dnes typicky RTP (Realtime Protocol) založený na UDP 4

5 Signalizační protokoly Slouží k informaci o požadavku ke zřízení relace Signalizační zprávy se mohou šířit jinou cestou než následný tok multimediálních dat relace často přeposílání signalizačních zpráv přes několik proxy serverů Poté, co je navázána relace (RTP), není nadále závislá na funkčnosti signalizačních protokolů až na ukončení relace 5

6 Používané signalizační protokoly Standardizované é a dobře dokumentované ITU H.323 (rodina standardů) IETF SIP (Session Initiation Protocol) Oba počítají s přenosem vlastních multimediálních dat v RTP Proprietární Cisco Skinny Client Control Protocol (SCCP) PBX nahrazena SW Cisco Call Manager, Cisco IP telefony Siemens CorNet PBX HiPath + IP telefony OptiSet 6

7 Signalizace mezi ústřednami MGCP Media Gateway Control Protocol Konfigurace Media Gateway z Call Agentů Media Gateway konvertuje mezi tradičními okruhy a VoIP IAX Inter-Asterisk Exchange Pro SW pobočkovou ústřednu Asterisk Zatím nestandardizovaný, ale otevřený a dobře dokumentovaný 7

8 H.323 (1) První verze v roce 1995 původně jen rozšíření přenosu přes PSTN (považovaného za základ) o přenos přes LAN verze z roku 1999 považuje H.323 za standard pro implementaci VoIP v globálním měřítku (Internet) i podnikových řešeních Filosofie vychází z telekomunikačního světa Cílem zachování všech služeb klasických telekomunikačních sítí (PSTN, ISDN, ATM) a dobrá propojitelnost s nimi Snaha integrovat inteligenci a řízení oprávnění do centrálního prvku (gatekeeper) Orientace na audio a případně video (včetně konferenčních služeb) 8

9 H.323 (2) Složitá vrstvená architektura s řadou vzájemně provázaných protokolů (cílem dobrá modularita) Podpora doplňkových služeb (i jisté uživatelské rozšiřitelnosti) Řeší signalizaci i dohodu parametrů spojení Binární formát zpráv ASN.1 (X.680) + Packet P Encoding Rules (PER, X.691) minimalizuje spotřebu pásma, ale obtížné na sledování a ladění Povinné udržování kompatibility se staršími verzemi standardu přináší obsáhlý kód Použití ve starších nebo rozsáhlých implementacích s návazností na klasické telefonní sítě (stále méně) veřejní poskytovatelé IP telefonie, větší pobočkové telefonní ústředny 9

10 SIP (1) RFC 3261 Protokol pro navazování obecných relací hlas, video, data, relace dvoubodové nebo multipoint (konference) Nezávislý na přenášeném obsahu relací pro přenos vlastních multimediálních dat používá unicast nebo multicast IP (RTP) Snaha rozprostřít inteligenci do koncových zařízení při ponechání možnosti inteligentního zpracování signalizace sítí (SIP servery) 10

11 SIP (2) Textově orientované zprávy formát obdobný HTTP v v UDP, lze i v TCP Důraz na rozšiřitelnost a škálovatelnost možnost přidávání nových hlaviček, ignorování neznámých hlaviček Jednodušší než H.323, snadnější, rychlejší a levnější implementace, postupně se dostává do popředí korporátní řešení konvergované sítě pro data i hlas, levná IP telefonie v Internetu Vlivem stále se rozšiřujících nástaveb se však i SIP pomalu začíná komplikovat... 11

12 H.323 Detailně 12

13 Logické komponenty k architektury (1) H.323 terminál HW nebo SW koncové zařízení Identifikováno (alespoň jedním) telefonním číslem Gatekeeper Registrace aktuálního umístění terminálů Vyhledávání adres terminálů na základě tel. čísel (resolving) Řízení přístupu (admission control) Směrování hovorů, rozklad zátěže, Zná využití sítě jednotlivými uživateli - možnost účtování Volitelná komponenta, lze i přímý kanál mezi terminály bez registrace terminálů u gatekeeperu Gateway do cizích spojově orientovaných sítí Jeví se jako terminál Identifikována telefonním číslem Poznámka: místo telef. čísel lze někdy použít obecnější aliasy 13

14 Logické komponenty k architektury (2) Multipoint Controller Propojuje signalizaci a kanály pro řízení konferencí hvězdicové uspořádání účastníků konference Poskytuje seznam účastníků konference Řídí výměnu médií (sjednocení formátu) mezi účastníky konference Multipoint Processor Směšuje proudy od jednotlivých účastníků konference a zasílá zpět k účastníkům (mullticastem nebo častěji unicastem); Broadcast konference = jediný zdroj, více cílů vysíláno multicastem Session Description Protocol (SDP) popisuje média relace Session Announcement Protocol (SAP) informuje o vysílaných relacích Multipoint Control Unit = Multipoint Controller + Multipoint Processor 14

15 Struktura doporučení ITU-T A u d i o V i d e o C o n f e r e n c e c o n t r o l G a t e k e e p e r D a t a a p p l i c a t i o n s R S V P R T P / R T C P R A S H H T M C U D P T C P + R F C I P / I P M u l t i c a s t I n t e g r a t e d / D i f f e r e n t i a t e d S e r v i c e s F o r w a r d i n g 15

16 H RAS (Registration, Admission and Status) Mezi H.323 terminálem a gatekeeperem a mezi gatekeepery vzájemně Registrace terminálů na gatekeeperu (+deregistrace) za použití autentizace Zjišťování adresy účastníka od gatekeeperu Žádosti o povolování hovoru u gatekeeperu autorizace - volání i přijetí hovoru Ověřování stavu (zapnutí ) terminálu a a počtu aktivních hovorů Nad UDP/ / 1719 (unicast( unicast) ) nebo UDP/1718 (multicast) 16

17 H Signalizace Kanál pro sestavovs estavování spojení podmnožina Q.931 (ISDN) podpora použití doplňkových služeb Mezi koncovými body spojení (H.323 terminály) Může procházet jedním nebo více gatekeepery 17

18 H.245: Řízení relací Sestavení a řízení volání účastníků konference (dvoubodové spojení chápáno jako speciální případ) Dohoda kódování srozumitelného všem účastníkům Konfigurace proudů médií IP adresy a porty použité pro příjem a vysílání jednotlivými účastníky V rámci r jedné relace může být otevřeno i více proudů (logických kanálů) s různou požadovanou šířkou pásma Lze použít pro přenos uživatelského vstupu (např. DTMF) Může procházet jedním nebo více gatekeepery Vychází ze zkušeností z konferencí v PSTN Komplexní a poněkud těžkopádný H.323 nevyužívá všechny jeho možnosti H.245 lze tunelovat v signalizačním kanále H Možnost optimalizace procedurou FastStart (FastConnect) nabídka médií se posílá přímo kanálem H

19 Registrace u gatekeeperu Nalezení gatekeeperu Multicast dotaz na (UDP/1718) GATEKEEPER_REQUEST, GRQ Do těla t dotazu lze vložit ID požadovaného gatekeeperu, pak odpovídá pouze on GATEKEEPER_CONFIRM, GCF Manuální konfigurace IP adresy gatekeeperu do terminálu Registrace terminálu u gatekeeperu REGISTRATION_REQEST, RRQ registrace pod telefonním číslem nebo uživatelským jménem REGISTRATION_CONFIRM CONFIRM,, RCFR / REGISTRATION_RE _REJECT,, RRJR RJ UNREGISTER_REQUEST, REQUEST, URQ UNREGISTER_CONFIRM _CONFIRM, UCF / UNREGISTER_RE REJECT, URJ Registrace má omezenou dobu platnosti, musí se obnovovat 19

20 Modely signalizace H u H

21 Zprávy zpracovávané gatekeeperem (sítí gatekeeperů) Vždy alespoň zprávy kanálu RAS Admission control Admission Request (ARQ) Admission Confirm (ACF) Admission Reject (ARJ) Admission control řeší jak volající, tak volaný (!) Volitelně i signalizační kanál (H.225.0) Volitelně i kanál pro výměnu médií (H.245) 21

22 Přímá signalizace H g a t e k e e p e r H t e r m i n á l H t e r m i n á l 1 A R Q 2 A C F / A R J 3 S e t - u p 4 A R Q 5 A C F / A R J 6 C o n n e c t 7 H c h a n n e l z p r á v y R A S k a n á l u z p r á v y k a n á l u s i g n a l i z a c e v o l á n í z p r á v y k a n á l u H

23 Signalizace H přes gatekeeper H g a t e k e e p e r H t e r m i n á l H t e r m i n á l 1 A R Q 2 A C F / A R J 3 S e t - u p 5 A R Q 6 A C F / A R J 7 C o n n e c t 4 S e t - u p 8 C o n n e c t 9 H c h a n n e l z p r á v y R A S k a n á l u z p r á v y k a n á l u s i g n a l i z a c e v o l á n í z p r á v y k a n á l u H

24 Řízení H.245 přes p gatekeeper H g a t e k e e p e r H t e r m i n á l H t e r m i n á l 1 A R Q 2 A C F / A R J 3 S e t - u p 5 A R Q 6 A C F / A R J 7 C o n n e c t 9 H c h a n n e l 4 S e t - u p 8 C o n n e c t 1 0 H c h a n n e l z p r á v y R A S k a n á l u z p r á v y k a n á l u s i g n a l i z a c e v o l á n í z p r á v y k a n á l u H

25 Komunikační fáze H Sestavení volání (H.225.0) 2.Počáteční komunikace a výměna schopností (H.245) 3.Sestavení audiovizuální komunikace 4.Služby volání 5.Ukončení volání 5. 25

26 1. Sestavení volání Signalizační zprávy (H.225.0) SETUP, ALERTING, (CALL PROCEEDING), CONNECT,, RELEASE COMPLETE, FACILITY Přímé sestavení bez registrace na gatekeeperu Registrace na stejném gatekeeperu Registrace na různých gatekeeperech RAS zprávy mezi gatekeepery pro nalezení lokace volaného Sestavení s MCU (konference) 26

27 2. Počáteční komunikace a výměna schopností (H.245) Pomocí řídícího kanálu H.245 Pokud není použita procedura FastConnect Možnost tunelování H.245 v signalizačních zprávách pokud není právě třeba žádnou signalizační zprávu zaslat, použije se zpráva FACILITY Určení rolí Master/Slave Výměna TERMINAL CAPABILITY SET 27

28 3. Sestavení audiovizuální komunikace Otevření dříve dohodnutých logických kanálů (proudů) UDP (audio,video) nebo TCP (data) 28

29 4. Služby volání Volitelné operace Změny šířky pásma Doplňkové služby 29

30 5. Ukončení volání Iniciuje koncový bod nebo i gatekeeper gatekeeper např. při překročení povolené doby hovoru Signalizační zpráva RELEASE COMPLETE Mělo by předcházet uzavření všech logických kanálů (proudů) Rozpojení logického kanálu H.245 (END SESSION COMMAND) O ukončení volání s protějškem musí terminál informovat i gatekeeper DISENGAGE REQUEST (DRQ), DISENGAGE CONFIRM (DCF) Kvůli účtování Pokud má být ukončením volání zrušena i celá konference, nutno explicitně zaslat zprávu H.245 DROP CONFERENCE 30

31 Příklad zprávy H

32 Zóny Prostředí H.323 děleno do zón Nemusí nijak kopírovat topologii IP sítě Za každou zónu zodpovědný primární gatekeeper Možnost použití záložních gatekeeperů Gatekeepery se vzájemně mohou žádat o zjištění adresy uživatele LOCATION REQUEST (LRQ) dotaz sousednímu gatekeeperu unicastem nebo všem multicastem LOCATION CONFIRM (LCF), pokud zná LOCATION REJECT (LRJ), pokud nezná Různé vzory šíření zpráv podle modelů signalizace použitých ve zúčastněných zónách 32

33 Zóny v H.323 Z ó n a A Z ó n a B H g a t e k e e p e r H g a t e k e e p e r H t e r m i n á l H t e r m i n á l z p r á v y R A S k a n á l u z p r á v y k a n á l u s i g n a l i z a c e v o l á n í a k a n á l u H p r o u d y m é d i i 33

34 Bezpečnost v H.323 (H.235) Autentizace signalizace sdílená hesla, digitální podpisy Integrita zpráv generována kontrola s použitím sdíleného hesla Šifrování kanálů médií dohoda parametrů v H.245 DES, 3DES, RC2 34

35 SIP Detailně 35

36 Logické komponenty User Agent Proxy Server Redirect Server Registrar Server architektury 36

37 User Agents Logická abstrakce koncových zařízení PC, mobilní telefon, PDA, brány PSTN, Využívají SIP k nalezení jiných koncových bodů a k dohodnutí parametrů relace s nimi User Agent Client volající, iniciuje požadavky SIP User Agent Server volaný, přijímá požadavky SIP a reaguje na ně 37

38 SIP servery Vzájemně logicky propojeny i do složité struktury Registrar server, Proxy server, Redirect server Zajišťují směrování požadavku na relace od volajícího co nejblíže k volanému k k proxy serveru, který zná aktuální umístění volaného, ten předá požadavek volanému Autentizace volajícího, autorizace relace, účtování, 38

39 Proxy server funkce klienta i serveru operuje ve jménu klienta prohlašuje sám sebe za iniciátora požadavku může přepisovat hlavičky požadavku outbound proxy (z hlediska klienta) řeší průchod přes firewall a účtování požadavků z vnitřní sítě (autonomně spravované jednotky) Koncová zařízení (UA) mají konfigurovánu IP adresu SIP proxy serveru 39

40 Typy proxy p serverů Bezestavový jen přeposílá požadavky, neřeší jejich vztah (transakce) rozklad zátěže, přeposílání zpráv, překlad zpráv neumožňuje štěpení a pohlcování opakovaně zasílaných zpráv Stavový udržuje stav požadavku během transakce Většina dnešních implementací Seskupuje zprávy do transakcí Stav udržován i po delší dobu (např. než volaný příjme/odm /odmítne hovor) Výkon limitován Podporuje štěpení požadavku = přeposílání jednoho požadavku na více cílů Podporuje účtování, překonávání NATu, Umožňuje pohlcování opakovaně zasílaných zpráv 40

41 Redirect server Neforwarduje signalizační zprávy, nepřijímá žádosti o zřízení relace Pouze vrací klientovi odpověď přesměrovávající na jiný server Seznam umístění požadovaného uživatele zjištěný od registrar serveru 41

42 Nalezení proxy serveru Manuální konfigurace UA Dynamické přidělení pomocí volby DHCP IPv4: volba 120 (RFC 3361), IPv6: volba 21 (RFC 3319) SIP server pro doménu vyhledáván pomocí DNS Využití SRV záznamů Alternativní SRV záznamy, UA volí round-robin algoritmem Formát: _Service._Protocol.Name TTL Class SRV Priority Weight Port TargetDomainName sip._udp.vsb.cz SRV sipproxy.vsb.cz 42

43 Registrar server Registruje aktuální umístění uživatelů IP adresa, port, uživatelské jméno -> Registrace s omezenou platností pole expires: v hlavičce registrace musí se pravidelně obnovovat Zpracovává zprávy REGISTER a žádosti o vyhledání umístění Zpravidla integrován s proxy serverem Nalezení registrátora: statická definice IP adresy multicast dotaz na sip.mcast.net ( ) 43

44 Registrace aktuálního umístění d a t a b á z e u m í s t n ě n í Z á z n a m v d a t a b á z i U ž i v a t e l s i p : a l i c f i r m a. c o m j e d o s t u p n ý n a s i p : a l i c : : s i p : a l i c f i r m a. c o m 3 r e g i s t r a r. f i r m a. c o m 1 R E G I S T E R 2 u l o ž e n í d o D B O K z p r á v y p r o t o k o l u S I P i n t e r n í t o k r e g i s t r á t o r a 44

45 Adresace v SIP SIP URL: user@host. user: username/telefonní í číslo host: domain name/ip adresa Často se používá stejný řetězec jako ová adresa sip: kocour@cs.vsb.cz cs.vsb.cz sip: @ SIP server pro doménu v DNS reprezentován položkou typu SRV nebo identifikován doménovým jménem, ke kterému existuje záznam A Není-li v URL specifikován transportní protokol, zkouší se nejprve UDP a pak TCP Implicitní port pro SIP je

46 Signalizace s použitím Způsob šíření SIP Zasílána na nakonfigurovaný proxy server Zasílána přímo na adresu a port požadovaného SIP URL V V případě zasílání přes UDP serverový User agent zasílá odpověď zpět na adresu uvedenou v hlavičce požadavku 46

47 Zprávy SIP Požadavky a odpovědi přenášeny v UDP nebo TCP Hlavičky požadavků a odpovědí jako u HTTP Hlavičky popisují parametry požadavku a odpovědi nebo specifikují obsah jejich těla 47

48 Nejčastější hlavičky zpráv From:, To: - iniciátor/příjemce zprávy v položce From: je i tag identifikující dialog Via: popisuje cestu, po které se zpráva šíří Call-ID: identifikuje zprávy jednoho dialogu CSeq: sekvenční číslo zprávy (v rámci dialogu) zajištění správného pořadí a párování požadavků a souvisejících odpovědí Contact: IP adresa a port, kde volající očekává odpověď na zprávu Content-Type, Content-Length popisuje typ média v těle zprávy User-Agent: název a verze UA (SIP klienta) 48

49 Příklad zprávy SIP INVITE SIP/2.0 URI dalšího skoku Content-Length: 337 Contact: Call-ID: Content-Type: application/sd From: CSeq: 2 INVITE Max-Forwards: 70 To: <sip:210@ > Via: SIP/2.0/UDP ;rport; \ branch=z9hg4bkc0a e529d00007d zaznanenávání cesty požadavku User-Agent: SJLabs-SJphone/ Proxy-Authorization: Digest username="422", \ realm="vsb.cz",nonce="216c048c",uri="sip:210@ ", \ response="c55c a83884c40d28fe8a9aa8 (Tělo zprávy) Zpráva protokolu SDP popis akceptovatelných médií 49

50 Příklad těla zprávy INVITE (protokol SDP) v=0 o= IN IP s=sjphone c=in IP t=0 0 a=direction:active m=audio RTP/AVP a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:97 ilbc/8000 a=rtpmap:98 ilbc/8000 a=fmtp:98 mode=20 a=rtpmap:101 telephone-event/8000 a=fmtp: ,16 50

51 Session Description Protocol (SDP) RFC 2327 protokol pro popis multimediální iální relace P2P, P2MP Používán protokolem SIP k ve zprávě INVITE a odpovědi na ni Dohoda formátů médií a adres koncových bodů transportních protokolů pro realtime kanály Popis médií, které lze nabídnout a přijmout IP adresy a porty pro příjem a vysílání médií Informace o šifrování Informace o šířce pásma 51

52 Zprávy SIP typu požadavek (1) INVITE Žádost o navázání spojení Pro obousměrná volání popisuje média podporovaná volajícím ACK Úspěšná odpověď (200 OK) popisuje média podporovaná volaným Potvrzení konečné odpovědi na přijetí zprávy INVITE volajícím 3-way handshake volaný čekáním na zprávu ACK ověřuje, zda volající mezitím neukončil snahu o navázání relace 52

53 Zprávy SIP typu požadavek (2) BYE Informace o ukončení relace Může iniciovat volající i volaný CANCEL Zrušení právě zpracovávané žádosti U U ještě nesestavené relace REGISTER Registrace aktuálního umístění klienta u SIP serveru IP adresa a port, na kterém klient poslouchá OPTIONS Zjištění vlastností podporovaných serverem 53

54 Odpovědi na SIP zprávy 6 tříd, 3-místné chybové kódy Konečné (final) Indikují ukončení akce Pozitivní a negativní odpověď, přesměrování Provizorní (provisional) Indikují probíhající vykonávání akce Požadavek byl převzat, ale dosud není znám výsledek akce RINGING, TRYING, 54

55 Příklad SIP odpovědi - hlavička SIP/ OK Via: SIP/2.0/UDP ; \ branch=z9hg4bkc0a e529d00007d ; \ received= ;rport=5060 From: "422"<sip:422@ >;tag= To: <sip:210@ >;tag=as23505f77 Call-ID: 0BE6CF2D-6A7F-4FAA- BD7A-758D8435A7D0@ C Seq: 2 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Contact: <sip:210@ > Content-Type: application/sdp Content-Length: 218 (Tělo zprávy) 55

56 Příklad SIP odpovědi - tělo v=0 o=root IN IP s=session c=in IP t=0 0 m=audio RTP/AVP a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp: a=silencesupp:off

57 Transakce a dialog v o l a j í c í v o l a n ý I N V I T E T R Y I N G R I N G I N G t r a n s a k c e O K A C K d i a l o g B Y E O K t r a n s a k c e 2 57

58 Transakce SIP Posloupnost vzájemně souvisejících vyměňovaných signalizačních zpráv Požadavek a všechny odpovědi na něj i i více provizorních, obvykle jedna konečná v v případě rozštěpení požadavku i více konečných Transakce vytvářejí UA a proxy servery Identifikace transakce: Původně To:+From:+Request-URI+CSeq Nyní část branch v hlavičce Via: Slouží pro podporu směrování a ohraničení trvanlivosti záznamu o stavu ve stavových entitách Volající a volaný si při prvním směrování zprávy přes řetězec proxy serverů vymění položku Contact: a další zprávy transakce si již vyměňují přímo Pokud požadujeme podporu NAT, musí všechny zprávy procházet přes proxy server(y) - hlavička Record route: 58

59 Dialog SIP Sekvence transakcí mezi dvěma UA Identifikovány poli CallID: a částmi Tag pole From: a To: hlaviček zpráv V V rámci jednoho dialogu v jednom směru aktivní vždy nejvýše jedna transakce Existují i zprávy, které nevytvářejí dialog zpráva MESSAGE rychá zpráva (instant message) 59

60 Typické signalizační scénáře SIP 60

61 Registrace u ž i v a t e l s k ý a g e n t r e g i s t r á t o r R E G I S T E R ( b e z o v ě ř o v a c í c h ú d a j ů ) P r o x y A u t h e n t i c a t i o n R e q u i r e d R E G I S T E R ( v č e t n ě o v ě ř o v a c í c h ú d a j ů ) O K 61

62 Zahajování relace přes proxy server v o l a j í c í p r o x y s e r v e r v o l a n ý I N V I T E T R Y I N G I N V I T E T R Y I N G R I N G I N G R I N G I N G O K O K A C K 62

63 Přihlášení k odběru asynchronních událostí u ž i v a t e l s k ý a g e n t s e r v e r S U B S C R I B E O K u d á l o s t N O T I F Y O K 63

64 Signalizace přes proxy server 2 3 D N S s e r v e r 4 p r o x y. f i r m b. c o m 1 p r o x y. f i r m a. c o m A l i c e B o b f i r m a f i r m b 1 I N V I T E 2 S I P s e r v e r p r o f i r m b. c o m? 3 p r o x y. f i r m b. c o m 4 I N V I T E 5 I N V I T E 6 B Y E z p r á v y p r o t o k o l u S I P D N S d o t a z y / o d p o v ě d i 64

65 Signalizace přes více proxy serverů 2 1 S I P p r o x y 1 S I P p r o x y v o l a j í c í v o l a n ý 1 I N V I T E 3 I N V I T E 2 I N V I T E 4 B Y E 65

66 Vyhledávání lokace uživatele Redirect server vrací seznam potenciálních lokací Klient se snaží kontaktovat uživatele sám Proxy server může sám zkoušet kontaktovat uživatele na známých lokacích, až se navázání relace podaří 66

67 Protokoly pro přenos p médií v reálném čase 67

68 Standardizované é kodeky Audio G.711a/ G.711u u 64 kbps (8kHz PCM) Podporován všemi zařízeními pro IP telefonii GSM (ETSI standard) 13 kbps vzorkování 8kHz, rámec 22 ms, predikční kódování G kbps vzorkování 8kHz, rámec 10 ms (nízká latence, ale poněkud vyšší overhead), predikční kódování patentován, nákup licence drahý, podpora v HW zařízeních Video (v v H.323 volitelné) H.261, H

69 Real-Time Protocol (RTP) RFC 1889 Nad UDP/5004 Identifikace přenášených p informací (kodeky) Kontrola pořadí paketů případně přeuspořádávání Přenos synchronizace informace o čase sejmutí jednotlivých vzorků Počítání statistik doručování 69

70 Hlavička paketu RTP Převzato z 70

71 Důležité položky hlavičky RTP Payload Type použitý kodek Sequence Number Timestamp čas sejmutí prvního vzorku v paketu Synchronization Source (SSRC) Hodnota jednoznačně identifikující zdroj přenášených datv rámci relace Contributing Source (CSRC) pole hodnot jednoznačné hodnoty identifikující zdroje přenášených dat (použito v případě směšování toků) CSRC jsou SSRC jednotlivých příspěvkových toků směšovače 71

72 RTP Control Protocol (RTCP) Nad UDP/5005 Ke každému RTP kanálu existuje RTCP kanál s číslem o 1 vyšším Zpětná vazba RTP přenosu Vyhodnocování kvality spojení Řízení parametrů adaptivních kodeků Přenos identifikátoru zdroje RTP dat (CNAME) Oznamování počtu účastníků konference Přenos řídících informací Identifikace všech účastníků 72

73 Typy RTCP paketů Sender Record počty vyslaných bajtů, Receiver Record Přenos informací od přijímajících účastníků relace Source Description Application Defined Lze kombinovat (compound RTCP packet) 73

74 Problémy s RTP a RTCP Používání velkého množství dynamických UDP portů při průchodu přes firewall často řešeno přeposíláním RTP toku přes prostředníka na hranici sítě (gatekeeper) 74

75 Software pro IP telefonii 75

76 Otevřené SW implementace IP telefonie Klienti: KPhone, SJPhone Knihovny: Open H323, osip Gatekeeper GNUGK SIP server: SIP Express Router (SER) proxy, registrar, redirect server Softwarová pobočková ústředna Asterisk 76

77 SIP Extensions Rozšíření pro různé speciální aplikace Rozšířené služby volání, bezpečnost, messaging Integrace se SW aplikacemi Postupně se dodefinovávají stále další ve zvláštních RFC viz např. 77

78 ENUM Mechanismus mapování telefonních čísel na URI serverů, přes něž lze v účastníka dosáhnout i i více URI k jednomu E.164 číslu Využívá DNS Implementováno např. v bind Hierarchie u telefonních čísel postupuje zleva doprava u u doménových jmen zprava doleva řešení analogické PTR záznamům Záznamy s E.164 čísly uloženy v převráceném tvaru v poddoménách e164.arpa. NAPTR záznamy Položky ORDER a PREFERENCE Podpora přepisů částí telefonních čísel určených pomocí regulárních výrazů 78

79 Reference a další studijní literatura Staněk, F.: Technologie pro přenos hlasu v paketových sítích. Diplomová práce FEI VŠB-TUO, 2005 Vedouci DP Petr Grygárek Obrázky použité v této prezentaci byly převzaty z uvedené DP se svolením autora. RTP: multimedia/rtp_4.pdf 79