Відмінності між версіями «Базове з'єднання з участю воротаря»
(Створена сторінка: <div style="background: #33ccff"> '''Технологія VoIP''' >> '''[[Розділ_6._Сигналізація_Н.323|Розділ 6. Сигналіза...) |
|||
(не показана одна проміжна версія ще одного учасника) | |||
Рядок 9: | Рядок 9: | ||
</center> | </center> | ||
</div> | </div> | ||
− | + | '''6.5.1 Базове з'єднання з участю воротаря'''<br> | |
+ | Сценарій цього першого випадку наведено на рис.6.19. Зухвала устаткування передає повідомлення ARQ з alias-адресою абонента, що викликається, у відповідь на яке воротар передає повідомлення ACF з повідомленням, що саме він буде маршрутизувати сигнальні повідомлення (Gatekeper routed call signaling), і з зазначенням транспортного адреси свого сигнального каналу. Далі викликає устаткування передає на цей транспортний адресу запит з'єднання Setup. Сторож пересилає повідомлення Setup викликається обладнанню та передає зухвалому обладнання повідомлення Call Proceeding, що означає, що отриманої інформації достатньо для обслуговування надійшов дзвінок. Викликаного обладнання також відповідає на Setup повідомленням Call Proceeding. Якщо обладнання має можливість прийняти виклик, вона передає запит допуску до ресурсів мережі ARQ, на який воротар може відповісти підтвердженням ACF або відмовою в допуску до ресурсів мережі ARJ. У першому випадку викликається устаткування передає повідомлення Alerting, і сторож маршрутизує його до викликає обладнання. Викликуваному користувачеві подається візуальний або акустичний сигнал про вхідний дзвінок, а тому, хто дається індикація того, що користувач, що викликається не зайнятий і йому подається викличний сигнал. При відмові в допуску до ресурсів мережі викликається обладнання закриває сигнальний канал шляхом передачі воротареві повідомлення Release Complete.<br> | ||
+ | Після того як користувач, що викликається візьме вхідний дзвінок, воротареві передається повідомлення Connect з транспортним адресою керуючого каналу Н.245 викликається обладнання. Сторож заміняє цю адресу транспортним адресою свого керуючого каналу Н.245 і пересилає Connect зухвалому обладнання, після чого відкривається керуючий канал Н.245.<br> | ||
+ | Щоб прискорити відкриття розмовної сесії, керуючий канал може бути відкритий викликуваним обладнанням після отримання повідомлення Setup з транспортним адресою керуючого каналу Н.245 викликає обладнання або воротаря, або викликають користувачем після отримання повідомлення Call Proceeding або Alerting, що містить транспортний адресу керуючого каналу Н.245 викликається користувача або воротаря.<br> | ||
+ | Після відкриття керуючого каналу Н.245 починається обмін даними про функціональні можливості обладнання. У розглянутому нами випадку всі керуючі повідомлення, що передаються від одного кінцевого обладнання до іншого, маршрутизуються воротарем. Термінали обмінюються повідомленнями '''TermlnalCapabilttySet''', в яких вказуються можливі алгоритми декодування прийнятої інформації. Слід зазначити, що повідомлення '''TermjnalCapabllHySet''' повинно бути першим повідомленням, переданим по керуючому каналу. Обладнання, яке прийняло повідомлення '''TermlnalCapabllitySet''' від іншого обладнання, підтверджує його отримання передачею повідомлення TermlnalCapabllttySetAck. | ||
+ | Потім ініціюється процедура визначення ведучого / веденого обладнання, необхідна для вирішення конфліктів, що виникають між двома пристроями при організації конференції, коли обидва вони можуть бути активними контролерами конференцій, або між двома пристроями, що намагаються одночасно відкрити двонаправлені логічні канали. У ході процедури пристрої обмінюються повідомленнями '''masterSlaveDetermlnation'''.<br> | ||
+ | <center> | ||
+ | [[Файл:VoIP_6.19.png]]<br> | ||
+ | '''Рис. 6.19.''' Приклад з'єднання з участю воротаря | ||
+ | </center><br> | ||
+ | У відповідь на отрімані Повідомлення masterSlaveDetermination обідва прістрої передають Повідомлення '''masterSlaveDeterminationAck''', в якіх вказується, його призначення та з ціх прістроїв є для даного з'єднання ведучим, а його призначення - ведення.<br> | ||
+ | Нагадаємо, Що можливе Сценарій процедури Master-Slave Determination, Що передбачає скороченню кількості переданих повідомлень: обладнання, його призначення та передало Повідомлення '''masterSlaveDetermination''' І Отримав у відповідь Повідомлення '''masterSlaveDeterminationAck''', передає Повідомлення '''masterSlaveDeterminationAck'''.<br> | ||
+ | Після обміну данімі про функціональні Можливості І визначення ведучого І виїденого обладнання Може Виконувати процедура Відкриття односпрямованіх логічніх каналів. У вімозі відкріті логічний канал (у нашому випадку - прямий логічний канал) '''openLogicalChannel''' обладнання вказує вид інформації, Який буде передаватіся з задовольняють каналу, І алгорітм кодування. У нашому випадка логічний канал прізначається для перенесення мови, тому в Повідомлення '''openLogicalChannel''' включається параметр '''mediaControlChannel''' Із зазначенням транспортного адреси каналу RTCP, за допомогою метода якого проводитися контроль передачі RTP пакетів. У відповідь на Повідомлення '''openLogicalChannel''' обладнання винні передати підтвердження '''openLogicalChannelAck''', в якому вказується транспортний адресою, на Який передавальній стороні слід надсілаті RTP пакети, а такоже транспортний адресою каналу RTCP.<br> | ||
+ | Далі відкрівається розмовності сесія. Обладнання віклікає користувач передає мовно інформацію, упакованих в пакети RTP / UDP / IP, на транспортний адресою RTP-каналу обладнання вікліканого користувач, а вікліканій користувач передає пакетованіх мовно інформацію на транспортний адресою RTP-каналу обладнання віклікає користувач. За допомогою метода каналу RTCP ведеться контроль передачі інформації з RTP каналах.<br> | ||
+ | Після Закінчення розмовної фазі почінається фаза руйнування з'єднання. Обладнання користувач, Що ініціює роз'єднання, винна пріпініті передачу мовної інформації, Закрити логічні канали І передати по керуючому каналу Повідомлення Н.245 '''endSessionCommand''', Що означає, Що користувач хоче Завершити з'єднання. Далі від зустрічного обладнання очікується Повідомлення endSessionCommand, після прийому якого керуючий канал Н.245 закрівається. Наступним кроком, ЯКЩО сигнальний канал Ще відкрите, передається Повідомлення Release Complete.<br> | ||
+ | Користувач, Що Отримав команду endSessionCommand від користувач, Який ініціював руйнування з'єднання, повинен пріпініті передачу мовної інформації, Закрити логічні канали І передати Повідомлення '''endSessionCommand'''. Далі, ЯКЩО сигнальний канал залішівся відкрітім, передає побажання Release Complete, І сигнальний канал закрівається.<br> | ||
+ | Після віщеопісаніх Дій кінцеве обладнання сповіщає воротар про звільнення зарезервованої смуги пропускання. З цією Метою шкіряний з учасніків з'єднання передає по каналу RAS Запит виходе Із з'єднання DRQ, на Який воротар повинен відповісті підтвердженням DCF, після чого обслуговування виклику вважається завершення.<br> | ||
<div style="background: #33ccff"> | <div style="background: #33ccff"> |
Поточна версія на 11:24, 21 грудня 2010
Технологія VoIP >> Розділ 6. Сигналізація Н.323
[ << 6.5 Алгоритми встановлення, підтримки і руйнування з'єднання ] [ 6.5.2 Базове з'єднання без участі воротаря >> ]
6.5.1 Базове з'єднання з участю воротаря
Сценарій цього першого випадку наведено на рис.6.19. Зухвала устаткування передає повідомлення ARQ з alias-адресою абонента, що викликається, у відповідь на яке воротар передає повідомлення ACF з повідомленням, що саме він буде маршрутизувати сигнальні повідомлення (Gatekeper routed call signaling), і з зазначенням транспортного адреси свого сигнального каналу. Далі викликає устаткування передає на цей транспортний адресу запит з'єднання Setup. Сторож пересилає повідомлення Setup викликається обладнанню та передає зухвалому обладнання повідомлення Call Proceeding, що означає, що отриманої інформації достатньо для обслуговування надійшов дзвінок. Викликаного обладнання також відповідає на Setup повідомленням Call Proceeding. Якщо обладнання має можливість прийняти виклик, вона передає запит допуску до ресурсів мережі ARQ, на який воротар може відповісти підтвердженням ACF або відмовою в допуску до ресурсів мережі ARJ. У першому випадку викликається устаткування передає повідомлення Alerting, і сторож маршрутизує його до викликає обладнання. Викликуваному користувачеві подається візуальний або акустичний сигнал про вхідний дзвінок, а тому, хто дається індикація того, що користувач, що викликається не зайнятий і йому подається викличний сигнал. При відмові в допуску до ресурсів мережі викликається обладнання закриває сигнальний канал шляхом передачі воротареві повідомлення Release Complete.
Після того як користувач, що викликається візьме вхідний дзвінок, воротареві передається повідомлення Connect з транспортним адресою керуючого каналу Н.245 викликається обладнання. Сторож заміняє цю адресу транспортним адресою свого керуючого каналу Н.245 і пересилає Connect зухвалому обладнання, після чого відкривається керуючий канал Н.245.
Щоб прискорити відкриття розмовної сесії, керуючий канал може бути відкритий викликуваним обладнанням після отримання повідомлення Setup з транспортним адресою керуючого каналу Н.245 викликає обладнання або воротаря, або викликають користувачем після отримання повідомлення Call Proceeding або Alerting, що містить транспортний адресу керуючого каналу Н.245 викликається користувача або воротаря.
Після відкриття керуючого каналу Н.245 починається обмін даними про функціональні можливості обладнання. У розглянутому нами випадку всі керуючі повідомлення, що передаються від одного кінцевого обладнання до іншого, маршрутизуються воротарем. Термінали обмінюються повідомленнями TermlnalCapabilttySet, в яких вказуються можливі алгоритми декодування прийнятої інформації. Слід зазначити, що повідомлення TermjnalCapabllHySet повинно бути першим повідомленням, переданим по керуючому каналу. Обладнання, яке прийняло повідомлення TermlnalCapabllitySet від іншого обладнання, підтверджує його отримання передачею повідомлення TermlnalCapabllttySetAck.
Потім ініціюється процедура визначення ведучого / веденого обладнання, необхідна для вирішення конфліктів, що виникають між двома пристроями при організації конференції, коли обидва вони можуть бути активними контролерами конференцій, або між двома пристроями, що намагаються одночасно відкрити двонаправлені логічні канали. У ході процедури пристрої обмінюються повідомленнями masterSlaveDetermlnation.
У відповідь на отрімані Повідомлення masterSlaveDetermination обідва прістрої передають Повідомлення masterSlaveDeterminationAck, в якіх вказується, його призначення та з ціх прістроїв є для даного з'єднання ведучим, а його призначення - ведення.
Нагадаємо, Що можливе Сценарій процедури Master-Slave Determination, Що передбачає скороченню кількості переданих повідомлень: обладнання, його призначення та передало Повідомлення masterSlaveDetermination І Отримав у відповідь Повідомлення masterSlaveDeterminationAck, передає Повідомлення masterSlaveDeterminationAck.
Після обміну данімі про функціональні Можливості І визначення ведучого І виїденого обладнання Може Виконувати процедура Відкриття односпрямованіх логічніх каналів. У вімозі відкріті логічний канал (у нашому випадку - прямий логічний канал) openLogicalChannel обладнання вказує вид інформації, Який буде передаватіся з задовольняють каналу, І алгорітм кодування. У нашому випадка логічний канал прізначається для перенесення мови, тому в Повідомлення openLogicalChannel включається параметр mediaControlChannel Із зазначенням транспортного адреси каналу RTCP, за допомогою метода якого проводитися контроль передачі RTP пакетів. У відповідь на Повідомлення openLogicalChannel обладнання винні передати підтвердження openLogicalChannelAck, в якому вказується транспортний адресою, на Який передавальній стороні слід надсілаті RTP пакети, а такоже транспортний адресою каналу RTCP.
Далі відкрівається розмовності сесія. Обладнання віклікає користувач передає мовно інформацію, упакованих в пакети RTP / UDP / IP, на транспортний адресою RTP-каналу обладнання вікліканого користувач, а вікліканій користувач передає пакетованіх мовно інформацію на транспортний адресою RTP-каналу обладнання віклікає користувач. За допомогою метода каналу RTCP ведеться контроль передачі інформації з RTP каналах.
Після Закінчення розмовної фазі почінається фаза руйнування з'єднання. Обладнання користувач, Що ініціює роз'єднання, винна пріпініті передачу мовної інформації, Закрити логічні канали І передати по керуючому каналу Повідомлення Н.245 endSessionCommand, Що означає, Що користувач хоче Завершити з'єднання. Далі від зустрічного обладнання очікується Повідомлення endSessionCommand, після прийому якого керуючий канал Н.245 закрівається. Наступним кроком, ЯКЩО сигнальний канал Ще відкрите, передається Повідомлення Release Complete.
Користувач, Що Отримав команду endSessionCommand від користувач, Який ініціював руйнування з'єднання, повинен пріпініті передачу мовної інформації, Закрити логічні канали І передати Повідомлення endSessionCommand. Далі, ЯКЩО сигнальний канал залішівся відкрітім, передає побажання Release Complete, І сигнальний канал закрівається.
Після віщеопісаніх Дій кінцеве обладнання сповіщає воротар про звільнення зарезервованої смуги пропускання. З цією Метою шкіряний з учасніків з'єднання передає по каналу RAS Запит виходе Із з'єднання DRQ, на Який воротар повинен відповісті підтвердженням DCF, після чого обслуговування виклику вважається завершення.
[ << 6.5 Алгоритми встановлення, підтримки і руйнування з'єднання ] [ 6.5.2 Базове з'єднання без участі воротаря >> ]
--Козінцев Олексій 36 гр. 16:04, 29 листопада 2010 (EET)