Протокол H.248 / MEGACO (Лекція 7) презентация

Содержание

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

Слайд 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 Backus-Naur 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Опис варіантів топології

Слайд 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

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

Слайд 34Дескриптори
Megaco / H.248 визначає ряд дескрипторів, призначених для використання разом з

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

Слайд 35Дескриптори
Загальний формат дескриптора виглядає наступним чином:
Descriptorname = {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Коди помилок

Слайд 67Коди помилок

Слайд 68Коди помилок

Слайд 69Коди помилок

Слайд 70Коди помилок

Слайд 71Приклад встановлення і руйнування з'єднання
Наведено приклад встановлення з'єднання з використанням протоколу

MEGACO між двома шлюзами (Residential Gateway), керованими одним контролером.
В даному прикладі шлюз, що викликає, MG1 має IP-адресу 124.124.124.222, адреса шлюзу, що викликається, MG2 - 125.125.125.111, адреса контролера шлюзів MGC - 123.123.123.4. Порт для зв'язку за протоколом MEGACO для всіх трьох пристроїв за замовчуванням має значення 55555

Слайд 72Алгоритм встановлення і руйнування з'єднання за допомогою протоколу MEGACO

Слайд 73Приклад встановлення і руйнування з'єднання
1. Шлюз MG1 реєструється у контролера MGC

за допомогою команди ServiceChange.
Використання нульового контексту означає, що порт зараз не бере участі ні в якому з’єднанні, а використання ідентифікатора порту ROOT означає, що команда ставиться до всього шлюзу, а не до якогось певного порту.
MG1 to MGC:
MEGACO / 1.0 [124.124.124.222] Transaction = 9998 {Context = - {
ServiceChange = ROOT {Services {
Method = Restart, Port = 55555, Profile = ResGW / 1.0)}
)

Слайд 74Приклад встановлення і руйнування з'єднання
2. Контролер підтверджує реєстрацію шлюзу:
MGC to MGl:
MEGACO

/ 1.0 [123.123.123.41:55555 Reply = 9998 {
Context = - {ServiceChange = ROOT {Servicee {Port = 55555, Profile = ResGW / 1.0})
)
3. Шлюз має вільні аналогові порти, які повинні бути запрограмовані для відстежування зміни опору абонентського шлейфу, що означає підняття абонентом трубки, після чого шлюз повинен передати абоненту акустичний сигнал «Відповідь станції».
Програмування проводиться за допомогою команди Modify з відповідними параметрами, причому програмується порт, що знаходиться в нульовому контексті.

Слайд 75Приклад встановлення і руйнування з'єднання
У команді вказується ідентифікатор порту (terminationid) -А4444,

ідентифікатор інформаційного потоку (streamid) -1, транспортна адреса обладнання, що передало команду - [123.123.123.4]: 55555, специфіцирується режим функціонування -дуплексний (SendReceive)
MGC to MGl:
MEGACO/1.0 [123.123.123.4]:55555 Transaction = 9999 { Context = - {
Modify = A4444 { Media {
TerminationState {
Buf feredEventHandling{Step,Procese}
}, Stream = 1 {
LocalControl {
Mode = SendReceive, g/GainControl=2, ; in dB, g/Encryption=xxx, g/EchoCancellation=Gl65, g/VoiceActDet=yes )
),
Events в 2222 {glinesup/offhook}
Signals {g/PlayTone{tone=dialtone} ) )

Слайд 76Приклад встановлення і руйнування з'єднання
На цьому ж етапі в шлюз може

бути завантажений план нумерації (в дескрипторі digit map).
У цьому випадку, після того як абонент підніме трубку, шлюз повинен передати йому акустичний сигнал «Відповідь станції» і починати прийом сигналів DTMF відповідно до плану нумерації.
Однак, в наведеному прикладі план нумерації буде завантажений тільки після того, як абонент підніме трубку, на 8 кроці.
Крім того, слід зазначити, що кроки 3 і 4 цього алгоритму можуть бути суміщені з кроками 8 і 9, відповідно, за допомогою дескриптора EventsDescriptor. При цьому кроки 6 і 7 опускаються

Слайд 77Приклад встановлення і руйнування з'єднання
4. Шлюз MG1 підтверджує виконання команди Modify:
mgi

to mgc:
MEGACO / l.O [124.124.124.222]: 55555 Reply = 9999 {
Context = - {Modify}>
5. Подібним же чином (кроки 1-4) програмується аналоговий порт шлюзу MG2, в прикладі має ідентифікатор А5555.
6. Далі шлюз MG1 виявляє, що абонент А підняв трубку, і сповіщає про цю подію Media Gateway Controller за допомогою команди Notify.
Mg1 to mgc:
MEGACO / l.O [124.124.124.222]: 55555 Transaction = 10000 {Context = - {
Notify = A4444 {ObservedEvents = 2 222 {
19990729T22000000: glinesup / offhook}>))

Слайд 78Приклад встановлення і руйнування з'єднання
7. Контролер підтверджує отримання команди Notify:
mgc to

mg1;
MEGACO / l.O [123.123.123.4] $ 55555 Reply = 10000 {
Context = - (Notify))
8. На наступному кроці MGC дає шлюзу інструкцію накопичувати цифри номера абонента, що викликається, відповідно до обраного плану нумерації.
Крім того, після отримання першої цифри номера необхідно зупинити передачу акустичного сигналу «Відповідь станції».

Слайд 79Приклад встановлення і руйнування з'єднання
14. Контролер MGC створює в шлюзі MG2

контекст для встановлення дуплексного з'єднання (режим SendReceive) із користувачем, що викликає
MGC to MG2:
MEGACO/1.0 [123.123.123.4]:55555 Transaction = 50003 { Context = $ {
Add = A5555 { Media {
Stream • 1 { )
),
Add = $ { Media {
Stream = 1 {
LocalControl {
Mode = SendReceive, g/NetworkType = RTP/IP4, g/MaxJitterBuffer=40, ; in ms g/PreferredPacketization=30, ; in ms g/PreferredEncoders =[G723, PCMU], g/PreferredDecoders=[G723, PCMU] , g/Gain=0 ; in dB ),
Remote=SDP{ v=0
c=IN IP4 124.124.124.222 m=audio 2222 RTP/AVP 4 0 a=sendrecv
} ; RTF profile for G.723 is 4 ) )
>

Слайд 80Приклад встановлення і руйнування з'єднання
15. Створення контексту підтверджується, фізичний порт шлюзу

MG2 A5555 з'єднується з UDP / RTP портом, що має ідентифікатор А5556. Відзначимо, що RTP-порт має номер 1111, тобто відмінний від номера порту Megaco / H.248 - 55555.
MG2 to MGC:
MEGACO / 1.0 [124.124.124.2221: 55555 Reply = 50003 {
Context = 5000 {Add, Add = А5556 {Media {
Stream = 1 {
Local • SDP {v = 0
c = IN IP4 125.125.125.1111 m = audio 1 111 RTP / AVP 4 0 a = sendreceive}
}; RTF profile for G723 is 4)
)

Слайд 81Приклад встановлення і руйнування з'єднання
16. Контролер MGC наказує порту А5555 шлюзу

MG2 почати передачу сигналу виклику.
MGC to MG2:
MEGACO / 1.0 [123.123.123.41:55555 Transaction = 50004 {Context = 5000 {
Modify = А5555 {
Signals {glinesup / PlayTone {tone = ring}}}
)
17. Шлюз MG2 підтверджує передачу сигналу «Посилка виклику» абоненту, що викликається.
MG2 to MGC:
MEGACO / 1.0 [125.125.125.111]: 55555 Reply = 50004 (
Context = 5000 {Modify}}

Слайд 82Приклад встановлення і руйнування з'єднання
18. Контролер наказує шлюзу MG1 почати передачу

абоненту, що викликає, акустичного сигналу «Контроль посилки виклику (КПВ)».
MGC to MG1:
MEGACO / 1.0 [123.123.123.4]: 55555 Transaction = 10005 {Context = 2000 {
Modify = A4444 {
Signals {g / PlayTone {tone = ringback}}}
}

Слайд 83Приклад встановлення і руйнування з'єднання
19. Шлюз MG1 підтверджує передачу зазначеного акустичного

сигналу в порт A4444.
MG1 to MGC:
MEGACO / 1.0 [124.124.124.222]: 55555 Reply = 10005 {
Context = 2000 {Modify))
На цьому етапі обом абонентам, які беруть участь у з'єднанні, надсилаються відповідні сигнали, і шлюз MG2 чекає, поки абонент прийме вхідний дзвінок, після чого між двома шлюзами будуть організовані двонаправлені розмовні канали

Слайд 84Приклад встановлення і руйнування з'єднання
20. Шлюз MG2 виявив, що викликаємий абонент

підняв трубку, і сповіщає про це контролер MGC.
MG2 to MGC:
MEGACO / 1.0 [125.125.125.111]: 55555 Transaction = 50005 {Context = 5000 {
Notify = А5555 {ObservedEvents = 1 234 {
19990729T22020002: glinesup / offhook)
)
)

Слайд 85Приклад встановлення і руйнування з'єднання
21. Контролер підтверджує отримання команди Notify.
MGC to

MG2:
MЕGACO / 1.0 [123.123.123.41:55555 Reply = 50005 {
Context = - (Notify))
22. Далі контролер MGC наказує шлюзу MG2 припинити передачу сигналу виклику.
MGC to MG2:
MEGACO / 1.0 [123.123.123.4]: 55555 Transaction = 50006 {Context = 5000 {
Modify = A5555 {
Events = 1235 {glinesup / onhook}, Signals {g / StopTone}; to turn off ringing)
)
23. Шлюз MG2 підтверджує виконання команди.
MG2 to MGC:
MEGACO / 1.0 [125.125.125.111]: 55555 Reply = 50006 {
Context = 5000 {Modify})

Слайд 86Приклад встановлення і руйнування з'єднання
24. Далі, контролер дозволяє шлюзу MG1 не

тільки приймати, але і передавати інформацію (режим SendReceive), і зупиняє передачу абоненту, що викликає, акустичного сигналу «КПВ».
MGC to MG1:
MEGACO / 1.0 [123.123.123.41:55555 Transaction = 10006 {Context = 2000 {
Modify = A4445 {Media {
Stream = 1 {
LocalControl {
Mode = SendReceive}
,,} /}
Modify = A4444 {
Signals {g / StopTone})}>

Слайд 87Приклад встановлення і руйнування з'єднання
25. Шлюз MG1 підтверджує виконання команди.
MG1 to

MGC:
MEGACO / 1.0 [124.124.124.222]: 55555 Reply = 10006 {
Context s 2000 {Modify, Modify »
26. Після цього починається розмовна фаза з'єднання, протягом якої учасники обмінюються мовною інформацією. Наступним кроком контролер MGC приймає рішення перевірити RТР-порт в шлюзі MG2.
MGC to MG2:
MEGACO / 1.0 [123.123.123.4]: 55555 Transaction = 50007 {
Context = - {AuditValue = A5556 {
AuditOtodia, Digit-Map, Events, Signals, Packages, Statietice}}
}}

Слайд 88Приклад встановлення і руйнування з'єднання
27. Шлюз MG2 виконує команду. У відповіді

на команду AuditValue передається вся інформація, що запитується, в тому числі статистика, зібрана за час з'єднання. Крім того, з відповіді видно, що не відбулося ніяких подій і не передавалося ніяких сигналів
MEGACO/1.0 [125.125.125.111]:55555 Reply = 50007 { Context = - {
AuditValue ( Media {
TerminationState {
BufferedEventHandling{Process} }, Stream = 1 {
LocalControl {
Mode = SendReceive, g/MaxJitterBuffer=40, ; in ms g/PreferredPacketization=30, ; in me g/PreferredEncoders =[G723, PCMU], g/PreferredDecoders=[G723, PCMU], g/Gain=0 ; in dB ), Local = SDP {
v=0
c=IN IP4 125.125.125.111 m=audio 1111 rtp/avp 4 0 a=sendrecv }, Remote = SDP{
v=0
c=IN IP4 124.124.124.222 m=audio 2222 RTP/AVP 4 0 a=sendrecv
} ; RTF profile for G.723 is 4 ) ), Packages {g, glinesup/ RTPPkg),
Statistics { RTPPkg/PacketsSent=1200, RTPPkg/OctetsSent=62300, RTPPkg/PacketsReceived=700, RTPPkg/OctetsReceived=45100, RTPPkg/PacketsLost=6, RTPPkg/Jitter=20, RTPPkg/AverageLatency=40 } } } )

Слайд 89Приклад встановлення і руйнування з'єднання
28. Абонент, що викликався, першим завершує з'єднання,

і шлюз MG2 сповіщає про це контролер MGC.
MG2 to MGC:
MEGACO / 1.0 [125.125.125.111]: 55555 Transaction = 50008 {Context = 5000 {
Notify = A5555 {ObservedEvents = +1235 {
19990729T24020002: glinesup / onhook))
}
29. Контролер MGC підтверджує отримання повідомлення Notify.
MGC to MG2:
MEGACO / 1.0 [123.123.123.4]: 55555 Reply = 50008 {
Context = - {Notify}}

Слайд 90Приклад встановлення і руйнування з'єднання
30. Отримавши інформацію від будь-якого з шлюзів

про те, що один з абонентів поклав трубку, контролер MGC завершує з'єднання.
Обом шлюзам передається команда Subtract.
Алгоритм завершення з'єднання передбачає однаковий обмін сигнальними повідомленнями між контролером і обома шлюзами, тому тут цей алгоритм розглядається на прикладі шлюзу MG2.
From MGC to MG2:
MEGACO / 1.0 [123.123.123.4]: 55555 Transaction = 50009 {Context = 5000 {
Subtract = A5555 {Audit {Statistics}}, Subtract = A5556 {Audit {Statistics}})}

Слайд 91Приклад встановлення і руйнування з'єднання
31. Кожен з портів шлюзу MG2, що

беруть участь в з'єднанні (фізичний порт - A5555 і RTP-порт - A5556), повертає статистику, зібрану за час з'єднання. У загальному випадку, контролер може запитувати статистичну інформацію тільки у одного з портів.
From MG2 to MGC:
MEGACO / 1.0 [125.125.125.H1]: 55555 Reply = 50009 {Context = 5000 {Subtract {
Statistics {; what are the stats for a TIM connection? TEMPkg / OctetsSent = 45123, TEMPkg / Duration = 40; in seconds}}. Subtract {
Statistics (
RTPPkg / PacketsSent = 1245, RTPPkg / OctetsSent = 62345 / RTPPkg / PacketsReceived = 780, RTPPkg / OctetsReceived = 45123, RTPPkg / PacketsLost = 10, RTPPkg / Jitter = 27, RTPPkg / AverageLatency = 48}
)

Слайд 92Приклад встановлення і руйнування з'єднання
32. Після завершення з'єднання контролер MGC наказує

шлюзам MG1 і MG2 бути готовими до того, що хтось із обслуговуваних ними абонентів підніме трубку.
Примітно, що портам шлюзу, які відображаються закінченнями в нульовому контексті, за замовчуванням може бути наказано виявляти, що абонент підняв трубку, при цьому контролер не передає шлюзам спеціальні команди, як це було показано раніше (крок 3)

Похожие презентации

Требования к СМК в рамках ЕЭАС 326
Реализация требований федерального государственного образовательного стандарта средствами системы Л.В.Занкова 164
История освоения шельфовых месторождений и развитие технологий разработки морского бурения 443
QML – новый подход к построению GUI 232
ПРОЗРАЧНОСТЬ 252
Склонение имен существительных. Падежные окончания имен существительных.Развитие речи. Заядлые рыбаки 266

Обратная связь

Если не удалось найти и скачать презентацию, Вы можете заказать его на нашем сайте. Мы постараемся найти нужный Вам материал и отправим по электронной почте. Не стесняйтесь обращаться к нам, если у вас возникли вопросы или пожелания:

Email: Нажмите что бы посмотреть 

Что такое ThePresentation.ru?

Это сайт презентаций, докладов, проектов, шаблонов в формате PowerPoint. Мы помогаем школьникам, студентам, учителям, преподавателям хранить и обмениваться учебными материалами с другими пользователями.

Для правообладателей

Яндекс.Метрика