Відмінності між версіями «Порівняльний аналіз протоколів MGCP і MEGACO»

Поточна версія на 14:39, 30 листопада 2010

9.3 Порівняльний аналіз протоколів MGCP і MEGACO
Мета даного параграфа - визначити, в чому схожі й чим відрізняються протоколи MGCP і MEGACO. Почнемо з загальних рис протоколів.
Обидва протоколу використовуються в мережах з однаковою архітектурою, де транспортними шлюзами управляють високоінтелектуальні контролери. Обидва протоколу вміють працювати зі шлюзами одних і тих же видів, класифікація шлюзів була дана в попередньому розділі. Порти шлюзів підтримують детектування одних і тих же подій і генерацію одних і тих же сигналів. Використовуються однакові транспортні механізми для доставки повідомлень систем сигналізації ОКС7, DSS1, ТСК. Процедури встановлення та руйнування з'єднань, що реалізуються обома протоколами, ідентичні. Крім того, використовуються однакові механізми підтримки захисту мережі. На цьому схожість протоколів MGCP і MEGACO/H.248 закінчується.
Найважливішим відзнакою протоколу MEGACO/H.248 від протоколу MGCP є використання іншої моделі організації зв'язку. Протокол MEGACO/H.248 працює не тільки з телефонними портами, але і UDP-портами. Крім того, connection в моделі MGCP - це, в загальному випадку, підключення до з'єднання між портами різного обладнання, в той час як context в моделі MEGACO/H.248 завжди відображає зв'язок між портами одного шлюзу (рис. 9.4).

Змінюючи топологію зв'язків портів, які стосуються одного контексту, за допомогою протоколу MEGACO контролер може гнучко управляти конференціями. Даної можливості в протоколі MGCP не передбачено.
Вище вже зазначалося, що для протоколу MEGACO/H.248 передбачено два способи кодування, тоді як повідомлення протоколу MGCP подаються в текстовому форматі, а бінарний спосіб кодування не підтримується. Крім того, у протоколах використовуються різні параметри команд і коди помилок.
Протокол MEGACO/H.248, так само, як і протокол MGCP, передбачає кореляцію команд і відповідей. Але якщо в протоколі MGCP транзакція утворюється з команди і відповіді на неї, то в протоколі MEGACO/H.248 транзакція складається із запиту - сукупності акцій і відгуку на запит. Загальна структура запиту виглядає так:
TransactionRequest (Transactionid {
ContextiD {Command ... Command),
ContextiD {Command ... Command}})
Загальна структура відгуку на запит наведена нижче:
TransactionReply (TransactionID {
ContextiD {Response ... Response},
ContextiD {Response ... Response}})
Кожна акція, у свою чергу, складається з однієї або декількох команд, які стосуються одного контексту, і відповідей на них (Мал. 9.5). Використання такого інструменту дозволяє значно зменшити обсяг переданої сигнальної інформації та збільшити швидкість встановлення з'єднань за рахунок того, що контролер може паралельно вести обробку сигнальної інформації, що відноситься до різних сполук.
Аналоги двох надлишкових команд EndpointConfiguration і NotificationRequest протоколу MGCP в протоколі MEGACO/H.248 відсутні, але, в той же час, додана команда Move, що дозволяє в одну дію перевести порт з одного контексту в інший. Як приклад використання команди Move наведемо сценарій додаткових послуг «Повідомлення про вхідний виклик і переклад існуючого з'єднання в режим утримання», англомовне назву послуг - Call Waiting і Call Hold.

Абонент А розмовляє з абонентом В, а абонент С викликає абонента А, при цьому, якій Ви телефонуєте передається акустичне повідомлення про вхідний виклик (рис. 9.6). Далі абонент А переводить з'єднання з абонентом В в режим утримання і з'єднується з абонентом С (рис. 9.7). Реалізація комбінації додаткових послуг Call Waiting і Call Hold, тобто передача порту з одного контексту в інший, стала можливою завдяки команді Move.

На закінчення даного параграфа хотілося б відзначити, що невідомо, як скоро знадобиться розширена, в порівнянні з MGCP, функціональність протоколу MEGACO/H.248. Крім того, на базі протоколу MGCP побудований ряд мереж IP-телефонії. Все це означає, що обидва протоколи MGCP і MEGACO/H.248 цілком можуть спільно використовуватися в одній мережі.

--Козінцев Олексій 36 гр. 17:24, 29 листопада 2010 (EET)