Історія створення та особливості протоколу MEGACO/H.248

Матеріал з Вікі ЦДУ
Версія від 14:25, 30 листопада 2010; Козінцев Олексій (обговореннявнесок)

(різн.) ← Попередня версія • Поточна версія (різн.) • Новіша версія → (різн.)
Перейти до: навігація, пошук

9.1 Історія створення та особливості протоколу MEGACO/H.248
Робоча група MEGACO комітету IETF, продовжуючи дослідження, спрямовані на удосконалення протоколу управління шлюзами, створила більш функціональний (в порівнянні з розглянутим у попередньому розділі протоколом MGCP) протокол MEGACO. Але розробкою протоколів керування транспортними шлюзами, крім комітету IETF, займалася ще і дослідницька група SG 16 Міжнародного союзу електрозв'язку. Так, у проекті 4-ї версії рекомендації Н.323 ITU-T ввів принцип декомпозиції шлюзів, вже описаний з тим або іншим ступенем деталізації в розділах 1, 2 і 8. Важливою особливістю нововведення ITU-T було те, що управління транспортними шлюзами - Media Gateway (MG) - здійснюється контролером транспортних шлюзів - Media Gateway Controller (MGC) - за допомогою протоколу MEGACO, адаптованого під мережеве оточення Н.323. Специфікації адаптованого протоколу наведено у нещодавно затвердженої рекомендації ITU-T H.248. У даній книзі цей протокол називається MEGACO/H.248, так як авторам не хотілося б применшити чиїсь заслуги у розробці та адаптації цього протоколу. На рис. 9.1. представлено дерево еволюції протоколу MEGACO/H.248.
Розглянемо коротко основні особливості протоколу MEGACO / H.248. Для перенесення сигнальних повідомлень MEGACO/H.248 можуть використовуватися протоколи UDP, TCP, SCTP або транспортна технологія ATM. Підтримка для цих цілей протоколу UDP - одна з обов'язкових вимог до контролера шлюзів. Протокол TCP повинен підтримуватися і контролером, і транспортним шлюзом, а підтримка протоколу SCTP, так само, як і технології ATM, є необов'язковою.

VoIP 9.1.png
Рис. 9.1. Дерево еволюції протоколу MEGACO/H.248


Ще однією особливістю протоколу MEGACO/H.248 є те, що повідомлення цього протоколу можуть кодуватися двома способами. Комітет IETF запропонував текстовий спосіб кодування сигнальної інформації, а для опису сеансу зв'язку запропонував використовувати протокол SDP. ITU-T передбачає бінарний спосіб представлення сигнальної інформації - ASN. 1, а для опису сеансів зв'язку рекомендує спеціальний інструмент - Tag-length-value (TLV). Контролер шлюзу повинен підтримувати обидва способи кодування, в той час як шлюз - лише один із цих способів.


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