Лекція 7. Протокол H.248 / MEGACO
Протокол H.248 / MEGACO
Мережева архітектура H.248/ MEGACO
Архітектура мережі з використанням протоколу Megaco / H.248
Архітектура мережі з використанням протоколу H.248 / MEGACO
Особливості Megaco / H .248
Особливості Megaco / H .248
Особливості Megaco / H .248
Особливості Megaco / H .248
Особливості Megaco / H .248
Особливості Megaco / H .248
Модель обслуговування виклику
Модель обслуговування виклику
Модель обслуговування виклику
Приклади моделі процесу обслуговування виклику
Закінчення (порти)
Закінчення (порти)
Закінчення (порти)
Закінчення (порти)
Закінчення (порти)
Контекст
Контекст
Контекст
Варіанти топології зв'язків між портами всередині одного контексту
Опис варіантів топології
Команди протоколу H.248 / MEGACO
Команди протоколу H.248 / MEGACO
Команди протоколу H.248 / MEGACO
Команди протоколу H.248 / MEGACO
Команди протоколу H.248 / MEGACO
Команди протоколу H.248 / MEGACO
Команди протоколу MEGACO / H.248
Команди протоколу MEGACO / H.248
Дескриптори
Дескриптори
Дескриптори
Дескриптор середовища
Дескриптор стану закінчення
Дескриптор стану закінчення
Дескриптор стану закінчення
Дескриптори потоку
Дескриптори потоку
Дескриптори потоку
Дескриптори потоку
Дескриптори потоку
Дескриптори подій
Дескриптор сигналів
Дескриптори
Дескриптор зміни обслуговування
Дескриптор зміни обслуговування
Дескриптор зміни обслуговування
Дескриптор DigitMap
Дескриптор DigitMap
Дескриптор DigitMap
Дескриптори
Дескриптор
Дескриптор
Дескриптор топології
Дескриптор топології
Транзакції
Транзакції
Транзакції
Транзакції
Повідомлення
Повідомлення
Коди помилок
Коди помилок
Коди помилок
Коди помилок
Коди помилок
Приклад встановлення і руйнування з'єднання
Алгоритм встановлення і руйнування з'єднання за допомогою протоколу MEGACO
Приклад встановлення і руйнування з'єднання
Приклад встановлення і руйнування з'єднання
Приклад встановлення і руйнування з'єднання
Приклад встановлення і руйнування з'єднання
Приклад встановлення і руйнування з'єднання
Приклад встановлення і руйнування з'єднання
Приклад встановлення і руйнування з'єднання
Приклад встановлення і руйнування з'єднання
Приклад встановлення і руйнування з'єднання
Приклад встановлення і руйнування з'єднання
Приклад встановлення і руйнування з'єднання
Приклад встановлення і руйнування з'єднання
Приклад встановлення і руйнування з'єднання
Приклад встановлення і руйнування з'єднання
Приклад встановлення і руйнування з'єднання
Приклад встановлення і руйнування з'єднання
Приклад встановлення і руйнування з'єднання
Приклад встановлення і руйнування з'єднання
Приклад встановлення і руйнування з'єднання
Приклад встановлення і руйнування з'єднання
702.58K

Протокол 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
Н
English     Русский Правила