|
|
| (не показано 5 проміжних версій цього учасника) |
| Рядок 1: |
Рядок 1: |
| | + | <div style="background: #33ccff"> |
| | + | '''[[Технологія VoIP]]''' >> |
| | + | '''[[Розділ_1._Конвергенція_мереж_зв'язку|Розділ 1.Конвергенція мереж зв'язку]]''' |
| | + | <center> |
| | + | ---- |
| | + | [ [[Рівні_архітектури_IP-телефонії|<< 1.4. Рівні архітектури IP-телефонії]] ] |
| | + | [ [[Побудова_мережі_за_рекомендацією_Н.323 |1.5.1. Побудова мережі за рекомендацією Н.323 >>]] ] |
| | + | ---- |
| | + | </center> |
| | + | </div> |
| | + | |
| | == '''1.5 Різні підходи до побудови мереж IP-телефонії''' == | | == '''1.5 Різні підходи до побудови мереж IP-телефонії''' == |
| | | | |
| | Щоб стало зрозуміло, чим конкретно відрізняються один від одного перераховані у попередньому параграфі протоколи, коротко розглянемо архітектуру мереж, побудованих на базі цих протоколів, і процедури встановлення та завершення з'єднання з їх використанням. | | Щоб стало зрозуміло, чим конкретно відрізняються один від одного перераховані у попередньому параграфі протоколи, коротко розглянемо архітектуру мереж, побудованих на базі цих протоколів, і процедури встановлення та завершення з'єднання з їх використанням. |
| | <br> | | <br> |
| − | '''''1.5.1 Побудова мережі за рекомендацією Н.323''''' <br>
| + | 1.5.1 [[Побудова мережі за рекомендацією Н.323]]<br> |
| − | Перший в історії підхід до побудови мереж IP-телефонії на стандартизованої основі запропоновано Міжнародним союзом електрозв'язку (ITU) в рекомендації Н.323 [42]. Мережі на базі протоколів Н.323 орієнтовані на інтеграцію з телефонними мережами і можуть розглядатися як мережі ISDN, накладені на мережі передачі даних. Зокрема, процедура встановлення з'єднання в таких мережах IP-телефонії базується на рекомендації Q.931 [44] і аналогічна процедурі, яка використовується в мережах ISDN.
| + | 1.5.2 [[Мережа на базі протоколу SIP]]<br> |
| − | <br> | + | 1.5.3 [[Мережа на базі MGCP і MEGACO]]<br> |
| − | Рекомендація Н.323 передбачає досить складний набір протоколів, який призначений не просто для передачі мовної інформації по IP-мереж з комутацією пакетів. Його мета - забезпечити роботу мультимедійних додатків у мережах з негарантованих якістю обслуговування. Мовний трафік - це тільки один з додатків Н.323, поряд з відео і даними. Атак як нічого в техніці (як і в житті) не дістається задарма, забезпечення сумісності з Н.323 різних мультимедійних додатків вимагає досить значних зусиль. Наприклад, для реалізації функції перемикання зв'язку (call transfer) потрібна окрема специфікація Н.450.2.
| + | 1.5.4 [[Порівняння підходів до побудови мережі IP-телефонії]]<br> |
| − | Варіант побудови мереж IP-телефонії, запропонований Міжнародним союзом електрозв'язку в рекомендації Н.323, добре підходить тим операторам місцевих телефонних мереж, які зацікавлені у використанні мережі з комутацією пакетів (IP-мережі) для надання послуг міжміського і міжнародного зв'язку. Протокол RAS, що входить у сімейство протоколів Н.323, забезпечує контроль використання мережевих ресурсів, підтримує аутентифікацію користувачів і може забезпечувати нарахування плати за послуги. <br>
| + | <div style="background: #33ccff"> |
| − | На рис 1.5. представлена архітектура мережі на базі рекомендації Н.323. Основними пристроями мережі є: термінал (Terminal), шлюз (Gateway), воротар (Gatekeeper) і пристрій керування конференціями (Multipoint Control Unit-MCU).<br>
| + | |
| | <center> | | <center> |
| − | [[Файл:VoIP_1.5.png]]<br>
| + | ---- |
| − | '''Рис. 1.5.''' Архітектура мережі Н.323
| + | [ [[Рівні_архітектури_IP-телефонії|<< 1.4. Рівні архітектури IP-телефонії]] ] |
| − | </center><br>
| + | [ [[Побудова_мережі_за_рекомендацією_Н.323 |1.5.1. Побудова мережі за рекомендацією Н.323 >>]] ] |
| − | Термінал Н.323 - крайовий пристрій користувача мережі IP-телефонії, яке забезпечує двосторонній мовну (мультимедійну) зв'язок з іншим терміналом Н.323, шлюзом або пристроєм управління конференціями.<br>
| + | ---- |
| − | Шлюз IP-телефонії реалізує передачу мовного трафіку по мережах з маршрутизацією пакетів IP по протоколу Н.323. Основне призначення шлюзу - перетворення мовної інформації, що поступає з боку ТФОП, у вигляд, придатний для передачі по мережах з маршрутизацією пакетів IP. Крім того, шлюз перетворює сигнальні повідомлення систем сигналізації DSS1 і ОКС7 в сигнальні повідомлення Н.323 і виробляє зворотне перетворення, відповідно до Рекомендації ITU H.246.<br>
| + | </center> |
| − | У придверні зосереджений весь інтелект мережі IP-телефонії. Мережа, побудована відповідно до рекомендації Н.323, має зонну архітектуру (рис. 1.6). Сторож виконує функції управління однією зоною мережі IP-телефонії, в яку входять: термінали, шлюзи, пристрої керування конференціями, зареєстровані у даного воротаря. Окремі фрагменти зони мережі Н.323 можуть бути територіально рознесені і з'єднуватися один з одним через маршрутизатори.<br>
| + | </div> |
| − | <center>
| + | --[[Користувач:Козінцев Олексій|Козінцев Олексій 36 гр.]] 11:14, 16 листопада 2010 (EET) |
| − | [[Файл: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>
| + | |
