Третій підхід до побудови мереж IP-телефонії заснований на використанні протоколу MGCP, також запропонований комітетом IETF, робочою групою MEGACO.

Під час розроблення цього протоколу робоча група MEGACO спиралася на мережну архітектуру, що містить основні функціональні блоки трьох видів (рис. 9.15.7):

• шлюз — Media Gateway (MG), що виконує функції перетворення мовленнєвої інформації, яка надходить із боку ТМЗК з постійною швидкістю передачі, у вигляд, придатний для передачі мережами з маршрутизацією пакетів IP (кодування й пакування мовленнєвої інформації в пакети RTP/UDP/IP, а також зворотне перетворення);
• контролер шлюзів — Call Agent, що виконує функції управління шлюзами;
• шлюз сигналізації — Signaling Gateway (SG), що забезпечує доставку сигнальної інформації, що надходить із боку ТМЗК, до контролера шлюзів і перенесення сигнальної інформації у зворотному напрямку.

Рис. 9.15.7. Архітектура мережі на базі протоколу MGCP

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

Шлюз сигналізації виконує функції STP — транзитного пункту мережі сигналізації ЗКС 7. Самі шлюзи виконують тільки функції перетворення мовленнєвої інформації. Один контролер управляє одночасно декількома шлюзами. У мережі можуть бути присутні кілька контролерів. Передбачається, що вони синхронізовані між собою й узгоджено управляють шлюзами, що беруть участь у з’єднанні. Разом з тим, MEGACO не визначає протоколу для синхронізації роботи контролерів. У ряді робіт, присвячених дослідженню можливостей протоколу MGCP, для цього пропонується використовувати протоколи Н.323, SIP або ISUP/IP.

Повідомлення протоколу MGCP переносяться протоколом без гарантованої доставки повідомлень UDP. Робоча група SIGTRAN комітету IETF нині розробляє механізм взаємодії контролера шлюзів і шлюзу сигналізації.

Шлюз сигналізації повинен приймати пакети трьох нижніх рівнів системи сигналізації ЗКС 7 (рівнів підсистеми перенесення повідомлень МТР), що надходять з ТМЗК, і передавати сигнальні повідомлення верхнього рівня користувача до контролера шлюзів. Шлюз сигналізації також повинен уміти передавати IP-мережею сигнальні повідомлення Q.931, що надходять з ТМЗК.

Основна увага робочої групи SIGTRAN приділяється питанням розробки найефективнішого механізму передачі сигнальної інформації з IP-мереж. Слід зазначити, що існує кілька причин, через які довелося відмовитися від використання протоколу TCP. Робоча група SIGTRAN пропонує використовувати для передачі сигнальної інформації протокол Stream Control Transport Protocol (SCTP), що має низку переваг перед протоколом ТСР, основним з яких є значне зниження часу доставки сигнальної інформації й, отже, часу встановлення з’єднання — одного з найважливіших параметрів якості обслуговування.

Відзначимо, що протокол MGCP є внутрішнім протоколом для обміну інформацією між функціональними блоками розподіленого шлюзу, що ззовні представляється одним шлюзом. Протокол MGCP є master/slave-протоколом. Це означає, що контролер шлюзів є головним, а сам шлюз — веденим пристроєм, що має виконувати всі команди, що надходять від контролера Call Agent.

Описане вище рішення забезпечує масштабованість мережі й простоту управління мережею через контролер шлюзів. Шлюзи не повинні бути інтелектуальними пристроями, вимагають меншої продуктивності процесорів і, отже, стають менш коштовними. Крім того, дуже швидко вводяться нові протоколи сигналізації або додаткові послуги, оскільки ці зміни зачіпають тільки контролер шлюзів, а не самі шлюзи.

Третій підхід, пропонований організацією IETF (робоча група MEGACO), добре підходить для розгортання глобальних мереж IP-телефонії, що приходять на зміну традиційним телефонним мережам.

Розглянемо алгоритми встановлення й руйнування з’єднання з використанням протоколу MGCP. Перший приклад охоплює взаємодію протоколу MGCP із протоколом ЗКС 7 (рис. 9.15.8).

Рис. 9.15.8. Установлення й руйнування з’єднання з використанням протоколу MGCP (приклад 1)

1. Від телефонної станції АТС-А до шлюзу сигналізації SG1 по спільному каналу сигналізації надходить запит з’єднання у вигляді повідомлення IAM протоколу ISUP. На рис. 9.15.8 шлюз сигналізації SG1 і SG2 сполучені із транспортними шлюзами TGW1 і TGW2 відповідно. Шлюз SG1 передає повідомлення IAM до контролера шлюзів, що обробляє запит і визначає, що виклик повинен бути спрямований до АТС-Б за допомогою шлюзу TGW2.
2. Контролер резервує порт шлюзу TGW1 (розмовний канал). Для цього він передає до шлюзу команду CreateConnection. Відзначимо, що порт шлюзу TGW1 може тільки приймати інформацію (режим «recvonly»), оскільки він ще не обізнаний про те, за якою адресою і в який спосіб йому слід передавати інформацію.
3. У відповіді на цю команду шлюз TGW1 повертає опис параметрів сеансу зв’язку.
4. Прийнявши відповідь шлюзу TGW1, контролер передає команду CRCX другому шлюзу TGW2 з метою зарезервувати порт у цьому шлюзі.
5. Шлюз TGW2 вибирає порт, що братиме участь у з’єднанні, і підтверджує прийом команди CRCX. За допомогою двох команд CRCX створюється односпрямований розмовний канал для передачі абонентові, що викликає, акустичних сигналів або мовних підказок і повідомлень. У той же час, порт шлюзу TGW2 уже може не тільки приймати, але й передавати інформацію, оскільки він отримав опис параметрів зв’язку від зустрічного шлюзу.
6. Далі контролер шлюзів передає повідомлення IAM до АТС-Б.
7. На повідомлення IAM станція АТС-Б відповідає підтвердженням АСМ, що негайно пересилається до станції АТС-А.
8. Після того як абонент, якого викликають, прийме виклик, АТС-Б передає до контролера шлюзів повідомлення ANM.
9. Далі контролер заміняє в шлюзі TGW1 режим «recvonly» на повнодуплексний режим за допомогою команди MDCX.
10. Шлюз TGW1 виконує й підтверджує зміну режиму.
11. Контролер передає повідомлення ANM до АТС-А, після чого починається розмовна фаза з’єднання.
12. Завершення розмовної фази відбувається в такий спосіб. У нашому випадку абонент Б, що викликав, дає відбій першим. АТС-Б передає через шлюз сигналізації повідомлення REL до контролера шлюзів.
13. Прийнявши повідомлення REL, контролер шлюзів завершує з’єднання з викликаним абонентом.
14. Шлюз підтверджує завершення з’єднання й передає до контролера зібрані за час з’єднання статистичні дані.
15. Контролер шлюзів передає повідомлення RLC до АТС-Б з метою підтвердити роз’єднання.
16. Паралельно контролер завершує з’єднання зі стороною, що викликала.
17. Шлюз GW1 підтверджує завершення з’єднання й передає до контролера зібрані за час з’єднання статистичні дані.
18. АТС-А підтверджує завершення з’єднання передачею повідомлення RLC, після чого з’єднання вважається зруйнованим.

Другий приклад ілюструє взаємодія протоколу MGCP із протоколами ЗКС 7 і Н.323 (рис. 9.15.9).

Рис. 9.15.9. Установлення й руйнування з’єднання з використанням протоколу MGCP (приклад 2)

1. З телефонної станції АТС-А до шлюзу сигналізації SG1 по спільному каналу сигналізації надходить запит з’єднання (повідомлення IAM). На рис. 9.15.9 шлюз сигналізації SG1 також сполучений із транспортним шлюзом TGW1. Шлюз SG1 передає повідомлення IAM контролеру шлюзів, що обробляє запит і визначає, що виклик повинен бути спрямований до кінцевого пристрою викликуваного користувача — терміналу Н.323.
2. Контролер шлюзів резервує порт шлюзу TGW1 (розмовний канал). Із цією метою він передає до шлюзу команду CreateConnection. І в цьому прикладі порт шлюзу TGW1 може тільки приймати інформацію (режим «recvonly»).
3. У відповіді на прийняту команду шлюз TGW1 повертає опис параметрів зв’язку.
4. Прийнявши відповідь від шлюзу TGW1, контролер передає до воротаря мережі Н.323 повідомлення ARQ з alias-адресою абонента, якого викликають.
5. У відповідь на повідомлення ARQ воротар передає повідомлення ACF із вказівкою транспортної адреси свого сигнального каналу.
6. Контролер передає запит з’єднання SETUP на транспортну адресу сигнального каналу воротаря, при цьому використовується процедура Fast Start. Воротар пересилає повідомлення SETUP до терміналу, якого викликають.
7. Термінал, якого викликають, передає запит допуску до ресурсів мережі ARQ.
8. У відповідь на запит ARQ воротар передає підтвердження запиту ACF.
9. Термінал, якого викликають, передає повідомлення ALERTING, що воротар маршрутизує до контролера шлюзів. При цьому користувачеві, якого викликають, подається візуальний або акустичний сигнал про вхідний виклик, а користувачеві, що викликає, подається індикація того, що користувач, якого викликають, не зайнятий і одержує сигнал про виклик.
10. Контролер перетворює повідомлення ALERTING у повідомлення АСМ, що негайно пересилається до АТС-А.
11. Після того як викликуваний користувач прийме вхідний виклик, контролер одержить повідомлення CONNECT.
12. Контролер шлюзів міняє в шлюзі TGW1 режим «recvonly» на повнодуплексний режим.
13. Шлюз TGW1 виконує й підтверджує зміну режиму з’єднання.
14. Контролер передає повідомлення ANM до АТС-А, після чого починається розмовна фаза з’єднання, у ході якої обладнання користувача, що викликав, передає мовленнєву інформацію, упаковану в пакети RTP/UDP/IP, на транспортну адресу RTP-каналу терміналу викликаного абонента, а той передає пакетовану мовленнєву інформацію на транспортну адресу RTP-каналу терміналу абонента, що викликав. За допомогою каналу RTCP ведеться контроль передачі інформації з RTP-каналу.
15. Після закінчення розмовної фази починається фаза руйнування з’єднання. Обладнання користувача, що ініціює руйнування з’єднання, має припинити передачу мовленнєвої інформації, закрити логічні канали й передати повідомлення RELEASE COMPLETE, після чого сигнальний канал закривається.
16. Контролер шлюзів передає повідомлення RELEASE до АТС-А з метою завершення з’єднання.
17. Окрім того, контролер передає до шлюзу команду DLCX.
18. Шлюз підтверджує завершення з’єднання й передає до контролера зібрані за час з’єднання статистичні дані.
19. Після вищеописаних дій контролер і кінцеве обладнання сповіщають воротар про звільнення смуги, що займалася. Із цією метою кожний з учасників з’єднання посилає воротареві по каналу RAS запит виходу із з’єднання DRQ, на який воротар повинен передати підтвердження DCF.
20. Від АТС-А надходить підтвердження роз’єднання RLC, після чого з’єднання вважається зруйнованим.

Слід зазначити, що алгоритм взаємодії протоколів SIP і MGCP не сильно відрізняється від вищеописаного алгоритму.

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

Міжнародний союз електрозв’язку в проекті версії 4 рекомендації Н.323 увів принцип декомпозиції шлюзів. Управління функціональними блоками розподіленого шлюзу здійснюватиметься контролером шлюзу — Media Gateway Controller — за допомогою адаптованого до Н.323 протоколу MEGACO, що у Рекомендації Н.248 названий Gateway Control Protocol.

Повідомлення протоколу MEGACO відрізняються від повідомлень протоколу MGCP, але процедури встановлення й руйнування з’єднань із використанням обох протоколів ідентичні, тому опис процедури встановлення з’єднання на базі протоколу MEGACO тут не наводиться.