Відмінності між версіями «Мережа на базі MGCP і MEGACO»

Версія за 11:24, 16 листопада 2010

1.5.3 Мережа на базі MGCP і MEGACO
Третій підхід до побудови мереж IP-телефонії, заснований на використанні протоколу MGCP [56], також запропоновано комітетом IETF, робочою групою MEGACO.
При розробці цього протоколу робоча група MEGACO спиралася на мережеву архітектуру, яка містить основні функціональні блоки трьох видів (рис. 1.12):

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

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

Шлюз сигналізації виконує функції 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 приведено у розділі 8.
Розглянемо алгоритми встановлення і руйнування з'єднання з використанням протоколу MGCP. Перший приклад охоплює взаємодію протоколу MGCP з протоколом ОКС7 (рис. 1.13).

1. Від телефонної станції АТС-А до шлюзу сигналізації SG1 за загальним каналу сигналізації надходить запит з'єднання у вигляді повідомлення IAM протоколу ISUP [6]. На рис. 1.13 шлюз сигналізації 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 (рис. 1.14).

1. З телефонної станції АТС-А до шлюзу сигналізації SG1 за загальним каналу сигналізації надходить запит з'єднання (повідомлення IAM). На рис. 1.14 шлюз сигналізації SG1 також суміщений з транспортним шлюзом TGW1. Шлюз SG1 передає повідомлення IAM контролеру шлюзів, який обробляє запит і визначає, що виклик повинен бути направлений до кінцевого пристрою викликається користувача - терміналу Н.323.
2. Контролер шлюзів резервує порт шлюзу TGW1 (розмовний канал). З цією метою він передає до шлюзу команду CreateConnec-tion. І в цьому прикладі порт шлюзу 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 тут не наводиться. Ці процедури, разом з детальним аналізом протоколу MEGACO, розглядаються в розділі 9.

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