Модель процесу обслуговування виклику

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

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

9.2 Модель процесу обслуговування виклику
При описі алгоритму встановлення з'єднання з використанням протоколу MEGACO комітет IETF спирається на спеціальну модель процесу обслуговування виклику, відмінну від моделі MGCP. Протокол MEGACO оперує з двома логічними об'єктами всередині транспортного шлюзу: порт (termination) і контекст (context), якими може керувати контролер шлюзу. Приклад моделі процесу обслуговування виклику наведено на рис. 9.2.
Порти є джерелами і приймачами мовної інформації. Визначено два види портів: фізичні і віртуальні. Фізичні порти, існуючі постійно з моменту конфігурації шлюзу, це аналогові телефонні інтерфейси обладнання, що підтримують одне телефонне з'єднання, або цифрові канали, що також підтримують одне телефонне з'єднання і згруповані за принципом тимчасового розділення каналів в тракт Е1. Віртуальні порти, які існують тільки протягом розмовної сесії, є портами з боку IP мережі (RTP-порти), через які ведуться передача і прийом пакетів RTP.

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


Віртуальні порти створюються шлюзом при отриманні від контролера команди Add і ліквідуються при отриманні команди Subtract, тоді як фізичні порти при отриманні команди Add або Subtract, відповідно, виводяться з нульового контексту або повертаються назад в нульовий контекст.
Порт має унікальний ідентифікатор (TerminationID), який призначається шлюзом при конфігурації порту. Наприклад, ідентифікатором порту може бути номер тракту Е1 і номер тимчасового каналу всередині тракту. Іноді команди можуть ставитися до всього шлюзу, тоді використовується спеціальний ідентифікатор порту (TerminationID) - «Root».
Порти мають ряд властивостей (properties), кожне з яких має унікальний ідентифікатор (propertylD). Наприклад, порти можуть мати властивості генерувати мовні підказки, акустичні та викличні сигнали, а також детектувати сигнали DTMF.
При створенні портів деякі властивості присвоюються їм за замовчуванням. За допомогою протоколу MEGACO контролер може змінювати властивості портів шлюзу. Властивості портів групуються в дескриптори, які включаються до команди управління портами (таблиця 9.1).
Таблиця 9.1 Дескриптори протоколу MEGACO

Контекст - це відображення зв'язку між кількома портами, тобто абстрактне уявлення з'єднання двох або більше портів одного шлюзу. У будь-який момент часу порт може відноситися тільки до одного контексту, який має свій унікальний ідентифікатор. Існує особливий вид контексту - нульовий. Всі порти, що входять до нульової контекст, не пов'язані ні між собою, ні з іншими портами. Наприклад, абстрактним поданням вільного (не зайнятого) каналу в моделі процесу обслуговування виклику є порт в нульовому контексті. У загальному випадку для приєднання порту до контексту служить команда Add. При цьому, якщо контролер не специфікує існуючий контекст, до якого повинен бути доданий порт, то шлюз створює новий контекст.
Якщо шлюз підтримує конференцію, то контекст визначає топологію зв'язків між портами, що беруть участь у конференції, тобто можливі напрямки потоків інформації для кожної пари портів. Приклади топологій, що підтримуються протоколом MEGACO/H.323, наведено на рис. 9.3.

VoIP 9.3.1.png
ВАРІАНТ 1


VoIP 9.3.2.png
ВАРІАНТ 1


VoIP 9.3.3.png
ВАРІАНТ 1


VoIP 9.3.4.png
ВАРІАНТ 1


VoIP 9.3.5.png
ВАРІАНТ 1


VoIP 9.3.6.png
ВАРІАНТ 1
Рис. 9.3. Варіанти топології зв'язків між портами усередині одного контексту


Короткий опис варіантів топології зв'язків у конференції, представлених на рис. 9.3, зведено в таблицю 9.2.
Таблиця 9.2 Опис варіантів топології

Слід зазначити, що порти шлюзу не знають про режим, який підтримують інші порти, які беруть участь у конференції.


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