69794

ТЕХНІЧНА РЕАЛІЗАЦІЯ IP-ТЕЛЕФОНІЇ

Дипломная

Информатика, кибернетика и программирование

Основа телефонної мережі - комутаційні станції, почавши свій шлях з ручних комутаторів, замінялися поступово на декадно-крокові, потім координатні. Великий стрибок у галузі електронних компонентів в 70-ті роки призвів до життя АТС принципово нового виду - електронних станцій,...

Украинкский

2014-10-10

538.9 KB

12 чел.

31

Зміст

ВСТУП 2

1 ТЕХНІЧНА РЕАЛІЗАЦІЯ IP-ТЕЛЕФОНІЇ 3

1.1 Визначення IP-телефонії 3

1.2 Види з’єднань в мережі IP-телефонії 6

1.3 Побудова мережі IP-телефонії 8

1.3.1 Побудова мережі за рекомендацією H.323 8

1.3.2 Мережа на базі протоколу SIP 10

1.4 Вплив мережі на показники якості IP-телефонії 12

2 ОГЛЯД ПРОТОКОЛІВ IP-ТЕЛЕФОНІЇ 15

2.1 Протокол IP 15

2.2 Протокол UDP 17

2.3 Протокол TCP 18

2.4 Протокол RTP 20

2.5 Стандарт H.323 22

2.6 Протокол SIP 24

2.7 Протокол MGCP 25

2.8 Протоколи кодування мовної інформації 27

2.8.1 Кодек G.711 27

2.8.2 Кодек G.723.1 27

2.8.3 Кодек G.726 27

2.8.4 Кодек G.728 27

2.8.5 Кодек G.729 28

2.8.6 Кодеки, стандартизовані ETSI 28

2.9 Протокол RSVP 29


ВСТУП

Розвиток людського суспільства нерозривно пов'язано з технічним прогресом і вдосконалення в області телекомунікацій грають у сучасному світі одну з основних ролей. З'явившись в кінці дев'ятнадцятого століття, засоби зв'язку пройшли великий шлях розвитку. Основа телефонної мережі - комутаційні станції, почавши свій шлях з ручних комутаторів, замінялися поступово на декадно-крокові, потім координатні. Великий стрибок у галузі електронних компонентів в 70-ті роки призвів до життя АТС принципово нового виду - електронних станцій, які і є домінуючими на телефонних мережах України і всього світу. Прискорюються процеси глобалізації, вибуховий розвиток мережі Internet, конвергенція всіх інформаційних потоків ставить перед сучасною телефонією такі завдання, вирішити які традиційні системи з комутацією каналів не можуть в силу принципових обмежень. Однак завдання ставляться і їх потрібно виконувати, і в кінці дев'яностих років двадцятого століття світу був показаний спадкоємець традиційних АТС - шлюз IP- телефонії - гібрид телефонії і пакетної передачі даних. Перші шлюзи були дуже невеликі і могли забезпечувати лише кілька розмов одночасно, чим нагадували перші телефонні комутатори на зорі свого розвитку. Минуло кілька років, шлюзи удосконалювалися і на даний момент поширення набувають пристрої ємністю в кілька цифрових потоків Е1. Деякі лідери телекомунікацій, такі як NORTEL або CISCO заявляють про масштабованості своїх вузлів IP- телефонії до 200 тисяч портів (каналів), а це вже є серйозним операторським рішенням, що показує зрілість даної технології.

1 ТЕХНІЧНА РЕАЛІЗАЦІЯ IP-ТЕЛЕФОНІЇ

1.1 Визначення IP-телефонії

Стрімкий розвиток Internet-технологій привів до появи безлічі додаткових сервісів. Одним з таких сервісів є IP-телефонія і за твердженням багатьох джерел вона скоро витіснить традиційну телефонію. Під IP-телефонією розуміється технологія, що дозволяє використовувати Internet для ведення міжнародних і міжміських телефонних розмов, а також передачі факсів в режимі реального часу.

IP-телефонія об'єднує телефонні мережі і мережі передачі даних в єдину комунікаційну мережу, яка пропонує могутній і економічний засіб зв'язку.

Тепер прийшов час роз'яснити, як же точно сформулювати визначення «IP–телефонія».

В першу чергу IP-телефонія це - технологія передачі мови (голосових даних) по мережі з використанням протоколів TCP/IP. Термінологія для позначення даної технології: VоIP (від Voice over IP). Сама технологія складається з двох частин:

- передача мовної інформації по мережах з комутацією пакетів по IP-мережах;

- протоколів сигналізації і управління викликами.

Передача мовної інформації здійснюється за допомогою стека протоколів RTP/UDP/IP (Real Time Protocol). Існує декілька протоколів для передачі сигналізації і управління, всі вони працюють і розвиваються: H.323, Session Initiation Protocol (SIP), Media Gatewaycontrol Protocol (MGCP), MEGACO/H.248 та інші.

Друге з близьких для нас зараз понять про IP–телефонію: комп'ютерна телефонія, що являє собою методи обробки, зберігання і передачі мовної інформації. Причому це одна з найпростіших і доступніших технологій вже набула широкого поширення, як у працівників крупних компаній, так і у домашніх користувачів.

І, нарешті, третє визначення IP–телефонії: Інтернет – телефонія, це застосування VоIP технології для передачі голосових даних з найменшими фінансовими витратами через мережу, доступну багатьом користувачам Internet. Таким чином, це визначення є вторинним і використовується як правило в комерційних цілях компаніями, що надають можливість спілкування за допомогою своїх каналів зв'язку і мережі Internet.

Інтернет-телефонія окремий випадок IP-телефонії, тут як лінії передачі використовуються звичайні канали Internet. У чистому вигляді IP-телефонія, як лінії передачі телефонного трафіку використовує виділені цифрові канали.

Але оскільки Інтернет-телефонія виходить з IP-телефонії, то ми застосовуватимемо для неї обидва ці терміни.

У мережах пакетної комутації по каналах зв'язку передаються одиниці інформації, що не залежать від фізичного носія. Такими одиницями можуть бути пакети, кадри або осередки (залежно від протоколу), але в кожному разі вони передаються по розділеній мережі, більше того – по окремих віртуальних каналах, не залежних від фізичного середовища. Кожен пакет ідентифікується заголовком, який може містити інформацію про використовуваний ним канал, його походження (тобто про джерело або відправника) та пункті призначення (про одержувача або отримувача).

У мережах на основі IP всі дані - голос, текст, відео, комп'ютерні програми або інформація в будь-який інший формі - передаються у вигляді пакетів. Будь-який комп'ютер і термінал такої мережі має свою унікальну IP - адресу, і передаванні пакети маршрутизуються до одержувача відповідно до цієї адреси, яка вказана в заголовку. Дані можуть передаватися одночасно між багатьма користувачами і процесами по одній і тій же лінії. При виникненні проблем IP-мережі можуть змінювати маршрут для обходу несправних ділянок. При цьому протокол IP не вимагає виділеного каналу для сигналізації.

Процес передачі голосу по IP-мережі складається з декількох етапів.

На першому етапі здійснюється оцифровка голосу. За тим оцифровані дані аналізуються і обробляються з метою зменшення фізичного обсягу даних, переданих одержувачу. Як правило, на цьому етапі відбувається придушення непотрібних пауз і фонового шуму , а також компресування.

На наступному етапі отримана послідовність даних розбивається на пакети і до неї додається протокольна інформація - адреса одержувача, порядковий номер пакету на випадок, якщо вони будуть доставлені не послідовно, і додаткові дані для корекції помилок. При цьому відбувається тимчасове накопичення необхідної кількості даних для утворення пакету до його безпосередньої відправки в мережу.

Витяг переданої голосової інформації з отриманих пакетів так само відбувається в кілька етапів. Коли голосові пакети приходять на термінал одержувача, то спочатку перевіряється їх порядкова послідовність. Оскільки IP - мережі не гарантують час доставки, то пакети із старшими порядковими номерами можуть прийти раніше, більше того, інтервал часу отримання також може коливатися. Для відновлення початкової послідовності і синхронізації відбувається тимчасове накопичення пакетів. Однак деякі пакети можуть бути взагалі втрачені при доставці, або затримка їх доставки перевищує допустимий розкид. У звичайних умовах приймальний термінал запитує повторну передачу помилкових або втрачених даних. Але передача голосу занадто критична до часу доставки, тому в цьому випадку або включається алгоритм апроксимації, що дозволяє на основі отриманих пакетів приблизно відновити втрачені, або ці втрати просто ігноруються, а пропуски заповнюються даними випадковим чином.

Отримана таким чином (не відновлена) послідовність даних декомпресується і перетвориться безпосередньо в аудіо - сигнал, що несе голосову інформацію одержувачу.

Таким чином, з великим ступенем ймовірності, отримана інформація не відповідає вихідній (спотворена) і затримана. Проте в деяких межах надмірність голосової інформації дозволяє миритися з такими втратами.

В даний час в IP-телефонії існує два основних способи передачі голосових пакетів по IP-мережі:

  1. через глобальну мережу Інтернет (Інтернет-телефонія);
  2. використовуючи мережі передачі даних на базі виділених каналів (IP-телефонія).

    У першому випадку смуга пропускання на пряму залежить від завантаженості мережі Інтернет пакетами, що містять дані, голос, графіку і так далі, а значить, затримки при проходженні пакетів можуть бути самими різними. При використанні виділених каналів виключно для голосових пакетів можна гарантувати фіксовану (або майже фіксовану) швидкість передачі.

    Для того, щоб здійснити міжміський (міжнародний) зв'язок за допомогою телефонних серверів, організація повинна мати по серверу в тих місцях, куди і звідки плануються дзвінки.

    Загальний принцип дії телефонних серверів (шлюзів) Інтернет - телефонії такий: з одного боку, сервер пов'язаний з телефонними лініями і може з'єднуватися з будь-яким телефоном світу .

З іншого боку, сервер пов'язаний з Інтернетом і може зв'язатися з будь-яким комп'ютером в світі. Сервер приймає стандартний телефонний сигнал, оцифровує його (якщо він початково не цифровий), значно стискає, розбиває на пакети і відправляє через Інтернет з використанням протоколу IP. Для пакетів, що приходять з мережі на телефонний сервер і що йдуть в телефонну лінію, операція відбувається в зворотному порядку.

Обидві складові операції (вхід сигналу в телефонну мережу і його вихід з телефонної мережі) відбуваються практично одночасно, що дозволяє забезпечити повнодуплексну розмову. На основі цих базових операцій можна побудувати багато різних конфігурацій. Наприклад, дзвінок «телефон - комп'ютер» або «комп'ютер - телефон» може забезпечувати один телефонний сервер.

    Основним стримуючим фактором на шляху масштабного впровадження IP-телефонії є відсутність у протоколі IP механізмів забезпечення гарантованої якості послуг, що робить його поки не найнадійнішим транспортом для передачі голосового трафіку. Сам протокол IP не гарантує доставку пакетів, а так же час їх доставки, що викликає такі проблеми, як «рваний голос» і просто провали в розмові. Сьогодні ці проблеми вирішуються: організації по стандартизації розробляють нові протоколи, виробники випускають нове обладнання, але на цьому рівні справи з сумісністю і стандартизацією йдуть вже не так добре, як з «упаковкою» промови в пакети. Зауважимо, що в рамках приватної корпоративної мережі деяка втрата якості голосового зв'язку при сильній завантаженості ресурсів цілком прийнятна за умови, що середній показник буде цілком задовільним.

    З точки зору масштабованості IP - телефонія видається цілком закінчених рішенням. По - перше, оскільки з'єднання на базі протоколу IP може починатися (і закінчуватися) в будь-якій точці мережі від абонента до магістралі. Відповідно, IP - телефонію можна вводити ділянка за ділянкою, що добре з точки зору міграції, так як її можна проводити «зверху вниз», «знизу вгору» або за якоїсь іншої схеми. Для рішень IP-телефонії характерна певна модульність: кількість і потужність різних вузлів - шлюзів, gatekeeper («контролер зони» - сервер обробки номерних планів) - можна нарощувати практично незалежно, відповідно до поточних потреб .

1.2 Види з’єднань в мережі IP-телефонії

Мережі IP - телефонії надають можливості для з'єднань користувачів чотирьох основних типів:

  1. «Від телефону до телефону», як показано на рис. 1.1. Виклик йде із звичайного телефонного апарату до АТС, на один з виходів якої підключений шлюз IP-телефонії, і через IP-мережу доходить до іншого шлюзу, який здійснює зворотні перетворення.

Рисунок 1.1 – Схема зв’язку «телефон – телефон»

(http://rudocs.exdat.com/pars_docs/tw_refs/539/538946/538946_html_395ce77e.png)

  1. «Від комп'ютера до телефону», як показано на малюнку 1.2. Мультимедійний комп'ютер, що має програмне забезпечення IP-телефонії, звукову плату (адаптер), мікрофон і акустичні системи, підключається до IP-мережі або до мережі Інтернет, і з іншого боку шлюз IP-телефонії має сполучення через АТС із звичайним телефонним апаратом.

Слід зазначити, що у з'єднаннях 1 і 2 типів замість телефонних апаратів можуть бути включені факсимільні апарати, і в цьому випадку мережа IP-телефонії повинна забезпечувати передачу факсимільних повідомлень.

Рисунок 1.2 - Схема зв’язку «комп’ютер – телефон»

(http://rudocs.exdat.com/pars_docs/tw_refs/539/538946/538946_html_m369d77da.png)

  1. «Від комп'ютера до комп'ютера», як показано на малюнку 1.3. У цьому випадку з'єднання встановлюється через IP-мережу між двома мультимедійними комп'ютерами, обладнаними апаратними та програмними засобами для роботи з IP-телефонією.

Рисунок 1.3 - Схема зв’язку «комп’ютер – комп’ютер»

(http://rudocs.exdat.com/pars_docs/tw_refs/539/538946/538946_html_m5de7f587.png)

  1. «Від WEB браузера до телефону», як показано на малюнку 1.4. З розвитком мережі Інтернет став можливим доступ і до мовних послуг. Наприклад, на WEB-сторінці компанії в розділі «Контракти» розміщується кнопка «Виклик», натиснувши на яку можна здійснити мовне з'єднання з представником даної компанії без набору телефонного номера.

Рисунок 1.4 - Схема зв’язку «WEB браузер – телефон»

(http://rudocs.exdat.com/pars_docs/tw_refs/539/538946/538946_html_15f110cf.png)

1.3 Побудова мережі IP-телефонії

1.3.1 Побудова мережі за рекомендацією H.323

Мережа IP-телефонії (згідно рекомендаціям ITU H.323) являє собою набір наступних пристроїв, сполучених по IP-мережі, рис. 1.5:

- термінал (Terminal);

- шлюз (gateway);

- контролер зони (gatekeeper);

- пристрій керування конференціями (Multipoint Control Unit-MCU).

Термінал Н.323 - кінцевий пристрій користувача мережі IP-телефонії, який забезпечує двосторонній мовний (мультимедійний) зв'язок з іншим терміналом Н.323, шлюзом або пристроєм управління конференціями.

Шлюз IP-телефонії реалізує передачу мовного трафіку по мережах з маршрутизацією пакетів IP по протоколу Н.323. Основне призначення шлюзу - перетворення мовної інформації, що поступає з боку ТМЗК, у вигляд, придатний для передачі по мережах з маршрутизацією пакетів IP. Крім того, шлюз перетворює сигнальні повідомлення систем сигналізації DSS1 і ЗКС7 в сигнальні повідомлення Н.323 і виробляє зворотне перетворення, відповідно до Рекомендації ITU H.246.

Рисунок 1.5 – Архітектура мережі H.323

(http://wiki.kspu.kr.ua/images/b/b5/VoIP_1.5.png)

У контролері зони зосереджений весь інтелект мережі IP-телефонії. Мережа, побудована відповідно до рекомендації Н.323, має зонну архітектуру, рис. 1.6. Контролер зони виконує функції управління однією зоною мережі IP-телефонії, в яку входять: термінали, шлюзи, пристрої керування конференціями, зареєстровані у даного контролера зони. Окремі фрагменти зони мережі Н.323 можуть бути територіально рознесені і з'єднуватися один з одним через маршрутизатори.

Рисунок 1.6 – Зона мережі H.323

(http://wiki.kspu.kr.ua/images/1/16/VoIP_1.6.png)

Найбільш важливими функціями контролера зони є:

  1. реєстрація кінцевих та інших пристроїв;
  2. контроль доступу користувачів системи до послуг IP-телефонії за допомогою сигналізації RAS;
  3. контроль, управління і резервування пропускної здатності мережі;
  4. ретрансляція сигнальних повідомлень Н.323 між терміналами.

В одній мережі IP-телефонії, що відповідає вимогам рекомендації ITU Н.323, може знаходитися декілька контролерів зон, що взаємодіють один з одним по протоколу RAS.

Крім основних функцій, визначених рекомендацією Н.323, контролер зони може відповідати за аутентифікацію користувачів і нарахування плати (біллінг) за телефонні з'єднання.

Пристрій управління конференціями забезпечує можливість організації зв'язку між трьома або більше учасниками. Рекомендація Н.323 передбачає три види конференції, рис. 1.7:

  1. централізована (тобто керована MCU, з яким кожен учасник конференції з'єднується в режимі точка-точка);
  2. децентралізована (коли кожен учасник конференції з'єднується з іншими її учасниками в режимі точка-група точок);
  3. змішана.

Рисунок 1.7 – Види конференції в мережах H.323

(http://wiki.kspu.kr.ua/images/3/31/VoIP_1.7.png)

1.3.2 Мережа на базі протоколу SIP

Мережа на базі протоколу SIP містить основні елементи трьох видів, рис. 1.8: агенти користувача, проксі-сервери і сервери переадресації. Агенти користувача (User Agent або SIP client) є додатками термінального обладнання і включають в себе дві складові: агент користувача - клієнт (User Agent Client - UAC) і агент користувача - сервер (User Agent Server - UAS), інакше відомі як клієнт і сервер відповідно. Клієнт UAC ініціює SIP-запити, тобто виступає в якості зухвалої сторони. Сервер UAS приймає запити і повертає відповіді, тобто виступає в якості викликається сторони.

Рисунок 1.8 – Архітектура мережі на базі протоколу SIP

(http://wiki.kspu.kr.ua/images/e/e2/VoIP_1.9.png)

Крім того, існує два типи мережевих серверів SIP: проксі-сервери (сервери-посередники) і сервери переадресації. Сервери SIP можуть працювати як в режимі зі збереженням станів поточних з'єднань (statefull), так і в режимі без збереження станів поточних з'єднань (stateless). Сервер SIP, що функціонує в режимі stateless, може обслужити як завгодно велику кількість користувачів, на відміну від контролера зони Н.323, який може одночасно працювати з обмеженою кількістю користувачів.

Проксі-сервер (Proxy-server) діє «від імені інших клієнтів» і містить функції клієнта (UAC) і сервера (UAS). Цей сервер інтерпретує і може перезаписувати заголовки запитів перед відправленням їх до інших серверів рис. 1.9. Відповідні повідомлення слідують по тому ж шляху назад до проксі-сервера, а не до клієнта.

Рисунок 1.9 – Мережа SIP з проксі-сервером

(http://wiki.kspu.kr.ua/images/d/d0/VoIP_1.10.png)

1.4 Вплив мережі на показники якості IP-телефонії

Якість зв’язку можна оцінити за наступними основними характеристиками:

  1. рівень спотворення голосу;
  2. частота "зникання" голосових пакетів;
  3. час затримки (між вимовленням фрази першого абонента і моментом, коли вона буде почута другим абонентом).

Втрачені пакети в IP-телефонії порушують мову і створюють спотворення тембру. У існуючих IP-мережах всі голосові кадри обробляються як дані. При пікових навантаженнях і перевантаженнях голосові кадри відкидатимуться, як і кадри даних. Проте кадри даних не зв'язані з часом і відкинуті пакети можуть бути успішно передані шляхом повторення. Втрата голосових пакетів, у свою чергу, не може бути заповнена у такий спосіб і в результаті відбудеться неповна передача інформації. Передбачається, що втрата до 5% пакетів непомітна, а понад 10-15% — недопустима. Причому дані величини істотно залежать від алгоритмів компресії/декомпресії.

На рис. 1.10 показано основні складові затримки в мережі IP-телефонії.

Час затримки при передачі мовного сигналу можна віднести до одного з трьох рівнів:

  1. перший рівень до 200 мс — відмінна якість зв'язку. Для порівняння, в телефонній мережі загального користування допустимі затримки до 150–200 мс;
  2. другий рівень до 400 мс — вважається хорошою якістю зв'язку. Якщо затримки постійно утримується на верхній межі 2-го рівня (на 400 мс), то не рекомендується використовувати цей зв'язок для ділових переговорів;
  3. третій рівень до 700 мс — вважається прийнятною якістю зв'язку для ведення неділових переговорів. Така якість зв'язку можлива також при передачі пакетів по супутниковому зв'язку. 

Рисунок 1.10 - Складові затримки в мережі IP-телефонії

(http://www.mini-server.ru/images/stories/knigi/ip-phone/image073.jpg)

Фактори, що вливають на якість, можуть бути поділені на дві категорії:

  1. Фактори якості IP-мережі:
  2. максимальна пропускна здатність - максимальна кількість корисних і надлишкових даних, які вона передає;
  3. затримка - проміжок часу, необхідний для передачі пакета через мережу;
  4. джитер - затримка між двома послідовними пакетами;
  5. втрата пакета - пакети або дані, втрачені при передачі через мережу.
  6. Фактори якості шлюзу:
  7. необхідна смуга пропускання - різні вокодери вимагають різну смугу. Наприклад, вокодер G.723 вимагає смуги 16,3 кбіт/с для кожного мовного каналу;
  8. затримка - час, необхідний для цифрового сигнального процесора DSP або інших пристроїв обробки для кодування і декодування мовного сигналу;
  9. буфер джитера - збереження пакетів даних до тих пір, поки всі пакети не будуть отримані і можна буде передати їх в необхідній послідовності для мінімізації джитера;
  10. втрата пакетів - втрата пакетів при стисненні і/або передачі в обладнанні IP-телефонії;
  11. придушення відлуння - механізм для придушення відлуння, що виникає при передачі по мережі;
  12. управління рівнем - можливість регулювати гучність мови.

Поліпшення кодування голосу і відновлення втрачених пакетів дозволило досягти рівня, коли мова розуміється абонентами настільки добре, що співбесідники не здогадуються, що з'єднання відбувається за технологією IP -телефонії. Зрозуміло, що затримки впливають на темп бесіди. Відомо, що для людини затримка до 250 мілісекунд практично непомітна. Для IP-телефонії існують на сьогоднішній день рішення, що не перевищують цю межу, так що розмова фактично не відрізняється від зв'язку по звичайній телефонній мережі.


2 ОГЛЯД ПРОТОКОЛІВ IP-ТЕЛЕФОНІЇ

2.1 Протокол IP

Протокол IP (Internet Protocol) описаний у документі RFC 791. Цей протокол власне і реалізує механізм проходження інформації по мережі, він спеціально обмежений задачами забезпечення передачі дейтаграм від відправника до одержувача через розподілену мережу. Дейтаграмою називають блоки для передачі даних. Крім цього, протокол IP забезпечує при необхідності функції фрагментації і збірки дейтаграм при передачі в розподілених мережах з різними розмірами кадрів. Протокол IP позбавлений механізмів підвищення достовірності передачі даних, управління протоколом, синхронізації та інших послуг, які звичайно застосовуються в протоколах більш високого рівня. Протокол IP отримує інформацію для передачі від протоколів більш високого рівня, таких як TCP і UDP, а потім передає її через розподілену мережу, використовуючи сервіси локальних мереж. Протокол IP виконує кілька основних функцій:

  1. Визначає базовий елемент передачі даних - дейтаграмму, її формат, значення полів у заголовку;
  2. Проводить фрагментацію дейтаграми та її складання;
  3. Виконує ненадійну доставку дейтаграми одержувачу;
  4. Забезпечує логічну адресацію пристроїв у мережі;
  5. Реалізує підтримку маршрутизації.

На рис. 2.1, наведено структуру IP-пакету, який складається з даних протоколу верхнього рівня і заголовку. За специфікацією протоколу, пакет має бути не більший за 65535 бітів (з заголовком та даними включно).

Рисунок 2.1 – Структура IP-пакета

(http://uk.wikipedia.org/wiki/IP)

Розглянемо кожне поле IP-пакету:

  1. Версія (Version) — 4-бітове поле, що описує використовувану версію протоколу IP. Всі пристрої зобов'язані використовувати протокол IP однієї версії, пристрій що використовує іншу версію буде відкидати пакети;
  2. Довжина IP-заголовку (IP header Length — HLEN) — 4-бітове поле, що описує довжину заголовку пакету в 32-бітових блоках. Це значення — це повна довжина заголовку з врахуванням двох полів змінної довжини;
  3. Тип обслуговування (Type of Service — TOS) — 8-бітове поле, що вказує на ступінь важливості інформації, що привласнена протоколом верхнього рівня;
  4. Загальна довжина (Total Length) — 16-бітове поле, що описує довжину пакету в байтах, із заголовком та даними включно. Для того щоб вирахувати довжину блока даних, потрібно від повної довжини відняти значення поля HLEN;
  5. Ідентифікація (Identification) — шістнадцятибітове поле, що зберігає ціле число, яке описує даний пакет. Це число являє собою послідовний номер;
  6. Флаги (Flags) — 3-бітове поле, в якому два молодших біта контролюють фрагментацію пакетів. Перший біт визначає чи було пакет фрагментовано, а другий чи є цей пакет останнім фрагментом в серії фрагментів;
  7. Зміщення фрагментації (Fragment Offset) — 13-бітове поле, що допомагає зібрати разом фрагменти пакетів. Це поле дозволяє використовувати 16 бітів в сумі для прапорів фрагментації;
  8. Час життя (Time-to-Live — TTL) — 8-бітове поле — лічильник, в якому зберігаються послідовно зменшуване значення кількості пройдених вузлів (роутетів, що їх ще іноді в цьому випадку називають хопами(hops)) на шляху до місця призначення. У випадку коли лічільник пройдених хопів дорівнюватиме нулю — пакет буде відкинуто, таким чином попереджується нескінченна циклічна пересилка пакетів;
  9. Протокол (Protocol) — 8-бітове поле, що вказує на те, який протокол верхнього рівня отримає пакет, після завершення обробки IP-протоколом. Наприклад TCP або UDP;
  10. Контрольна сума заголовку (Header Checksum) — 16-бітове поле, що допомагає перевірити суцільність заголовку пакету;
  11. IP-адреса відправника (Source IP address) (адресант, сорс, відправник) — 32-бітове поле, що зберігає IP-адресу вузла-відправника;
  12. IP-адреса отримувача (Destination IP adress) (адресат, дест, отримувач) — 32-бітове поле, що зберігає адресу вузла призначення (отримувача);
  13. Опції (Options) — поле змінної довжини, що дозволяє протоколу IP реалізувати підтримку різних опцій, зокрема засобів безпеки;
  14. Підкладка (Padding) — поле, що використовується для вставки додаткових нулів, для гарантування кратності IP-заголовку 32 бітам;
  15. Дані (Data) — поле змінної довжини (64 Кбіт макс.), що зберігає інформації для верхніх рівнів.

Хоча основною частиною заголовку є адреси відправника і призначення, саме інші частини заголовку роблять протокол таким надійним і гнучким. Інформація, що зберігається в полях заголовку задає дані пакету і призначена для протоколів верхніх рівнів.

2.2 Протокол UDP

Протокол дейтаграм користувача UDP (User Datagram Protocol) описаний у документі RFC 768. Він надає прикладним програмам транспортні послуги. Протокол UDP, також як і IP, забезпечує негарантовану доставку дейтаграм одержувачу і не підтримує установку сполук. Взаємодія між прикладними програмами і протоколом UDP здійснюється через протокольні порти. Протокольний порт можна визначити як абстрактну точку призначення конкретної прикладної програми, що на конкретному комп'ютері або мережному пристрої. У стеці протоколів TCP/IP, порт це механізм, що дозволяє робочій станції одночасно підтримувати кілька сеансів зв'язку з віддаленими пристроями та їх програмами. Можна сказати, що порт служить для вказівки одержувача інформації. Коли робоча станція отримує з мережі пакет, в якому вказана її IP адреса, вона може направити пакет певною програмою, використовуючи унікальний номер порту, який визначається під час установки сеансу зв'язку.

    Слід зазначити що порти протоколів TCP і UDP розрізняються програмним забезпеченням робочих станцій та інших мережевих пристроїв. Дейтаграма протоколу UDP складається з двох частин: заголовка і області даних. Заголовок складається з чотирьох 16 бітних полів, які визначають порт відправника, порт одержувача, довжину повідомлення і контрольну суму. На рис. 2.2, показаний формат полів у дейтаграмі протоколу.

Рисунок 2.2 – Структура UDP-пакета

(http://uk.wikipedia.org/wiki/UDP)

Поля "Початковий номер порту" і "Номер порту призначення" містять 16 бітні номери портів. Отже 216 = 65535 значень унікальних номерів портів можна адресувати при пересиланні даних за допомогою протоколу UDP. Поле "Початковий номер порту" може бути не використано, при цьому воно повинно містити нулі.

    Поле "Довжина" містить 16 бітів в дейтаграмі, при цьому враховується довжина заголовків UDP і даних.

    Поле "Контрольна сума" може обчислюватися, а може і ні. Якщо контрольна сума не обчислюється, її значення дорівнює 0. Обчислення цього поля не здійснюється при роботі UDP в високонадійній локальної мережі. При роботі в ненадійній мережі тільки контрольна сума може вказати на достовірність і цілісність даних, що прийшли. Це пов'язано з тим, що протокол IP не вирахував контрольну суму поля даних в IP дейтаграмах.

    Порти з нумерацією від 0 до 1023 називаються керованими і жорстко пов'язані з певними програмними процесами. Порти з номерами від 1023 до 65535 називають динамічними, і мережеве програмне забезпечення саме визначає необхідний для роботи порт в даний час. Фактично, навіть у цьому діапазоні багато номерів портів уже прив'язані до конкретних програм, які отримали широке поширення. Все вищесказане також відноситься і до портів протоколу TCP.

2.3 Протокол TCP

Протокол управління передачею TCP описаний в RFC 793. Він призначений для використання в якості надійного транспортного засобу при спілкуванні віддалених систем в локальних мережах з комутацією пакетів, а так само в системах, які об'єднують такі мережі. Протокол TCP так само як і протокол UDP працює на транспортному рівні моделі OSI. Він забезпечує надійне транспортування даних між прикладними програмами шляхом встановлення логічного з'єднання, чим і відрізняється від свого побратима UDP. Для забезпечення надійної передачі даних за встановленим логічним з'єднанням між парами прикладних програм протокол TCP повинен забезпечувати виконання таких функцій:

  1. передачу необхідних даних;
  2. підтримання достовірності даних при передачі;
  3. управління потоком даних;
  4. розподіл каналів зв'язку;
  5. роботу з обслуговування встановлених з'єднань;
  6. забезпечення встановленого пріоритету користувачів і відповідного рівня безпеки.

Процес з'єднання можна представити в наступній послідовності:

  1. ініціатор з'єднання надсилає запит до протоколу TCP на відкриття порту для передачі;
  2. після відкриття порту протокол TCP на стороні додатку-ініціатора надсилає запит додатком, з яким потрібно встановити з'єднання;
  3. протокол TCP на приймальній стороні відкриває порт для прийому даних і відсилає квитанцію, що підтверджує прийом запиту;
  4. приймальна сторона відкриває порт для передачі і так само передає запит до протилежної сторони;
  5. додаток-ініціатор відкриває порт для прийому і повертає квитанцію.

З цього моменту з'єднання вважається встановленим. Після цього починається обмін інформацією по даному з'єднанню.

Заголовок TCP слідує за заголовком IP і доповнює його інформацією, специфічною для протоколу TCP. На рис. 2.3, представлений формат заголовку протоколу TCP.

Рисунок 2.3 – Формат заголовка TCP

(http://uk.wikipedia.org/wiki/TCP)

Поля "Порт джерела" і "Порт призначення" ідентичні відповідним полям у заголовку протоколу UDP.

Поле "Номер послідовності" визначає номер черги для першого байта даних в цьому сегменті. Винятки становлять випадки, коли присутній прапорець синхронізації SYN.

Поле "Номер підтвердження" містить наступний номер черги, який відправник даної дейтаграми бажає отримати у зворотньому напрямку. При цьому контрольний біт підтвердження ACK повинен бути встановлений. Номери підтвердження надсилаються постійно, як тільки з'єднання буде встановлено.

Поле "Зсув даних" визначає кількість 32-х бітних слів у TCP-заголовку і вказує на початок поля даних. Заголовок протоколу TCP завжди закінчується на 32-х бітному кордоні слова, навіть якщо він містить опції.

Поле "Зарезервовано" обов'язково має бути заповнено нулями.

Поле "Прапорці" (керуючі біти) містить 8 бітових прапорців:

  1.  CWR - gоле встановлюється відправником, щоб показати що TCP-сегмент був отриманий з встановленим полем;
  2.  ECE - Поле показує, що відправник підтримує ECN;
  3.  URG - Поле «Показник важливості» задіяно;
  4.  ACK - Поле «Номер підтвердження» задіяно;
  5.  PSH - інструктує отримувача передати дані з прийомного буферу до програми, якій ці дані призначені;
  6.  RST - обірвати з'єднання, скинути буфер (очищення буферу);
  7.  SYN - синхронізація номерів послідовності;
  8.  FIN - прапорець, якщо встановлений, вказує на завершення з'єднання.

Поле " Вікно" містить оголошуєме значення розміру вікна в байтах.

Поле "Контрольна сума" розраховується по сегменту, при цьому визчається 16-бітове доповнення суми всіх 16 бітних слів заголовка і даних. Якщо сегмент містить непарну кількість байт, то він буде доповнений нулями справа до утворення 16 бітного слова. При цьому вирівнюючий байт не передається разом з сегментом в мережі. Контрольна сума враховує так само 96-бітний псевдозаголовок, який ставитися перед заголовком протоколу TCP. Псевдозаголовок містить адресу відправника, адресу одержувача, тип протоколу і довжину TCP сегмента. Механізм псевдозаголовка забезпечує захист протоколу TCP від спотворення сегментів при передачі.

Поле "Вказівник важливості" визначає зсув даного сегмента щодо номера черги. Цей покажчик повідомляє номер черги для байта, наступного за терміновими даними. Поле використовується спільно з контрольним бітом URG.

Поле "Опції" має змінну довжину і може бути відсутнім взагалі. Воно розташовується в кінці заголовка протоколу TCP, і його довжина кратна восьми бітам. Протокол TCP повинен бути готовий обробляти всі види опцій. Опції використовуються для вирішення допоміжних завдань, наприклад при виборі максимального значення розміру сегмента.

2.4 Протокол RTP

Протокол RTP (англ. Real-time Transport Protocol) працює на транспортному рівні і використовується при передачі трафіку реального часу. Протокол був розроблений Audio-Video Transport Working Group в IETF і вперше опублікований в 1996 році як RFC 1889, і замінений в RFC 3550 в 2003 році.

Протокол RTP переносить у своєму заголовку дані, необхідні для відновлення голосу та відео на приймальному вузлі, а також дані про тип кодування інформації (JPEG, MPEG і т. п.). В заголовку цього протоколу, зокрема, передаються мітка і номер пакету. Ці параметри дозволяють при мінімальних затримках визначити порядок і час декодування кожного пакета, а також інтерполювати втрачені пакети.

RTP не має стандартного зарезервованого номера порту. Єдине обмеження полягає в тому, що з'єднання проходить з використанням парного номера, а наступний непарний номер використовується для зв'язку з протоколом RTCP. Той факт, що RTP використовує динамічно назначаємі адреси портів, створює йому труднощі для проходження міжмережевих екранів, для обходу цієї проблеми, як правило, використовується STUN-сервер.

Встановлення і розрив з'єднання не входить в список можливостей RTP, такі дії виконуються сигнальним протоколом (наприклад, RTSP або SIP протоколом).

На рис 2.4, наведено структуру RTP-пакета. Пакет RTP - інформаційний пакет, що містить фіксований заголовок. Один пакет транспортного нижнього рівня, наприклад UDP, зазвичай містить один RTP-пакет, але це вимога не є обов'язковим. Поле джерел інформації може бути порожнім.

Рисунок 2.4 – Структура RTP-пакета

(http://uk.wikipedia.org/wiki/RTP)

V - поле версії. Поточна версія - друга.

Р - поле заповнення. Це поле сигналізує про наявність заповнюючих октетів наприкінці корисного навантаження. Заповнення застосовується, коли додаток вимагає, щоб розмір корисного навантаження був кратний, наприклад, 32 бітам. У цьому випадку останній октет вказує число заповнюючих октетів .

Х - поле розширення заголовка. Коли це поле задано, то за основним заголовком слідує ще один додатковий, використовуваний в експериментальних розширеннях RTP.

СС - поле числа відправників. Це поле містить число ідентифікаторів відправників, чиї дані знаходяться в пакеті, причому самі ідентифікатори слідують за основним заголовком.

М - поле маркера. Сенс біта маркера залежить від типу корисного навантаження. Біт маркера використовується зазвичай для позначення меж потоку даних. У випадку відео він задає кінець кадру. У випадку голосу він задає початок промови після періоду мовчання.

РТ - поле типу корисного навантаження. Це поле ідентифікує тип корисного навантаження і формат даних, включаючи стиснення і шифрування. У стаціонарному стані відправник використовує тільки один тип корисного навантаження протягом сеансу, але він може його змінити у відповідь на зміну умов, якщо про це сигналізує протокол управління передачею в реальному часі RTCP.

Порядковий номер - поле порядкового номера. Кожне джерело починає нумерувати пакети з довільного номера, збільшуємого потім на одиницю з кожним посланим пакетом даних RTP. Це дозволяє виявити втрату пакетів і визначити порядок пакетів з однаковою відміткою про час. Декілька послідовних пакетів можуть мати одну і ту ж позначку про час, якщо логічно вони породжені в один і той же момент, як, наприклад, пакети, що належать до одного і того ж відеокадру .

Мітка часу - поле позначки про час. Це поле містить момент часу, в який перший октет даних корисного навантаження був створений. Одиниці, в яких час вказується в цьому полі, залежать від типу корисного навантаження. Значення визначається по локальних годинах відправника.

Synchronization Source (SSRC) Identifier - поле ідентифікатора джерела синхронізації: сгенероване випадковим чином число, унікальним чином ідентифікує джерело протягом сеансу і незалежне від мережевої адреси. Це число грає важливу роль при обробці порції даних, що надійшла від одного джерела.

Contributing Source (CSRC) Identifier - список полів ідентифікаторів джерела, "підмішаних" в основний потік, наприклад, за допомогою мікшера. Мікшер вставляє цілий список SSRC ідентифікаторів джерел, які брали участь у побудові даного RTP-пакета. Цей список і називається CSRC. Кількість елементів у списку: від 0 до 15. Якщо число учасників більше 15 - вибираються перші 15. Прикладом може служити аудіо-конференція, в RTP- пакети якої зібрані промови всіх учасників, кожен зі своїм SSRC – вони то і утворюють список CSRC. При цьому вся конференція має загальний SSRC.

2.5 Стандарт H.323

Набір рекомендацій ITUH.323 визначає мережеві компоненти, протоколи і процедури, що дозволяють організувати мультимедіа-зв'язок в пакетних мережах, в тому числі в ЛОМ Ethernet. Вони визначають порядок функціонування абонентських терміналів у мережах з розподіляючим ресурсом, що не гарантують якості обслуговування QoS. H.323-сумісні пристрої можуть застосовуватися для телефонного зв'язку (IP-телефонія), передачі звуку і відео (відеотелефонія), а також звуку, відео і даних (мультимедійні конференції).

У зв'язку з появою безлічі апаратно-програмних засобів організації телефонного зв'язку по протоколу IP, потрібно було внести зміни у специфікації H.323, так як ці засоби за часту виявлялися не сумісними один з одним. Зокрема, знадобилося забезпечити взаємодію телефонних пристроїв на базі ПК і звичайних телефонів для мереж, що функціонують за принципом комутації каналів. Друга версія H.323, що враховує нові вимоги, була прийнята в січні 1998 року.

Нині готується наступна версія стандарту. У ній будуть описані створення пакетних мереж факсимільного зв'язку та організація зв'язку між H.323 шлюзами. Мова йде і про функції, поширені в сучасній телефонії, включаючи повідомлення про надходження другого виклику і режим довідки. Деякі компанії домагаються включення в H.323 підтримки мультимедіа-можливостей, заснованих на запропонованому IETF протоколі SIP. Крім «телефонних» функцій нова версія буде доповнена засобами, що дозволяють враховувати параметри сеансів для цілей тарифікації, а також підтримкою каталогів - замість цифрових IP-адрес можна буде користуватися іменами абонентів.

Стандарт H.323 входить в сімейство рекомендацій H.32x, що описують порядок організації мультимедіа-зв'язку в мережах різних типів:

  1.  H.320 - вузькосмугові цифрові комутовані мережі, включаючи ISDN;
  2.  H.321 - широкосмугові мережі ISDN і ATM;
  3.  H.322 - пакетні мережі з гарантованою смугою пропускання;
  4.  H.324 - телефонні мережі загального користування.

Одна з основних цілей розробки стандарту H.323 - забезпечення взаємодії з іншими типами мереж мультимедіа-зв'язки. Дане завдання реалізується за допомогою шлюзів , які здійснюють трансляцію сигналізації і форматів даних. Стандарт H.323 дозволяє створити надійні рішення для організації комунікацій по надійним мережам із змінною затримкою. За умови відповідності стандарту пристрої з різними можливостями можуть взаємодіяти один з одним. Наприклад, термінали з відеозасобами можуть брати участь в аудіоконференції . У сукупності з іншими стандартами ITU-Т на мультимедійний зв'язок і телеконференції, рекомендації H.323 застосовні для будь-яких видів з'єднань - від численних до з'єднань «точка-точка».

Стандарт H.323 визначає також порядок взаємодії з кінцевими пристроями інших стандартів. Найбільш часто така задача виникає при сполученні телефонних мереж з комутацією пакетів і комутацією каналів. Мережі стандарту H.323 сумісні і з іншими типами H.32x-мереж. Міжмережева взаємодія різних H.32x-мереж визначає рекомендація H.246. На наступному етапі розвитку IP-телефонії до специфікацій H.323 відповідним нижнім рівням ЕМВВС, будуть додані нові. Вони зафіксують можливості забезпечення класів (class-of-service, CoS) і якості обслуговування (quality-of-service, QoS), тобто послуг, що належать, відповідно, до другого (канального) і третього (мережевого) рівням.

2.6 Протокол SIP

Протокол ініціювання сеансів (Session Initiation Protocol, SIP) - є протоколом прикладного рівня і призначається для організації, модифікації і завершення сеансів зв’язку: мультимедійних конференцій, телефонних з'єднань і розподілу мультимедійної інформації.

Протокол SIP розроблений комітетом IETF, а специфікації протоколу представлені в документі RFC 3261. В основу протоколу закладені наступні принципи:

Персональна мобільність користувачів. Користувачі можуть переміщатися без обмежень в межах мережі, тому послуги зв’язку повинні надаватися їм у будь-якому місці цієї мережі. Користувачеві надається унікальний ідентифікатор, а мережа надає йому послуги зв’язку незалежно від того, де він знаходиться. Для цього користувач за допомогою спеціального повідомлення інформує мережа про свої переміщення.

Масштабованість мережі характеризується, в першу чергу, можливості збільшення кількості елементів мережі при її розширення. Серверна структура мережі, побудованої на базі протоколу SIP, в повній мірі відповідає цій вимозі.

Розширюваність протоколу характеризується можливістю доповнення протоколу новими функціями при введенні нових послуг та його адаптації до роботи з різними додатками. Розширення функцій протоколу SIP може бути здійснена за рахунок введення нових заголовків і типів повідомлень.

Інтеграція в стек існуючих протоколів Інтернет, розроблених IETF. Протокол SIP є частиною складної архітектури, розробленої комітетом IETF. Ця архітектура включає в себе також протокол резервування ресурсів (Resource Reservation Protocol, RSVP; RFC 2205), транспортний протокол реального часу (Real-Time Transport Protocol, RTP; RFC 1889), протокол передачі потоків у реальному часі (Real-Time Streaming Protocol, RTSP; RFC 2326), протокол опису параметрів зв’язку (Session Description Protocol, SDP; RFC 2327) та інші. Однак функції протоколу SIP не залежать ні від одного з цих протоколів.

Взаємодія з іншими протоколами сигналізації. Протокол SIP може бути використаний спільно з протоколом Н.323. Можливо також взаємодія протоколу SIP з системами сигналізації ТМЗК - EDSS1 і ОКС № 7. Для спрощення такої взаємодії сигнальні повідомлення протоколу SIP можуть переносити не тільки SIP-адресу, але й телефонний номер формату Е.164 або будь-якого іншого формату. Крім того, протокол SIP, нарівні з протоколами H.323 і ISUP, може застосовуватися для забезпечення функціонування пристроїв управління шлюзами, в цьому випадку він повинен взаємодіяти з протоколом MGCP або MEGACO. Важливою особливістю протоколу SIP є його незалежність від транспортних технологій. В якості транспорту можна використовувати протоколи Х.25, Frame Relay, AAL5, IPX і ін Структура повідомлень SIP не залежить від обраної транспортної технології.

Сигнальні повідомлення SIP можуть переноситися не тільки протоколом транспортного рівня UDP, але і протоколом ТСР. Протокол UDP дозволяє швидше, ніж TCP, доставляти сигнальну інформацію (навіть з урахуванням повторної передачі непідтверджених повідомлень), а також вести паралельний пошук місця розташування користувачів і передавати запрошення до участі в сеансі зв’язку в режимі під LGPL. У свою чергу, протокол ТСР спрощує роботу з міжмережевими екранами, а також гарантує надійну доставку даних. При використанні протоколу ТСР різні повідомлення, що відносяться до одного викликом, або можуть передаватися по одному TCP-з'єднання, або для кожного запиту і відповіді на нього може відкриватися окреме TCP-з'єднання. На малюнку 1.1 показано місце, займане протоколом SIP у стеку протоколів TCP/IP.

Для організації взаємодії з існуючими додатками IP-мереж і для забезпечення мобільності користувачів протокол SIP використовує адресу, подібний адресою електронної пошти. В якості адрес робочих станцій використовуються спеціальні універсальні покажчики ресурсів - URL (Universal Resource Locators), так звані SIP URL.

SIP-адреси бувають чотирьох типів:

  1.  ім’я @ домен;
  2.  ім’я @ хост;
  3.  ім’я @ IP-адреса;
  4.  № телефону @ шлюз.

Таким чином, адреса складається з двох частин. Перша частина - це ім’я користувача, зареєстрованого в домені або на робочій станції. Якщо друга частина адреси ідентифікує будь-який шлюз, то в першій вказується номер телефону абонента.

У другій частині адреси вказується ім’я домену, робочої станції або шлюзу. Для визначення IP-адреси пристрою необхідно звернутися до служби доменних імен - Domain Name Service (DNS). Якщо ж у другій частині SIP-адреси розміщується IP-адресу, то з робочою станцією можна зв’язатися безпосередньо.

На початку SIP адреси ставиться слово 'sip:', яке вказує, що це саме SIP-адреса, тому що бувають і інші (наприклад, 'tel:'). Нижче наводяться приклади SIP-адрес:

  1. sip: Alexander@niits.ru;
  2. sip: user1@192.168.0.215;
  3. sip: 387-75-47@sip-gateway.ru.

2.7 Протокол MGCP

MGCP (англ. Media Gateway Control Protocol) - протокол для управління шлюзами між IP-мережею і коммутованою телефонною мережею загального користування (ТМЗК). Загальна архітектура бази та програмного інтерфейсу описана в RFC 2805, а поточне конкретне визначення MGCP - в RFC 3435 (застарів RFC 2705). Це наступник Simple Gateway Control Protocol (SGCP).

MGCP є протоколом сигналізації і управління викликами, який використовується в рамках Voice over IP (VoIP) системи, яка зазвичай взаємодіє з комутованою телефонною мережею загального користування (PSTN). Протокол є декомпозицією інших моделей VoIP, таких як H.323, в якому шлюзи (наприклад, гейткіпер H.323) мають більш високий рівень інтелекту сигналізації.

MGCP використовує Session Description Protocol (SDP) для визначення та узгодження медіа-потоків, які будуть передаватися у сесії, і протокол реального часу (RTP) для фреймування медіа потоків.

Розподілена система складається з Call Agent або Media Gateway Controller (MGC), принаймні одного Media Gateway (MG), який виконує перетворення форматів медіаданих і пакетів, і принаймні одного Signaling gateway (SG) при підключенні до PSTN.

Call Agent використовує MGCP, щоб сповістити Media Gateway:

  1. Які події повинні бути представлені Call Agent:
  2. Як кінці повинні бути з'єднані разом:
  3. Які сигнали повинні бути відтворені на кінцях.

MGCP також дозволяє Call Agent перевірити поточний стан кінцевих точок на Media Gateway.

MG використовує MGCP для повідомлень MGC про події (наприклад, стан зайнятості абонентського шлейфу, або набрані цифри).

Як правило, Media Gateway налаштований список викликів агентів, з яких вона може прийняти програмування (де цей список зазвичай включає в себе тільки один або два виклики агентів). У принципі, події можуть бути спрямовані на різні агенти викликів для кожної кінцевої точки на шлюз (відповідно до програми по Call Агенти, встановивши параметр NotifiedEntity). На практиці, однак, як правило, бажано, щоб у будь-який момент усі кінці на шлюз повинен бути одним і тим же Call Agent, інші агенти виклику доступні тільки для забезпечення надмірності у разі, якщо первинний Call Agent не вдається, або втрачає контакт з Media Gateway. У разі такої відмови несе відповідальність резервного Call Agent, щоб перепрограмувати МГ так що шлюз підпадає під контроль резервного Call Agent. Догляд необхідна у таких випадках; двох агентів Call знали, що вони втратили контакт один з одним, але це не гарантія того, що вони не як спробу контролювати ж шлюз. Можливість аудиту шлюз для визначення Call Agent В наш час контроль може бути використаний для вирішення подібних конфліктів.

2.8 Протоколи кодування мовної інформації

2.8.1 Кодек G.711

Кодек G.711 - «дідусь» всіх цифрових кодеків мовних сигналів, був схвалений ITU-T в 1965 році. Застосовує спосіб перетворення аналогового сигналу в цифровий з використанням полулогарифмічної шкали. Типова оцінка MOS складає 4.2. В першу чергу. Відзначимо, що, як і для ТМЗК, мінімально необхідним для обладнання VolP є ІКМ-кодування G.711. Це означає, що будь-який пристрій VolP має підтримувати цей тип кодування.

2.8.2 Кодек G.723.1

Рекомендація G.723.1 затверджена ITU-T в листопаді 1995 року. Форум IMTC вибрав кодек G.723.1 як базовий для додатків IP-телефонії. Кодек G.723.1 виробляє кадри тривалістю 30 мс з тривалістю попереднього аналізу 7.5 мс. Передбачено два режими роботи: 6.3 Кбіт/с (кадр має розмір 189 бітів, доповнених до 24 байтів) і 5.3 Кбіт/с (кадр має розмір 158 бітів, доповнених до 20 байтів). Режим роботи може змінюватися динамічно від кадру до кадру. Обидва режими обов'язкові для реалізації.

Оцінка MOS складає 3.9 в режимі 6.3 Кбіт/с і 3.7 в режимі 5.3 Кбіт/с.

Кодек специфікований на основі операцій як з плаваючою точкою, так і з фіксованою точкою у вигляді коду на мові С. Реалізація кодека на процесорі з фіксованою точкою вимагає продуктивності близько 16 MIPS.

Кодек G.723.1 має детектор мовної активності і забезпечує генерацію комфортного шуму на віддаленому кінці в період мовчання. Ці функції специфіковані в додатку A (Annex A) до рекомендації G.723.1. Параметри фонового шуму кодуються дуже маленькими кадрами розміром 4 байта. Якщо параметри шуму не змінюються суттєво, передача повністю припиняється.

2.8.3 Кодек G.726

Алгоритм кодування АДІКМ (рекомендація ITU-TG.726, прийнята в 1990 р.), забезпечує кодування цифрового потоку G.711 зі швидкістю 40, 32, 24 або 16 Кбіт/с, гарантуючи оцінки MOS на рівні 4.3 (32 Кбіт/с), що часто приймається за еталон рівня якості телефонного зв'язку (toll quality). У додатках IP-телефонії цей кодек практично не використовується, тому що він не забезпечує достатньої стійкості до втрат інформації.

2.8.4 Кодек G.728

Кодек G.728 використовує оригінальну технологію з малою затримкою LD-CELP (low delay code excited linear prediction) і гарантує оцінки MOS, аналогічні АДІКМ G.726 при швидкості передачі 16 Кбіт/с. Даний кодек спеціально розроблявся як більш досконала заміна АДІКМ для обладнання ущільнення телефонних каналів, при цьому було необхідно забезпечити дуже малу величину затримки (менше 5 мс), щоб виключити необхідність застосування ехокомпенсаторів. Ця вимога була успішно виконано вченими Bell JLabs в 1992 році: кодер має тривалість кадру тільки 0.625 мс. Реально затримка може досягати 2.5 мс, так як декодер повинен підтримувати синхронізацію в рамках структури з чотирьох кадрів.

Недоліком алгоритму є висока складність - близько 20 MIPS для кодера і 13 MIPS для декодера - і відносно висока чутливість до втрат кадрів.

2.8.5 Кодек G.729

Кодек G.729 дуже популярний в додатках передачі мови по мережах Frame Relay. Він використовує технологію CS-ACELP (Conjugate Structure, Algebraic Code Excited Linear Prediction). Кодек використовує кадр тривалістю 10 мс і забезпечує швидкість передачі 8 Кбіт/с. Для кодера необхідний попередній аналіз сигналу тривалістю 5 мс.

Існують два варіанти кодека:

  1. G.729 (схвалений ITU-T у грудні 1996), що вимагає близько 20 MIPS для кодера і 3 MIPS для декодера;
  2. спрощений варіант G.729A (схвалений ITU-T в листопаді 1995), що вимагає близько 10.5 MIPS для реалізації кодера і близько 2 MIPS для декодера.

У специфікаціях G.729 визначені алгоритми VAD, CNG і DTX. У періоди мовчання кодер передає 15-бітові кадри з інформацією про фоновий шум, якщо тільки шумова обстановка змінюється.

2.8.6 Кодеки, стандартизовані ETSI

У рамках діяльності Європейського інституту ETSI стандартизовані вузькосмугові кодеки для застосування в системах мобільного зв'язку (GSM).

Специфікації кодека GSM Full Rate, відомого також як GSM 06.10, затверджені у 1987р. Це перший і, швидше за все, найбільш відомий з вузькосмугових кодеків, застосовуваний у мільйонах мобільних телефонів по всьому світу. Забезпечує хорошу якість і стійку роботу в умовах фонового шуму (оцінка MOS порядку 3.7 в умовах без шуму). Кодуються кадри тривалістю 20 мс, утворюючи цифровий потік зі швидкістю 13 Кбіт/с. Кодек не вимагає високої продуктивності процесора - необхідно тільки 4.5 MIPS для дуплексної реалізації. Кодек дуже важливий для некомерційних проектів в області IP-телефонії, особливо - для проектів, пов'язаних з відкритим поширенням вихідних текстів ПЗ (open source), завдяки можливості безкоштовного ліцензування. Такі проекти сьогодні можуть використовувати тільки кодеки GSM FR і G.711, а також АДІКМ.

Існують також специфікації кодеків GSM Half Rate, прийняті в 1994 році, і GSM Enhanced Full Rate, прийняті в 1995 році. Характеристики цих кодеків перевершують характеристики початкового варіанту, описаного вище, однак алгоритми вимагають більшої продуктивності процесора (до 30 MIPS). У додатках IP-телефонії вони, з різних причин, поширення поки не отримали.

Розгляд кодеків було б неповним, якби, поряд зі специфікованою ITU-T і ETSI, не були згадані і т.зв. нестандартні кодеки. Сьогодні в додатках VolP, крім кодеків, що пройшли процедури міжнародної стандартизації в ITU-T і ETSI, в продуктах ряду фірм-виробників застосовуються також нестандартні внутрішньофірмові алгоритми. Такі алгоритми часто ліцензуються для використання у продуктах інших компаній. В якості прикладів можна назвати такі кодеки, як Lucent/Elemedia SX7003P, що має дуже хороші характеристики на помірному обчислювальної складності, і Voxware RT24, який передбачає наднизьку (2.4 Кбіт/с) швидкість передачі інформації при збереженні досить гарної якості мови (оцінка MOS близько 3.2 ).

2.9 Протокол RSVP

Протокол резервування ресурсів RSVP (RFC 2205) надає простий механізм резервування необхідної ємності черг для окремих потоків трафіку. Він був розроблений організацією IETF як засіб для запиту і резервування ресурсів в маршрутизованих мережах, подібних Інтернет. Одна з робочих груп, опрацьовують питання, пов'язані з RSVP, - Integrated Services Working Group - займається розвитком моделі Інтернет з метою забезпечення інтеграції найрізноманітніших служб. Основне її завдання - описати типи служб і відповідні кожному з них вимоги до якості обслуговування. Звертаючись до тієї чи іншої службі, додаток використовує протокол RSVP, щоб повідомити мережі про свої побажання щодо якості обслуговування. Це означає, що RSVP призначений для наскрізного розподілу мережевих ресурсів між окремими потоками трафіку. Отже, щоб забезпечити запитану  якість обслуговування, всі вузли повинні підтримувати RSVP.

Група Integrated Services визначила «поведінку» елементів мережі для двох типів служб: з контрольованим завантаженням (RFC 2211) і з гарантованою якістю обслуговування (RFC 2212). Перші забезпечують передачу потоку трафіку з якістю обслуговування, близьким до того, яке досяжно за відсутності завантаження мережевого елемента (для цього залучається жорсткий алгоритм управління доступом). Другі гарантують певну смугу пропускання і затримку, завдяки чому дейтаграми доставляються в межах зазначеного терміну і не скидаються через переповнення черг. Разом з тим служби з гарантованою якістю обслуговування не роблять спроб мінімізувати величину розкиду затримок.

Сам протокол RSVP не визначає жодних функціональних властивостей елементів мережі і призначений тільки для передачі запитів на резервування мережевих ресурсів. Резервування ініціюється стороною, що приймає потік. Воно діє для певного потоку даних і на певний період часу, для продовження резервування приймач повинен періодично відправляти відповідні повідомлення. Всі маршрутизатори, що знаходяться на шляху передачі потоку, зобов'язані резервувати ресурси для забезпечення зазначеної якості обслуговування.

Існує два основних типи повідомлень RSVP: Resv і Path. Повідомлення Path посилається в напрямку від відправника до приймача за маршрутом пересилки даних і готує маршрутизатори до можливого резервування ресурсів. Приймач посилає по тому ж самому маршруту повідомлення Resv, яке і резервує на маршрутизаторах ресурси, необхідні для надання необхідної якості обслуговування.

Кожен маршрутизатор повинен класифікувати пакети і обслуговувати черги таким чином, щоб забезпечити кожному потоку необхідний йому рівень обслуговування. Це дозволяє досягти непоганих результатів в управлінні якістю обслуговування, але при збільшенні числа сеансів RSVP навантаження на маршрутизатор теж різко зростає. Тому розглянута технологія добре підходить лише для мереж з контрольованим числом сеансів RSVP.

    Одне з можливих рішень щодо зменшення навантаження на маршрутизатор - об'єднання на кордоні мережі безлічі потоків трафіку в один або кілька шляхів RSVP; так, у разі IP-телефонії, трафік безлічі абонентів цілком можна пустити по одному RSVP-шляху між мовними шлюзами. У мультисервісних мережах таке об'єднання може базуватися на моделі Diff-Serv.


3 ВИБІР ВАРІАНТІВ ПОБУДОВИ КОРПОРАТИВНОЇ МЕРЕЖІ НА ОСНОВІ IP-ТЕЛЕФОНІЇ


 

А также другие работы, которые могут Вас заинтересовать

53604. Введение в информатику. Правила техники безопасности 582.5 KB
  Дидактическая цель: дать общее представление об информатике как о науке ввести понятие информатика cформировать знания по технике безопасности работы в компьютерном классе. Знать: формулировку понятия информатика основные правила техники безопасности нормы работы в компьютерном классе основные упражнения физкультминутки. Информатика и ИКТ : учебник для 7 класса Н. Вначале мы узнаем что изучает предмет информатика а также поймем значимость этого предмета в современном мире.
53605. Оценка облигаций 23 KB
  Номинальная цена напечатана на бланке облигации и обозначает сумму, которая берется взаймы и подлежит возврату по истечении срока облигационного займа.
53606. Сантиметр 30 KB
  Сколько грибков у белочки Сколько грибков у ежика Как узнать сколько всего грибков Как записать это выражение Клик Прочитайте это выражение разными способами. Устное решение примеров слайд 4 –кликаем Задания с окошками слайд 5 – кликаем Восстановление числового ряда слайд 6 –кликаем Задание от гнома – Найти лишнюю фигуру слайд 7 почему...
53607. Компоненты оборотных активов 30 KB
  Оборотные средства (current assets) – это активы предприятия, возобновляемые с определенной регулярностью для обеспечения текущей деятельности, вложения в которые как минимум однократно оборачиваются в течение года или одного производственного цикла.
53608. Сложение и вычитание смешанных чисел 139 KB
  Высота Тайницкой башни м Благовещенской м. На сколько первая выше второй 2 Высота Водовзводной башни м Комендантской башни м Петровской башни м а Первой Безымянной м. Какая высота четырёх башен вместе 3 Высота Никольской башни до звезды м. Какова высота Угловой Арсенальной башни 4 Высота Боровицкой башни 54 м а Беклемишевской м.
53609. Основные теории структуры капитала: традиционная, Модильяни-Миллера 27 KB
  Соотношение между собственными и заемными источниками средств является одним из ключевых аналитических показателей, характеризующих степень риска инвестирования финансовых ресурсов в данное предприятие
53610. Парные звонкие глухие согласные 174 KB
  Развивающие цели: Развитие художественных представлений и умений творческой деятельности. Развитие восприятия: Развитие целостности предметности осмысленности восприятия. Развитие речи: Развитие диалогической и монологической речи развитие содержательности понятности и выразительности речи. Развитие памяти: Развитие образной эмоциональной памяти.
53611. Пространственные представления 55.5 KB
  Образовательная: продолжать работу по формированию пространственных представлений у детей; 2. Сколько предметов сдала дама в багаж ответ детей Ребята а сейчас мы с вами поиграем в игру. Вы готовы ответ детей Для игры нам понадобятся: 2 красных круга 1 желтый и 2 зеленых треугольника 2 синих и 2 красных квадрата.
53612. Балет. Становление башкирского балета 73.5 KB
  Какие как вы думаете Отвечают на вопрос Отвечают на вопрос На доске учитель рисует балерину Слайд 1. Рассматривают рисунок записывают тему урока Слайд 2. Размышления над вопросом запись имен в таблице дома Слайд 3. Медичи Тальони Слайд 4.