Технологии за интегриране на глас и данни 1. Въведение 2. Глас върху ATM (VoATM – Voice over ATM) 3. Глас върху Frame Relay (VoFR – Voice over Frame Relay) 4. Глас върху IP (VoIP – Voice over IP) 5. Протоколи за работа в реално време: RTP and RTCP

5.1 Транспортен протокол в реално време (RTP – Real-Time Transport Protocol)

5.2 Управляващ протокол в реално време (RTCP – Real-Time Control Protocol)

5.3 Формат на пакетите при RTCP 5.4 Транслатори и смесители за RTP 5.5 Приложения за работа в реално време

6. IP телефония 6.1 Въведение 6.2 Протоколен комплект за IP телефония 6.3 Препоръка на ITU-T H.323 6.4 Протокол за инициализиране на сесия (SIP – Session Initiation Protocol) 6.5 Протокол за управление на шлюза на съобщителната среда (MGCP –

Media Gateway Control Protocol) 6.6 Контролер на шлюза на съобщителната среда (Megaco - Media Gateway

Controller) 6.7 Функционално сравнение на протоколите за сигнализация

7. Устройства за кодиране и декодиране на гласови сигнали 1. Въведение

Интегрирането на глас и данни (Voice/data integration) в последно време набира все по-голяма скорост поради увеличения интерес както от страна на потребителите, така и от страна на производителите. Като използват предимствата на интегрирани приложения потребителите могат да оптимизират инвестициите си в мрежова инфраструктура. От страна на доставчиците бяха преодолени техническите проблеми в много области, включително стандарти, технология и характеристики на мрежите.

Тези технологии засягат пряко и доставчиците на услуги, които са привлечени от възможностите за по-ниски цени – счита се, че цената на предаване на глас чрез пакети в момента е от 20 до 50% от цената на традиционната телефония, основаваща се на комутация на вериги. Разработчиците на корпоративни мрежови решения са заинтересовани от икономиите, които могат да бъдат направени от избягване на междуградските и международни разговори. И едните и другите са заинтересовани от намалените цени за поддържане и по-ефикасните контрол и управление на мрежите.

Основаващите се на пакети гласови системи осигуряват достъп и до нови усъвършенствани услуги като унифицирано предаване на съобщения (Unified Messaging) и контрол върху приложенията от страна на потребителите. Тези услуги ще увеличат производителността на потребителите и ще им позволят да ползват избирателно само необходимите им услуги.

Стандарти

В резултат на сериозни усилия вече окончателно са приети много стандарти за сигнализиране при пакетно предаване на глас. Тези стандарти, осигуряващи взаимна работа, са вече достатъчно наложили се, така че да облекчат доставчиците на различни компоненти за системи глас/данни и да намалят рисковете за потребителите. Така например, препоръка H.323, приета от ITU-T през 1996 г., вече има четири версии, а изделията, реализирани съгласно нея, са доказали добри параметри и възможности за взаимна работа. Общото “узряване” на стандартите доведе до сигурни набори от протоколи, които могат да бъдат закупени “от рафтовете” на доставчиците, с което още повече се осигурява взаимната работа.

Технология

Интегрирането на глас и данни е улеснено от технологичното развитие. Новите цифрови процесори за обработка на сигнали (DSP – Digital Signal Processor) позволяват обработка в реално време на аналогови сигнали в цифровия домен. Тези технологии значително намаляват цената и сложността на разработката на изделия и на използването на решения за глас върху данни.

В друга област, беше отбелязан пробив и в технологията за кодиране на глас (voice codec). Преди се считаше, че качеството на гласа намалява с намаляване на ширината на лентата (т.е. на скоростта на битовете, с които е кодиран гласовия сигнал), и то линейно. Новите сложни алгоритми, които се използват в новите кодеци, обаче, промениха това виждане. Сега вече е възможно да се предава глас с сравнително добро звучене само в част от честотната лента, която беше необходима по-рано. Тези нови алгоритми са вградени в стандарти, така че е осигурена взаимната работа при предаване на силно компресиран гласов сигнал.

Характеристики на мрежите

Накрая, технологията на мрежите за данни се подобри до степен, така че глас може да бъде пренасян надеждно. Последните години се характеризират със сравнително слабо нарастване на трафика на глас, докато трафикът на данни нараства експоненциално. Резултатът е, че в много мрежи вече трафикът на данни е по-голям от трафика на глас. В допълнение, относителното значение на трафика на данни се увеличи, тъй като много фирми и организации базират повече от своите бизнес практики и политики върху наличието на мрежи за данни. Тази увеличена важност на мрежите за данни наложи фундаментална промяна в начина, по който тези мрежи се проектират, изграждат и управляват. Традиционният модел на “най-доброто усилие” (best-effort) отстъпи пред по-усъвършенствана политика, осигуряваща на мрежите управляемо качество на услугите и поддържане на разширен обхват от приложения. Трафикът на глас, като приложение върху мрежа за данни, извлече голяма полза от тези технологии. Така например, усилията за осигуряване поддръжката на чувствителния към закъснения трафик на SNA през IP мрежи доведе до пробиви в управлението на времето за изчакване (latency) и използването на приоритети при обработката на опашки, които постижения директно се използват и при трафика на глас.

За да получат новите технологии и приложения широко разпространение, обаче, те трябва да си осигурят повишено потребителско търсене. Такъв е случаят с интегрирането на глас и данни, тъй като тези технологии са икономични за

2

потребителите и в бъдеще ще им осигурят значително повече възможности от сегашните системи за предаване на глас, основаващи се на комутация на вериги.

Икономически предимства

Оценява се, че пренасянето на глас с помощта на пакети струва само от 20 до 30% от еквивалентната цена при мрежите за глас с комутация на вериги. Това се отнася както до обществените оператори (carriers) и доставчици на услуги (service providers), така и до корпоративните (частни) потребители. Така например, много корпоративни потребители, които са реализирали интегрирани технологии глас върху данни (voice/data) за пренос на глас през техните глобални мрежи (WANs) за данни, и са осъществили свързване на техните PBXs, разположени в различни географски райони, са реализирали възвръщане на инвестициите в рамките на шест месеца (особено ако са успели да избегнат международните разговори).

Използването на системи за данни за пренасяне на глас между централите чрез виртуални свързващи линии (virtual tie lines) се оказва полезно също и за доставчиците на услуги. На практика много нови обществени оператори започват да възприемат основаните на пакети технологии за пренос на глас като тяхна основна стратегия за изграждане на мрежовата инфраструктура.

Икономиите, свързани с пакетните гласови технологии, не се изчерпват само с обикновен пренос. В домена на данните е възможно гласовите повиквания да бъдат комутирани по-икономично отколкото от традиционните централи с установяване на връзка. За големи предприятия, разпръснати на много площадки, икономиите произтичат от използването на мрежата за данни като тандемна централа (tandem switch), която маршрутизира между PBXs гласовите повиквания при всяко повикване (on a call-by-call basis). Получената при това структура на мрежа за глас е по-проста за администриране и използва гъвкава, не блокираща комутираща структура (switching fabric), изградена в ядрото си от системи за данни.

Развитие в приложенията

Реалните икономии в разходите са достатъчни, за да обосноват прилагането на технологии за интегриране на глас и данни. Съществуват, обаче, допълнителни предимства, които ще станат по-очевидни в бъдеще. С развитие на приложенията организациите ще спечелят от увеличената производителност чрез интегрирането на гласовите и компютърни приложения. През 80-те години производителите на PBXs започнаха така нареченото интегриране на компютри с телефония (CTI – Computer Telephony Integration), т.е. интегриране на компютри с PBXs за осигуряване на приложения, като например усъвършенствани центрове за повикване (call centers).

С развоя на интегрирането между глас и данни границата между приложенията за глас и данни ще продължи да се размива. Така например вече са достъпни унифицирани системи за пренасяне на съобщения (Unified Messaging systems), които обединяват в една обща и удобна система гласовата поща, електронната поща и факсимилните съобщения. При тези усъвършенствани системи потребителите могат да чуят по телефона съдържанието на отправен до тях e-mail, или могат да прикачат документи към гласовото си съобщение. На фирмено ниво, новите приложения, като виртуалните центрове за повикване (virtual call centers) позволяват на агентите на центъра за повикване да бъдат разпределени навсякъде в обсега на мрежата за данни, като при това се запазва целия набор от функции и услуги на центъра за повикване. Потребителите могат да приемат повикванията със

3

своя компютър, вместо да използват традиционния телефонен апарат, както и могат да отговарят на зададени чрез Интернет въпроси на потребителите с възможности за електронен “чат” (chat) и изпращане или приемане на e-mails между телефонните разговори. Тези възможности излизат далеч извън рамките на обикновените икономии на разходи и в края на краищата ще направят фирмите много по-ефективни и печеливши.

Съществуват три общи подхода към интегрирането на мрежите за глас и данни, всеки със своите предимства и недостатъци: • глас върху ATM (VoATM – Voice over ATM) • глас върху Frame Relay (VoFR – Voice over Frame Relay) • глас върху IP (VoIP – Voice over IP). Съществуват също и смесени решения, като например VoIP върху Frame Relay, и т.н. Те са илюстрирани на фиг.1. Тази фигура показва, че VoATM и VoFR са преди всичко транспортен механизъм между централи (PBXs), докато VoIP може да осъществи връзка до самото бюро на потребителя.

Voice over IP(over Frame Relay or ATM)

Voice over FrameRelay or ATM

PBXPBX

PBXPBX

PBXPBX

Router Router

Фиг.1 VoIP, VoFR и VoATM

Глас върху ATM (VoATM) може да бъде реализиран чрез емулация на линия за връзка чрез AAL1 (с постоянна скорост на битовете – CBR), или като глас с променлива скорост на битовете (VBR) чрез AAL2. И в двата случая се емулира стандартно кодиран посредством импулсно-кодова модулация (PCM – pulse code modulation) гласов сигнал.

ATM предлага много предимства за пренасяне и комутиране на глас. Преди всичко, гаранции за качеството на услугата (QoS) могат да бъдат специфицирани за всяко повикване (per-call basis). В допълнение, сигнализацията при комутируемите виртуални връзки (SVCs) при ATM (Q.2931) се основава на сигнализацията на ISDN (Q.931). Администрирането е подобно на това при традиционните мрежи за глас.

От друга страна, обаче, VoATM е излишно сложна технология, която не се поддържа напълно от производителите, така че отсъства пълна съвместимост

4

между техните изделия. Тя също има тенденцията да е по-скъпа, тъй като е основно ориентирана към оптични мрежи. И най-важното, ATM се реализира обикновено като протокол на ниво 2 на WAN, поради което не обхваща целия път до работните места на потребителите. Независимо от това ATM е твърде ефективна технология при осигуряване на съединителни линии между централи (trunking) и транзитните (tandem) комутационни услуги между съществуващите централи за глас и PBXs.

Глас върху Frame Relay (VoFR) намери широко разпространение в много мрежи. Подобно на VoATM, тази технология се прилага основно за свързване (tie trunk) или транзитно комутиране (tandem-switching) между отдалечени PBXs. Тя има предимството на по-просто администриране и сравнително по-ниска цена от VoATM, особено когато се реализира върху частна WAN мрежа. Тя също може да се оразмери по-икономично от VoATM, тъй като поддържа връзки от E1 (T1) до 64 kbit/s (56 kbit/s). Когато се реализира върху добре конструирана мрежа Frame Relay, VoFR работи много добре и осигурява добро качество.

Качеството на гласа върху Frame Relay, обаче, може да бъде отрицателно повлияно от времето на изчакване (latency) и от джитера. Макар че обикновено минималната ширина на лентата (скорост на битовете) и неравномерността на постъпване на пакетите (burstiness) са обект на договаряне, времето на изчакване и джитера често не са обект на споразуменията за ниво на услугата (SLAs – service level agreements) между потребителите и доставчиците на услуги. Като резултат, характеристиките на гласа могат да варират. Дори и качеството първоначално да е добро, то може да деградира с времето, тъй като мрежата на доставчика на услуги се насища от повече трафик. Ето защо множество големи корпоративни потребители започват да договарят с телефонните компании времето на изчакване и джитера, както и общата пропускателна способност за пакети. В този случай VoFR може да осигури отлична гласова услуга.

Глас върху IP (VoIP) е най-младата от трите технологии. За разлика от останалите две, VoIP е изградена върху слой 3 техонлогия, и може да предложи много по-ценно и удобно решение, тъй като достига до бюрото на потребителя. Това означава, че в допълнение на свързването (tie trunk) или транзитното комутиране (tandem-switching) на PBXs, VoIP на практика може, като приложение, да започне да заменя тези PBXs. Като реализация на слой 3, VoIP може да бъде маршрутизиран и прозрачно пренесен през всеки вид мрежова инфраструктура, включително Frame Relay и ATM. От трите технологии за пакетно пренасяне на глас, обаче, VoIP най-трудно може да осигури качество на гласа, тъй като не може да гарантира QoS. Нормални приложения, като например TCP върху IP, не са чувствителни към времето на изчакване, но трябва да предават повторно загубени поради колизии или задръстване пакети. Гласът е много по-чувствителен към забавяне на пакетите, отколкото към загуба на пакети. В допълнение към нормалното задръстване в трафика, QoS при VoIP често зависи от по-ниските слоеве, които не могат да различат трафикът на глас, смесен с трафика на данни.

2. Глас върху ATM

Както е известно, в ATM са дефинирани различни адаптационни видове (adaptation types) за различните видове трафик, всеки със своите предимства и ограничения. Адаптационното ниво 1 (AAL1 – ATM adaptation layer 1) е най-често използваното ниво за услуги с постоянна скорост на битовете (CBR).

5

Неструктурираното AAL1 поема непрекъснат поток от битове и ги разполага в ATM клетки. Това е общ подход за поддържане на пълен E1 поток от край до край. Проблемът на този подход е, че се пренася винаги пълен E1 поток, независимо от действително използваните в момента канали.

Структурираното AAL1 съдържа указател (pointer) в полезния товар, който позволява поддържане на структура DS0 (digital signal level 0 – единичен канал с 64 kbit/s в йерархията на T1) в последователни клетки. Така се повишава ефективността, тъй като не се предоставя лента на неизползваните в момента DS0s. Това, очевидно, е технология с динамично предоставяне на n.64 kbit/s.

Опцията за обратно преобразуване (remapping) позволява на мрежата ATM да поеме (terminate) структурирани AAL1 клетки и да пренасочи приетите DS0s към правилните крайни точки. Това премахва необходимостта от перманентни виртуални връзки (PVCs) между всички възможни комбинации източник – местоназначение. Основната разлика между предишния подход (неструктурирано AAL1) е че в мрежата не се изгражда PVC от край до край.

Сигнализиране при VoATM

На фиг. 2 е показан метод за пренасяне, при който сигнализирането за гласовите връзки се транспортира през мрежата прозрачно. Създават се перманентни виртуални връзки (PVCs) както за сигнализирането, така и за пренос на глас. Първоначално съобщение за сигнализиране се пренася от едната крайна станция до другата прозрачно през PVC за сигнализиране. След това двете крайни системи координирано избират PVC за провеждане на гласовата връзка между тях.

Non-ATM network

Non-ATM network

ATMnetwork

PVCnon-ATMsignalling PVC for

voice

Фиг. 2 Прозрачно сигнализиране при VoATM – транспортен модел

Както се вижда, в нито един момент ATM мрежата не участва при интерпретиране на сигнализирането между двете крайни станции. Някои конкретни изделия, обаче, са в състояние да разбират сигнализирането по присъединен канал (CAS – channel associated signaling) и могат да предотвратят изпращане на празни клетки с гласов сигнал, когато крайните станции са изключени (в състояние on-hook – с поставена микротелефонна гарнитура).

На фиг. 3 е показан модел с преобразуване. При този модел мрежата ATM интерпретира сигнализацията както от не-ATM, така и от ATM мрежови устройства.

6

Създават се PVCs между крайните станции и мрежата ATM. Това контрастира на предишния модел, при който PVCs се пренасят прозрачно през мрежата.

Non-ATM network

Non-ATM network

ATMnetwork

PVCnon-ATMsignalling PVC for

voice

SVC forvoice

Фиг.3 Сигнализиране при VoATM – модел с преобразуване Заявката за сигнализиране от крайна станция предизвиква мрежата ATM да създаде комутируема виртуална връзка (SVC) до желаната крайна станция с подходящо QoS. Създаването на SVC има следните предимства пред установяването на PVCs, какъвто е предишния случай: • SVCs използват по ефективно предоставената ширина на лентата от PVCs. • QoS за връзките не трябва да бъде постоянно, както е при PVCs. • Възможността за комутиране на повиквания в рамките на мрежата може да

доведе до елиминиране на транзитните централи (PBX), а възможно – и разположените по периферията на мрежата PBXs.

Адресиране при VoATM При мрежите ATM съществуват различни видове адреси на крайните системи (AESAs – ATM End System Addresses). Всички те използват формат с дължина от 20 байта – фиг.4.

Initial Domain Part(IDP)

AFI IDI HO-DSP ESI SEL

Domain Specific Part(DSP)

AFI Authority and Format IdentifierIDI Initial Domain IdentifierHO-DSP High Order Domain Specific PartESI End System IndicatorSEL Selector

Фиг. 4 Формат на AESA

7

• IDP (Initial Domain Part) – част на първоначалния домен. Специфицира по уникален начин административния орган, който е отговорен за предоставяне и приписване на стойности от специфичната за домена част (DSP – Domain Specific Part). IDP се състои от две полета, разгледани по-долу.

• AFI (Authority and Format Identifier) – идентификаторът на орган и формат показва конкретния формат за адресиране, който се използва. Специфицирани са три идентификатора: код на страната за данни (DCC – Data Country Code), международен указател на кодове (ICD – International Code Designator), и E.164. Всички те се администрират от ITU-T. Дължината на това поле винаги е един байт.

• IDI (Initial Domain Identifier) – идентификатор на първоначалния домен. Този адрес еднозначно и уникално идентифицира мрежата на потребителя. Схемата на E.164 AESA има по-дълъг IDI, съответстващ на 15-цифровия номер на B-ISDN мрежа.

• DSP (Domain Specific Part) – специфичната за домена част. Идентифицира логическото групиране и крайните ATM станции. Състои се от три полета, разгледани по-долу. Тези полета може да имат различна дължина в зависимост от вида на AFI.

• HO-DSP (High Order-Domain Specific Part) – специфична за домена част от висок порядък. Стойностите и формата на това поле се определят от посочената в IDI единица. Дължината на това поле може да варира.

• ESI (End System Indicator) – индикатор на крайната система. Той идентифицира крайната ATM система и може да съдържа MAC адреса на LAN, определян от IEEE. Дължината на това поле е 6 байта.

• SEL (Selector) – селектор. Използва се от крайната система за вътрешни цели. Дължината на това поле е един байт.

При транспортния модел потребителското приложение не се интересува от лежащото по-ниско адресиране, използвано от мрежата за глас. При модела с преобразуване, обаче, възможността да се комуникира от устройство в не-ATM мрежа с устройство в ATM мрежа предполага наличието на ниво за преобразуване (mapping) на адреса. За щастие ATM поддържа схемата за адресиране на E.164, използвана от телефонните мрежи в целия свят. Маршрутизиране при VoATM

ATM използва частния интерфейс мрежа-мрежа (PNNI – private network-to-network interface), протокол за маршрутизиране на DL ниво, даващ възможност за глобално разширяване. В допълнение към определянето на достижимостта (reachability) и маршрутизирането в една ATM мрежа, този протокол може да изгражда също и връзка (call setup).

Заявка за VC повикване предизвиква в мрежата ATM да бъде поискана връзка с определени изисквания към QoS. ATM централата на източника определя оптималния път през мрежата на базата на протокола PNNI и на заявеното QoS. Проверява се всеки комутатор по пътя за да се определи дали той разполага с подходящите за връзката ресурси.

След установяване на връзката гласовият трафик протича между крайните станции като че ли съществува наета линия между тях. Спецификацията PNNI определя маршрутизирането в частните мрежи. За мрежите на мрежовите оператори (carrier networks) протоколът между комутаторите е BICI (Broadband Inter-Carrier Interface) – стандарт на ITU-T, който определя протоколите и процедурите за изграждане,

8

поддържане и разпадане (terminating) на широколентови комутируеми виртуални връзки (Broadband SVCs) между обществени мрежи. VoATM и закъсненията

При ATM съществуват няколко механизма за управление на закъсненията и техните вариации. Възможностите за дефиниране на QoS при ATM позволява да се заяви конкретен трафик с постоянна скорост на битовете (CBR) с гарантирана ширина на лентата и вариации на закъснението. Използването от виртуалните връзки (VCs) на опашки позволява всеки трафичен поток да бъде третиран по уникален начин. Така може да бъде даден приоритет на трафика на глас. Използването от ATM на малки пакети (клетки) с фиксиран размер намалява времето на чакане на опашка и вариациите на това време, присъщи на пакетите с променлив размер.

3. Глас върху Frame Relay (VoFR – Voice over Frame Relay)

Технологията глас върху Frame Relay позволява една Frame Relay мрежа да пренася гласов трафик (например телефонни разговори или факсимилни съобщения). Frame Relay е общодостъпен и евтин транспортен механизъм, който се предлага от повечето големи далекосъобщителни оператори.

Сигнализиране при VoFR

Първоначално изграждането на връзка при Frame Relay не беше стандартизирано, така че изделия от различни доставчици не можеха да работят взаимно. Документът FRF.11 [1] на Frame Relay Forum създава общ стандарт за изграждане на връзка, видовете кодиране и формата на пакетите при VoFR, с което се създават условия за взаимна работа на устройства с различен произход.

Адресиране при VoFR

Преобразуването на адресите се осъществява чрез статични таблици, които свързват набраните цифри с конкретни PVCs. Как се маршрутизира гласа зависи от това, кой протокол за маршрутизиране е избран за изграждане на PVCs и от хардуера, използван в мрежата Frame Relay. Маршрутизирането може се основава на ограничения в достъпната лента, броя на участъците (hops), закъснението, или комбинация от тези фактори, но повечето реализации за маршрутизиране оптимизират използването на достъпната лента.

Използва се напълно свързана мрежа (full mesh) от PVCs за глас и данни, с което се минимизира броя на транзитните мрежови участъци и се максимализира възможността за предоставяне на различно QoS. Изградена по този начин мрежа минимизира закъсненията и подобрява качеството на гласа, но притежава най-висока цена.

Таксуването на болшинството доставчици на Frame Relay се основава на броя на използваните PVCs. За намаляване на разходите, сегментите за данни и глас могат да бъдат конфигурирани така, че да използват едни и същи PVCs, с което се намалява необходимия брой PVCs. При това изпълнение централният комутатор на мрежата пренасочва гласовите повиквания. Съществува и възможността за създаване на транзитен участък, когато се налага пренасянето на глас от една отдалечена PBX до друга.

9

Закъснението и неговите вариации в една мрежа Frame Relay могат да бъдат минимизирани чрез редица механизми. Присъствието на дълги рамки с данни в една нискоскоростна Frame Relay връзка може да предизвика неприемливи закъснения за критичните във времето рамки, пренасящи глас. За намаляване на този проблем някои производители използват по-къси рамки и за данни. Документът FRF.12 [2] предлага стандартен подход за това, така че изделията от различни производители да могат да работят взаимно и потребителите да знаят, какво качество на гласа да очакват.

Методи за даване на по-висок приоритет на рамките с глас пред рамките с данни също спомага за намаляване на закъснението и неговите вариации. За осигуряване на качество на гласа за всяка PVC трябва да бъде зададена стойността на предоставената скорост на информацията (CIR – committed information rate), която да осигури, че рамки с глас не са отхвърлят. Бъдещите мрежи Frame Relay ще осигурят сигнализиране чрез SVC и договаряне на QoS за всяко повикване. Това ще допринесе за подобряване на качеството на VoFR в бъдеще.

4. Глас върху IP (VoIP – Voice over IP)

Както беше споменато по-горе, глас върху IP е решение, използващо слой 3 на модела на OSI, а не решение върху слой 2. Това позволява VoIP автономно да работи над мрежи Frame Relay и ATM. По-важното е, че VoIP работи върху типични LANs и достига до бюрото на потребителите. В този смисъл VoIP е по-скоро приложение, а не услуга, и протоколите за VoIP са се развивали в тази посока.

Протоколите VoIP попадат в две общи категории: централизирани и разпределени. Най-общо централизираните модели следват архитектурата клиент/сървер, докато разпределените модели се основават на взаимодействия между равнопоставени единици (peer-to-peer). Всички технологии VoIP използват обща преонсна среда, като предават гласовата информация като пакети на RTP (Real Time Protocol) чрез IP. Те също си приличат по това, че поддържат голямо разнообразие от схеми за компресиране на гласа (codecs). Различията са при сигнализирането и в това, къде се поддържат логиката на повикването и състоянието на повикването – дали в крайните точки или в централизиран интелигентен сървер. И двете архитектури имат предимства и недостатъци. Разпределените модели могат лесно да бъдат разширявани и са по-устойчиви, тъй като при тях няма централен възел, който може да се повреди. От своя страна централизираните модели за управление на повикването предлагат по-просто обслужване и могат по-лесно да поддържат традиционните допълнителни услуги (като конферентни услуги), но те са ограничени в разширяването си от капацитета на централния сървер. Създадени са хибридни модели, които съчетават най-добрите страни на двата подхода.

Разпределените схеми за управление на повикването при VoIP включват най-старата архитектура, H.323, както и най-новата - Session Initiation Protocol (SIP). Централизираните методи за управление на повикването включват Media Gateway Control Protocol, както и някои нестандартизирани фирмени протоколи.

5. Протоколи за работа в реално време: RTP и RTCP Стандартите на протоколите за работа в реално време са разработени от Работната група за пренос на адио и видео в рамките на IETF (Internet Engineering Task Force). Основните стандарти са документирани в RFC 3550 [3] и RFC 3551 [4].

10

За да може дадено приложение да използва услуги в реално време, трябва да бъдат реализирани два протокола: • Транспортният протокол в реално време (RTP – Real-Time Transport Protocol)

осигурява пренос на пакети на данни в реално време (real-time data packets). • Управляващият протокол в реално време (RTCP – RTP Control Protocol)

наблюдава качеството на услугата, осигурявана от съществуващите сесии на RTP.

Двата стандарта описват в детайли функциите, които се очаква да бъдат общи за всички видове приложения в реално време. Архитектурата съзнателно е оставена незавършена, така че да може да бъдат обхванати нови приложения в реално време. За разлика от други протоколи, при RTP настройката става чрез подходящи модификации или добавки към заглавните части. Това позволява протоколът лесно да бъде адаптиран към новите стандарти за пренос на аудио и видео. 5.1 Транспортен протокол в реално време (RTP – Real-Time Transport Protocol) Протоколът RTP осъществява транспортните функции, необходими за синхронизирането на мултимедийни потоци от данни. Нека си представим приложение, използващо както видео, така и аудио компоненти. Протоколът RTP може да бъде използван за маркиране на пакетите, свързани с конкретните видео и аудио потоци. Това позволява пакетите да бъдат синхронизирани в приемащата станция. На фиг. 5 е показана работата на RTP при мултимедийно предаване. Данните аудио и видео се капсуловат (encapsulated) в пакетите на RTP преди предаването им от предавателя към приемника.

IP UDP RTP Payload

RTP Application Layer Framing

A AV V

RTP Stream

UDP

IP

RTPVideo

(V) Audio(A)

UDP

IP

RTPVideo

(V) Audio(A)

Фиг. 5 Работа на RTP в мултимедийно обкръжение Ако мултимедийното приложение не използва услугите на протокола RTP, приемникът може да не е в състояние да асоциира съответните аудио и видео пакети. Това може да се дължи на променящите се характеристики на мрежата по време на мултимедийната сесия. Задръстване или други преходни условия в мрежата може да предизвикат загуба или преподреждане на пакетите по време на пренасянето. Това може да забави доставката на пакетите за променлив период от

11

време. Така възникват проблеми с качеството при типичните мултимедийни приложения. Според спецификациите протоколът RTP може да бъде използван с който и да е подходящ мрежов или транспортен протокол. На практика, мултимедийните приложения обикновено използват RTP съвместно с UDP. Това позволява приложението да използва услугите за мултиплексиране и контролна сума (checksum), които се осигуряват от UDP. Протоколът RTP често се използва за поддържане и на групови (multicast) приложения. Самият протокол RTP не включва какъвто и да е механизъм за гарантирана доставка или за други услуги, свързани с качеството на обслужването. Стандартът не предпазва от доставка на пакетите извън определения им ред, нито предполага, че лежащата по-ниско мрежа е надеждна и доставя пакетите в правилна последователност. Разработчиците на всяко приложение, използващо RTP, сами трябва да определят, дали тези нива на услугата са приемливи, и да потърсят други решения, в случай че не са. 5.1.1 Формат на заглавието при RTP Заглавната част на пакетите на RTP имат показания на фиг. 6 формат:

0 8 16 31SequenceNumber

PayloadTypeMCSRC

CountV P X

Timestamp

Synchronization Source (SSRC) Identifier

Contributing Source (CSRC) Identifiers

Фиг. 6 Формат на заглавието на пакетите RTP

Заглавието на всеки RTP пакет съдържа 16 октета (байта), като само първите 12 от тях са задължителни. Отделните полета имат следното интерпретиране: • V: показва версията на RTP. • P: съдържа запълващ (padding) бит. Ако този бит е “1”, пакетът съдържа група от

запълващи октети, които не са част от полезния товар. Тази функция се използва от някои алгоритми за криптиране.

• X: съдържа бит за разширение. Ако този бит е установен в състояние “1”, след заглавието с фиксирана дължина следва разширение на заглавието.

• Брой на допринасящите (участващите) източници - CSRC Count: това поле съдържа броя на идентификаторите на допринасящи (contributing) източници, които следват във фиксираното заглавие.

• M: Това поле позволява съществени събития да бъдат маркирани в потока от пакети, като например границите на рамка.

• Тип на полезния товар (Payload type): Специфицира формата на полезния товар в пакета на RTP. В даден момент предаващият по протокола RTP излъчва само един тип на полезния товар.

12

• Последователен номер (Sequence number): Използва се от приемащата станция за възстановяване последователността на пакетите и за откриване на загуба на пакети.

• Времева марка (Timestamp): Времевата марка съдържа стойност, представляваща времето, когато полезните данни са дискретизирани (sampled).

• Идентификатор на източника за синхронизация (SSRC): Източникът за синхронизация е произволно избран идентификатор за RTP станция. Всички пакети от един и същ източник съдържат един и същ идентификатор SSRC. Всяко устройство в една сесия на RTP трябва да има уникален идентификатор SSRC. Това позволява на приемника да групира пакетите за възпроизвеждане.

• Идентификатори на допринасящите източници (CSRC): Полето на допринасящите източници (Contributing Source) съдържа списък на източниците на полезния товар в текущия пакет. Това поле се използва, когато смесител (виж т. 5.4) комбинира различни потоци от данни. Информацията, съдържаща се в това поле, позволява на приемника да идентифицира оригиналните източници.

5.1.2 Услуги на протокола Протоколът RTP осигурява транспортни услуги от край до край за приложения, които предават данни в реално време. Тези услуги включват: • Идентифициране на типа на полезния товар • Номериране на последователността • Нанасяне на времеви печат (Timestamping). Идентифициране на типа на полезния товар: Един пакет RTP може да съдържа части или от аудио, или от видео поток от данни. За разграничаване между тези потоци, изпращащото приложение включва идентификатор на типа на полезния товар в заглавието на пакета RTP. Идентификаторът показва конкретната схема за кодиране, използвана за създаване на полезния товар. Приемащото приложение определя подходящия алгоритъм да декодиране. В множество документи на IETF [7 – 33] са дефинирани различни формати на полезната информация (Payload Format) на RTP. В следващата таблица са показани поддържаните типове на полезния товар:

Audio Video Payload type Encoding name Payload type Encoding name

0 PCMU 24 unassigned 1 1016 25 CelB 2 G726-32 26 JPEG 3 GSM 27 unassigned 4 G723 28 nv 5 DVI4 (8 KHz) 29 unassigned 6 DVI4 (16 KHz) 30 unassigned 7 LPC 31 H261 8 PCMA 32 MPV 9 G722 33 MP2T 10 L16 Stereo 34 H263 11 L16 Mono 35-71 unassigned 12 QCELP 72-76 reserved 13 reserved 77-95 unassigned 14 MPA 96-127 dynamic 15 G728 dynamic BT656

13

16 DVI4 dynamic H263-1998 17 DVI4 dynamic MP1S 18 G729 dynamic MP2P 19 reserved dynamic BMPEG 20-23 unassigned dynamic GSM-EFR dynamic L8 dynamic RED dynamic VDVI

Този списък се поддържа от IANA (Internet Assigned Numbers Authority). Той се актуализира при появата на нови аудио и видео формати. Макар че протоколът RTP е разработен първоначално за поддържане на мултимедийни данни, той не е ограничен до трафик на аудио и видео. Всяко приложение, което произвежда непрекъснат поток от данни, може да използва услугите на RTP. Няколко схеми за кодиране могат да специфицират динамичен тип на полезния товар. Системите, които използват тези схеми за кодиране, динамично се договарят относно идентификатора на полезния товар. Номериране на последователността: Последователните номера се използват от приемащата RTP станция за възстановяване на първоначалния ред на пакетите. Приемникът е в състояние да открие загубата на пакети, като използва информацията от това поле. Последователният номер нараства с единица за всеки изпратен RTP пакет с данни. Първоначалната стойност на последователния номер се определя случайно. Това затруднява хакерските атаки върху криптирането. Случаен номер се използва дори и когато станцията-източник не криптира RTP пакетите. Пакетите може да преминават през транслатор, който не предоставя криптиращи услуги. Нанасяне на времеви печат (Timestamping): Времеви печати (Time stamps) се използват от протокола RTP за синхронизиране на данните от различни източници. Времевият печат представлява времето на дискретизиране (създаване) на първия октет в пакета на RTP с данни. Той се извлича от часовник, който работи монотонно и линейно. Разделителната способност (resolution) на часовника зависи от изискваната от приложението точност на синхронизация. Възможно е няколко последователни RTP пакети да носят един и същи времеви печат. Това може да се случи, например, ако един единствен видео-кадър се предава посредством множество RTP пакети. Тъй като полезният товар на тези пакети е логически генериран в един и същи момент, те имат едни и същ времеви печат. Първоначалната стойност на времевия печат е случайна. На фиг. 7 е показан пример за генериране на времеви печати при видео приложения.

14

100 JPEG Videoframe

SequenceNumber

PayloadType

99 JPEG Videoframe

98 JPEG Videoframe

97 JPEG Videoframe

Videoframe

SamplingTimer

Application

UDP

IP

RTP

Фиг. 7 Генериране на RTP пакети при видео приложения 5.2 Управляващ протокол в реално време (RTCP – Real-Time Control Protocol) За да се справят с доставката в реално време, много приложения се нуждаят от обратна връзка относно текущите характеристики на мрежата. Тази функция се предоставя от управляващия протокол в реално време (RTCP – Real-Time Control Protocol). Протоколът се базира на периодично изпращане на управляващи (контролни) пакети до всички участници в сесията. Основна функция на протокола RTCP да осигури обратна връзка относно качеството на разпространяването на данни чрез RTP. Това е сравнимо с функциите за управление на потока и на задръстванията, осигурявани от други транспортни протоколи. Обратната връзка, предоставена от всяка приемаща станция, се използва за диагностициране на проблемите при разпространението. Чрез изпращане на обратна връзка до всички участници в сесията, устройство, което има проблеми, може да определи дали проблемът е местен или отдалечен. Това също позволява и на управляващата единици (например доставчикът на мрежови услуги), който не е участник в сесията, да получи информацията за обратна връзка. Тогава доставчикът на мрежови услуги може да действа като независим (third party) наблюдател и да диагностицира мрежовите проблеми. Протоколът RTCP използва UDP - връзка за комуникиране. Тя е независима от UDP – връзката, използвана от протокола RTP. На фиг. 8 е показана взаимната работа на протоколите RTP и RTCP.

15

UDP

IP

RTP RTCP

Application

UDP

IP

RTP RTCP

Application

UDP

IP

RTP RTCP

Application

RTPRTCP

RTP

Sender

Receivers

Фиг. 8 Доставка на пакетите на RTCP и RTP Архитектурата на RTCP дефинира пет вида контролна информация, използвана за докладване на текущите характеристики: • Доклад на изпращащата станция (Sender report): Този доклад се изпраща от

източника на потока от данни, използващ протокола RTP. Той съдържа статистически данни относно предаването и приемането, наблюдавани от изпращащата станция. Този доклад се изпраща като групов (multicast) пакет, обработван от всички участници в сесия на RTP. Форматът на пакета за този доклад е показан по-долу.

• Доклад на приемащата станция (Receiver report): Този доклад съдържа статистически данни за участниците, които не са активни изпращащи станции. Ако станцията е изпратила какъвто и да е пакет с данни за интервала от време от изпращане на последния си доклад, тя изпраща доклад на изпращаща станция, в противен случай изпраща доклад на приемаща станция.

• Доклад за описване на източника (Source description report): Пакет за описание на източника се използва от изпращащата станция по протокола RTP за осигуряване на информация относно местните възможности. Дефинираните описания на източника (source descriptions) включват:

− CNAME: уникално име на източника − NAME: реалното име на източника − EMAIL: e-mail адрес на потребителя на приложението − PHONE: телефонния номер на потребителя на приложение − LOC: географско местоположение на потребителя на приложение − TOOL: име на конкретното приложение или инструмент (tool) − NOTE: допълнителни бележки относно източника − PRIV: частни разширения.

• Довиждане (BYE): Това съобщение се използва от източника, когато напуска конференцията. То се използва и при изключване на смесител (mixer). Чрез него се оповестяват всички източници, които допринасят в сесията.

5.3 Формат на пакетите при RTCP

16

На фиг. 9 е показан форматът на доклада на изпращащата станция при RTCP. Докладът е разделен на три секции. Първата секция съдържа заглавна част. Тази секция специфицира типа на пакета, дължината, и идентификация на изпращача. Втората секция съдържа информация на изпращащата станция. Третата секция съдържа блокове на доклада на приемника. Пакетът може да съдържа няколко блокове с доклади на приемника. Това позволява на предаващата станция да докладва за обратна информация от пакетите RTP, приети от други изпращащи станции. Форматът на доклада на изпращащата станция е показан напълно за яснота. Форматите на останалите три вида доклади са подобни. 0 2 3 8 16 31 Header V=2 P RC RT=SR=200 Length

SSRC of Sender Sender Information

NTP time stamp, most significant word NTP time stamp, least significant word

RTP time stamp sender's packet count sender's octet count sender's octet count

Report Block 1 SSRC_1 (SSRC of first source)

fraction lost cumulative number of packets lost extended highest sequence number received

interarrival jitter last SR (LSR)

delay since last SR (DLSR) Report Block 2

SSRC_2 (SSRC of first source) ...

profile-specific extensions

Фиг. 9 Формат на пакета на RTCP Полетата в пакета се използват както следва: • V (Version): това поле показва версията • P (Padding): това поле показва, дали в края на пакета има запълваща (padding)

информация • RC (Report Count): това поле съдържа броя на блоковете с доклади в този пакет • RT (Report Type): това поле съдържа типа на доклада (SR = Sender Report) • Length: това поле съдържа дължината на пакета • SSRC of sender: това поле съдържа идентификатора на източника за

синхронизация (SSRC) на станцията, изпращаща този пакет • NTP timestamp: това поле съдържа абсолютното време, определено от NTP

(Network Time Protocol). Протоколът RTCP използва число в секунди след 1.01.1990 г.

• RTP timestamp: това поле съдържа времевия печат от пакетите на протокола RTP в съответствие с изпращащата станция

17

• Sender’s packet count: това поле съдържа общия брой на пакетите данни на протокола RTP, изпратени от предаващата станция от началото на предаването

• Sender’s octet count: това поле съдържа общия брой на байтовете на полезния товар, изпратени от предаващата станция от началото на предаването

• SSRC_n: това поле съдържа идентификатора на SSRC на друга предаваща станция по протокола RTP, от която тази предаваща станция е получила пакети. Броят на блоковете на доклада с различни SSRCs на изпращащи станции зависи от броя на другите източници, които тази изпращаща станция е чула след последния си доклад

• Fraction lost: това поле съдържа (процентната) част от пакетите с данни по протокола RTP, които са се загубили след излъчване на предишния доклад

• Cumulative number of packets lost: това поле показва общия брой на загубени RTP пакети от източника SSRC_n.

• Extended highest sequence number received: това поле съдържа най-високия последователен номер, който е приет в RTP пакет от източника SSRC_n.

• Interarrival jitter: това поле съдържа очакваните вариации на времето на разпространение (interarrival times) от съответния източник. Ако пакетите пристигат равномерно, стойността на джитера е нула. Ако пакетите пристигат неравномерно, стойността на джитиетра е висока.

• Last SR timestamp (LSR): това поле съдържа средните 32 бита от 64-битовата NTP времеви печат, приета в последния RTCP доклад на изпращащата станция от източника SSRC_n.

• Delay since last SR (DLSR): това поле съдържа закъснението между приемането на последния SR пакет от източника SSRC_n и изпращането на текущия блок на доклада, изразено в единици от 1/65536 s.

5 П(кв 5 ТфсвMжв Ес

NTP - Network Time Protocol [5] Протокол, изграден върху TCP, който позволява поддържане на прецизно времена локално ниво посредством разположени в Интернет радио- и атомни часовници. Този протокол е в състояние да синхронизира разпределени часовници с точност до милисекунди за продължителен период от време.

.4 Транслатори и смесители за RTP

ротоколът RTP поддържа използването на транслатори (translators) и смесители mixers) за модифициране на потока от RTP пакети. Тези устройства се използват огато някои от участниците в мултимедийната сесия трябва да получават данните различни формати.

.4.1 Транслиране при RTP

ранслатори при RTP се използват за промяна на типа на данните в RTP пакет. На иг. 6 е показан пример за използване на такъв транслатор. В този пример три танции, включени във видеоконферентна сесия, обменят MPEG трафик през исокоскоростна локална мрежа. Всяка станция генерира трафик със скорост 1.5 bit/s. Друга станция, свързана посредством серийна връзка с по-ниска скорост, елае да участва във видеоконференцията. Ширината на лентата на нейната ръзка, обаче, не е достатъчна за поддържане на видео потоци.

дно от решенията на този проблем е промяна на видеоформата на всички работни танции с такъв, който произвежда трафик с по-ниска скорост (например H.261 със

18

скорост от 256 kbit/s). Намаляването на скоростта на данните, обаче, влошава общото качество на видеото. Алтернативно решение е да се използва устройство за транслиране на RTP. При това решение, пакетите, съдържащи MPEG данни от свързаните към LAN работни станции се транслират (преобразуват) във формат с по-ниска скорост на данните, и едва след това се препращат към серийно-свързаната работна станция. В конкретния пример всеки отделен MPEG поток се преобразува във видео поток съгласно H.261. Това намалява всеки поток от 1.5 Mbit/s в поток с 256 kbit/s. Отделните H.261 потоци след това може да бъдат предадени през серийната връзка. Трите свързани към локалната мрежа работни станции продължават да използват формата с по-високо качество MPEG за комуникиране помежду си.

1.5 Mbit/s 1.5 Mbit/s

1.5 Mbit/s

1 Mbit/s

256 kbit/s

3 x 256 kbit/s

100 Mbit/s

MPEG H.261

Workstation Workstation

Workstation

Workstation Router Router

Translator

Фиг. 10 Транслиране (преобразуване) при RTP Транслираните RTP пакети се препредават с непроменени идентификатори на източника на синхронизация. Това позволява приемниците на транслираните RTP пакети да идентифицират оригиналния източник. Приемникът не е в състояние да открие присъствието на транслатор, освен ако няма информация за типа на полезния товар, използван от оригиналния източник. Едно често използвано приложение на RTP транслаторите е осигуряване на взаимна работа със защитни стени (firewalls), които са реализирани на приложно ниво. При тази конфигурация, участниците в конференция не са пряко достижими чрез групово IP предаване (IP multicast). Те са разположени зад защитна стена, която не пропуска груповите (multicast) IP пакети. За поддържане на такива участници може да бъдат използвани транслатори. Инсталират се два транслатора, по един от двете страни на защитната стена. Външният транслатор се конфигурира да насочи всички групови пакети чрез сигурен тунел до партниращия му вътрешен транслатор, разположен зад защитната стена. Този транслатор от своя страна препраща информацията като групови пакети към групата, ограничена в рамките на защитената вътрешна мрежа. 5.4.2 Смесване при RTP Смесителите при RTP се използват за комбиниране на няколко потока от данни в един единствен RTP поток. Тези устройства се използват за поддръжка на аудио приложения, при които има само един или двама едновременно говорещи. Смесване при RTP не може да се използва при видео приложения. На фиг. 11 е показано приложение, при което се използва RTP смесване. В този пример три участника в аудио-конференция са свързани към LAN със скорост от 1

19

Mbit/s. Всеки участник произвежда PCM звуков поток със скорост 64 kbit/s. Четвърта работна станция, свързана посредством серийна връзка с по-ниска скорост, желае да участва в аудио-конференцията. Скоростта на тази връзка не е достатъчна за поддържане на комбинираните 192 kbit/s, произведени от съществуващите трима участника. Смесител RTP обединява трите потока в единичен поток със скорост 64 kbit/s. Това позволява на новата станция да се присъедини към конференцията.

64 kbit/s

1 Mbit/s

Workstation Workstation

Workstation

Workstation Router Router

64 kbit/s64 kbit/s

64 kbit/s

64 kbit/s

PCM Audio PCM Audio

Mixer

Фиг. 11 Смесване при RTP В горния пример типът на полезната информация на входящите и изходящи пакети остава непроменен. Възможно е, обаче, смесването при RTP да бъде комбинирано с RTP транслиране. Това би било необходимо, например, ако четвъртата работна станция на фиг. 11 е свързана посредством нискоскоростен модем. Тогава форматът на полезната информация на изходящия поток би трябвало да бъде променен съгласно спецификация, осигуряваща по-ниска скорост (например в GSM аудио със скорост 8-16 kbit/s). Когато множество входни потоци се обработват от RTP смесител е възможно тяхната синхронизация да бъде нарушена. Ако това се случи, смесителят генерира нова синхронизация за единичния изходен поток. Полето SSRC на изходния поток съдържа SSRC идентификатора на смесителя. За да може приемащата станция да идентифицира оригиналните източници на звукови данни смесителят включва SSRC идентификаторите на всеки оригинален източник. Тази информация се включва в списъка на CSRC идентификаторите, съдържащ се в заглавието на RTP пакета. 5.5 Приложения за работа в реално време Много съществуващи приложения за работа в реално време осигуряват поддръжка на видеоконферентните връзки, IP телефонията и поточно пренасяне на съдържание (media streaming). По-долу са посочени някои мултимедийни приложения в реално време: • QuickTime: QuickTime е приложение от Apple Computer, Inc., което осигурява

поточно предаване на аудио и видео съдържание. То предлага характеристики на живо поточно предаване, които премахват необходимостта от “смъкване” (downloading) на файлове в местната изчислителна среда. QuickTime може да осигури бързо разпръскване с високо качество и поддържа протоколите RTP и RTSP (Real Time Streaming Protocol) [6] за поточно предаване на съдържание (content) през Internet.

20

• RealAudio и RealVideo: това са приложения на RealNetworks, Inc. за доставка на цифрово съдържание. Те осигуряват поточно предаване на звук и видео с високо качество и поддържат RTP and RTSP.

• NetMeeting: NetMeeting е приложение, разработено от Microsoft Corp., което осигурява IP телефония, съвместна работа върху проекти (white boarding), текстови разговори (text chats), и съвместно използване на приложения и файлове. Приложенията поддържат RTP и RTSP.

• CU-seeMe: CU-seeMe е група от приложения, разработени от CuseeMe Networks, Inc. Те осигуряват софтуер за видео разговори по Internet, който поддържа видео, аудио и комуникации за съвместна работа. Те използват RTP за предаване в реално време.

• IP/TV: това е видео приложение от типа клиент/сървер, разработено от Cisco Systems, Inc. Софтуерът поддържа няколко стандарта за видео и аудио с високо качество (напр. MPEG, H.261). С помощта на IP/TV може да бъде разпространявано живо видео (live video), програмирано видео (scheduled video), и видео по поръчка (video on demand).

• Real-Time Streaming Protocol (RTSP) [6]: Този протокол създава и управлява няколко синхронизирани във времето потоци от непрекъснато видео и аудио.

Източниците на данни може да включват както живи данни, така и запаметени видео-клипове. По време на RTSP сесия потребителят на RTSP може да отвори и затвори множество сигурни транспортни връзки със сървера за представяне на RTSP заявки. Като алтернатива потребителят може да използва транспортен протокол без установяване на връзка, като UDP. Потоците, управлявани от RTSP, може да използват RTP, но работата на RTSP не зависи от този протокол. Протоколът RTSP обикновено не отговаря за доставката на потоците от данни, макар че е възможно преплитане на поток със съдържание с поток от управляващи данни. 6. IP телефония IP телефонията (наричана също “глас върху IP” - Voice over IP – VoIP) осигурява възможност за пренос на гласов трафик през IP мрежа. Това може да бъде извършено през който и да е вид IP мрежа, включително Internet, корпоративните intranets, или локални мрежи. При това гласовият сигнал се превръща в цифрова форма и се включва в IP пакети. След това пакетите се предават през IP мрежа. Създадени са стандартни протоколи, осигуряващи структури за сигнализиране, необходими за въвеждане на гласов трафик в мрежите за данни. Тези протоколи осигуряват възможности за локализиране на потребителите, договаряне на възможностите и изграждане на връзки. Между многото причини, които водят до конвергенция между мрежите за глас и данни, е достатъчно да бъдат споменати само двете най-важни: • Корпорациите, които са развили големи мрежи за данни очакват от обединената

мултимедийна мрежа икономия от цените и намаление на разходите • Появяват се нови приложения за интегриране на глас и данни. Те предлагат

подобрения на съществуващите бизнес-процеси. Примери за тези процеси включват поддържана от компютри съвместна работа, основаващи се на Web центрове за повиквания, и интегрирани гласова поща с e-mail.

21

6.1 Въведение За да може IP телефонията да има успех е необходимо да бъдат решени няколко ключови проблема. Някои от тях произтичат от факта, че IP мрежите са по начало създадени за пренос на данни. Други проблеми са свързани с потенциалното нарастване на услугите и на мрежите. Като минимум една мрежа за IP телефония трябва да осигурява: • Качество: Качеството на връзката трябва да бъде най-малко равно на това,

осигурявано в момента от традиционната обществена комутируема телефонна мрежа (PSTN – Public Switched Telephone Network), наричана още мрежа, предоставяща “простата стара телефонна услуга” (POTS – Plain Old Telephone Service). Закъснението на сигнала от край до край има най-голямо отражение върху възприеманото качество (perceived quality). Това закъснение включва времето, необходимо на устройството на викащата страна да събере и кодира група от гласови отчети. То включва и времето, необходимо за пренасяне на тези отчети през мрежата. По-големи закъснения може да доведат до няколко проблема:

− Гласовото ехо се причинява от отразяване на сигнала на гласа на говорещия. То се наблюдава също и в обикновените POTS мрежи. Тъй като закъснението при VoIP обикновено превишава това на мрежите POTS, ехото става основен проблем при IP телефонията. Ехото става съществен проблем на качеството когато общото закъснение превиши 50 ms. За минимизиране на влиянието на този проблем се налага използването на устройства за премахване на ехото (echo cancellation). − При голямо закъснение може да настъпи припокриване на говорещите. За минимизиране на този проблем трябва да бъде използвано приоритизиране на трафика. − Яснотата (clarity) на гласа също се влияе от общите характеристики на IP мрежата. Загубата на късно пристигащи гласови пакети може да повлияе негативно върху възприеманата ясност. Схемите за преобразуване в цифров вид и за компресиране, използвани за преобразуване на гласовите сигнали в IP пакети, може също да имат отражение върху ясността на гласа.

• Използваемост: функционалността и лекотата на работа на мрежа VoIP трябва най-малкото да са на нивото на съществуващите POTS мрежи. Мрежите за IP телефония няма да получат всеобщо признание, ако услугите изискват сложни номерационни планове, имат голям процент на неосъществени разговори, или изискват по-голямо време за завършване на разговора.

• Възможности за нарастване: системите VoIP имат потенциала да осигуряват услуги с високо качество при много по-ниски разходи в сравнение със съществуващите PSTN. Това създава възможност за много бързо нарастване на тези услуги. Системите за IP телефония трябва да бъдат разширяеми за да могат да осигурят тези потенциални скорости на нарастване.

• Взаимна работа и интегриране: мрежите, предоставящи IP телефония, трябва да могат да работят с подобни продукти от различни доставчици. Те също трябва да могат да работят със съществуващите PSTN. За потребителите на гласови услуги всички тези мрежи трябва да изглеждат като една единствена среда.

6.2 Протоколният пакет на IP телефония За реализиране на IP телефония се използват редица отделни протоколи. За да осигурят необходимите услуги, тези протоколи взаимодействат в йерархичен

22

модел. Взаимната работа на протоколите може да бъде представено като набор или пакет (stack), подобно на представянето, използвано от много други комуникационни системи. Един от начините за дефиниране на пакета е да се разделят протоколите в две функционални секции, илюстрирани на фиг. 12.

UDP or TCP

IP

Data Link

Physical

RTP/RTCP H.225Call Control

H.225RAS Control

H.245 Conf. ControlRSVP SAP/SDP

SIP H.323 MGCP Megaco

Transport andQuality

Signalling and Support

Фиг. 12 Протоколният набор за IP телефония Двете секции на протоколния набор осигуряват следните функции: • протоколи за пренасяне и за осигуряване на качество: тези протоколи се

използват за пренасяне на реалния гласов трафик • протоколи за сигнализиране и поддържащи протоколи: преобладаващите

усилия в областта на IP телефонията са посветени на разработката на протоколи за сигнализиране. Тези протоколи локализират потребителите, договарят параметрите на връзката, и управляват гласовите повиквания. Съществуват четири основни протокола за сигнализиране:

− Препоръка на ITU-T H.323 − Протокол за инициализиране на сесия (SIP – Session Initiation Protocol) − Протокол за управление на шлюз на (преносната) среда (MGCP - Media Gateway Control Protocol) − Препоръка на ITU-T H.248/Контролер на шлюз на (преносната) среда (Megaco – Media Gateway Controller)

Както беше споменато по-горе (виж т.4), първите два протокола са централизирани и следват архитектурата клиент/сървер, докато последните два протокола са разпределени и се основават на взаимодействия между равнопоставени единици (peer-to-peer). Изброените протоколи са несъвместими и често предоставят излишни функции. Когато се използват в една и съща среда, за комуникиране между тях са необходими конвертори или шлюзове. По-долу се описват накратко тези протоколи за сигнализиране.

23

6.3 Препоръка на ITU-T H.323 Препоръка на ITU-T H.323 е разработена за мултимедийни видеоконферентни връзки през мрежи с пакетна комутация. Първата версия на H.323 е от 1996 г. В момента е в сила версия 4 от м. ноември 2000 г. Препоръка H.323 е производна на препоръка на ITU-T H.320, която се отнася до видео-конферентни връзки. H.323 използва LAN протокол, докато препоръка H.320 използва ISDN протокол, а H.324 – PSTN протокол. Тези стандарти определят начина, по който се осъществява предаване в реално време на аудио и видео, наред с данни, по различни комуникационни мрежи. Съблюдаването на тези стандарти осигурява общи възможности и взаимна работа между мрежовите мултимедийни приложения, които може да се осигурят от различни доставчици. В стандартна мрежа съгласно H.323 има четири основни компонента: • Терминали • Шлюзове (Gateways) • Пазители на шлюзовете (Gatekeepers) • Многоточкови управляващи устройства (MCUs – multipoint control units) 6.3.1 Терминали Терминалите са клиенти на локални мрежи (LAN client), свързани в мрежа за IP телефония. Един H.323 терминал може да комуникира с други H.323 терминали, с H.323 шлюз или с H.323 MCU. Всички терминали трябва да поддържат гласови комуникации. Поддържането на видео и данни е опция. H.323 специфицира процедурите, необходими за съвместната работа на различни терминали. Всички H.323 трябва да поддържат набора от протоколи, описани по-долу (т. 2.3.6). Терминалите H.323 поддържат многоточкови разговори и осигуряват възможност за инициализиране на ад-хок конференции. Те също имат многоадресни възможности, които позволяват на множество потребители да участват в разговор, без да се налага централизирано смесване или комутиране. 6.3.2 Шлюзове Шлюзовете позволяват на стандартни телефони да използват VoIP услуги. Те осигуряват връзка между H.323 терминали и терминали, свързани или към IP мрежа, или към друг H.323 шлюз. Шлюзът действа като транслатор, осигурявайки интерфейса между PSTN и мрежата IP. Шлюзът отговаря за преобразуване на протоколите за сигнализация на повикването и за управление, използвани от различните мрежи. Той също отговаря за преобразуване на (преносната) среда между мрежите – т.е. за мултиплексиране, съгласуване на скоростите, прекодиране на гласовите сигнали. Прокси (proxy) е специален вид шлюз, който на практика препредава H.323 към друга сесия H.323. Проксито може да осигури QoS, оформяне на трафика и управление на H.323 трафик.

24

6.3.3 Пазачи на шлюзове (Gatekeepers) Това са най-важните компоненти в една H.323 среда. Мрежа от H.323 терминали и шлюзове под управлението на конкретен gatekeeper формира интегрирана подмрежа в рамките на по-голямата IP мрежа. Функциите на gatekeeper включват: • Справочен сървер (Directory server): като използва информацията, получена по

време на регистрирането на терминалите, тази функция транслира един H.323 адрес в IP (транспортен) адрес. Това позволява потребителят да има значещи, непроменени имена за назоваване на другите потребители в системата. Тези имена са произволни и може да изглеждат подобни на имената, използвани в приложенията e-mail или гласова поща.

• Надзираващи функции: пазачът на шлюз може да бъде използван за даване на разрешение за повикване. Така може да бъдат поставени ограничения върху използваната лента, намалявайки вероятността от задръстване в мрежата.

• Сигнализиране на повикването: пазачът на шлюз може да извърши маршрутизиране на повикването за да осигури допълнителни услуги. Той също може да осигури функции на многоточков контролер, поддържащи повиквания с голям брой участници.

• Управление на повикванията: пазачът на шлюз може да бъде използван за извършване на таксуване на повикванията и за тяхното управление.

6.3.4 Многоточкови управляващи устройства (MCUs – multipoint control units) Многоточковото управляващо устройство (MCU) е крайна точка в мрежата. То осигурява възможността три или повече терминала или шлюзове да участват в многоточкова конференция, при което управлява конференцията и комутирането на (преносната) среда. Съществуват три вида многоточкови конференции: • Централизирани: всички терминали имат връзки точка-точка с MCU.

Управляващото устройство е отговорно за управлението на конференцията. То приема, обработва и предава гласовите пакети към другите терминали.

• Децентрализирани: терминалите комуникират пряко един с друг. В конференцията няма пряко участващо MCU.

• Смесена многоточкова: това представлява смес от централизирани и децентрализирани конференции. Многоточковото управляващо устройство осигурява, щото работата на конференцията да е прозрачна за всеки терминал.

6.3.5 Примерна конфигурация на мрежа H.323 На фиг. 13 е показана примерна конфигурация на H.323 мрежа. Базирана на IP мрежа е свързана с PSTN чрез шлюзове H.323-PSTN.

25

d i g i t a l d i g i t a l

H.323 Gatekeeper DNS Server

IP Network

H.323 toPSTN

GatewayH.323 to

PSTNGateway

PSTN PSTN

Voice Communi-cation Path

H.323 Terminal H.323 Terminal

Фиг. 13 Примерна мрежова конфигурация при H.323 На фигурата са посочени три вида връзки: • Терминалите H.323 могат директно да комуникират през инфраструктурата на

IP мрежа. • Терминалите H.323, свързани към IP мрежа, могат да комуникират със

стандартни телефони в PSTN. При тази конфигурация, шлюзът H.323 осигурява взаимната работа между свързани към IP терминали H.323 и други аудио устройства, които са свързани към не-IP мрежи.

• Два стандартни PSTN телефона могат да комуникират чрез инфраструктурата на IP мрежа. В тази конфигурация, IP мрежата се използва само за транспортни услуги.

6.3.6 Наборът от протоколи H.323 Препоръка H.323 е обобщаваща препоръка, тъй като различни нейни компоненти са дефинирани в други препоръки и стандарти. На фиг. 14 е показан наборът от протоколи, на които H.323 се позовава.

UDP or TCP

IP

Data Link

Physical

G.711, G.723-1, etc.

RTP/RTCP RSVP

H.225Call Control

H.225RAS Control

H.245Conference Control

Audio System Control and User Interface

26

Фиг. 14 Наборът от протоколи на H.323

В набора от протоколи, реализиращи препоръка H.323, са включени: • Управление на повикването H.225: Този протокол осигурява сигнализирането

за повикване и функции за управление на повикванията. В мрежи без пазач на шлюза, съобщенията на сигнализацията на повикването се предават директно между викащата и виканата крайни точки. В мрежи, които съдържат пазач на шлюза, тези съобщения първоначално се обменят между викащата крайна точка и пазача. Съобщенията за управление на повикванията на H.225 използват транспортните услуги на TCP.

• Управление на регистрирането, допускането и сигнализирането – H.225 registration, admission and signaling (RAS) control: Каналът RAS се използва за комуникиране между крайните точки и пазача на шлюза. Протоколът дефинира стандартни процедури за откриване на пазача, регистриране на крайните точки, локализиране на крайните точки, и управление на допускането. Съобщенията RAS на H.225 използват транспортните услуги на UDP.

• Управление на конферентни връзки H.245: Този протокол се използва след като фазата за изграждане на повикването е приключила. H.245 се използва за договаряне на преносните канали, използвани от RTP и RTCP. Протоколът дефинира стандартни процедури за размяна на възможности, определяне и приписване на водещи (master) и подчинени (slave) участници, и за управление на конференциите..

• G.711, G.723.1: По-долу, в раздел 2.8, е приведена информация относно тези спецификации за кодиране и компресия.

• Транспортен протокол в реално време (RTP – Real-Time Transport Protocol): този протокол позволява на приемника да открие загуба на пакети. Той също осигурява информация относно синхронизацията, което позволява на приемника да компенсира променливото време на пристигане на пакетите (т.е. на техния “джитер”). Този протокол беше разгледан по-подробно в т. 1.1.

• Управляващ протокол в реално време (RTCP – Real-Time Control Protocol): този протокол съпътства RTP. Той се използва за получаване на обратна информация относно състоянието на мрежата и качеството на обслужването. Този протокол е разгледан по-горе в т. 1.2.

• Протокол за резервиране на ресурси (RSVP – Resource Reservation Protocol): Мрежов компютър използва RSVP за заявяване на конкретно качество на обслужване (QoS) от мрежата. Заявката се обработва от всеки възел по протежение на пътя на сесията. Устройствата запазват подходящи ресурси за поддържане на потока от данни на конкретното приложение.

6.3.7 Управление на повикването и взаимна работа при H.323 Осъществяването на връзката при H.323 става чрез стъпките, показани на фиг. 15:

27

Connect (12) Connect (12) Connect (12)Alerting (11) Alerting (11) Alerting (11)

ACF (10)

ARQ (9)

Call proceeding (7)Call proceeding (7)

Call proceeding (7)

ARQ (1)LRQ (2)

LCF (3)ACF (4)

Setup (5)Setup (6)

Setup (8)

Endpoint 1 Gatekeeper 1 Gatekeeper 2 Endpoint 2

RAS messagesMulticast RAS messagesCall signalling messages

ARQ Admission Request LRQ Location Request LCF Location Confirmation ACF Admission Confirmation RAS Registration, Admission and Status

Фиг.15 Управление на повикването между устройства H.323

Както може да се види от горната фигура, протоколът H.323 е ясен и гъвкав, но с цената на ниска ефективност. 6.4 Протокол за инициализиране на сесия (SIP – Session Initiation Protocol) Протоколът SIP е протокол за сигнализиране на приложно ниво, използван за инициализиране, модифициране и приключване на повиквания. Това позволява на клиенти, шлюзове VoIP и други комуникационни системи за се свързват помежду си. Функционално, услугите и характеристиките, осигурявани от SIP, са подобни на версия 2 на H.323. Основният стандартизационен документ на SIP е RFC 2543. В стандартна SIP мрежа има два компонента: • потребителски агент • мрежов сървер. 6.4.1 Потребителски агент (User agent) Потребителски агент е резидентна програма във всяка SIP крайна станция. Той се състои от две части: • Клиент на потребителския агент (UAC – User Agent Client) – отговорен за

излъчване на SIP заявки.

28

• Сървер на потребителския агент (UAS – User Agent Server) – отговорен за получаването и реагирането на заявките.

Потребителски агент е еквивалентен на терминал H.323. 6.4.2 Мрежови сървери Сърверите на SIP мрежа се използват за поддържане на усъвършенствани функции за повикване. Съществуват три вида мрежови сървери: • Пренасочващи (Redirect) сървери се използват по време на инициализирането

на повикването за определяне на адреса на виканото устройство. Тази информация се връща на викащото устройство.

• Прокси (Proxy) сървери осигуряват маршрутизиране на приложно ниво на заявките и отговорите на SIP. Когато сървер получи заявка, той пренасочва тази заявка към следващия сървер, който има повече информация относно виканото устройство.

• Регистриращи (Registrar) сървери се използват за записване на SIP адреси и на свързаните с тях IP адреси на устройства.

Мрежовите SIP сървери обикновено реализират комбинация от различни сърверни типове. Мрежовите сървери са функционален еквивалент на пазачите на шлюзове (gatekeeper) при H.323. 6.4.3 Архитектура на SIP При разработката на стандарта за SIP е използван модела на Internet. Ето защо архитектурата на SIP е подобна на тази на HTTP. И двете системи използват модела за комуникиране заявка-отговор (request-response). Викащото устройства изпраща заявка до виканото устройство. Виканото устройство решава дали да приеме или да отхвърли заявката и връща отговора си на инициатора. Протоколът SIP използва и други черти на HTTP. Форматът на съобщенията на SIP се основава на HTTP. SIP използва по същия начин повече от полетата на заглавието, правилата за кодиране и кодовете за грешка на HTTP. Това осигурява читаем, текстово-ориентиран формат за представяне на информацията. Адресът на SIP се означава като SIP-URL (SIP Uniform Resource Locator – унифициран локатор на ресурс). Той има формат sip:username@hostname.domain. Този адрес се използва за идентифициране на единично устройство или на група от устройства. То позволява потребителят да инициализира повикване посредством избор на връзка (link) чрез избиране в стандартна програма за сърфиране (browser). 6.4.4 Набор от протоколи на SIP При работа със SIP, за гласови повиквания се използва RTP, както и при H.323. Основната разлика между SIP и H.323 е начинът, по който се реализира сигнализирането и управлението на повикването. Наборът от протоколи при SIP е показан на фиг. 16.

29

UDP or TCP

IP

Data Link

Physical

G.711, G.723-1, etc.

RTP/RTCP RSVP

AudioSystem Control and

User Interface

SIP SAP/SDP

Фиг. 16 Набор от протоколи SIP Протоколът SIP разчита на допълнителни стандарти за извършване на функциите по сигнализиране и управление на повикването. Те включват: • Протокол за описание на сесия (SDP – Session Description Protocol): SDP е

протокол за обявяване на сесия и за покана за сесия в мултимедийна среда. Той позволява на приелите обявата за сесия да участват в нея. Протоколът е документиран в RFC 2327.

• Протокол за обявяване на сесия (SAP – Session Announcement Protocol): SAP е друг протокол за обявяване на многоточкови конференции и сесии. Той е предназначен за обявяване за съществуването на дълготрайни групови сесии в широка географска област.

6.5 Протокол за управление на шлюза на съобщителната среда (MGCP –

Media Gateway Control Protocol) Протоколът за управление на шлюза на съобщителната среда – MGCP (Media Gateway Control Protocol) се използва за управление на телефонни шлюзове от външни елементи за управление на повикването, наречени контролери на шлюза на съобщителната среда – MGCs (Media Gateway Controllers) или агенти на повикването (Call Agents). Телефонния шлюз (telephony gateway) е мрежов елемент, който осигурява преобразуване между гласовите сигнали, пренасяни по телефонните вериги, и пакетите данни, които се пренасят през Интернет или през други мрежи с комутация на пакети. Протоколът MGCP е разработен първоначално за преодоляване на отбелязаните недостатъци на H.323. Протоколът позволява разделяне на телефонния шлюз на група от компоненти. Тези компоненти установяват отношения водещ-подчинен (master-slave). Водещата компонента е агент на повикването (call agent). Подчинените компоненти се наричат шлюзове (gateways).

Протоколът MGCP приема архитектура за управление на повикванията, при която интелигентността за управление на повикването е извън шлюзовете и е присъща на външните елементи за управление на повикването. MGCP приема, че тези външни елементи, или агенти на повикването ще се синхронизират помежду си, така че да подават кохерентни команди към шлюзовете, които се намират под

30

тяхното управление. В същината си MGCP е протокол master/slave, при който се очаква шлюзовете да изпълняват командите, изпратени от агентите на повикването.

Моделът на MGCP приема, че основната мрежа (the core) е тази, която притежава интелигентност за осъществяване на усъвършенствани услуги. Крайните телефони имат минимални технически възможности. По това MGCP се отличава от архитектурата на SIP, при която интелигентността е разположена в крайните мрежови точки. Моделът на MGCP дава предимства на мрежовите оператори, тъй като позволява предоставяне на усъвършенствани услуги посредством евтини крайни точки. Основните функционални възможности на MGCP са описани в RFC 2705. Стандартът осигурява интерфейс за приложно програмиране (API – application programming interface) и съответния протокол (MGCP). В стандартна MGCP мрежа има два основни компонента: • агент на повикването (Call agent). • шлюз (Gateway) 6.5.1 Агенти на повикването Агентът на повикването насочва работата на шлюза. Интелигентността, необходима за извършване на действията при повикване, е разположена в агента на повикването. Тези устройства са също отговорни за функциите по сигнализиране и обработка на повикванията. Една MGCP не е необходимо да се интегрира с мрежа H.323. Тъй като агентът на повикването на MGCP изпълнява функции по сигнализирането, той може да действа като пазач на шлюза при H.323. 6.5.2 Шлюз Шлюзът отговаря за преобразуването между гласовите сигнали, използвани в PSTN, и пакетите данни, използвани в IP мрежи. Примери на шлюзове са: • Групови (Trunking) шлюзове осигуряват интерфейса между традиционната PSTN

телефонна мрежа и VoIP мрежа. Тези шлюзове обикновено управляват голям брой вериги.

• Домашни (Residential) шлюзове осигуряват интерфейс между традиционния краен потребител на телефонни услуги (посредством аналогов съединител RJ-11) и VoIP мрежа. Тук се включват интерфейсите чрез кабелни модеми и xDSL устройства.

6.5.3 Команди при MGCP

Протоколът MGCP осъществява интерфейса за управление на шлюзовете като набор от транзакции. Транзакциите се състоят от команда и от задължителен отговор. Съществуват осем типа команди:

31

CreateConnection (CRCX)

Creates a connection between two endpoints; uses SDP to define the receive capabilities of the paricipating endpoints.

MGC --> MG

ModifyConnection (MDCX)

Modifies the properties of a connection; has nearly the same parameters as the CreateConnection command.

MGC --> MG

DeleteConnection Terminates a connection and collects statistics on the execution of the connection.

MGC <--> MG

NotificationRequest RQNT

Requests the media gateway to send notifications on the occurrence of specified events in an endpoint.

MGC --> MG

Notify (NTFY)

Informs the media gateway controller when observed events occur.

MGC <-- MG

AuditEndpoint (AUEP)

Determines the status of an endpoint. MGC --> MG

AuditConnection (AUCX)

Retrieves the parameters related to a connection. MGC --> MG

RestartInProgress (RSIP)

Signals that an endpoint or group of endpoints is take in or out of service.

MGC <-- MG

MGC=Media Gateway Controller MG=Media Gateway

Първите четири команди се изпращат от агента на повикването към шлюза (MG). Командата Notify се изпраща от шлюза към агента на повикването. Шлюзът може също да изпрати и командата DeleteConnection. Агентът на повикването може да изпрати някоя от двете Audit команди към шлюза. Шлюзът може да изпрати командата RestartInProgress към агента на повикването.

Всички команди се състоят от заглавна част, следвана (като опция) от описание на сесията. Всички отговори се състоят от заглавие на отговора, следвано (като опция) от описание на сесията. Заглавните части и описанията на сесиите са кодирани като група от редове с текст, следвани от служебни знаци (CR – връщане на каретката и LF – преместване с един ред). Заглавието е разделено от описанието на сесията посредством празен ред.

Особен интерес представляват съобщенията за известяване (notification messages). Шлюзът използва тези съобщения за да информира агента на повикването за за промяна в състоянието. Те обикновено включват сигнализиране или събития:

• сигнализиране — повикване (позвъняване), обратен тон при повикване, тон при номеронабиране, тон за пренасочване, тон за задръстване в мрежата, тон заето, тон за потвърждаване, тон при отговаряне, тон при изчакване на повикването, сигнал “свободен комутатор” (off-hook), сигнал за заемане с по-висш приоритет (preemption), проверка за непрекъснатост, проверка за целостта на връзката, тонове при тонално номеронабиране (DTMF)

• събития — факсимилни тонове, модемни тонове, проверка за непрекъснатост, установяване на целостта на връзката (в резултат на проверката за непрекъснатост), преход при повдигане (off-hook) или затваряне (on-hook), приемане на DTMF цифри.

Протоколът MGCP притежава редица черти, които го правят привлекателен за приложение в VoIP системи. Преди всичко, размяната на съобщения се основава на UDP, а не на TCP, което го прави по-ефикасен. Моделът на централизирано управление е изложен на опасност от повреда в една точка, но шлюзовете могат да се преориентират към резервен MGC при повреда на първичния контролер. Така моделът може да бъде толкова надежден, колкото и останалите модели за управление на повикванията. Количеството на обслужваните крайни точки зависи

32

основно от обработващата мощност на MGC. Когато тя стане ограничаващ фактор, мрежата може да бъде разделена на отделни MGC домени. Така че моделът за управление на повикванията на MGCP може да обхване милиони крайни точки.

Протоколът е също и надежден, тъй като всяка заявка се потвърждава. При това са възможни три отговора: успех, временна грешка и перманентна грешка. Непотвърдени заявки може да бъдат повторени. Протоколът MGCP разчита на DNS за преобразуване на имената в IP. Това означава, че един IP адрес може да бъде приписан на множество възли, както и че един възел може да има множество IP адреси. Това всичко допринася за гъвкавостта на протокола.

Типичният ход на обработката на повикването при MGCP е показан на Фиг. 17:

Phone L-GW1 CA SS7-GW (ISUP) T-GW1

Off-hook Notify (1)

Notify (3)

Notify (7)

Dial-tone NotificationRequest (2)

CreateConnection (4)

CreateConnection (6)

CreateConnection (15)

Digits

ModifyConnection (11)

IAM (5)

COT (8)

ACM (9)

ANM (10)

REL (12)

RLC (13)DeleteConnection (14)

Conversation

ISUP Messages:

IAM – initial address message COT – continuity test ACM – address complete message ANM – answer message REL – release message RLC – release complete message

Фиг. 17 Поток на повикването при MGCP

6.6 Контролер на шлюза на съобщителната среда (Megaco - Media Gateway

Controller) Подобно на използването на MGCP в IP телефонна мрежа, Megaco разглежда взаимодействието между шлюз и агент на повикването. За разлика от MGCP, обаче, Megaco поддържа по-широк кръг от мрежи, включително и ATM. Това прави този протокол приложим към със значително по-широка гама от шлюзове. След приемане на стандарта MGCP пред IETF са представени множество предложения за неговото подобряване и усъвършенстване. Протоколът Megaco

33

комбинира тези предложения в една архитектура. Той е резултат на съвместна разработка на ITU и IETF. Протоколът Megaco е предназначен да поддържа шлюзове с размери вариращи от единичен порт до хиляди портове. В стандартната Megaco мрежа има два компонента: • край на връзката (Termination) • контекст (Context). 6.6.1 Край на връзка (Termination) Край на връзка представлява поток, постъпващ в или напускащ шлюза. Някои краища на връзки, представляващи в общия случай портове на шлюза, се създават автоматически при активиране на устройството. Други краища на връзки се създават при необходимост. Те представляват преходни потоци през мрежата, например трафични потоци на протокола RTP и VoIP потоци. 6.6.2 Контекст Краищата на връзки се разполагат в контексти. Това се случва когато два или повече краища на връзки се свържат заедно. Едно обикновено повикване може да има два края на връзки за контекст (terminations per context) – един край на връзка, представляващ крайното устройство, и друг край на връзка, представляващ свързването към мрежата. Конферентно повикване може да има множество краища на връзки за контекст, всеки край на връзка представляващ един клон на конференцията. Протоколът Megaco използва редица команди за обработване на краищата на връзки и контексти. Командата MOVE прехвърля край на връзка от един контекст в друг. Тези команди се изпращат от агента на повикването към шлюза. 6.7 Функционално сравнение на протоколите за сигнализация Разгледаните по-горе протоколи за сигнализиране съществено се различават: • Те са разработени от различни стандартизационни организации. H.323

например е разработен от ITU, организация, която по традиция разработва стандарти за среда с комутация на вериги. Стандартът SIP е разработен от Internet Engineering Task Force (IETF). По традиция тази организация разработва стандарти за мрежи за данни.

• Протоколите са разработени в различно време - H.323 през 1995 г., докато SIP – четири години по-късно.

Всеки протокол за сигнализиране има предимства и недостатъци. 6.7.1 Приложимост Протоколът H.323 е първият основен VoIP протокол за сигнализиране. Дълго време той е бил предлаган като стандарт за взаимна работа. Така той има най-силно пазарно присъствие. Той е бил първоначално възприет от традиционните доставчици на телефонни услуги и производителите, тъй като те са били запознати с концепцията и архитектурата. Когато обаче доставчиците започват да проявяват

34

интерес към предлагане на усъвършенствани услуги, секторът започва да мигрира от H.323 към SIP. Тъй като стандартът Megaco осигурява надмножество на функциите, предлагани от протокола MGCP, поддръжката за MGCP започва да намалява. 6.7.2 Сложност на протокола и възможности за нарастване (scalability) Протоколът H.323 е сравнително сложен. Много от услугите изискват взаимодействие между множеството под-протоколи, реализиращи стандарта. Това е недостатък за приложенията, свързани с IP телефонията, тъй като се увеличава тяхната сложност. Сложността влияе отрицателно и върху времето, необходимо за разработване на нови приложения, основаващи се на този стандарт. Протоколът SIP използва съществуващата зрялост на протокола HTTP. Този протокол е доказал, че работи добре в големи мрежови среди. Възможностите за нарастване, създадени по време на еволюцията на HTTP, са включени в SIP. Това позволява на SIP да бъде потенциално мащабиран за много големи мрежи. 6.7.3 Възможност за взаимна работа Възможността за взаимна работа (Interoperability) включва съответствие между различните реализации на стандарта от производителите, както и между различните версии на самия стандарт. • между реализациите на различни производители: описанието на услугите в

H.323 е много подробно, така че се наблюдават малко проблеми при взаимната работа. От друга страна SIP е много гъвкав и лесно разширяем, като са предвидени минимални защити, които да попречат на един производител да разшири протокола по начин, различен от този на друг производител.

• между различните версии: при H.323 се приети мерки, които да осигурят съвместимост между различните версии. Обратно, новите версии на SIP могат да изоставят по-стари черти на протокола, които не са получили достатъчна подкрепа. Това намалява сложността на протокола, но предизвиква несъвместимост между версиите му. Някои характеристики, реализирани в по-старите версии на SIP, може да не бъдат поддържани от по-новите му версии.

6.7.4 Лекота на реализирането Сигнализирането при H.323 е кодирано посредством системата за означаване ASN.1. Това кодиране изисква сложно синтактично анализиране (parsing) и усложнява реализирането на протокола и отстраняването на грешки (debugging). Обратно, съобщенията при SIP са текстово-ориентирани. Това позволява по-лесна реализация и опростява търсенето и отстраняването на грешки. 6.7.5 Поддържане на качеството на обслужване Характеристиките на H.323 и SIP по отношение на качеството на обслужване са сравними. Двата протокола имат съпоставими времена за изграждане на връзка. Както H.323, така и SIP нямат пряка поддръжка за резервиране на ресурси. Всеки от тях разчита на протокола RSVP за резервиране на мрежови ресурси. 6.7.6 Приемане

35

Протоколите SIP, MGCP, и Megaco имат подкрепата на IETF. Това е една от най-широко приеманата организация за стандартизация. 7. Устройства за кодиране и декодиране на гласови сигнали Технологията за кодиране/декодиране (codec) на глас през последните години отбеляза бърз напредък благодарение на развитието на архитектурите за цифрова обработка на сигналите (DSP – digital signal processing), както и на изследванията в областта на човешката реч и нейното разпознаване. Новите устройства за кодиране и декодиране (кодек – кодеци) вършат много повече от просто аналогово-цифрово и цифрово-аналогово преобразуване. Те могат да анализират гласа като приложат сложни шаблони за предсказване и след това да предадат гласовия сигнал като използват минимална ширина на лентата (минимална скорост на битовете). По-долу се разглеждат някои примерни кодеци и използваната от тях лента. Простата импулсно-кодова модулация (PCM – pulse code modulation) е дефинирана в препоръка ITU-T G.711. Тя предвижда две основни разновидности на PCM с 64 kbit/s: µ-law и A-law. Двата метода са подобни, тъй като използват логаритмична компресия за постигане на качеството на 12- или 13-битово линейна PCM само с 8 бита. Те се различават по сравнително второстепенни детайли на компресията, като µ-law има известно предимство в отношението сигнал-шум при ниски нива на сигнала. Исторически µ-law се използва в Северна Америка, докато A-law – в Европа. Преобразуването от µ-law в A-law се поема от страната с µ-law.

Друг метод за компресия използва адаптивна диференциална импулсно кодова модулация (ADPCM – adaptive differential pulse code modulation). Общоизползвана реализация на ADPCM е ITU-T G.726, при която размерът на отчетите се редуцира до 4 бита, а скоростта – до 32 kbit/s. За разлика от PCM, четирите бита не кодират пряко моментната стойност на речевия сигнал, а кодират разликите (differences) в тези стойности, както и скоростта на тяхната промяна, използвайки много опростено линейно предсказване.

PCM и ADPCM са примери на кодеци на формата на сигнала (waveform codecs), техника за компресия, която използва излишъка на самата форма на сигнала. През последните 15-20 години се създават нови техники за компресия, които използват натрупаните познания относно самото генериране на речта в говорния тракт на човека. Тези техники използват обработка на сигналите, която компресира речта като изпраща само опростена информация относно параметрите на оригиналното възбуждане на речта (speech excitation) и оформянето на вокалния тракт, при което се достига до значително по-ниски скорости за предаване на тази информация. Тези техники могат да бъдат обобщено групирани като кодеци на източника (source codecs) и включват разновидности като кодиране с линейно предсказване (LPC – linear predictive coding), възбудено от кода линейно предсказване (CELP – code excited linear prediction), и много-импулсно квантуване с много нива (MP-MLQ – multipulse, multilevel quantization).

Усъвършенстваните кодеци с предсказване разчитат на математическия модел на човешкия вокален тракт и вместо да изпращат компресиран гласов сигнал, изпращат данни за математическия модел, така че сигналът да може да бъде генериран в приемащата станция.

Използването на устройства за кодиране и декодиране добавя допълнително закъснение към общото време, необходимо за доставката на гласовите пакети:

36

• компресиращият хардуер предизвиква закъснение, тъй като буферира данните

за да може да оцени конкретните гласови сегменти • компресиращият хардуер предизвиква допълнително закъснение, тъй като

извършва действителните изчисления, необходими за компресиране на речта. За да бъде намалено влиянието на това закъснение, трябва да бъде намерен баланс между качеството на гласа и използваната лента. Този баланс е уникален за всяко конкретно приложение на смес от глас и данни, и е различен за различните приложни среди.

Стандартизираните от ITU-T най-популярни кодеци за телефония и предаване на глас чрез пакети са:

• G.711 – PCM техника за кодиране на некомпресиран гласов сигнал със скорост 64 kbit/s. Основен формат за предаване на глас в обществените и частни телефонни мрежи. Тази скорост е напълно във възможностите на LAN, но не е оптимална за предаване извън границите на локалната мрежа. Този стандарт осигурява качество на речта, отговарящо на изискванията за междуселищни връзки (toll-quality). Всички терминали H.323 трябва да поддържат реч, кодирана съгласно G.711.

• G.726 – ADPCM техника, осигуряваща скорости от 40, 32, 24, или 16 kbit/s. Използва се от мрежи за пакетно предаване на глас и от някои частни мрежи или PBXs, така че е възможно да се разменя гласов трафик между тях

• G.728 – компресия на глас чрез CELP с малка вариация на закъснението, осигуряваща 16 kbit/s. Кодираният с CELP глас може да бъде транскодиран в G.711 формат, така че да може да бъде предаван през телефонните мрежи

• G.723.1 - част от фамилията стандарти H.324, осигурява две скорости - 5.3 и 6.4 kbit/s. По-високата скорост използва технологията MP-MLQ и осигурява по-добро качество, докато по-ниската скорост използва CELP, има добро качество и предоставя допълнителна гъвкавост за системното проектиране. Стандартът е избран като подразбиращ се (default) кодер за IP телефония от International Multimedia Teleconferencing Consortium (IMTC) VoIP Forum. Реализациите на този стандарт, обаче, може да натоварват значително процесора на терминала. Това може да повлияе отрицателно върху по-широкото разпространение на стандарта.

• G.729 – CELP компресия с 8 kbit/s. Двата варианта на този стандарт(G.729 и G.729 Annex A) се различават съществено по отношение на изчислителната сложност, като и двата осигуряват качество на речта съпоставимо с това на ADPCM с 32 kbit/s. Този стандарт е избран от IMTC VoIP Forum като алтернативен подразбиращ се кодер за IP телефония.

Тъй като устройствата за кодиране и декодиране във все по-голяма степен разчитат на субективни техники за компресия, такива стандартни параметри за качество като общи хармонични изкривявания или отношение сигнал/шум се заменят от субективни методи за оценка на качеството на кодека. Общоприет еталонен тест (benchmark) за оценка на гласов кодек са средните точки за оценка (MOS – mean opinion score). Важно е при оценката да бъдат осигурени голямо разнообразие от слушатели и материали за оценка. Всеки слушател дава на представения еталонен материал оценка от 1 (лош) до 5 (отличен). След това оценките се осредняват за да се получи MOS. При този начин на тестване се използва за оценка на влиянието на различни странични фактори, като ниво на окръжаващия шум, брой на последователните кодирания и декодирания и т.н.,

37

върху работата на конкретния кодек. Тези данни служат за база за сравнение с други кодеци.

Оценката MOS за няколко различни ITU-T кодеци е посочена в следващата таблица, където те са сравнени със стандартната PCM.

Bit Rate (kbps)

Processing 1 (MIPS)

Framing Size MOS Score

G.711 PCM 64 0.34 0.125 4.1 G.726 ADPCM 32 14 0.125 3.85 G.728 LD-CELP 16 33 0.625 3.61 G.729 CS-ACELP 8 20 10 3.92 G.729 x2 Encodings 8 20 10 3.27 G.729 x3 Encodings 8 20 10 2.68 G.729a CS-ACELP 8 10.5 10 3.7 G.723.1 MP-MLQ 6.3 16 30 3.9 G.723.1 ACELP 5.3 16 30 3.65 1 MIP – обработваща мощност за Texas Instruments 54x DSPs Тази таблица дава полезна информация за сравнение. Сложността на обработката е посочена в милиони инструкции за секунда (MIPS) и е оценка за натоварването на крайното устройство. Като правило по-високата оценка е свързана или с по-сложен кодек, или с по-широка лента. Цитирани източници:

1. FRF.11 Voice over Frame Relay Implementation Agreement 2. FRF.12 Frame Relay Fragmentation Implementation Agreement 3. RFC 3550 RTP: A Transport Protocol for Real-Time Applications H.

Schulzrinne, S. Casner, R. Frederick, V. Jacobson [ July 2003 ] (Obsoletes RFC1889)

4. RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control H. Schulzrinne, S. Casner [ July 2003 ] (Obsoletes RFC1890)

5. RFC 2030 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI D. Mills [ October 1996 ] (Obsoletes RFC1769)

6. RFC 2326 Real Time Streaming Protocol (RTSP) H. Schulzrinne, A. Rao, R. Lanphier [ April 1998 ]

7. RFC 3640 RTP Payload Format for Transport of MPEG-4 Elementary Streams [ November 2003 ]

8. RFC 3558 RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV) [ July 2003 ]

9. RFC 3557 RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding [ July 2003 ]

10. RFC 3555 MIME Type Registration of RTP Payload Formats [July 2003] 11. RFC 3497 RTP Payload Format for Society of Motion Picture and Television

Engineers (SMPTE) 292M Video [ March 2003 ] 12. RFC 3389 Real-time Transport Protocol (RTP) Payload for Comfort Noise

(CN) [ September 2002 ] 13. RFC 3267 Real-Time Transport Protocol (RTP) Payload Format and File

Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs [ June 2002 ]

38

14. RFC 3190 RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio [ January 2002 ]

15. RFC 3189 RTP Payload Format for DV (IEC 61834) Video [ January 2002 ] 16. RFC 3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio [ June

2001 ] 17. RFC 3047 RTP Payload Format for ITU-T Recommendation G.722.1 [ January

2001 ] 18. RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual Streams [

November 2000 ] 19. RFC 2862 RTP Payload Format for Real-Time Pointers [ June 2000 ] 20. RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony

Signals [ May 2000 ] 21. RFC 2793 RTP Payload for Text Conversation [ May 2000 ] 22. RFC 2736 Guidelines for Writers of RTP Payload Format Specifications [

December 1999 ] 23. RFC 2733 An RTP Payload Format for Generic Forward Error Correction [

December 1999 ] 24. RFC 2658 RTP Payload Format for PureVoice(tm) Audio [ August 1999 ] 25. RFC 2435 RTP Payload Format for JPEG-compressed Video [ October 1998 ] 26. RFC 2431 RTP Payload Format for BT.656 Video Encoding [ October 1998 ] 27. RFC 2429 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263

Video (H.263+) [ October 1998 ] 28. RFC 2343 RTP Payload Format for Bundled MPEG [ May 1998 ] 29. RFC 2250 RTP Payload Format for MPEG1/MPEG2 Video [ January 1998 ]

(Obsoletes RFC2038) 30. RFC 2198 RTP Payload for Redundant Audio Data [ September 1997 ] 31. RFC 2190 RTP Payload Format for H.263 Video Streams [ September 1997 ] 32. RFC 2032 RTP Payload Format for H.261 Video Streams [ October 1996 ] 33. RFC 2029 RTP Payload Format of Sun's CellB Video Encoding [ October

1996 ]

39