v. 2.2 Katedra softwarového inženýrství, Matematicko-fyzikální fakulta, Univerzita Karlova, Praha Rodina protokol, verze 2.2 ást 11: VOIP, IP telefonie Jií Peterka, 2005
v. 2.2 terminologie VOIP (Voice over IP) obecné oznaení pro technologii penosu zdigitalizovaného hlasu po protokolu IP mže být realizována rznými zpsoby proprietárn Skype, Fayn, dle standardu H.323 dle standardu SIP a MGCP. mže být využita k rzným úelm jako veejná služba jako služba pro privátní úely nap. telefonování v rámci firmy jako technologickéešení u operátor v páteních ástech svých sítí penáší data nikoli na principu pepojování okruh, ale pomocí VOIP mže využívat rznou penosovou infrasktrukturu veejný Internet privátní intranet.. IP telefonie obecné oznaení pro službu vtšinou veejná služba využívá technologie VOIP nedlá rozdíl mezi použitou penosovou infrastrukturou Internet, intranet internetová telefonie varianta IP telefonie, pro penosy dat využívá veejný Internet VOD (Voice over Data) obecnjší oznaení než VOIP jakákoli technologie pro penos zdigitalizovaného hlasu po datových sítích nap.: VoFR (Voice over Frame Relay) VoATM (Voice over ATM) VoDSL (Voice over DSL) 2
v. 2.2 historie 1995: izraelská firma Vocaltec pedstavuje svj Internet Phone všeobecn považováno za zaátek (bžn dostupné) internetové telefonie znan nedokonalé, ale postupn se zlepšuje 1996: ITU vydává doporuení H.323 jako standard IP telefonie "ze svta spoj" 1998: první použitelná revize 1999: objem datového provozu v telekomunikaních sítí se vyrovnává hlasovému provozu (v digitální podob) dále roste už jen datový provoz hlasový provoz vícemén stagnuje 1999: IETF schvaluje protokol SIP Session Initiation Protocol RFC2543 (17.3.1999) RFC3261 až RFC 3265 (2002) jako ešení IP telefonie "ze svta poíta" souást rodiny protokol () 1999: v únoru 1999 v R zakázána služba Paegas Internet Call v ervenci liberalizovány hlasové služby na bázivoip generální povolenítú. 22/1999 1999 data hlas 3
v. 2.2 IP telefonie: co všechno se musí vyešit jak digitalizovat (kódovat) hlas? ve svt POTS (PSTN) je vše pevn dáno PCM, 64 kbit/s na hovor ve svt IP telefonie pipadá v úvahu více možností tyto možnosti musí být definovány svými standardy jak se domluvit na schopnostech zaízení v POTS: schopnosti jsou stejné zde: mohou se i významn lišit musí existovat mechanismy, prostednictvím kterých se zúastnné strany dohodnou na tom, co umí a co budou používat jak penášet data relativn nejsnazší až na otázku kvality služeb jak propojit systémy IP telefonie s klasickou telefonní sítí musí existovat vhodné brány jak "zaadit" telefon do sít ve svt POTS (PSTN) jsou telefony pevn piazené k telefonním ústednám a ty je "obsluhují" ve svt IP telefonie není pedem dáno, "kam telefon patí" musí existovat správci, kterým, se IP telefony pihlásí a které je "zaadí" a zalení do celé telefonní sít a umožní jejich dostupnost pro píchozí volání jak navazovat spojení jak ešit adresaci telefonníísla, vs. IP adresy jak hledat cestu k volanému eší správci. 4
v. 2.2 H.323 plným jménem: "Visual Telephone Systems and Equipment for Local Area Networks Which Provide a Non Guaranteed Quality of Service" pochází od ITU Mezinárodní telekomunikaní unie je "plnohodnotným" ešením velmi komplexní, robustní pokrývá všechny aspekty telefonie dobe navazuje na klasickou telefonii velmi drahé a komplikovanéešení ne vždy nutné realizovat v plném rozsahu dnes spíše ustupuje ve prospch SIP-u který je "odlehený", flexibilnjší, jednodušší H.323 je celkovou architekturou IP telefonie nikoli jedním protokolem obsahuje adu konkrétních protokol ale krom IP telefonie eší (voliteln) také: videopenosy a datové penosy pedpokládá: penosovou infrastrukturu bez podpory QoS pokrývá (zahrnuje protokoly pro): správu terminál a zóny kódování hlasu G.711, G.729 a ada dalších ízení hovor signalizaci penos dat používá UDP i TCP (nad IP) 5
v. 2.2 architektura H.323 gatekeeper (správce, eší administrativní funkce) MCU Multipoint Control Unit (eší komunikaci více uzl souasn) zóna IP sí V PSTN (voice) gateway V brána mezi systémem IP telefonie a klasickou telefonní sítí terminály terminálový adaptér pro použití klasického (ne-ip) telefonu 6
v. 2.2 architektura H.323 RAS kanál data data V gatekeeper zprostedkuje "vyhledání volaného" + další. samotný hovor v datové podob (a jeho ízení) probíhá pímo na peer-to-peer bázi komunikace terminál-gatekeeper mže být nespojovaná nad protokolem UDP mezi terminály (terminálem a bránou) se vytváí "hovorový kanál" (call channel) obvykle: spojovaný, nad TCP slouží potebám: signalizace ízení hovoru peer-to-peer komunikace data se penáší "samostatn" nespojovan (RTP nad UDP) 7
v. 2.2 signalizace a ízení hovor, signalizace (Signalling) eší "telekomunikaní záležitosti" týká se zizování, vedení a ukonování spojení mezi A a B zahrnuje nap.: peklad adres volaného/volajícího zjištní, zda je k dispozici dostatená penosová kapacita vyhledání cesty k volanému identifikace volajícího vi volanému B se dozvídá, kdo je A identifikace volaného vi volajícímu v rámci H.323 eší H.225 definuje formát zpráv pro své souásti souásti: (telefonní) signalizace Q.931 signalizace pevzatá z ISDN komunikace s gatekeeperem RAS (Registration/Admission/Status) ízení hovoru (Call Control) eší "datové záležitosti" týká se využití spojení mezi A a B pro poteby penosu hlasu (a ev. obrazu) zahrnuje nap.: dohodu, které kodeky budou používány dohodu na schopnostech obou zaízení dohodu o portech pro media streamy kam budou poslány dohodu na dalších parametrech penos v rámci H.323 eší hlavn H.245 Control Protocol for Multimedia Communication mže být tunelován skrze H.225 vhodná napíklad kvli firewallm 8
v. 2.2 "ist transportní" podpora QoS standardizovaný zpsob "balení" multimediálních dat do penášených paket, s podporou jejich multimediálního charakteru ale bez vlivu na zpsob jejich penosu ten je stále best effort!!! RTP (Real Time Protocol) "balí" jednotlivéásti multimediálních dat do vlastních blok (paket) a ty vkládá do UDP paket pipojuje informace o typu multimediálního obsahu Payload type 0: PCM, 64 kbps Payload type 3, GSM, 13 kbps Payload type 26, Motion JPEG Payload type 33, MPEG2 video. penos dat v rámci H.323: RTP/RTCP nad UDP o poadí paketu jednotlivé pakety ísluje, usnaduje detekci ztracených paket RTP RTCP o ase vzniku dat (timestamp) íká kdy pesn data vznikla tím usnaduje jejich bufferování na stran klienta UDP o konkrétním streamu (proudu) v rámci jednoho RTP penosu IP mže být penášeno více samostatných proud (stream) podporuje multicast RTCP (Real Time Control Protocol) zprostedkovává vzájemné informování zdroje a píjemc nap. o procentu ztracených funguje paket, o jejich zpoždní, o spojovan!! schopnostech píjemce apod. transportní vrstva penáší popis RTP streamu,. 9
v. 2.2 protokoly H.323 gatekeeper standardníešení H.225(RAS) H.225(RAS) volitelnéešení Q.931 H.245 RTP/G.7xx RTCP H.225 (RAS) H.225 (RAS) voliteln video video kodeky hlas audio kodeky RTCP H.225 H.225 RTP (RAS) Q.931 H.245 UDP TCP IP vrstva síového rozhraní povinné ízení voliteln data fax T.120 T.38 H.245 Q.931 RTP/G.7xx RTCP H.245 Q.931 10
v. 2.2 pedstava komunikace v H.323 A G B A i B se již díve zaregistrovali u gatekeeper-u G A žádá G o zprostedkování hovoru s B (1) pomocí RAS zpráv G posílá A údaje, potebné pro kontaktování B (2) IP adresu A posílá B zprávu SETUP (3) B odpovídá A zprávou CALL PROCEEDING (4) B žádá G o souhlas (5) G udluje souhlas (6) B vrací A zprávu CONNECT (8) mezi A a B existuje transportní spojení nad TCP A a B si vymují zprávy H.245 (9) domlouvají se na svých schopnostech a vzájemné komunikaci jaké kodeky, pes jaké porty si budou pedávat data, A a B si vymují data (10) pes UDP, nespojovaným zpsobem probíhá hovor. A G B 1. ARQ 2. ACF 3. SETUP 4. CALL PROCEEDING 5. ARQ 6. ACF 7. Alert 8. CONNECT 9. výmna zpráv H.245 10. penos dat (pes RTP/UDP) 11
v. 2.2 spojení mezi terminály komunikace terminálu s gatekeeperem je jednorázová odehrává se na zaátku hovoru, kdy se terminál dotazuje gatekeeperu pak se mže spojení zrušit další komunikace již probíhá pímo mezi terminály mezi nimi existuje nkolik spojení: 1x (obousmrn) pro signalizaci nad TCP pro protokol Q.931 musí petrvat, aby terminály mohly ukonit svou komunikaci 1x (obousmrn) pro ízení komunikace nad TCP pro protokol H.245 1x dopedný datový kanál RTP nad UDP 1x zptný datový kanál RTP nad UDP 1x (obousmrn) datový ídící kanál RTCP nad UDP mohou být asymetrické signalizace (Q.931) ízení hovoru (H.245) penos dat (RTP) penos dat (RTP) ízení penosu (RTCP) 12
v. 2.2 terminály v H.323 terminály (koncová zaízení) jsou povinné mohou to být jednoúelová zaízení IP telefony, videotelefony, nebo bžná PC s multimediálním rozšíením povinná je podpora hlasových služeb povinný je audiokodek G.771 odpovídá kódování PCM další kodeky jsou volitelné doporueny jsou G.723.1 a G.729 povinná je podpora: H.225 signalizace H.245 ízení hovoru RTP/RTCP penos dat podpora videoslužeb je volitelná doporueny jsou videokodeky H.261 and H.263 podpora datových a faxových služeb je volitelná pokud je implementována, eší se standardy z ISDN T.120 Data conferencing. T.38 Fax. Technika G.711 PCM G.723 MP- MLQ G.726 ADPCM G.728 LD- CELP G.729 CS- ACELP Penosová rychlost (Kbps) 64 (bez komprese) 6.4/5.3 40/32/24 16 8 Nároky na výpoetní kapacitu žádné stední nízké velmi vysoké vysoké Výsledná kvalita hlasu vynikající Dobrá (6.4) Slabá (5.3) dobrá (40) slabá (24) dobrá dobrá Zpsobené zpoždní N/A vysoké velmi malé nízké nízké 13
v. 2.2 gatekeeper v H.323 funkce gatekeeper-u je v H.323 nepovinná ale pokud gatekeeper existuje, musí se u nj všechny terminály zaregistrovat a musí používat jeho služby zóna: všechny terminály, které "spadají do psobnosti" gatekeeperu které se u nj zaregistrovaly terminál kontaktuje gatekeeper UDP broadcastem na port 1718 RAS Registration/Admission/Status kanál mezi terminály a gatekeeperem, pro "služební" poteby gatekeeper zajišuje: peklady adres nap. mezi ITU-T E.164: 221092274 na IP/URL: 147.32.53.1:1700 správu zóny kdo je lenem, kdo ne, ízení pístupu zkoumá, zda lze sestavit hovoru, pidlit penosovou kapacitu atd. ízení penosové kapacity pidluje kapacitu na základ požadavk, voliteln: zajišuje signalizaci a ízení hovor standardn si eší terminály samy zajišuje správu penosových kapacit podpora QoS, zmna pidlené kapacity atd. autorizuje hovory rozhoduje, zda smí být spojeny 14
v. 2.2 gateway (brána) H.323 brána zajišuje pechod (konverze) mezi systémy s rznými protokoly nejastji: mezi systémem IP telefonie a klasickou telefonní sítí ale také: mezi jinak ešenými systémy IP telefonie pedstava: brána (gateway) je z jedné strany telefonní ústedna, z druhé poíta konverzní funkce: konverze na úrovni penosu dat Ethernet, ATM, konverze datového obsahu pevod mezi rzné kódovaným hlasem nap. z/do G.711 (PCM), které se používá v klasické telefonní síti konverze signalizaních protokol signalizace v H.323 a v klasické telefonní síti se liší klasická telefonní sí používá signalizaci SS7, pípadn DSS1 IP sí V PSTN 15
v. 2.2 MCU Multipoint Control Unit v H.323 (jednotka pro ízení konferenního spojení) slouží potebám konferencí MCU má dvásti: souasné komunikaci více terminál zajišuje: domluvu na spolených vlastnostech konference jaké kodeky se budou používat. vlastní prbh konference distribuci konferenních dat style point-to-multipoint realizuje multicast MP MC MCU MP MC (Multipoint Controller) ídí sestavování konference zjišuje vlastnosti terminál v konferenci, inicializuje a ukonuje kanály pro audio, video a datové penosy MP (Multipoint Processor) zpracovává multimediální data penášená v konferenci zajišuje multicast jde o volitelný modul pokud je realizován, mže být i samostatný (vzhledem k MCU). jednotek MP mže být i více MP MP 16
v. 2.2 vývoj standardu H.323 verze 1 (kvten 1996) definuje základní architekturu, vetn: terminálu gateway (brány) gatekeeper (správce) MCU (jednotky pro ízení konferenního spojení) ješt moc nepoítala s potebami IP telefonie spíše zamena na potebu videokonferencí v poítaových sítích verze 2 (leden 1998) vtší podpora IP telefonie nap. rychlejší navazování spojení, podpora zabezpeení, integrace datových služeb, identifikace volajícího, pesmrování hovor atd. verze 3 (záí 1999) pinesla hlavn rozšíení doplkových služeb parkování hovoru, ekající volání, ekající zprávy rozšíení o mechanismy správy a dohledu spolupráce mezi gatekeeperem a mechanismy rychlého sestavování spojení v paketových sítích verze 4 (listopad 2000) vtší spolehlivost snazší rozšiitelnost možnost použití URL pro adresy volaných verze 5 (kvten 2003) lepší návaznost na protokoly 17
v. 2.2 SIP (Session Initiation Protocol) ešení (nejen) pro IP telefonii ze svta výstup pracovní skupiny MMUSIC v rámci IETF práce zapoaly v roce 1995 první RFC pijato v roce 1999 další verze v roce 2002 SIP je pouze signalizaní protokol eší: sestavení spojení (relace) mezi dvma i více úastníky dohled nad používáním tohoto spojení rušení spojení (relace) neeší: vlastní penosy dat ízení hovoru dohadování na schopnostech zaízení, použitých kodecích atd. SIP lze využít napíklad i pro Instant Messaging a další služby SIP je (jeden) protokol aplikaní vrstvy H.323 byl "deštníkem" nad adou dalších protokol SIP je jednoduchý textový protokol blízký protokolu HTTP jeho filosofie je blízká WWW lze jej dobe integrovat s dalšími protokoly na SIP navazují další protokoly, kteréešíízení hovoru nejastji SDP Session Description Protocol eší: kódování multimediálních dat schopnosti zaízení ísla port pro datové penosy zprávy SDP jsou zapouzdeny ve zprávách SIP!!! 18
v. 2.2 Filosofie SIP-u úastníci se mohou dynamicky pemisovat je teba: identifikovat je nezávisle na jejich poloze vhodné SIP adresy mít možnost zjistit kde se práv nachází dát jim šanci oznámit jejich aktuální polohu "operace REGISTER" úastník se na novém míst zaregistruje umt jim pedávat pozvání k navázání spojení/relace tak aby se volající nemusel sám zjišovat kde se volaný nachází "operace INVITE" sí (SIP) se postará o správné vyhledání a pedání výzvy REGISTER "volaný" sdlí svou polohu INVITE volající pošle výzvu/pozvánku sí (SIP) vyhledá volaného a pedá mu výzvu/pozvánku INVITE 19
v. 2.2 architektura SIP redirect server location server registrar server proxy server: pomáhá hledat spojení redirect server: íká kam pesmrovat žádosti o navázaní spojení IP sí V PSTN proxy server proxy server pímá komunikace terminál location server: zná umístní koncových stanic (SIP terminál) registrar server jemu se SIP terminály pihlašují a oznamují mu své umístní 20
v. 2.2 architektura SIP SIP terminál UA UAC UAS UAC UAS UA SIP terminál UA (User Agent) nachází se v každém SIP terminálu nebo brán vetn proxy serveru obsahuje: UAC: User Agent Client žádá o spojení UAS: Use Agent Server pijímá žádosti o spojení styl komunikace mezi UAC a UAS je velmi podobný komunikaci WWW klienta a WWW serveru pomocí HTTP posílají si požadavky formulované jako metody v textové form a upesnné hlavikami odpovdi jsou íselné stejná konvence jako FTP, SMTP a HTTP komunikace mže probíhat po UDP nebo TCP není to pedepsáno 21
v. 2.2 SIP metody a odpovdi INVITE ACK žádost o sestavení spojení mže být pijata, odmítnuta, pesmrována atd. potvrzení INVITE finálním píjemcem zprávy (volaným) BYE ukonení spojení CANCEL ukonení nesestaveného spojení REGISTER registrace UA OPTIONS dotaz na možnosti a schopnosti serveru UAC UAS 1XX informaní zprávy nap. 100 Trying, 180 Ringing 2XX kladná odpov- úspšné vyízení nap. 200 OK 3XX pesmrování, dotaz je teba smovat jinam 302 Moved Temporarily", "305 Use Proxy") 4XX chybný požadavek dotaz by se neml ve stejné podob opakovat nap. 403 Forbidden 5XX chyba serveru nap. 500 Server Internal Error, 501 Not Implemented 6XX globální (celková, zásadní) chyba nap. 606 Not Acceptable 22
v. 2.2 SIP navazování a rušení spojení nejjednodušší pípad: když volající koncové zaízení (UA) zná umístní volaného UA: osloví jej pímo navazování spojení pedstavuje 3-fázový handshake jiné možnosti: volající osloví proxy server ten zajistí vyhledání volaného sám pedá žádost o navázání spojení dál cílovému UA volající osloví redirection server server vrátí volajícímu adresu volaného UA, na kterou se má obrátit obdoba ICMP redirect ukonení spojení: mže iniciovat kterákoli strana INVITE 100 trying 180 ringing 200 OK ACK RTP/RTCP penos dat BYE 200 OK 23
v. 2.2 SIP navazování a rušení spojení když volající nezná pesnou adresu i cestu k volanému mže využít služeb proxy serveru nebo redirect serveru proxy server: pijme žádost INVITE urí komu ji pedat dál sám ji pedá dál redirect server: pijme žádost INVITE urí komu ji pedat dál vrátí informace o správném smrování tomu, kdo zaslal výzvu INVITE a ten by ml sám kontaktovat cíl INVITE 100 trying INVITE 100 trying INVITE 302 moved temporarily ACK 180 ringing 200 OK ACK 180 ringing 200 OK ACK INVITE 100 trying 180 ringing 24
v. 2.2 SIP location a registrar server (oba servery obvykle splývají) registrar server: location server: pijímá metody REGISTER pomáhá proxy serverm a redirect registrace od klient (UAC) serverm hledat cestu k volanému mže podporovat autentizaci servery se ho dotazuji, on odpovídá terminál se musí prokázat že je tím za koho se vydává metody LOOKUP a REPLY nejsou souástí SIP-i kdykoli je njaký SIP terminál zapnut: musí najít nejbližší registrar server a zaregistrovat se u nj (2) (3) LOOKUP REPLY REGISTER 200 OK (1) INVITE (4) proxy s. redirect (4) 25
v. 2.2 "vize SIP" protokol SIP vznikal s pedstavou, že: telefonní hovory a videokonferenní volání vznikají v Internetu lidé jsou identifikováni jmény i emailovými adresami a ne telefonními ísly volaného je možné zastihnou bez hledu na to, kde se práv nachází a jaké zaízení používá kvli tomu SIP musíešit i vhodné adresování a pesmrovávání "nezávislost na umístní" SIP by ml být schopen pedat pozvání úastníkovi bez ohledu na to, kde se práv nachází SIP by ml fungovat v reálném ase SIP by ml sloužit nejen IP telefonii, ale teba i IM (Instant Messagingu) a dalším aplikacím SIP adresy: obecn jde o jednu z variant URL adresy <schema>:<specifickáást> konkrétn: sip:user@host sip:user@doména napíklad: sip:bob@192.168.10.1 lze poslat INVITE pímo sip:bob@harvard.edu nutno ešit pes PROXY jak se SIP adresy pekládají? prostednictvím DNS se vyhledá registrar a location server pro danou doménu 26
v. 2.2 peklad SIP adres v DNS je nový typ RR záznamu: SRV <IP adresa> udává IP adresu (registrar) serveru pro danou doménu použití v praxi pokud volající nezná IP adresu volaného: pošle svj INVITE nejbližšímu SIP proxy serveru proxy server funguje jako DNS server a router zjistí si SRV záznam píslušné domény z nj zjistí adresu registrar serveru domény zeptá se registrar serveru / location serveru získá informace o tom, kudy má výzvu INVITE pedat dál pokud se uživatel pemístil nkam jinam a tam se zaregistroval, ml by o tom mít registrar/location server informace výzvu INVITE sám pedá dál obdobn funguje redirect server který ale jen vrátí informace volajícímu volající pak sám pedává INVITE dál DNS pro doménu harvard.edu sip.harvard.edu! INVITE bob@harvard.edu bob? sip.harvard.edu srv=sip.harvard.edu cesta! INVITE bob@harvard.edu SRV? proxy server INVITE 27
v. 2.2 hlaviky (SIP headers) obdobn jako u HTTP, mohou požadavky i odpovdi protokolu SIP obsahovat také doplující hlaviky (headers) slouží jako parametry upesují požadavek/odpov píklad: INVITE sip:bob <bob@harvard.edu> FROM: sip:alice <Alice@harvard.edu> Subject: chci s tebou mluvit kvuli Content-type: application/sdp. pro specifikaci datových typ se používá MIME typ nap. application/sdp že jde o nco, co má zpracovávat aplikace registrovaná pro zpracování protokolu SDP (Session Description Protocol) souástí požadavku (i odpovdi) mže být takéást formulovaná v SDP upesuje "technické parametry", napíklad použité kodeky, schopnosti zaízení atd. píklady hlaviek: FROM: <sip adresa> od koho pichází žádost o spojení povinné TO: <sip adresa> komu je výzva urena stejné jako parametr u INVITE povinné VIA: <adresa> informace o tom, kudy byl požadavek veden pes který proxy server CALL-ID: <identifikátor> jednoznaný identifikátor požadavku pro hovor: íká který hovor to je» nap. pro následné ukonení» pro vylouení opakovaných výzev apod. pro registraci: vyluuje duplicitu» každý uzel by (až do nového bootu) ml používat stejné ID Content-Type: <MIME type> Content-Length: <délka> Content-Encoding: <id.> 28
v. 2.2 píklad ----------------------------------------------------------------- SIP Header ----------------------------------------------------------------- INVITE sip:5120@192.168.36.180 SIP/2.0 Via: SIP/2.0/UDP 192.168.6.21:5060 From: sip:5121@192.168.6.21 To: <sip:5120@192.168.36.180> Call-ID: c2943000-e0563-2a1ce-2e323931@192.168.6.21 CSeq: 100 INVITE Expires: 180 User-Agent: Cisco IP Phone/ Rev. 1/ SIP enabled Accept: application/sdp Contact: sip:5121@192.168.6.21:5060 Content-Type: application/sdp 29
v. 2.2 protokol SDP (Session Description Protocol) pokud je v požadavku/odpovdi hlavika: Content-type: application/sdp pak tlo "patí" protokolu SDP podrobnji popisuje technické parametry oddleno prázdnou ádkou od hlaviek SDP umožuje odesilateli popsat svj RTP/AVP Audio/Video Profil a schopnosti penosu dat nap. jaké kodeky podporuje jaké metody šifrování jakou vyžaduje šíku penosového pásma jakou latenci, rychlost atd. píklad: m = audio RTP/AVP 0 3 4 5 výet "audio možností" íslo 0 1 2 3 4 5.. Kodek PCM Rezerva Rezerva GSM G.723 DVI4.. Frekvence [Hz] 8000 8000 8000 8000.. 30
v. 2.2 dialog protokolu SIP výzvu INVITE mže píjemce akceptovat odpovdt 200 OK a v rámci odpovdi poslat své schopnosti jeho schopnosti se mohou týkat opaného smru komunikace komunikace nemusí být symetrická, každý smr mže být ešen jinak, nap. s rznou rychlostí / kapacitou, s jiným kódováním atd. problém: volajícímu (odesilateli výzvy) to nemusí vyhovovat nemusí na to mít schopnosti proto je nutný 3-fázový handshake aby volající mohl vyjádit souhlas i nesouhlas se schopnostmi/požadavky píjemce výzvy volající INVITE 200 OK ACK volaný píjemce mže výzvu odmítnout: 603 Decline ncchce ji pijmout mže navrhnout jiný termín 606 Not Acceptable nemže ji pijmout obvyklý dvod: nkteré parametry navazovaného spojení (nap. kodeky) nepodporuje v odpovdi mže popsat své možnosti pomocí protokolu SDP prbh dalšího dialogu není pedepsán zda volající reaguje na odmítnutí zcela novou výzvou nové Call-ID nebo upesuje pvodní výzvu stejné Call-ID 31
v. 2.2 MGCP (Media Gateway Control Protocol) jde o ešení, které umožuje oddlit pepojování hovor ve smyslu "hloupé ústedny" zajišuje "Media Gateway" rozhodování o smrování hovor obdoba centralizovaného smrování, s route serverem zajišuje "Call Agent" resp. Media Gateway Controller MGCP je protokol, prostednictvím kterého spolu obásti komunikují V Call Agent MGCP Media Gateway vztah MGCP k H.323 a SIP-u H.323 a SIP jsu protokoly pro charakteru peer-to-peer mezi prvky na stejné úrovni MGCP je protokol charakteru klient/server Call Agent se chová jako server poskytuje ídící informace pro Media Gateway Media Gateway se chová jako klient MGCP není náhrada pro SIP ani H.323 je spíše jejich doplkem Call Agent mže komunikovat (spolupracovat) s ostatními "Call Agents" pomocí SIP nebo H.323 SIP/H.323 MGCP SIP/H.323 32