|
|
| (не показано 25 проміжних версій цього учасника) |
| Рядок 1: |
Рядок 1: |
| − | <div style="background: #33ccff"> | + | <div style="background: #cccccc"> |
| | <center> | | <center> |
| − | [[http://wiki.kspu.kr.ua/index.php/Технологія_VoIP Зміст]] | + | ---- |
| − | [[http://wiki.kspu.kr.ua/index.php?title=Розділ_2._Мережеві_аспекти_IP-телефонії Розділ 2. Мережеві аспекти ІР-телефонії]] | + | [ '''[[Технологія VoIP]]''' ][ [[Розділ_2._Мережеві_аспекти_IP-телефонії|Розділ 2. Мережеві аспекти IP-телефонії >>]] ] |
| | + | ---- |
| | </center> | | </center> |
| | </div> | | </div> |
| | | | |
| − | ----
| |
| | | | |
| − | == '''1.1 Пропорції в телекомунікаціях''' ==
| |
| − | Гуляючи в тінистому гаю, грецький філософ Анаксимен розмовляв зі своїм учнем. «Скажи мені, - запитав юнак, - чому тебе часто долають сумніви? Ти прожив довге життя, навчений досвідом і вчився у великих еллінів. Як же так вийшло, що і для тебе залишилося настільки багато незрозумілих питань?». У відповідь філософ окреслив палицею перед собою два кола: малий і великий. «Твої знання-це маленьке коло, а мої - великий. Але все, що залишилося поза цих кіл, - невідомість. Маленьке коло c невідомістю стикається мало. Чим ширше коло твоїх знань, тим протяженнее його кордон з невідомістю. І надалі, чим більше ти будеш дізнаватися нового, тим більше у тебе буде виникати незрозумілих питань».<br>
| |
| − | Класична телефонія з її традиційними телефонними послугами POTS (Plain Old Telephone Service), досить добре вивчена за свою більш ніж столітню історію, відповідає малому колу з цієї повчальної притчі. Велике коло представляє народжувану індустрію інфокомунікацій, що є результатом взаємопроникнення (конвергенції) інформаційних і телекомунікаційних технологій та послуг і дійсно породжує більше нерозв'язаних питань, ніж готових відповідей.<br>
| |
| − | З часу свого виникнення телекомунікації базуються на передачі електромагнітних сигналів через транспортну середу, якою можуть бути:<br>
| |
| − | <ul>
| |
| − | <li>металевий кабель,</li>
| |
| − | <li>оптоволокно,</li>
| |
| − | <li>радіоканал.</li>
| |
| − | </ul>
| |
| − | Передана у вигляді електромагнітних сигналів інформація може бути:<br>
| |
| − | <ul>
| |
| − | <li>мова,</li>
| |
| − | <li>дані,</li>
| |
| − | <li>відеозображення.</li>
| |
| − | </ul>
| |
| − | або будь-яку їхню комбінацію, звану мультимедійною інформацією.<br>
| |
| − | Ці три джерела і три складові частини телекомунікацій в повній мірі відображають їх сучасний стан, причому сучасність тут розуміється в широкому сенсі. Передача по мережах зв'язку інформації трьох перерахованих вище видів благополучно здійснювалася не одне десятиліття, поки не спрацював принцип, давно відомий у сфері мистецтв, - вся справа в пропорціях.<br>
| |
| − | Ще в 1996 р. в США трафік передачі даних вперше перевищив мовний (рис. 1.1) і продовжує демонструвати завидні темпи зростання (до 30% на рік у порівнянні з 3% у рік для телефонії). Те ж відбулося в Європі в 1999 році. Все це послужило поштовхом до початку нової ери в телекомунікаціях - ери інтегрованих рішень та конвергенції всіх видів зв'язку. Протокол IP отримав світове визнання і, до певної міри, став «де-факто» стандартом для передачі мультимедійної інформації.<br>
| |
| − | Якщо додати сюди феномен мережі Інтернет, де, за найскромнішими підрахунками, зростання числа користувачів становить 5% на місяць, то стане цілком зрозуміло, що всі ці події самим безпосереднім чином тягнуть за собою докорінну зміну підходів до побудови інформаційних мереж. Мова і дані міняються місцями. Традиційні мережі передачі даних базувалися на магістралях з комутацією каналів, призначених для телефонного трафіку. При новому підході - все навпаки: телефонія буде надстраиваться над інфраструктурою мережі передачі даних.<br>
| |
| − | Зміщення центру ваги в область передачі даних поставило питання про пошук зручного способу вбудовування мови в мультимедійний цифровий потік. Причина популярності IP як раз і полягає в його сприйнятливості до вимог з боку не тільки послуг передачі даних, але і додатків реального часу. Прикладом може служити успішно реалізована технологія передачі мовної інформації по мережах з маршрутизацією пакетів IP - Voice over IP (VolP) або IP-телефонія.<br>
| |
| − | <center>
| |
| − | [[Файл:VoIP_1.1.png]]<br>
| |
| − | '''Рис. 1.1.''' Ріст трафіка Інтернет та телефонного трафіку
| |
| − | </center><br>
| |
| − | Але поняття Voice over IP має на увазі не тільки і не стільки використання мережі Інтернет в якості середовища передачі мови, скільки сам протокол IP і технології, щоб забезпечити надійну і високоякісну передачу мовної інформації в мережах пакетної комутації. Відсутність гарантованої якості обслуговування при передачі мови компенсується появою таких технологій, як багатопротокольна комутація по мітках - Multiprotocol Label Switching (MPLS), протокол резервування ресурсів - Resource Reservation Protocol (RSVP), диференціальне обслуговування різнотипного трафіку - Differentiated Services (DiffServ) та інших. Все більшу популярність набуває передача пакетів IP, упакованих у контейнери систем синхронної цифрової ієрархії - Synchronous Digital Hierarchy (SDH), а також технологія спектрального мультиплексування - Wave Division Multiplexing (WDM). У всіх випадках необхідною умовою є підпорядкування кожного вузла системи єдиної політики управління трафіком. Цьому ж покликані допомогти протоколи RTP, RTSP, Diffentiaten Services та інші механізми, що розглядаються в наступних розділах. Тут же досить зазначити, що стандартизація мовних технологій на основі стеку TCP / IP і їх підтримка лідерами ринку пакетної телефонії забезпечать сумісність обладнання різних виробників і дозволять створювати системи, в яких можливі виклики з аналогового телефонного апарату, підключеного до порту маршрутизатора, на персональний комп'ютер, або з персонального комп'ютера на номер ТфОП, в рамках трьох сценаріїв IP-телефонії, що розглядаються в наступному розділі.<br>
| |
| | | | |
| − | == '''1.2 Перспективи розвитку ТМЗК та IP-мереж''' ==
| + | '''1.1 [[Пропорції в телекомунікаціях]]'''<br> |
| − | Продовжуючи аналіз росту трафіку даних і мови, представленого у вигляді графіків на рис.1 в попередньому параграфі, автори дозволили собі навести прогноз зростання кількості абонентів (графіки на рис.1.2). Суть прогнозу аж ніяк не в тому, що кількість користувачів мереж стаціонарного зв'язку, мобільного зв'язку та Інтернет до 2004-2006 років досягне мільярда, а в тому, що ємності цих мереж зближуються. У контексті даної глави остання обставина, відповідно до закону діалектики про перехід кількості в якість, призводить до принципово новим думкам з приводу конвергенції цих мереж. Важливим стимулом таких думок є прогноз загальносвітових доходів від телекомунікаційних послуг, зроблений Dataquest (рис. 1.26), графічне представлення якого майже збігається з верхньою кривою на рис. 1.2а. Порогова величина в цьому прогнозі становить трильйон доларів США сукупного доходу за сегментами ринку (мова, дані, мобільний зв'язок), а перехід за цей поріг очікується ще раніше - в 2002-2003 рр..<br>
| + | '''1.2 [[Перспективи розвитку ТМЗК та IP-мереж]]'''<br> |
| − | <center>
| + | '''1.3 [[Транспортні технології пакетної комутації]]'''<br> |
| − | [[Файл:VoIP_1.2.png]]<br> | + | '''1.4 [[Рівні архітектури IP-телефонії]]'''<br> |
| − | '''Рис. 1.2.''' Зростання чисельності абонентів, їх перерозподіл (а) і загальносвітові показники доходів від телекомунікаційних послуг за сегментами ринку (б) | + | '''1.5 [[Різні підходи до побудови мереж IP-телефонії]]''' <br> |
| − | </center><br>
| + | '''1.5.1 [[Побудова мережі за рекомендацією Н.323]]'''<br> |
| − | Одним з аспектів, що сприяють згаданої вище конвергенції, є ключовий принцип відділення організації послуг від транспортування інформації, що становить основу ідеї Інтелектуальних мереж. Суть концепції Інтелектуальної мережі (IN) полягає в побудові універсальної середовища, що забезпечує найбільшу ефективність створення і надання нових телефонних послуг. Поступово ця концепція стала засобом глобального нагнітання обчислювальної потужності в телефонну мережу загального користування (ТФОП), про що чимало сказано в тільки що вийшла монографії.<br>
| + | '''1.5.2 [[Мережа на базі протоколу SIP]]'''<br> |
| − | Тут же є корисним продовжити кількісні оцінки і спробувати уявити собі короткостроковий і довгостроковий прогнози розвитку телекомунікаційних послуг.<br>
| + | '''1.5.3 [[Мережа на базі MGCP і MEGACO]]'''<br> |
| − | Короткостроковий прогноз автори пов'язують із згаданими вище аспектами конвергенції мереж і послуг зв'язку. Довгостроковий прогноз припускає, що переважання додатків типу клієнт-сервер на основі IP-мереж (наприклад, пошук інформації, пошта та інші) збережеться. Але у віддаленій перспективі внутрішня природа мережі, що базується на протоколі IP, може стати гальмом для виконання вимог інтерактивної мультимедіа: висока швидкодія в реальному часі і «наскрізна» широкосмугова інтерактивність. Для такого роду додатків в майбутньому буде потрібно більш потужна платформа.<br>
| + | '''1.5.4 [[Порівняння підходів до побудови мережі IP-телефонії]]'''<br> |
| − | Рис.1.3 ілюструє еволюцію телекомунікаційних додатків на основі IP.<br>
| + | |
| − | Прийнявши до уваги ту обставину, що IP-телефонія є одним з найважливіших додатків на базі протоколу IP, на підставі рис.1.3 читач може прийняти рішення про те, наскільки доцільно прочитати цю книгу. Основний висновок авторів з цього малюнка полягає в тому, що Internet Protocol безумовно буде домінуючим протоколом в мережах наступного покоління, яким належить підтримувати передачу мови, даних, факсиміле, відеоінформації та мультимедіа.<br>
| + | |
| − | <center>
| + | |
| − | [[Файл:VoIP_1.3.png]]<br> | + | |
| − | '''Рис. 1.3.''' Тенденції розвитку телекомунікаційних послуг | + | |
| − | </center><br>
| + | |
| − | Першочергова мета конвергенції мереж на базі протоколу IP-це зниження загальних витрат, що складаються не тільки з капітальних витрат на придбання та інсталяцію телекомунікаційного обладнання, а й з витрат на його утримання. Теоретично одна об'єднана мережа зменшила б потреба у кваліфікованому персоналі - одні й ті ж люди стали б займатися і телефонією, і системами передачі даних. Наявність лише одного каналу доступу до розподіленої мережі теж грунтовно знизило б щомісячні витрати. Направляючи мовної трафік через корпоративну магістральну мережу передачі даних, можна істотно зменшити витрати на традиційні телефонні послуги. І, нарешті, скорочення одиниць використовуваного обладнання значно зменшить вартість його технічного обслуговування. Як зазначив представник одного міжнародного оператора зв'язку, перехід на технологію IP-телефонії дозволить йому заощадити близько 70% коштів на капітальні витрати, 60-80% коштів, що виділяються на організацію каналів доступу, і 50% коштів на поточне обслуговування та ремонт мережі.<br>
| + | |
| − | Однак економія на вартості інфраструктури - це не те, заради чого задумувався перехід до об'єднаних мереж. Революція станеться тоді, коли з'являться нові програми, наприклад, коли центри обслуговування клієнтів зможуть в реальному часі «супроводжувати» кожного покупця з моменту його появи на домашній сторінці компанії в мережі Інтернет до оформлення замовлення на покупку потрібного продукту, «проводячи» його через такі етапи , як демонстрація каталогу пропонованих виробів і з'ясування незрозумілих питань в ході телефонного спілкування з представником компанії. Інший приклад застосування нових технологій - використання співробітниками телефонного сервісу своєї корпоративної УАТС незалежно від того, де він і знаходяться, наприклад, при роботі вдома. <br>
| + | |
| − | При всіх оптимістичних прогнозах, викладених вище, не слід забувати, що традиційна телефонний зв'язок спирається на потужну базу, що створювалася протягом багатьох десятиліть, і така система не може не володіти певною інерцією. Виходячи з цього, навряд чи варто очікувати, що не сьогодні-завтра станеться миттєвий революційний стрибок у галузі зв'язку, та Інтернет-телефонія витіснить всі інші технології. Швидше навпаки: протягом найближчих 5-10 років традиційна телефонія буде як і раніше займати домінуючі позиції. Перехід на нові, більш прогресивні методи буде відбуватися поступово еволюційним шляхом, в різних країнах з різною швидкістю. А це означає, що протягом тривалого часу ТфОП і IP-мережі будуть змушені існувати паралельно, забезпечуючи взаємну прозорість і об'єднуючи свої зусилля в обслуговуванні різнорідного абонентського трафіку.<br>
| + | |
| − | Згідно з відомою формулою про неможливість знаходитися в якомусь суспільстві і бути поза його законів, при входженні IP-телефонії в давно сформувалося глобальне телефонне суспільство необхідне дотримання основних законів існуючій ТфЗК:<br>
| + | |
| − | експлуатаційна надійність з трьома дев'ятками після коми, жорсткі норми якості передачі мови в реальному часі і т.п.<br>
| + | |
| − | Не менш законів, правил і норм важливі традиції, що сформувалися за більш ніж столітній період існування ТфОП. І. Губерманом дана точна формулювання важливості традицій:<br>
| + | |
| − | <ul>
| + | |
| − | <li>Владика наш - традиція. А в ній-свої благословіння і перепони;</li>
| + | |
| − | <li>неписані правила сильніше, ніж самі люті закони.</li>
| + | |
| − | </ul>
| + | |
| − | Тому не менш важливо зберегти всі звичні для користувача дії - набір номера, спосіб доступу до телефонних послуг і т. д. Таким чином, абонент не повинен відчувати різниці між IP-телефонією і звичайним телефонним зв'язком ні за якістю мови, ні за алгоритмом доступу.
| + | |
| − | З тих же причин дуже бажано забезпечити між ТФОП і IP-мережами повну прозорість передачі користувальницької інформації та сигналізації. Справа в тому, що на відміну, наприклад, від більшості корпоративних мереж зв'язку, мережі загального користування не мають національних і відомчих меж. IP-телефонія повинна мати можливість підтримувати спільну роботу і забезпечувати інформаційну прозорість з безліччю стандартів зв'язку, прийнятих у різних країнах світу. Мова йде не тільки про електричну стикуванні - необхідно знайти взаємоприйнятне рішення таких завдань, як взаємодія протоколів верхніх рівнів та програм, нарахування плати та ін.<br>
| + | |
| | | | |
| − | == '''1.3 Транспортні технології пакетної комутації''' ==
| |
| − | Більшість виробників, які мають широким асортиментом продукції для пакетної телефонії, займають «технологічно нейтральне» положення і надають покупцеві можливість самому вибирати ту технологію, яка краще всього відповідає його інтеграційної стратегії.
| |
| − | Основні технології пакетної передачі мови - Frame Relay, ATM і маршрутизація пакетів IP - різняться ефективністю використання каналів зв'язку, ступенем охоплення різних ділянок мережі, надійністю, керованістю, захистом інформації та доступу, а також вартістю. Обмежений обсяг книги не дозволяє дати глибокий порівняльний аналіз цих технологій з точки зору передачі мови, тому тут наводяться в найбільш компактною графічній формі тільки результати такого аналізу (рис.1.4).<br>
| |
| − | <center>
| |
| − | [[Файл:VoIP_1.4.png]]<br>
| |
| − | '''Рис. 1.4. а)''' Голос по АТМ
| |
| − | </center><br>
| |
| − | <center>
| |
| − | [[Файл:VoIP_1.4.1.png]]<br>
| |
| − | '''Рис. 1.4. б)''' Голос Frame Relay
| |
| − | </center><br>
| |
| − | <center>
| |
| − | [[Файл:VoIP_1.4.2.png]]<br>
| |
| − | '''Рис. 1.4. в)''' Голос по IP<br>
| |
| − | '''Рис. 1.4.''' Порівняння технологій пакетної передачі мови: a) VoATM, б) VoFR, в) VolP
| |
| − | </center><br>
| |
| − | Транспортна технологія ATM вже кілька років успішно використовується в магістральних мережах загального користування і в корпоративних мережах, а зараз її починають активно використовувати і для високошвидкісного доступу по каналах xDSL (для невеликих офісів) і SDH / Sonet (для великих підприємств). Головні переваги цієї технології - її зрілість, надійність та наявність розвинених засобів екс
| |
| − | таційний управління мережею. У ній є неперевершені за своєю ефективністю механізми управління якістю обслуговування і контролю використання мережевих ресурсів. Проте обмежена поширеність і висока вартість устаткування не дозволяють вважати ATM кращим вибором для організації наскрізних телефонних з'єднань від одного кінцевого вузла до іншого.<br>
| |
| − | Технології Frame Relay судилося зіграти в пакетній телефонії ту ж роль, що і квазіелектронних АТС у телефонії з комутацією каналів: вони показали приклад ефективної програмно керованої техніки, але мали обмежені можливості подальшого розвитку. Користувачами недорогих послуг Frame Relay, що забезпечують цілком передбачувану продуктивність, стали багато корпоративні мережі, і більшість з них цілком задоволені своїм вибором. У короткостроковій перспективі технологія передачі мови по Frame Relay буде цілком ефективна для організації мультисервісного доступу і каналів далекого зв'язку. Але мережі Frame Relay поширені незначно: як правило, на практиці використовуються некомутовані з'єднання точка-точка.<br>
| |
| − | Технологія передачі мовної інформації по мережах з маршрутизацією пакетів IP приваблює, в першу чергу, своєю універсальністю - мова може бути перетворена в потік IP-пакетів у будь-якій точці мережевої інфраструктури: на магістралі мережі оператора, на кордоні територіально розподіленої мережі, в корпоративній мережі і навіть безпосередньо в терміналі кінцевого користувача. Зрештою, вона стане найбільш широко поширеною технологією пакетної телефонії, оскільки здатна охопити всі сегменти ринку, будучи при цьому добре адаптується до нових умов застосування. Незважаючи на універсальність протоколу IP, впровадження систем IP-телефонії стримується тим, що багато операторів вважають їх недостатньо надійними, погано керованими і не дуже ефективними. Але грамотно спроектована мережева інфраструктура з ефективними механізмами забезпечення якості обслуговування, що розглядаються в розділі 10, робить ці недоліки малосуттєвими. У розрахунку на порт вартість систем IP-телефонії перебуває на рівні (або трохи нижче) вартості систем Frame Relay, і явно нижче вартості обладнання ATM. При цьому вже зараз видно, що ціни на продукти IP-телефонії знижуються швидше, ніж на інші вироби, і що відбувається значне загострення конкуренції на цьому ринку.<br>
| |
| | | | |
| − | == '''1.4 Рівні архітектури IP-телефонії''' ==
| |
| − | Архітектура технології Voice over IP може бути спрощено представлена у вигляді двох площин. Нижня площина - це базова мережа з маршрутизацією пакетів IP, верхня площина - це відкрита архітектура управління обслуговуванням викликів (запитів зв'язку).
| |
| − | Нижня площина, кажучи спрощено, являє собою комбінацію відомих протоколів Інтернет: це - RTP (Real Time Transport Protocol), який функціонує поверх протоколу UDP (User Datagram Protocol), розташованого, у свою чергу, в стеку протоколів TCP / IP над протоколом IP. Таким чином, ієрархія RTP / UDP / IP являє собою свого роду транспортний механізм для мовного трафіку. Цей механізм буде більш докладно розглянутий у розділі 4, присвяченій протоколах Інтернет для передачі мови в реальному часі. Тут же відзначимо, що в мережах з маршрутизацією пакетів IP для передачі даних завжди передбачаються механізми повторної передачі пакетів у разі їх втрати. При передачі інформації в реальному часі використання таких механізмів лише погіршить ситуацію, тому для передачі інформації, чутливої до затримок, але менш чутливою до втрат, такий як мова і відеоінформація, використовується механізм негарантованої доставки інформації RTP / UDPD / IP. Рекомендації ITU-Т допускають затримки водному напрямку не перевищують 150 мс. Якщо приймальня станція запросить повторну передачу пакету IP, то затримки при цьому будуть занадто великі. <br>
| |
| − | Тепер перейдемо до верхньої площини управління обслуговуванням запитів зв'язку. Взагалі кажучи, управління обслуговуванням виклику передбачає прийняття рішень про те, куди виклик повинен бути спрямований, і яким чином має бути встановлене з'єднання між абонентами. Інструмент такого управління-телефонні системи сигналізації, починаючи з систем, підтримуваних декадно-крокових АТС і передбачають об'єднання функцій маршрутизації і функцій створення комутованого розмовного каналу в одних і тих же декадно-крокових шукачів. Далі принципи сигналізації еволюціонували до систем сигналізації по виділеним сигнальним каналах, до многочастотной сигналізації, до протоколів загальноканальної сигналізації № 7 [6, 7] і до передачі функцій маршрутизації у відповідні вузли обробки послуг Інтелектуальної мережі.<br>
| |
| − | У мережах з комутацією пакетів ситуація більш складна. Мережа з маршрутизацією пакетів IP принципово підтримує одночасно цілий ряд різноманітних протоколів маршрутизації. Такими протоколами на сьогодні є: RIP - Routing Information Protocol, IGRP - Interior Gateway Routing Protocol, EIGRP - Enhanced Interior Gateway Routing Protocol, IS-IS - Intermediate System-to-intermediate System, OSPF - Open Shortest Path First, BGP - Border Gateway Protocol та ін Точно так само і для IP-телефонії розроблено цілий ряд протоколів. <br>
| |
| − | Найбільш поширеним є протокол, специфікований в рекомендації Н.323 ITU-T, зокрема, тому, що він став застосовуватися раніше інших протоколів, яких, до того ж, до впровадження Н.323 взагалі не існувало.<br>
| |
| − | Інший протокол площині управління обслуговуванням виклику-SIP - орієнтований на те, щоб зробити кінцеві пристрої і шлюзи більш інтелектуальними і підтримувати додаткові послуги для користувачів.<br>
| |
| − | Ще один протокол - SGCP - розроблявся, починаючи з 1998 року, для того, щоб зменшити вартість шлюзів за рахунок реалізації функцій інтелектуальної обробки виклику в централізованому обладнанні. Протокол IPDC дуже схожий на SGCP, але має багато більше, ніж SGCP, механізмів експлуатаційного управління (ОАМ & Р). В кінці 1998 року робоча група MEGACO комітету IETF розробила протокол MGCP, який базується, в основному, на протоколі SGCP, але з деякими доповненнями в частині ОАМ & Р. <br>
| |
| − | Робоча група MEGACO не зупинилася на досягнутому, продовжувала вдосконалювати протокол управління шлюзами і розробила більш функціональний, ніж MGCP, протокол MEGACO. Його адаптований до Н.323 варіант (під назвою Gateway Control Protocol) ITU-T пропонує в рекомендації Н.248.<br>
| |
| | | | |
| − | == '''1.5 Різні підходи до побудови мереж IP-телефонії''' == | + | <div style="background: #cccccc"> |
| − |
| + | |
| − | Щоб стало зрозуміло, чим конкретно відрізняються один від одного перераховані у попередньому параграфі протоколи, коротко розглянемо архітектуру мереж, побудованих на базі цих протоколів, і процедури встановлення та завершення з'єднання з їх використанням.
| + | |
| − | <br>
| + | |
| − | '''''1.5.1 Побудова мережі за рекомендацією Н.323''''' <br>
| + | |
| − | Перший в історії підхід до побудови мереж IP-телефонії на стандартизованої основі запропоновано Міжнародним союзом електрозв'язку (ITU) в рекомендації Н.323 [42]. Мережі на базі протоколів Н.323 орієнтовані на інтеграцію з телефонними мережами і можуть розглядатися як мережі ISDN, накладені на мережі передачі даних. Зокрема, процедура встановлення з'єднання в таких мережах IP-телефонії базується на рекомендації Q.931 [44] і аналогічна процедурі, яка використовується в мережах ISDN.
| + | |
| − | <br>
| + | |
| − | Рекомендація Н.323 передбачає досить складний набір протоколів, який призначений не просто для передачі мовної інформації по IP-мереж з комутацією пакетів. Його мета - забезпечити роботу мультимедійних додатків у мережах з негарантованих якістю обслуговування. Мовний трафік - це тільки один з додатків Н.323, поряд з відео і даними. Атак як нічого в техніці (як і в житті) не дістається задарма, забезпечення сумісності з Н.323 різних мультимедійних додатків вимагає досить значних зусиль. Наприклад, для реалізації функції перемикання зв'язку (call transfer) потрібна окрема специфікація Н.450.2.
| + | |
| − | Варіант побудови мереж IP-телефонії, запропонований Міжнародним союзом електрозв'язку в рекомендації Н.323, добре підходить тим операторам місцевих телефонних мереж, які зацікавлені у використанні мережі з комутацією пакетів (IP-мережі) для надання послуг міжміського і міжнародного зв'язку. Протокол RAS, що входить у сімейство протоколів Н.323, забезпечує контроль використання мережевих ресурсів, підтримує аутентифікацію користувачів і може забезпечувати нарахування плати за послуги. <br>
| + | |
| − | На рис 1.5. представлена архітектура мережі на базі рекомендації Н.323. Основними пристроями мережі є: термінал (Terminal), шлюз (Gateway), воротар (Gatekeeper) і пристрій керування конференціями (Multipoint Control Unit-MCU).<br>
| + | |
| | <center> | | <center> |
| − | [[Файл:VoIP_1.5.png]]<br>
| |
| − | '''Рис. 1.5.''' Архітектура мережі Н.323
| |
| − | </center><br>
| |
| − | Термінал Н.323 - крайовий пристрій користувача мережі IP-телефонії, яке забезпечує двосторонній мовну (мультимедійну) зв'язок з іншим терміналом Н.323, шлюзом або пристроєм управління конференціями.<br>
| |
| − | Шлюз IP-телефонії реалізує передачу мовного трафіку по мережах з маршрутизацією пакетів IP по протоколу Н.323. Основне призначення шлюзу - перетворення мовної інформації, що поступає з боку ТФОП, у вигляд, придатний для передачі по мережах з маршрутизацією пакетів IP. Крім того, шлюз перетворює сигнальні повідомлення систем сигналізації DSS1 і ОКС7 в сигнальні повідомлення Н.323 і виробляє зворотне перетворення, відповідно до Рекомендації ITU H.246.<br>
| |
| − | У придверні зосереджений весь інтелект мережі IP-телефонії. Мережа, побудована відповідно до рекомендації Н.323, має зонну архітектуру (рис. 1.6). Сторож виконує функції управління однією зоною мережі IP-телефонії, в яку входять: термінали, шлюзи, пристрої керування конференціями, зареєстровані у даного воротаря. Окремі фрагменти зони мережі Н.323 можуть бути територіально рознесені і з'єднуватися один з одним через маршрутизатори.<br>
| |
| − | <center>
| |
| − | [[Файл:VoIP_1.6.png]]<br>
| |
| − | '''Рис. 1.6.''' Зона мережі Н.323
| |
| − | </center><br>
| |
| − | Найбільш важливими функціями воротаря є:<br>
| |
| − | <ul>
| |
| − | <li>реєстрація кінцевих та інших пристроїв;</li>
| |
| − | <li>контроль доступу користувачів системи до послуг IP-телефонії за допомогою сигналізації RAS;</li>
| |
| − | <li>перетворення alias-... викликається користувача (оголошеного імені абонента, номер телефону, адреси електронної пошти тощо) в транспортна адреса мереж з маршрутизацією пакетів IP (IP адреса номер порту TCP);</li>
| |
| − | <li>контроль, управління і резервування пропускної здатності мережі;</li>
| |
| − | <li>ретрансляція сигнальних повідомлень Н.323 між терміналами.</li>
| |
| − | </ul>
| |
| − | В одній мережі IP-телефонії, що відповідає вимогам рекомендації ITU Н.323, може знаходитися декілька воротарів, що взаємодіють один з одним по протоколу RAS.<br>
| |
| − | Крім основних функцій, визначених рекомендацією Н.323, воротар може відповідати за аутентифікацію користувачів і нарахування плати (біллінг) за телефонні з'єднання.<br>
| |
| − | Пристрій управління конференціями забезпечує можливість організації зв'язку між трьома або більше учасниками. Рекомендація Н.323 передбачає три види конференції (рис. 1.7):<br>
| |
| − | централізована (тобто керована MCU, з яким кожен учасник конференції з'єднується в режимі точка-точка), децентралізована (коли кожен учасник конференції з'єднується з іншими її учасниками в режимі точка-група точок) і змішана.<br>
| |
| − | <center>
| |
| − | [[Файл:VoIP_1.7.png]]<br>
| |
| − | '''Рис. 1.7.''' Види конференції в мережах Н.323
| |
| − | </center><br>
| |
| − | Перевагою централізованої конференції є порівняно просте термінальне обладнання, недоліком - велика вартість пристрою управління конференціями.<br>
| |
| − | Для децентралізованої конференції потрібно більш складне термінальне обладнання і бажано, щоб у мережі IP підтримувалася передача пакетів IP у режимі під LGPL (IP multicasting). Якщо цей режим у мережі не підтримується, термінал повинен передавати мовну інформацію кожному з решти учасників конференції в режимі точка-крапка.<br>
| |
| − | Пристрій управління конференціями складається з одного обов'язкового елемента-контролера конференцій (Multipoint Controller - МС), і, крім того, може включати в себе один або більше процесора для обробки інформації користувача (Multipoint Processor - МР). Контролер може бути фізично суміщений з воротарем, шлюзом або пристроєм управління конференціями, а останнє, в свою чергу, може бути поєднане зі шлюзом або воротарем.<br>
| |
| − | Контролер конференцій використовується для організації конференції будь-якого виду. Він організовує обмін між учасниками конференції даними про режими, підтримуваних їх терміналами, і вказує, в якому режимі учасники конференції можуть передавати інформацію, причому в ході конференції цей режим може змінюватися, наприклад, при підключенні до неї нового учасника.<br>
| |
| − | Так як контролерів в мережі може бути декілька, для кожної знову створюваної конференції повинна бути проведена спеціальна процедура виявлення того контролера, який буде керувати даної конференцією.<br>
| |
| − | При організації централізованої конференції, крім контролера МС, повинен використовуватися процесор МР, що обробляє інформацію користувача. Процесор МР відповідає за перемикання або змішування мовних потоків, відеоінформації та даних. Для децентралізованої конференції процесор не потрібен.<br>
| |
| − | Існує ще один елемент мережі Н .323 - проксі-сервер Н.323, тобто сервер-посередник. Цей сервер функціонує на прикладному рівні і може перевіряти пакети з інформацією, якою обмінюються два додатки. Проксі-сервер може визначати, з яким додатком (Н.323 або іншим) асоційований виклик, і здійснювати потрібне з'єднання. Проксі-сервер виконує наступні ключові функції:<br>
| |
| − | <ul>
| |
| − | <li>підключення через засоби комутованого доступу або локальні мережі терміналів, не підтримують протокол резервування ресурсів (RSVP).Два таких проксі-сервера можуть утворити в IP-мережі тунельне з'єднання з заданою якістю обслуговування;</li>
| |
| − | <li>маршрутизацію трафіку Н.323 окремо від звичайного трафіку даних;</li>
| |
| − | <li>забезпечення сумісності з перетворювачем мережевих адрес, оскільки допускається розміщення обладнання Н.323 в мережах з простором адрес приватних мереж;</li>
| |
| − | <li>захист доступу - доступність тільки для трафіку Н.323.</li>
| |
| − | </ul>
| |
| − | <br>
| |
| − | Більш докладно архітектура мережі Н.323 буде розглянута в розділі 5, а зараз доцільно сказати кілька слів про протоколи сигналізації, що входять в сімейство Н.323.<br>
| |
| − | Протокол RAS (Registration, Admission, Status) забезпечує взаємодію кінцевих та інших пристроїв з воротарем. Основними функціями протоколу є: реєстрація пристрою в системі, контроль його доступу до мережевих ресурсів, зміна смуги пропускання в процесі зв'язку, опитування та індикація поточного стану пристрою. В якості транспортного протоколу використовується протокол з негарантованої доставкою інформації UDP.<br>
| |
| − | Протокол Н.225.0 (Q.931) підтримує процедури встановлення, підтримки і руйнування з'єднання. В якості транспортного протоколу використовується протокол із установленням з'єднання і гарантованою доставкою інформації TCP.<br>
| |
| − | За протоколом Н.245 відбувається обмін між учасниками з'єднання інформацією, яка необхідна для створення логічних каналів. За цим каналам передається мовна інформація, упакована в пакети RTP / UDP / IP.<br>
| |
| − | Виконання процедур, передбачених протоколом RAS, є початковою фазою встановлення з'єднання з використанням сигналізації Н.323. Далі слідують фаза сигналізації Н.225.0 (Q.931) та обмін керуючими повідомленнями Н.245. Руйнування з'єднання відбувається в зворотній послідовності: в першу чергу закривається керуючий канал Н.245 і сигнальний канал Н.225.0, після чого воротар по каналу RAS оповіщається про звільнення раніше займалася смуги пропускання.<br>
| |
| − | Складність протоколу Н.323 демонструє рис. 1.8, на якому представлений спрощений сценарій встановлення з'єднання між двома користувачами. У даному сценарії припускається, що кінцеві користувачі вже знають IP-адреси один одного. У звичайному випадку етапів буває більше, оскільки у встановленні з'єднання беруть участь придверні, і шлюзи.<br>
| |
| − | Розглянемо крок за кроком цей спрощений сценарій.<br>
| |
| − | <ol>
| |
| − | <li>Кінцевий пристрій користувача А посилає запит з'єднання - повідомлення SETUP - до кінцевого пристрою користувача ВнаТСР-порт1720.</li>
| |
| − | <li>Кінцевий пристрій викликається користувача В відповідає на повідомлення SETUP повідомленням ALERTING, що означає, що пристрій вільно, а викликається користувачеві подається сигнал про вхідний дзвінок.</li>
| |
| − | <li>Після того, як користувач У приймає виклик, до викликає стороні А передається повідомлення CONNECT з номером ТСР-порту керуючого каналу Н.245.</li>
| |
| − | <li>Кінцеві пристрої обмінюються по каналу Н.245 інформацією про типи використовуваних мовних кодеків (G.729, G.723.1 і т.д.), а також про інші функціональні можливості обладнання, і сповіщають один одного про номери портів RTP, на які слід передавати інформацію.</li>
| |
| − | <li>Відкриваються логічні канали для передачі мовної інформації.</li>
| |
| − | <li>Мовна інформація передається в обидві сторони в повідомленнях протоколу RTP, крім того, ведеться контроль передачі інформації за допомогою протоколу RTCP.</li>
| |
| − | </ol>
| |
| − | <br>
| |
| − | <center>
| |
| − | [[Файл:VoIP_1.8.png]]<br>
| |
| − | '''Рис. 1.8.''' Спрощений сценарій встановлення з'єднання в мережі Н.323
| |
| − | </center><br>
| |
| − | Наведена процедура обслуговування виклику базується на протоколі Н.323 версії 1. Версія 2 протоколу Н.323 дозволяє передавати інформацію, необхідну для створення логічних каналів, безпосередньо в повідомленні SETUP протоколу Н.225.0 без використання протоколу Н.245. Така процедура називається «швидкий старт» (Fast Start) і дозволяє скоротити кількість циклів обміну інформацією при встановленні з'єднання. Крім організації базового з'єднання, в мережах Н.323 передбачено надання додаткових послуг відповідно до рекомендацій ITU H.450.X. Більш детальний огляд сигналізації Н.323 у главі 6.<br>
| |
| − | Слід відзначити ще одну важливу проблему - якість обслуговування в мережах Н.323. Кінцевий пристрій, запитуюча у вартового дозвіл на доступ, може, використовуючи поле transportQoS в повідомленні ARQ протоколу RAS, повідомити про свою здатність резервувати мережеві ресурси. Рекомендація Н.323 визначає протокол резервування ресурсів (RSVP) як засіб забезпечення гарантованої якості обслуговування, що пред'являє до терміналів вимога підтримки протоколу RSVP. На жаль, протокол RSVP використовується аж ніяк не повсюдно, що залишає мережі Н.323 без основного механізму забезпечення гарантованої якості обслуговування. Це - загальна проблема мереж IP-телефонії, характерна не тільки для мереж Н.323.<br>
| |
| − | Моніторинг якості обслуговування забезпечується протоколом RTCP, однак обмін інформацією RTCP відбувається тільки між кінцевими пристроями, які беруть участь в з'єднанні. Більш докладно ця проблематика розглядається в розділі 10, повністю присвяченій якості обслуговування викликів IP-телефонії.<br>
| |
| − |
| |
| − | '''''1.5.2 Мережа на базі протоколу SIP'''''<br>
| |
| − | Другий підхід до побудови мереж IP-телефонії, запропонований робочою групою MMUSIC комітету IETF в документі RFC 2543 [54], заснований на використанні протоколу SIP - Session Initiation Protocol. SIP є текст - орієнтований протокол, який є частиною глобальної архітектури мультимедіа, розробленої комітетом Internet Engineering Task Force (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), протокол повідомлення про зв'язок (Session Announcement Protocol, SAP). Однак функції протоколу SIP не залежать від будь-якого з цих протоколів.<br>
| |
| − | Відразу слід зазначити, що хоча на сьогодні найбільш широке поширення одержав протокол Н.323, все більша кількість виробників намагається передбачити у своїх нових продуктах підтримку протоколу SIP. Поки що це - одиничні явища і серйозної конкуренції протоколу Н.323 вони скласти не можуть. Однак, враховуючи темпи зростання популярності протоколу SIP, досить імовірно, що в найближчому майбутньому рішення на його базі займуть значну нішу ринку IP-телефонії.<br>
| |
| − | Підхід SIP до побудови мереж IP-телефонії набагато простіше в реалізації, ніж Н.323, але менше підходить для організації взаємодії з телефонними мережами. В основному це пов'язано з тим, що протокол сигналізації SIP, що базується на протоколі HTTP, погано узгоджується з системами сигналізації, що використовуються в ТФОП. Тому протокол SIP більше підходить постачальникам послуг Інтернет для надання послуги IP-телефонії, причому ця послуга буде всього лише частиною пакету послуг.
| |
| − | Тим не менш, протокол SIP підтримує послуги інтелектуальної мережі (IN), такі як перетворення (меппінг) імен, переадресація та маршрутизація [8], що істотно для використання SIP як протокол сигналізації в мережі загального користування, де пріоритетним завданням оператора є надання широкого спектру телефонних послуг. Іншою важливою особливістю протоколу SIP є підтримка мобільності користувача, тобто його здатність отримувати доступ до замовлених послуг в будь-якому місці і з будь-якого терміналу, а також здатності мережі ідентифікувати та автентифікувати користувача при його переміщенні з одного місця в інше. Це властивість SIP не унікально, і, наприклад, протокол Н.323 теж значною мірою підтримує таку можливість. Зараз настав момент, коли ця можливість стане головною привабливою рисою мереж IP-телефонії нового покоління. Даний режим роботи зажадає дистанційної реєстрації користувачів на сервері ідентифікації і аутентифікації.<br>
| |
| − | Перейдемо безпосередньо до архітектури мереж, що базуються на протоколі SIP (рис. 1.9).
| |
| − | <br>
| |
| − | <center>
| |
| − | [[Файл:VoIP_1.9.png]]<br>
| |
| − | '''Рис. 1.9.''' Приклад мережі на базі протоколу SIP
| |
| − | </center><br>
| |
| − | Мережа SIP містить основні елементи трьох видів: агенти користувача, проксі-сервери і сервери переадресації.
| |
| − | Агенти користувача (User Agent або SIP client) є додатками термінального обладнання і включають в себе дві складові: агент користувача - клієнт (User Agent Client - UAC) і агент користувача - сервер (User Agent Server - UAS), інакше відомі як клієнт і сервер відповідно. Клієнт UAC ініціює SIP-запити, тобто виступає в якості зухвалої сторони. Сервер UAS приймає запити і повертає відповіді, тобто виступає в якості викликається сторони.<br>
| |
| − | Крім того, існує два типи мережевих серверів SIP: проксі-сервери (сервери-посередники) і сервери переадресації. Сервери SIP можуть працювати як в режимі зі збереженням станів поточних з'єднань (statefull), так і в режимі без збереження станів поточних з'єднань (stateless). Сервер SIP, що функціонує в режимі stateless, може обслужити як завгодно велику кількість користувачів, на відміну від воротаря Н.323, який може одночасно працювати з обмеженою кількістю користувачів.<br>
| |
| − | Проксі-сервер (Proxy-server) діє "від імені інших клієнтів» і містить функції клієнта (UAC) і сервера (UAS). Цей сервер інтерпретує і може перезаписувати заголовки запитів перед відправленням їх до інших серверів (рис. 1.10). Відповідні повідомлення слідують по тому ж шляху назад до проксі-сервера, а не до клієнта.
| |
| − | <br>
| |
| − | <center>
| |
| − | [[Файл:VoIP_1.10.png]]<br>
| |
| − | '''Рис. 1.10.''' Мережа SIP з проксі-сервером
| |
| − | </center><br>
| |
| − | Нижче представлений алгоритм встановлення з'єднання за допомогою протоколу SIP за участю проксі-сервера:<br>
| |
| − | <ol>
| |
| − | <li>Проксі-сервер приймає запит з'єднання INVITE від устаткування викликає користувача.</li>
| |
| − | <li>Проксі-сервер установлює місцезнаходження клієнта за допомогою сервера позиціонування (location server).</li>
| |
| − | <li>Проксі-сервер передає запит INVITE викликається користувачеві.</li>
| |
| − | <li>Обладнання викликається користувача повідомляє останнього про вхідний дзвінок і повертає проксі-сервера повідомлення про те, що запит INVITE обробляється (код 100). Проксі-сервер, у свою чергу, направляє цю інформацію обладнанню викликає користувача.</li>
| |
| − | <li>Коли абонент, що викликається приймає виклик, його обладнання сповіщає про це проксі-сервер (код 200), який переправляє інформацію про те, що дзвінок, до обладнання викликає користувача.</li>
| |
| − | <li>Викликаюча сторона підтверджує встановлення з'єднання передачею запиту АСК, яке проксі-сервер переправляє викликається стороні. Встановлення з'єднання закінчено, абоненти можуть обмінюватися мовною інформацією.</li>
| |
| − | </ol>
| |
| − | <br>
| |
| − | Сервер переадресації (Redirect server) визначає поточне місце розташування абонента, що викликається і повідомляє його зухвалому користувачеві (рис. 1.11). Для визначення поточного місцезнаходження абонента, що викликається сервер переадресації звертається до сервера визначення місця розташування, принципи роботи якого в документі RFC 2543 не специфіковані.<br>
| |
| − | <center>
| |
| − | [[Файл:VoIP_1.11.png]]<br>
| |
| − | '''Рис. 1.11.''' Мережа SIP з сервером переадресації
| |
| − | </center><br>
| |
| − | Алгоритм встановлення з'єднання з використанням протоколу SIP за участю сервера переадресації виглядає наступним чином:<br>
| |
| − | <ol>
| |
| − | <li>Сервер переадресації приймає від зухвалої сторони запит з'єднання INVITE і зв'язується з сервером визначення місцезнаходження, який видає поточну адресу викликається клієнта.</li>
| |
| − | <li>Сервер переадресації передає цю адресу викликає стороні. На відміну від проксі-сервера, запит INVITE до обладнання викликається користувача сервер переадресації не передає.</li>
| |
| − | <li>Обладнання викликає користувача підтверджує завершення транзакції з сервером переадресації запитом АСК.</li>
| |
| − | <li>Далі обладнання викликає користувача передає запит INVITE на адресу, отриманий від сервера переадресації.</li>
| |
| − | <li>Обладнання викликається користувача повідомляє останнього про вхідний дзвінок і повертає зухвалому обладнанню повідомлення про те, що запит INVITE обробляється (код 100).</li>
| |
| − | <li>Коли абонент, що викликається приймає виклик, про це сповіщається обладнання викликає користувача (код 200). Встановлення з'єднання закінчено, абоненти можуть обмінюватися мовною інформацією.</li>
| |
| − | </ol>
| |
| − | <br>
| |
| − | Існує також і безсерверний варіант з'єднання, коли один термінал може передати запит іншому терміналу безпосередньо.
| |
| − | Дамо коротку характеристику самого протоколу SIP. Слід зауважити, що повідомлення SIP можуть переноситися як протоколом TCP, так і протоколом UDP.<br>
| |
| − | Протокол SIP передбачає 6 запитів і відповідей на них. Сигналізація SIP дає можливість для користувача агентам і мережевих серверів визначати місце розташування, видавати запити і керувати з'єднаннями.<br>
| |
| − | '''INVITE''' - запит приваблює користувача або послугу до участі в сеансі зв'язку і містить опис параметрів зв'язку з цим. За допомогою цього запиту користувач може визначити функціональні можливості терміналу свого партнера по зв'язку і почати сеанс зв'язку, використовуючи обмежене число повідомлень і підтверджень їх прийому.<br>
| |
| − | '''АСК''' - запит підтверджує прийом від викликається сторони відповіді на команду INVITE і завершує транзакцію.<br>
| |
| − | '''OPTIONS''' - запит дозволяє отримати інформацію про функціональні можливості користувацьких агентів і мережевих серверів. Однак цей запит не використовується для організації сеансів зв'язку.<br>
| |
| − | '''BYE''' - запит використовується викликає і що викликається сторонами для руйнування з'єднання. Перед тим як зруйнувати з'єднання, призначені для користувача агенти відправляють цей запит до сервера, повідомляючи про намір припинити сеанс зв'язку.<br>
| |
| − | '''CANCEL'''-запит дозволяє користувальницьким агентам і мережевих серверів скасувати будь-який раніше переданий запит, якщо відповідь на неї ще не був отриманий.<br>
| |
| − | '''REGISTER''' - запит застосовується клієнтами для реєстрації інформації про місцезнаходження з використанням серверів SIP.
| |
| − | Більш детальна інформація про протокол SIP приведено у розділі 7.<br>
| |
| − | '''''1.5.3 Мережа на базі MGCP і MEGACO'''''<br>
| |
| − | Третій підхід до побудови мереж IP-телефонії, заснований на використанні протоколу MGCP [56], також запропоновано комітетом IETF, робочою групою MEGACO.<br>
| |
| − | При розробці цього протоколу робоча група MEGACO спиралася на мережеву архітектуру, яка містить основні функціональні блоки трьох видів (рис. 1.12):<br>
| |
| − | <ul>
| |
| − | <li>шлюз - Media Gateway (MG), який виконує функції перетворення мовної інформації, що поступає з боку ТфОП з постійною швидкістю передачі, у вигляд, придатний для передачі по мережах з маршрутизацією пакетів IP (кодування і упаковку мовної інформації в пакети RTP / UDP / IP , а також зворотне перетворення);</li>
| |
| − | <li>контролер шлюзів - Call Agent, якої виконує функції управління шлюзами;</li>
| |
| − | <li>шлюз сигналізації - Signaling Gateway (SG), який забезпечує доставку сигнальної інформації, що поступає з боку ТфОП, до контролера шлюзів і перенесення сигнальної інформації в зворотному напрямку.</li>
| |
| − | </ul>
| |
| − | <br>
| |
| − | <center>
| |
| − | [[Файл:VoIP_1.12.png]]<br>
| |
| − | '''Рис. 1.12.''' Архітектура мережі на базі протоколу MGCP
| |
| − | </center><br>
| |
| − | Таким чином, весь інтелект функціонально розподіленого шлюзу зосереджений в контролері, функції якого можуть бути розподілені між кількома комп'ютерними платформами.<br>
| |
| − |
| |
| − | Шлюз сигналізації виконує функції STP - транзитного пункту мережі сигналізації ОКС7. Самі шлюзи виконують тільки функції перетворення мовної інформації. Один контролер управляє одночасно декількома шлюзами. У мережі можуть бути присутні кілька контролерів. Передбачається, що вони синхронізовані між собою і злагоджено управляють шлюзами, що беруть участь в з'єднанні. Разом з тим, MEGACO не визначає протоколу для синхронізації роботи контролерів. У ряді робіт, присвячених дослідженню можливостей протоколу MGCP, для цієї мети пропонується використовувати протоколи Н.323, SIP або ISUP / IP.<br>
| |
| − | Повідомлення протоколу MGCP переносяться протоколом без гарантованої доставки повідомлень UDP. Робоча група SIGTRAN комітету IETF в даний час розробляє механізм взаємодії контролера шлюзів і шлюзу сигналізації.<br>
| |
| − | Шлюз сигналізації повинен приймати надходять з ТфОП пакети трьох нижніх рівнів системи сигналізації ОКС7 (рівнів підсистеми перенесення повідомлень МТР) і передавати сигнальні повідомлення верхнього, користувальницького, рівня до контролера шлюзів. Шлюз сигналізації також повинен вміти передавати по IP-мережі приходять з ТфОП сигнальні повідомлення Q.931.<br>
| |
| − | Основну увагу робочої групи SIGTRAN приділяється питанням розробки найбільш ефективного механізму передачі сигнальної інформації по IP-мереж. Слід зазначити, що існує кілька причин, з яких довелося відмовитися від використання для цієї мети протоколу TCP. Робоча група SIGTRAN пропонує використовувати для передачі сигнальної інформації протокол Stream Control Transport Protocol (SCTP), що має ряд переваг перед протоколом ТСР, основним з яких є значне зниження часу доставки сигнальної інформації і, отже, часу встановлення з'єднання - одного з найважливіших параметрів якості обслуговування.<br>
| |
| − | Якщо в ТфОП використовується сигналізація по виділених каналах сигнальним (ТСК), то сигнали спочатку надходять разом з користувацької інформацією в транспортний шлюз, а потім передаються в контролер шлюзів без посередництва шлюзу сигналізації.<br>
| |
| − | Відзначимо, що протокол MGCP є внутрішнім протоколом для обміну інформацією між функціональними блоками розподіленого шлюзу, який ззовні видається одним шлюзом. Протокол MGCP є master / slave протоколом. Це означає, що контролер шлюзів є провідним, а сам шлюз - веденим пристроєм, який має виконувати всі команди, що надходять від контролера Call Agent.<br>
| |
| − | Вищеописане рішення забезпечує масштабованість мережі і простоту управління мережею через контролер шлюзів. Шлюзи не повинні бути інтелектуальними пристроями, вимагають меншої продуктивності процесорів і, отже, стають менш дорогими. Крім того, дуже швидко вводяться нові протоколи сигналізації або додаткові послуги, так як ці зміни стосуються тільки контролер шлюзів, а не самі шлюзи.
| |
| − | Третій підхід, запропонований організацією IETF (робоча група MEGACO), добре підходить для розгортання глобальних мереж IP-телефонії, що приходять на зміну традиційним телефонних мереж. Більш детальна інформація про протокол MGCP приведено у розділі 8.<br>
| |
| − | Розглянемо алгоритми встановлення і руйнування з'єднання з використанням протоколу MGCP. Перший приклад охоплює взаємодію протоколу MGCP з протоколом ОКС7 (рис. 1.13).<br>
| |
| − | <br>
| |
| − | <center>
| |
| − | [[Файл:VoIP_1.13.png]]<br>
| |
| − | '''Рис. 1.13.''' Встановлення і руйнування з'єднання з використанням протоколу MGCP (Приклад 1)
| |
| − | </center><br>
| |
| − | <ol>
| |
| − | <li>Від телефонної станції АТС-А до шлюзу сигналізації SG1 за загальним каналу сигналізації надходить запит з'єднання у вигляді повідомлення IAM протоколу ISUP [6]. На рис. 1.13 шлюз сигналізації SG1 і SG2 суміщені з транспортними шлюзами TGW1 і TGW2 відповідно. Шлюз SG1 передає повідомлення IAM до контролера шлюзів, який обробляє запит і визначає, що виклик повинен бути направлений до АТС-Б за допомогою шлюзу TGW2.</li>
| |
| − | <li>Контролер резервує порт шлюзу TGW1 (розмовний канал). З цією метою він передає до шлюзу команду CreateConnection. Відзначимо, що порт шлюзу TGW1 може тільки приймати інформацію (режим «recvonly»), так як він ще не обізнаний про те, за якою адресою і яким чином їй слід передавати інформацію.</li>
| |
| − | <li>У відповіді на цю команду шлюз TGW1 повертає опис параметрів сеансу зв'язку.</li>
| |
| − | <li>Прийнявши відповідь шлюзу TGW1, контролер передає команду CRCX другого шлюзу TGW2 з метою зарезервувати порт в цьому шлюзі.</li>
| |
| − | <li>Шлюз TGW2 вибирає порт, який буде брати участь в з'єднанні, і підтверджує прийом команди CRCX. За допомогою двох команд CRCX створюється односпрямований розмовний канал для передачі, хто телефонує акустичних сигналів чи мовних підказок і повідомлень. У той же час, порт шлюзу TGW2 вже може не тільки приймати, але і передавати інформацію, так як він отримав опис параметрів зв'язку від зустрічного шлюзу.</li>
| |
| − | <li>Далі контролер шлюзів передає повідомлення IAM до АТС-Б.</li>
| |
| − | <li>На повідомлення IAM станція АТС-Б відповідає підтвердженням АСМ, яке негайно пересилається до станції АТС-А.</li>
| |
| − | <li>Після того як абонент прийме виклик, АТС-Б передає до контролера шлюзів повідомлення ANM.</li>
| |
| − | <li>Далі контролер заміняє у шлюзі TGW1 режим «recvonly» на повнодуплексний режим за допомогою команди MDCX.</li>
| |
| − | <li>Шлюз TGW1 виконує і підтверджує зміну режиму.</li>
| |
| − | <li>Контролер передає повідомлення ANM до АТС-А, після чого починається розмовна фаза з'єднання.</li>
| |
| − | <li>Завершення розмовної фази відбувається наступним чином. У нашому випадку викликав абонент Б дає відбій першим. АТС-Б передає через шлюз сигналізації повідомлення REL до контролера шлюзів.</li>
| |
| − | <li>Прийнявши повідомлення REL, контролер шлюзів завершує з'єднання з викликаним абонентом.</li>
| |
| − | <li>Шлюз підтверджує завершення з'єднання і передає до контролера зібрані за час з'єднання статистичні дані.</li>
| |
| − | <li>Контролер шлюзів передає повідомлення RLC до АТС-Б з метою підтвердити роз'єднання.</li>
| |
| − | <li>Паралельно контролер завершує з'єднання з викликала стороною.</li>
| |
| − | <li>ШлюзТGW1 підтверджує завершення з'єднання і передає до контролера зібрані за час з'єднання статистичні дані.</li>
| |
| − | <li>АТС-А підтверджує завершення з'єднання передачею повідомлення RLC, після чого з'єднання вважається зруйнованим.</li>
| |
| − | </ol>
| |
| − | Другий приклад ілюструє взаємодію протоколу MGCP з протоколами ОКС7 і Н.323 (рис. 1.14).
| |
| − | <br>
| |
| − | <center>
| |
| − | [[Файл:VoIP_1.14.png]]<br>
| |
| − | '''Рис. 1.14.''' Встановлення і руйнування з'єднання з використанням протоколу MGCP (Приклад 2)
| |
| − | </center><br>
| |
| − | <ol>
| |
| − | <li>З телефонної станції АТС-А до шлюзу сигналізації SG1 за загальним каналу сигналізації надходить запит з'єднання (повідомлення IAM). На рис. 1.14 шлюз сигналізації SG1 також суміщений з транспортним шлюзом TGW1. Шлюз SG1 передає повідомлення IAM контролеру шлюзів, який обробляє запит і визначає, що виклик повинен бути направлений до кінцевого пристрою викликається користувача - терміналу Н.323.</li>
| |
| − | <li>Контролер шлюзів резервує порт шлюзу TGW1 (розмовний канал). З цією метою він передає до шлюзу команду CreateConnec-tion. І в цьому прикладі порт шлюзу TGW1 може тільки приймати інформацію (режим «recvonly»).</li>
| |
| − | <li>У відповіді на прийняту команду шлюз TGW1 повертає опис параметрів зв'язку.</li>
| |
| − | <li>Прийнявши відповідь від шлюзу TGW1, контролер передає до воротаря мережі Н.323 повідомлення ARQ з alias адресою абонента, що викликається.</li>
| |
| − | <li>У відповідь на повідомлення ARQ воротар передає повідомлення ACF із зазначенням транспортного адреси свого сигнального каналу.</li>
| |
| − | <li>Контролер передає запит з'єднання SETUP на транспортний адресу сигнального каналу воротаря, при цьому використовується процедура Fast Start. Сторож пересилає повідомлення SETUP до викликуваного терміналу.</li>
| |
| − | <li>Викликаний термінал передає запит допуску до ресурсів мережі ARQ.</li>
| |
| − | <li>У відповідь на запит ARQ воротар передає підтвердження запиту ACF.</li>
| |
| − | <li>Викликаний термінал передає повідомлення ALERTING, яке воротар маршрутизує до контролера шлюзів. При цьому викликається користувачеві подається візуальний або акустичний сигнал про вхідний дзвінок, а зухвалому користувачеві подається індикація того, що користувач, що викликається не зайнятий і отримує сигнал про виклик.</li>
| |
| − | <li>Контролер перетворює повідомлення ALERTING до повідомлення АСМ, яке негайно пересилається до АТС-А.</li>
| |
| − | <li>Після того як користувач, що викликається візьме вхідний дзвінок, контроллер отримає повідомлення CONNECT.</li>
| |
| − | <li>Контролер шлюзів змінює в шлюзі TGW1 режим «recvonly» на повнодуплексний режим.</li>
| |
| − | <li>Шлюз TGW1 виконує і підтверджує зміну режиму з'єднання.</li>
| |
| − | <li>Контролер передає повідомлення ANM до АТС-А, після чого починається розмовна фаза з'єднання, в ході якої устаткування викликав користувача передає мовну інформацію, упаковану в пакети RTP / UDP / IP, на транспортний адресу RTP-каналу терміналу викликаного абонента, а той передає пакетованих мовну інформацію на транспортний адресу RTP-каналу терміналу викликав абонента. За допомогою каналу RTCP ведеться контроль передачі інформації з RTP каналу.</li>
| |
| − | <li>Після закінчення розмовної фази починається фаза руйнування з'єднання. Обладнання користувача, що ініціює руйнування з'єднання, повинно припинити передачу мовної інформації, закрити логічні канали і передати повідомлення RELEASE COMPLETE, після чого сигнальний канал закривається.</li>
| |
| − | <li>Контролер шлюзів передає повідомлення RELEASE до АТС-А з метою завершення з'єднання.</li>
| |
| − | <li>Крім того, контролер передає до шлюзу команду DLCX.</li>
| |
| − | <li>Шлюз підтверджує завершення з'єднання і передає до контролера зібрані за час з'єднання статистичні дані.</li>
| |
| − | <li>Після вищеописаних дій контролер і кінцеве обладнання сповіщають воротар про звільнення займалася смуги пропускання. З цією метою кожен з учасників з'єднання посилає воротареві по каналу RAS запит виходу із з'єднання DRQ, на який воротар повинен передати підтвердження DCF.</li>
| |
| − | <li>Від АТС-А приходить підтвердження роз'єднання RLC, після чого з'єднання вважається зруйнованим.</li>
| |
| − | </ol><br>
| |
| − | Слід зауважити, що алгоритм взаємодії протоколів SIP і MGCP не сильно відрізняється від вищеописаного алгоритму.<br>
| |
| − | Робоча група MEGACO комітету IETF продовжує роботу з удосконалення протоколу управління шлюзами, в рамках якої розроблено більш функціональний, ніж MGCP, протокол MEGACO.<br>
| |
| − | Міжнародний союз електрозв'язку в проекті версії 4 рекомендації Н.323 ввів принцип декомпозиції шлюзів. Управління функціональними блоками розподіленого шлюзу буде здійснюватися контролером шлюзу - Media Gateway Controller - за допомогою адаптованого до Н.323 протоколу MEGACO, який в рекомендації Н.248 названий Gateway Control Protocol.<br>
| |
| − | Повідомлення протоколу MEGACO відрізняються від повідомлень протоколу MGCP, але процедури встановлення і руйнування з'єднань з використанням обох протоколів ідентичні, тому опис процедури встановлення з'єднання на базі протоколу MEGACO тут не наводиться. Ці процедури, разом з детальним аналізом протоколу MEGACO, розглядаються в розділі 9.<br>
| |
| − |
| |
| − |
| |
| − |
| |
| − | '''''1.5.4 Порівняння підходів до побудови мережі IP-телефонії'''''
| |
| − |
| |
| − |
| |
| − | В даний час для побудови добре функціонуючих і сумісних з ТфОП мереж IP-телефонії підходять протоколи Н.323 і MGCP. Як вже зазначалося, протокол SIP дещо гірше взаємодіє з системами сигналізації, що використовуються в ТфОП (порівняльний аналіз протоколів Н.323 і SIP можна знайти у главі 7).<br>
| |
| − |
| |
| − | Підхід, заснований на використанні протоколу MGCP, має досить важливою перевагою перед підходом, запропонованим ITU в рекомендації Н.323: підтримка контролером шлюзів сигналізації ОКС7 і інших видів сигналізації, а також прозора трансляція сигнальної інформації по мережі IP-телефонії. У мережі, побудованої на базі рекомендації Н.323, сигналізація ОКС7, як і будь-яка інша сигналізація, конвертується шлюзом в сигнальні повідомлення Н.225.0 (Q.931).<br>
| |
| − | Основним недоліком третього з наведених у цьому параграфі підходів є незакінченість стандартів. Функціональні складові розподілених шлюзів, розроблені різними фірмами-виробниками телекомунікаційного обладнання, практично несумісні. Функції контролера шлюзів точно не визначені. Не стандартизовані механізми перенесення сигнальної інформації від шлюзу сигналізації до контролера і в зворотному напрямку. До недоліків можна віднести також відсутність стандартизованого протоколу взаємодії між контролерами. Крім того, протокол MGCP є протоколом управління шлюзами, але не призначений для управління з'єднаннями за участю термінального обладнання користувачів (IP-телефонів). Це означає, що в мережі, побудованої на базі протоколу MGCP, для управління термінальним устаткуванням повинен бути присутнім воротар або сервер SIP.<br>
| |
| − | Варто також відзначити, що в існуючих програмах IP-телефонії, таких як надання послуг міжнародного та міжміського зв'язку, використовувати протокол MGCP (також, як і протокол SIP) недоцільно в зв'язку з тим, що переважна кількість мереж IP-телефонії сьогодні побудовано на базі протоколу Н.323. Оператору доведеться будувати окрему мережу IP-телефонії на базі протоколу MGCP (або SIP), що пов'язано зі значними капіталовкладеннями. У той же час, оператор зв'язку, що має обладнання стандарту Н.323, може приєднатися до існуючих мереж IP-телефонії.<br>
| |
| − | В останньому із згаданих підходів (у проекті версії 4 рекомендації Н.323) ITU-Т ввів принцип декомпозиції шлюзів, використаний у третьому підході. Управління функціональними блоками розподіленого шлюзу буде здійснюватися контролером шлюзу - MGC (Media Gateway Controller) за допомогою протоколу MEGACO/H.248. У проекті версії 4 рекомендації Н.323 передбачена також можливість прозорої передачі сигналізації ОКС7 і інших видів сигналізації по мережах IP-телефонії та обробка сигналізації всіх видів придверний без перетворення в сигнальні повідомлення Н.225.0.<br>
| |
| − |
| |
| − | Наведених у цій главі відомостей аж ніяк не достатньо для остаточних висновків щодо перспектив використання того або іншого протоколу IP-телефонії, хоча перше враження вже може скластися. У наступних розділах автори постараються представити більш глибокі відомості з даної тематики, проте зобов'язуються не нав'язувати читачеві якусь одну точку зору, а дати йому все необхідне для того, щоб він міг сам зробити належні висновки.<br>
| |
| − | <br>
| |
| − |
| |
| | ---- | | ---- |
| − | <div style="background: #33ccff">
| + | [ '''[[Технологія VoIP]]''' ][ [[Розділ_2._Мережеві_аспекти_IP-телефонії|Розділ 2. Мережеві аспекти IP-телефонії >>]] ] |
| − | <center>
| + | ---- |
| − | [[http://wiki.kspu.kr.ua/index.php/Технологія_VoIP Зміст]] | + | |
| − | [[http://wiki.kspu.kr.ua/index.php?title=Розділ_2._Мережеві_аспекти_IP-телефонії Розділ 2. Мережеві аспекти ІР-телефонії]] | + | |
| | </center> | | </center> |
| | </div> | | </div> |
| − | ----
| + | |
| | --[[Користувач:Козінцев Олексій|Козінцев Олексій 36 гр.]] 04:14, 3 листопада 2010 (EET) | | --[[Користувач:Козінцев Олексій|Козінцев Олексій 36 гр.]] 04:14, 3 листопада 2010 (EET) |
