Протокол H.248 / MEGACO (Лекція 7)

1. Лекція 7. Протокол H.248 / MEGACO

Доц., к.т.н. Григоренко О.Г.

2. Протокол H.248 / MEGACO

Мережева архітектура H.248 / MEGACO
Особливості Megaco / H .248
Модель обслуговування виклику
Команди протоколу H.248 / MEGACO
Дескриптори
Транзакції
Повідомлення
Приклад встановлення і руйнування з'єднання

3. Мережева архітектура H.248/ MEGACO

• Робоча група MEGACO комітету IETF, продовжуючи
дослідження, спрямовані на удосконалення
протоколу управління шлюзами, створила більш
функціональний в порівнянні з протоколом MGCP
протокол MEGACO.
• В основу протоколу покладено принцип декомпозиції
функцій шлюзу, тобто шлюз розділяється на окремі
блоки (так само як в протоколі MGCP)

4. Архітектура мережі з використанням протоколу Megaco / H.248

5. Архітектура мережі з використанням протоколу H.248 / MEGACO

• Архітектура мережі з використанням протоколу H.248 / MEGACO
включає:
• MG - транспортний шлюз. Конвертує мовну інформацію з боку
ТМЗК, наприклад, цифровий потік Е1, в той вид інформації, який
придатний для передачі IP-мережею, тобто він кодує і упаковує
мовну інформацію в IP-пакети, і навпаки.
• SG - шлюз сигналізації. Приймає сигнальну інформацію з боку
ТМЗК, наприклад, сигналізацію СКС №7, перетворює її в вид,
придатний для передачі по IP-мережі, і передає пристрою
керування транспортним шлюзом MGC.
• MGC - пристрій управління шлюзом (контролер транспортного
шлюзу). Виконує функції управління транспортним шлюзом. На
основі інформації, отриманої від шлюзу сигналізації, MGC в
процесі встановлення з'єднання посилає транспортному шлюзу
певні команди по протоколу MEGACO

6. Особливості Megaco / H .248

• Цей протокол відомий в комітеті IETF під назвою Megaco (Mеdia
Gаteway Cоntrol Protocol), а в Міжнародному союзі
електрозв'язку ITU - під назвою H.248.
• Протокол Megaco / H.248 багато в чому архітектурно схожий з
MGCP.
• Подібно MGCP, він визначає транспортні шлюзи MG, які
перетворюють інформацію з формату, прийнятого в одній
мережі, в формат, необхідний в іншій мережі, і контролери
транспортних шлюзів MGC або Softswitch, які керують
встановленням з'єднань і їх скасуванням в межах шлюзів MG.
• Обидва протоколи були розроблені з урахуванням аналогічного
набору вимог.

7. Особливості Megaco / H .248

• Для перенесення сигнальних повідомлень Megaco / H.248 може
використовуватися протокол UDP, протокол TCP, протокол SCTP
або транспортна технологія ATM.
• Підтримка для цих цілей протоколу UDP - обов'язкова вимога
тільки до контролера шлюзів.
• Протокол ТСР повинен підтримуватися і контролером, і
транспортним шлюзом.
• Підтримка протоколу SCTР як і технології ATM, є необов'язковою

8. Особливості Megaco / H .248

• Ще однією особливістю протоколу Megaco / H.248 є те, що
повідомлення цього протоколу можуть кодуватися двома
способами.
• Комітет IETF запропонував текстовий спосіб кодування
сигнальної інформації, а для опису сеансу зв'язку запропонував
використовувати протокол SDP. Кодування тексту пишеться
відповідно до форм Бекуса-Наура ABNF (Augmented BackusNaur Form)
• ITU-T передбачає бінарний спосіб представлення сигнальної
інформації на мові ASN. 1 (Abstract Syntax Notation One),
розглянутий в рекомендації ITU-TX.680 від 1997 року, а для
опису сеансів зв'язку рекомендує спеціальний інструмент схему ТLV (тип-довжина-значення)

9. Особливості Megaco / H .248

• В результаті, специфікація Megaco / H.248 написана таким
чином, що забезпечує як кодування тексту, так і двійкове
кодування протоколу, нівелює різницю між IETF, який зазвичай
використовує АВNF, і ITU, де обраний формат АSN.1.
• Питання про те, чи є текстовий протокол кращим рішенням, ніж
протокол сигналізації у вигляді машинних кодів (або навпаки), в
процесі розробки протоколу вирішено не було.
• Сьогодні H.248 / Megaco підтримує обидва варіанти і
рекомендує, щоб при реалізації Softswitch використовувалися і
той, і інший варіант протоколу, а при реалізації транспортних
шлюзів або пристроїв інтегрованого доступу IAD може бути
обраний будь-який кращий для розробника варіант

10. Особливості Megaco / H .248

• Протокол Megaco призначений замінити реалізації на базі
протоколу MGCP, які є текстовими. У прикладах, що ілюструють
використання Megaco, для подання повідомлень застосовується
форма синтаксису ASN. 1.
• Між протоколами MGCP і Megaco / H.248 багато спільного і крім
подібності їх архітектури. Обидва протоколи працюють за
принципом «ведучий-ведений», при якому Softswitch управляє
транспортним шлюзом і його портами через запити включення
живлення, повідомлення про події, генерації сигналів, які
передаються до порту, а також встановленням і руйнуванням
сигнального з'єднання шляхом створення і ліквідації логічних
з'єднань між портами.

11. Особливості Megaco / H .248

• Синтаксис команд і відповідей на команди в
протоколах MGCP і Megaco абсолютно різний.
• Кодування та умовні позначення подій і сигналів, а
також модель обслуговування викликів мають ряд
відмінностей

12. Модель обслуговування виклику

• Опис алгоритму встановлення з'єднання з використанням
протоколу Megaco спирається на модель процесу
обслуговування виклику, відмінну від розглянутої моделі
MGCP.
• У своїй моделі процесу обслуговування виклику протокол
Megaco оперує двома логічними об'єктами:
• закінчення або порт (termination) і
• контекст (context).
• Закінчення (порт) можна розглядати як логічний об'єкт
транспортного шлюзу або IAD, який може бути джерелом
і приймачем мультимедійної інформації, багато в чому
аналогічним порту (endpoint) протоколу MGCP

13. Модель обслуговування виклику

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

14. Модель обслуговування виклику

• В алгоритмі встановлення з'єднання за допомогою
протоколу Megaco, представленому для шлюзу типу
Residential Gateway, порт (закінчення), що відповідає
фізичному пристрою (наприклад, телефонному апарату),
входить в той же контекст, що і логічне RTP-з'єднання, для
того щоб забезпечити відображення двостороннього
мультимедійного зв'язку.
• Контекст має локальне значення, тобто дійсний для
одного транспортного шлюзу.
• Існує особливий вид контексту - нульовий (null). У нього за
замовчуванням входять всі порти, які не пов'язані ні між
собою, ні з іншими портами

15. Приклади моделі процесу обслуговування виклику

16. Закінчення (порти)

• Закінчення (Terminations), звані іноді, для простоти,
портами, є джерелами і приймачами медіа інформації і,
одночасно, логічними об'єктами транспортного шлюзу.
• Можна виділити два види закінчень в залежності від того,
який інтерфейс - фізичний або віртуальний вони
представляють.
• Фізичні закінчення аналогічні напівпостійним з'єднанням
в традиційної телефонії і існують з моменту конфігурації
шлюзу. Це - аналогові телефонні інтерфейси обладнання,
що підтримують одне телефонне з'єднання, або цифрові
телефонні канали.

17. Закінчення (порти)

• Віртуальні закінчення існують лише під час розмовного
сеансу, є інтерфейсами з боку IP-мережі (наприклад,
RTP-закінчення), через які ведуться передача і прийом
пакетів.
• Віртуальні закінчення створюються шлюзом при
отриманні від Softswitch команди Add і ліквідуються
при отриманні команди Subtract, тоді як фізичні
закінчення при отриманні команди Add або Subtract,
відповідно, виводяться з нульового контексту або
повертаються назад в нульовий контекст

18. Закінчення (порти)

• Закінчення мають різні властивості
• Наприклад, підключене до аналогової лінії закінчення має не
такі характеристики, як закінчення, підключене до цифрового
каналу 64 Кбіт / с.
• Властивості закінчення визначаються набором дескрипторів,
що включаються до складу команд Megaco, що дозволяє
змінювати властивості кінцевих пристроїв відповідно до
вказівок, що передаються з Softswitch в MG.
• Відповідно, кожне закінчення має унікальний ідентифікатор
TerminationlD, який призначається шлюзом при конфігурації
порту.
• Ідентифікатори фізичних закінчень формуються
безпосередньо в транспортному шлюзі

19. Закінчення (порти)

• Наприклад, ідентифікатором порту може служити номер тракту
E1 і номер тимчасового каналу всередині тракту.
• Іноді команди можуть відноситися до всього шлюзу, тоді
використовується загальний ідентифікатор закінчень Root.
• Використовується також і механізм групових символів wildcard:
ALL і CHOOSE. Перший дозволяє адресуватися до кількох
закінчень одночасно, а другий - надати шлюзу право вибору
підходящого закінчення.
• До того ж, закінчення мають ряд початкових властивостей
(properties), кожна з яких теж має унікальний ідентифікатор
propertyID. Наприклад, закінчення можуть мати здатність
генерувати мовні підказки, акустичні і викличні сигнали, а також
виявляти сигнали DTMF.

20. Закінчення (порти)

• Деякі властивості закінчень присвоюються їм за замовчуванням
при створенні, а за допомогою команд протоколу Megaco /
H.248 ці властивості можна змінювати.
• Самі властивості закінчень визначаються дескрипторами, що
включаються в команди Megaco / H.248
• Закінчення, як тільки що згадувалося, можуть генерувати і
передавати сигнали і бути запрограмовані на виявлення подій,
при виникненні яких транспортний шлюз повинен буде
передати повідомлення до Softswitch або виконати певні дії.
• В закінченні можуть накопичуватися статистичні дані і потім
передаватися за запитом та / або при видаленні закінчення з
контексту

21. Контекст

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

22. Контекст

• Існує особливий вид контексту - нульовий.
• Всі закінчення, що входять до нульового контексту, не пов'язані ні
між собою, ні з іншими портами.
• Для даної моделі обслуговування викликів закінчення в нульовому
контексті є абстрактним поданням вільного (незайнятого) каналу.
• У загальному випадку для приєднання закінчення до контексту
служить команда Add.
• Якщо команда Add не вказує контекст, в який має бути додано
закінчення, в результаті виконання команди Add створюється
новий контекст. Це єдиний механізм для створення нового
контексту.
• Закінчення переводиться з одного контексту в інший за
допомогою команди Move, а видаляється з контексту за
допомогою команди Subtract. Якщо в результаті виконання
команди Subtract з контексту видаляється останнє закінчення, цей
контекст стирається

23. Контекст

• Атрибутами контексту є:
ідентифікатор контексту ContextID,
топологія контексту (хто кому передає і від кого приймає
інформацію),
пріоритет (один з 16 рівнів),
індикатор «аварійного виклику» (вищий пріоритет в
обслуговуванні).
• Протокол має засоби, щоб управляти параметрами
контексту.
• Короткий опис варіантів топології зв'язків в конференції,
представлених на рисунку наведено в таблиці
• Слід зазначити, що порти шлюзу не знають про режим,
який підтримують інші порти, які беруть участь в
конференції

24. Варіанти топології зв'язків між портами всередині одного контексту

25. Опис варіантів топології

Варі
ант
Опис
1
Порти 1 і 2 ізольовані один від одного, порт 2 тільки приймає
інформацію від порту 3, обмін інформацією між портами 1 і 3 двосторонній
2
Топологія зв'язків не специфікована, будь-який порт передає
інформацію іншим портам і приймає інформацію від інших
портів, що беруть участь в конференції
3
Порти 1 і 2 ізольовані один від одного, порт 3 передає
інформацію портам 1 і 2 і приймає інформацію від них
4
Порти 1 і 2 ізольовані один від одного, порт 3 тільки приймає
інформацію від порту 2 і обмінюється інформацією з портом 1
5
Двосторонній зв'язок між закінченнями 2 і 3 (як в третьому
випадку)
Двосторонній зв'язок між усіма закінченнями (як у другому
випадку)
6

26. Команди протоколу H.248 / MEGACO

• Megaco / H.248 визначає вісім команд, які забезпечують
можливість управляти і маніпулювати контекстами і
закінченнями.
• Більшість команд призначена для того, щоб передаватися з
Softswitch в транспортні шлюзи MG, за винятком команд Notify і
ServiceChange.
• Команда Add (додати). З її допомогою Softswitch дає вказівку
шлюзу додати закінчення до контексту.
• Якщо команда Add не вказує контекст, куди додається
закінчення, то створюється новий контекст. Якщо в команді не
вказано певний TerminationlD, а використаний символ
групового вибору ($), MG створить нове віртуальне закінчення і
додасть його в контекст

27. Команди протоколу H.248 / MEGACO

• Командою Modify (змінити) Softswitch дає вказівку шлюзу
змінити властивості закінчення.
• Команда Modify змінює значення властивостей закінчення,
наказує закінченню відправити один або кілька сигналів або
виявляти певні події і доповідати про них.
• Команда Subtract (виключити) видаляє закінчення з контексту.
Відповідь на команду може містити статистичні дані, які
стосуються участі закінчення в контексті. Ці дані залежать від
типу кінцевого пристрою.
• Для закінчення RTP статистичні дані можуть включати в себе
відомості про передані пакети, про отримані пакети, про
джиттер і т.п. В цьому відношенні команда Subtract аналогічна
команді DLCX протоколу MGCP.

28. Команди протоколу H.248 / MEGACO

• Команда Move (перемістити) переміщує закінчення з одного
контексту в інший. Вона не використовується для переміщення
закінчення з нульового контексту або в нього, оскільки ці
операції повинні виконуватися командами Add і Subtract,
відповідно.
• Можливість переміщати закінчення з одного контексту в інший це корисний інструмент для реалізації послуги «виклик з
очікуванням»
• Команда AuditValue (перевірити значення) використовується
Softswitch для пошуку поточних значень властивостей, подій і
сигналів, асоційованих з одним або декількома закінченнями.

29. Команди протоколу H.248 / MEGACO

• Команда AuditCapabilities (перевірити можливості)
використовується Softswitch для пошуку можливих значень
властивостей, подій і сигналів, асоційованих з одним або
декількома закінченнями.
• На перший погляд, ця команда може здатися дуже схожою на
команду AuditValue. Різниця між ними полягає в тому, що
команда AuditValue використовується для визначення
поточного стану закінчення, в той час як команда
AuditCapabilities дозволяє визначати стани, які закінчення може
приймати.
• Наприклад, AuditValue буде вказувати будь-які сигнали, що
подаються закінченням в даний момент, а AuditCapabilities
може вказати всі можливі сигнали, які закінчення може
подавати в разі потреби.

30. Команди протоколу H.248 / MEGACO

• Команда Notify (повідомити) передається MG для того, щоб
інформувати Softswitch про події, які відбулися в транспортному
шлюзі.
• З приводу подій, про які необхідно повідомляти, зазвичай
попередньо приходить запит в складі команди з Softswitch в MG,
наприклад, в команді Modify.
• Події, про які повідомляється, зазвичай супроводжуються
параметром RequestedlD, щоб Softswitch міг пов'язати ці події з
раніше переданими запитами.

31. Команди протоколу H.248 / MEGACO

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

32. Команди протоколу MEGACO / H.248

Команда
Напрямок
передачі
Призначення
Add (Додати)
MGC -> MG Контролер дає вказівку шлюзу додати
порт до контексту
Modify
(Змінити)
MGC -> MG Контролер дає вказівку шлюзу змінити
властивості порту
Subtract
(Відключити)
MGC -> MG Контролер вилучає порт з контексту
Move
(Перевести)
MGC -> MG Контролер переводить порт з одного
контексту в інший в одну дію
AuditValue
(Перевірити
порт)
MGC -> MG Контролер запитує властивості порту,
події, що відбулися, або сигнали, що
передаються в канал, а також
статистику, зібрану на поточний
момент часу

33. Команди протоколу MEGACO / H.248

Команда
Напрямок
передачі
AuditCapabilities MGC -> MG
(Перевірити
можливості
порту)
Notify
(Повідомити)
Призначення
Контролер запитує можливі значення
властивостей порту, список подій, які
можуть бути виявлені портом, список
сигналів, які порт може посилати в
канал, статистичні дані
MG -> MGC Шлюз інформує контролер про події,
що відбулися
MG ->MGC, Шлюз інформує контролер про те, що
ServiceChange
MGC -> MG один або кілька портів виходять з
(Змінити
робочого стану або повертаються в
обслуговування)
робочий стан. Контролер може
наказати порту або групі портів вийти
з обслуговування або повернутися в
обслуговування

34. Дескриптори

• Megaco / H.248 визначає ряд дескрипторів, призначених
для використання разом з командами і відповідями.
• Дескриптори утворюють параметри команди і / або
відповіді і містять додаткову інформацію про їх
властивості.
• Залежно від команди або відповіді той чи інший
дескриптор буває
обов'язковим,
забороненим або
опціональним.
• У більшості випадків, якщо дескриптор не є обов'язковим,
він - опціональний. Випадків, коли дескриптор є
забороненим, достатньо мало.

35. Дескриптори

• Загальний формат дескриптора виглядає наступним чином:
• Descriptorname = <somelD> {parm = value, parm = value, ...}
• Дескриптор модему, Modem, специфікує тип модему і
пов'язані з ним параметри, які слід використовувати в
з'єднаннях модему при передачі аудіо, відео або даних.
• Визначено такі типи модемів: V.18 (текстова телефонія),
V.22 (1200 б / с), V.22bis (2400 б / с), V.32 (9600 б / с), V.32bis
(14400 б / с), V.34 (33600 б / с), V.90 (56 Кб / с), V.91 (64 Кб /
с) і синхронна ISDN.
• За замовчуванням закінчення не має дескриптора модему.
Інакше кажучи, при початку роботи закінчення ніякі
властивості його модему не задаються. Вони можуть
задаватися пізніше, в результаті передачі команди Add або
Modify з Softswitch в MG

36. Дескриптори

• Дескриптор модему був включений в першу версію
специфікації Megaco RFC 3015, а в синтаксис версії 2 він
включений тільки тому, щоб забезпечити зворотну
сумісність. Таким чином, в наступних версіях протоколу
цей дескриптор не використовується, і при прийомі його
необхідно ігнорувати.
• Дескриптор мультиплексування, Mux, характеризує тип
мультиплексування в мультимедійному терміналі.
Протокол підтримує типи мультиплексування: H.211,
H.223, H.226, V.76 і Nx64K

37. Дескриптор середовища

• Дескриптор середовища, Media, описує різні інформаційні потоки
(медіа-потоки).
• Це ієрархічний дескриптор в тому відношенні, що він містить
загальний дескриптор, відомий як дескриптор стану закінчення,
який можна застосувати до закінчення в загальному, і ряд
дескрипторів потоків, які можна застосувати до кожного медіапотоку окремо.
• Крім того, кожен дескриптор середовища містить до трьох
підлеглих дескрипторів, відомих як локальний дескриптор
управління, локальний дескриптор і віддалений дескриптор,
відповідно. Ієрархію цього типу можна представити таким списком:
• дескриптор середовища
дескриптор потоку
Локальний дескриптор управління
локальний дескриптор
віддалений дескриптор

38. Дескриптор стану закінчення

• Дескриптор стану закінчення, TerminationState, містить відомості
про дві характеристики закінчення:
ServiceStates і
EventBufferControl, а також
відомості про ряд інших характеристик, які до медіа-потоків
відношення не мають.
• Характеристика ServiceStates вказує, чи доступне закінчення для
використання. Вона може мати три значення:
тестування,
поза обслуговування і
в обслуговуванні.
• Значення в обслуговуванні не означає, що в даний момент
закінчення бере участь в зв'язку, а вказує, що закінчення або
бере активну участь в ньому, або може бути використано для
його створення. Значення в обслуговуванні встановлюється за
умовчанням

39. Дескриптор стану закінчення

• Характеристика EventBufferControl вказує, чи слід відомості про
виявлені закінченням події поміщати в буфер або їх треба
негайно обробляти.
• Спочатку закінчення доповідає про події, повідомлення, про які
замовив Softswitch за допомогою команди, яка містить
EventsDescriptor.
• Чи буде закінчення фактично доповідати про зазначені в
EventsDescriptor події, залежить від того, чи встановлена
EventBufferControl в стан off (вимкнено) або в стан lockstep
(жорсткої конфігурації).
• Якщо встановлено off, закінчення негайно доповість про виявлену
подію.
• Якщо встановлено lockstep, дані про подію будуть поміщені в
буфер з дисципліною FIFO (першим увійшов, першим
обслужений).

40. Дескриптор стану закінчення

• Вміст буфера перевіряється при отриманні нового
EventsDescriptor, який зазначає, які події має виявляти
закінчення.
• Включення EventBufferControl до складу
TerminationStateDescriptor дозволяє Softswitch
включати або вимикати негайне повідомлення про
події та не передавати кожен раз EventsDescriptor без
необхідності.
• Дескриптор стану закінчення є необов'язковим

41. Дескриптори потоку

• Дескриптори потоку, Stream.
• Потік визначається дескрипторами LocalControlDescriptor,
LocalDescriptor, RemoteDescriptor і ідентифікується за
допомогою StreamID.
• Значення StreamID використовуються між MG і Softswitch, щоб
вказувати, які медіа-потоки взаємопов'язані.
• В межах одного контексту потоки з одним і тим же StreamID
з'єднані.
• Потік створюється визначенням в контексті нового StreamID в
закінченні.
• Потік видаляється за допомогою установки порожнього
локального або віддаленого дескриптора і установки значень
ReserveGroup і ReserveValue в підпорядкованому
LocalControlDescriptor в логічне значення false

42. Дескриптори потоку

• Дескриптор LocalControlDescriptor містить відомості про
особливі характеристики медіа-потоку, зокрема, про
характеристики Mode, ReserveGroup і ReserveValue.
• Характеристика Mode (режим) може приймати одне з
наступних значень:
тільки передача,
тільки прийом,
передача / прийом,
неактивний або
закільцьований.
• Напрямки передачі і прийому визначаються по
відношенню до зовнішньої сторони контексту.

43. Дескриптори потоку

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

44. Дескриптори потоку

• Характеристики ReserveValue і ReserveGroup вказують, які
ресурси повинні бути резервовані для варіантів, що
специфіковані Softswitch в LocalDescriptor і RemoteDescriptor.
• LocalDescriptor і RemoteDescriptor можуть уточняти кілька
характеристик та / або груп характеристик.
• Наприклад, опис SDP може вказувати дві групи характеристик:
одну - для G.711 А-закону і одну - для G.729.
• Якщо логічне значення ReserveGroup дорівнює true (істина), то
MG повинен резервувати ресурси для однієї з цих груп
характеристик.
• ReserveValue використовується аналогічно, але застосовується з
метою резервування ресурсів для однієї певної
характеристики, а не для групи характеристик

45. Дескриптори потоку

• Дескриптори LocalDescriptor і RemoteDescriptor містять
або не містять кілька описів сеансів SDP, що описують
сеанс на локальному і віддаленому кінцях з'єднання,
відповідно.
• Використання SDP згідно протоколу Megaco має деякі
відхилення від строгого синтаксису SDP, як він
специфікований в документі RFC 2327.
• Зокрема, рядки s =, t = і o = є опціональними, знак
групового вибору ($) дозволений, допускається вказувати
кілька альтернативних значень параметра в тих місцях, де
зазвичай мають використовувати одне значення.
• LocalDescriptor, і RemoteDescriptor можуть містити кілька
описів сеансів

46. Дескриптори подій

• Дескриптор подій, Events, містить Requestldentifier і список
подій, які MG повинен виявляти і про які повідомляти
(перехід в стан «трубка піднята», тональний сигнал факсу і
ін.).
• Призначення Requestldentifier - пов'язувати запити і
наступні повідомлення.
• Зазвичай повідомлення про виявлені події негайно
передаються в Softswitch. Однак, в залежності від значення
EventBufferControl (яке є специфіцируємим в
TerminationStateDescriptor), відомості про події можуть і
записуватися в буфер.
• Коли події записуються в буфер, і потім про них має
повідомлятися в Softswitch, то пов'язана з цими подіями
інформація зберігається в EventBufferDescriptor

47. Дескриптор сигналів

• Дескриптор сигналів, Signals, містить список сигналів, які має подавати
закінчення.
• Сигнали можуть подаватися тільки одному потоку або всім потокам в
закінченні.
• До складу типових сигналів можуть входити, наприклад, такі акустичні
сигнали, що подаються в абонентську лінію , як «відповідь станції» або
«контроль посилки виклику».
• Існують сигнали трьох типів:
On / off - сигнал залишається включеним (on) до тих пір, поки явно не
буде вимкнений (off),
Timeout - сигнал зберігається до тих пір, поки не закінчиться певний
період часу або поки не буде вимкнений ще до закінчення заданого
часу,
короткий - сигнал повинен подаватися тільки на дуже короткий час, як
в разі багаточастотних сигналів в сполучних лініях з сигналізацією R1.5.
• Дескриптор сигналів може включати до свого складу логічну
послідовність сигналів, які необхідно відтворювати один за одним

48. Дескриптори

• Дескриптор перевірки, Audit Descriptor, задає перелік
інформації, яку необхідно передавати з MG в Softswitch.
• Дескриптор перевірки є просто списком інших
дескрипторів, які повинні переноситися у відповіді. У їх
число можуть входити дескриптори: мультиплексування,
подій, сигналів, ObservedEvents, DigitMap, статистичних
даних і EventBuffer.
• Дескриптор ServiceChangeDescriptor використовується
тільки в поєднанні з командою ServiceChange і включає в
себе таку інформацію, як тип зміни обслуговування, яке
відбулося або повинно відбутися, причина зміни
обслуговування і нову адресу для використання після
зміни обслуговування

49. Дескриптор зміни обслуговування

• Тип зміни обслуговування визначається параметром
ServiceChangeMethod, який може приймати одне з
наступних значень:
Graceful (поступове),
Forced (примусове),
Restart (перезапуск),
Disconnected (відключено),
Handoff (передача управління),
Failover (несправність).
• Graceful вказує виведення закінчень з обслуговування після
заданої затримки і без переривання існуючих з'єднань.
• Forced вказує раптове, різке виведення з обслуговування з
втратою існуючих з'єднань.

50. Дескриптор зміни обслуговування

• Restart вказує, що відновлення обслуговування почнеться після
заданої затримки.
• Disconnected застосовується до всього MG і вказує, що з'єднання
з Softswitch зруйновано, але буде відновлено. Softswitch може
передавати команду Audit для перевірки того, що
характеристики кінцевого пристрою не змінилися за час втрати
контакту.
• Handoff передається з Softswitch в MG, щоб вказати, що
Softswitch виводиться з обслуговування та управління приймає
новий Softswitch. Значення Handoff передається також з MG в
новий Softswitch під час спроби встановити контакт після
прийому handoff від попереднього Softswitch.
• Failover передається з MG в Softswitch, якщо MG виявив
несправність і проводиться перемикання на резервний MG

51. Дескриптор зміни обслуговування

• Параметр ServiceChangeDelay визначає тривалість
використовуваної затримки в секундах. Його необхідно
передавати, наприклад, в поєднанні зі зміною
обслуговування типу Graceful.
• Якщо параметр відсутній, або має значення нуль, затримки
не відбувається.
• У разі зміни обслуговування по типу Graceful нульове
значення вказує, що Softswitch повинен чекати природного
видалення кінцевих пристроїв з їх контексту; тобто чекати,
коли сеанси зв'язку з використанням зазначених закінчень
завершаться за ініціативою їх учасників.
• Параметр ServiceChange Reason вказує причину зміни
обслуговування

52. Дескриптор DigitMap

• Дескриптор DigitMap є описом плану нумерації.
• Інакше кажучи, DigitMap специфіцирує безліч
дозволених для набору комбінацій цифр. Вони
зберігається в MG, так що той може передавати прийняті
цифри в Softswitch блоками, а не по одній.
• План нумерації може бути завантажений в MG засобами
експлуатаційного управління або з Softswitch по
командам Megaco.
• Якщо план завантажується з Softswitch, то щоб
переправити інформацію, використовується дескриптор
DigitMap

53. Дескриптор DigitMap

• З точки зору синтаксису DigitMap є рядком або списком рядків,
причому кожен рядок складається з ряду символів, що
представляють собою цифри від 0 до 9 і букви від А до К.
• Букву X можна використовувати як груповий символ, що
позначає будь-яку цифру від 0 до 9, а символ «точка» (.)
використовується для вказівки нуля або декількох повторень
цифри або рядків цифр, що безпосередньо передували.
• Цей символ можна використовувати для вказівки номера з
довжиною, не визначеною в плані нумерації.
• Крім того, рядок може містити три символи, що визначають
запуск таймера (T), короткого таймера (S) і довгого таймера (L).
• Щоб зрозуміти призначення цих таймерів, розглянемо, що
відбувається, коли абонент піднімає трубку звичайного
телефонного апарату, щоб викликати станцію.

54. Дескриптор DigitMap

• АТС виявляє виклик, подає сигнал «Відповідь станції» і готується
до прийому першої цифри номера, включаючи таймер
очікування цієї цифри (близько 30 секунд).
Якщо цифра не надійде протягом цього часу, АТС визначить
спрацьовування таймера і передасть абоненту зумер «Зайнято».
Це - таймер Т.
• Коли абонент почав набирати номер, запускається межцифровой
таймер.
• Цей таймер буває або коротким таймером S, або довгим
таймером L, в залежності від плану нумерації.
• Якщо абонент набрав деяку кількість цифр, а АТС потрібно більше
цифр для маршрутизації виклику, при очікуванні наступної цифри
зазвичай застосовується короткий таймер.
• Крім того, в АТС запускається таймер обмеження тривалості
непродуктивного заняття до моменту отримання сигналу
«Відповідь» від абонента, що викликається, для чого
застосовується довгий таймер L

55. Дескриптори

• Дескриптор StatisticsDescriptor містить інформацію, яка
відноситься до використання закінчення в даному
контексті.
• Особливості статистичних даних, які повинні передаваться
за запитом, залежать від типу закінчення.
• Строго кажучи, цей дескриптор завжди є опціональним і
може передаватися при видаленні закінчення з контексту
по команді Subtract або у відповідь на команду AuditValue

56. Дескриптор

• Дескриптор ObservedEvents є обов'язковим параметром в
команді Notіfy, де він використовується для того, щоб
інформувати Softswitch про події, які були виявлені.
• У більшості інших відповідей на команди цей дескриптор є
необов'язковим, крім ServiceChange.
• При використанні у відповіді на команду AuditValue він
призначений для передачі інформації про події, які
записані в буфері подій і ще не відомі Softswitch.
• Дескриптор містить Requestldentifier зі значенням, яке
погоджено з прийнятим в дескрипторі подій списком
таких подій, які повинні бути виявлені в першу чергу. Цим
забезпечується ув'язка запитуваних даних про події та
даних про події в повідомленнях

57. Дескриптор

• Дескриптор опціонально допускає включення в нього
часових міток із зазначенням моменту виявлення кожної
спостережуваної події.
• Ця часова мітка структурується у вигляді
yyyymmddThhmmssss, де записуються сотні секунд.
• Буква T відокремлює рік, місяць і день від години, хвилини
і секунд.
• Сама часова мітка відділяється від опису відповідної події
двокрапкою.
• Дескриптор Error передається у відповіді, коли не може
бути виконана команда. Він може бути також включений в
команду Notify, передану з MG в Softswitch.
• Дескриптор помилок складається з коду помилки і
текстового опису помилки, опціонально супроводжуючого
цей код

58. Дескриптор топології

• Дескриптор топології Topology відрізняється від інших дескрипторів
в тому сенсі, що він відповідає лише контексту, а не певному
закінчення в контексті.
• Призначення дескриптора - вказати, як мають протікати в контексті
медіа-потоки, тобто хто і кого повинен чути або бачити.
• За замовчуванням всі закінчення в контексті можуть передавати і
приймати інформацію один від одного. Якщо бажана інша ситуація,
то використовується дескриптор топології.
• Дескриптор складається з послідовності трійок об'єктів виду
закінчення1 - закінчення2 - з'єднання.
• Така трійка вказує, існує чи ні потік між двома закінченнями
(/so/ate), чи повинен цей потік бути одностороннім (oneway) або
двостороннім (bothway).
• Порядок, в якому кінцеві пристрої з'являються в трійці, має
значення: наприклад, трійка з1-з2-oneway означає, що закінчення1
може передавати інформацію в закінчення2, але закінчення2 не
може передавати інформацію в закінчення1

59. Дескриптор топології

• Якщо в контексті використовується більше двох закінчень,
то потрібно більше однієї трійки.
• Наприклад, якщо використовується три кінцевих пристрої
(з1, з2 і з3), то в описі топології потрібні три трійки: для
зв'язку між з1 і з2, для зв'язку між з1 і з3 і для зв'язку між
з2 і з3.
• Дескриптор топології може бути корисним інструментом
для реалізації таких послуг як виклик з попереднім
замовленням або конференцзвязок, з можливістю
частини її учасників провести окремі розмови перед
поверненням в загальну групу.
• За замовчуванням характеристики всіх дескрипторів, за
винятком дескриптора стану закінчення і дескриптора
локального управління, є порожніми

60. Транзакції

• Команди, що передаються між Softswitch і MG,
групуються в структури, які влаштовані так, що за набором
команд, які стосуються одного контексту, може слідувати
набір команд, що відносяться до іншого контексту.
• Згруповані команди передаються разом в єдиному блоці
TransactionRequest. Це можна уявити так:
• TransactionRequest (TransactionID {
ContextID1 (Command, Command, ... Command),
ContextID2 (Command, Conmand, ... Command), ContextID3
(Command, Command, ... Command)})

61. Транзакції

• Після прийому TransactionRequest одержувач виконує вкладені
команди.
• Команди виконуються послідовно, в тому порядку, в якому
вони вказані в TransactionRequest.
• Після виконання всіх команд передається відповідь
TransactionReply.
• Відповідь має структуру, аналогічну структурі
TransactionRequest в тому сенсі, що містить кілька відповідей
для декількох контекстів.
• TransactionReply можна уявити так:
• TransactionReply (TransactionID {
• ContextID1 (Response, Response, ... Response), ContextID2
(Response, Response, ... Response}, ContextID3 (Response,
Response, ... Response)})

62. Транзакції

• Якщо одержувачу TransactionRequest буде потрібно якийсь
час для виконання запиту, він може передати відправнику
цього запиту попередню відповідь, щоб той не вважав
запит втраченим.
• Ця попередня відповідь TransactionPending сповіщає, що
TransactionRequest прийнята і в даний момент
обробляється.
• Така відповідь містить ухвалений TransactionID без будьяких параметрів:
• TransactionPending (TransactionID {.})
• Параметр normalMGExecutionTime визначає інтервал часу,
протягом якого контролер очікує отримання відповіді від
шлюзу.
• Аналогічний параметр normalSoftswitchExecutionTime
визначає час очікування шлюзом відповіді від контролера

63. Транзакції

• Для обмеження часу очікування використовується
пара параметрів MGOriginatedPendingLimit і
SoftswitchOriginatedPendingLimit, вона визначає
гранично допустиму кількість одержуваних
повідомлень TransactionPending.
• Після досягнення вказаної межі передається або
відповідь, або повідомлення про помилку транзакції

64. Повідомлення

• Кілька транзакцій протоколу можуть поміщатися в
повідомлення.
• Повідомлення забезпечується заголовком, що ідентифікує
відправника.
• Ідентифікатором повідомлення MID (Message Identifier)
служить призначене ім'я (наприклад, доменна адреса /
домене ім'я / ім'я пристрою) об'єкта, що передає
повідомлення.
• За умовчанням пропонується використовувати доменне
ім'я.
• Об'єкти протоколу Megaco / H.248 (як MG, так і Softswitch)
повинні використовувати один і той же MID у всіх
створюваних ними повідомленнях протягом усього часу
взаємодії між ними.

65. Повідомлення

• Кожне повідомлення містить номер версії протоколу, який
створив повідомлення. Для версії відводиться два розряду.
Поточна версія протоколу - 2.
• Транзакції в межах повідомлення обробляються незалежно.
• Порядок транзакцій в повідомленні не впливає на порядок,
в якому їх повинен обробляти одержувач повідомлення.
• Зауважимо, що цей порядок відрізняється від порядку
обробки команд в межах транзакції, де черговість команд
має значення
• Повідомлення Megaco / H.248 - це, по суті, тільки
транспортний механізм, на відміну від повідомлень
багатьох інших мережевих протоколів
• В таблиці наведені коди помилок, які використовуються в
протоколі MEGACO / H.248

66. Коди помилок

Код
помилок
Опис
400
Некоректний запит
401
Помилка в протоколі
402
Авторизація не підтверджена
403
Синтаксична помилка в транзакції
410
Некоректний ідентифікатор
411
В транзакції вказано ідентифікатор неіснуючого
контексту
412
Відсутні вільні ідентифікатори контексту
420
Немає такої події або сигналу в пакеті (package)
421
Невідома транзакція або некоректна комбінація
транзакцій
422
Синтаксична помилка в транзакції

67. Коди помилок

Код
Опис
помилок
430
Невідомий ідентифікатор порту
431
Н