Перегляд вихідного коду сторінки Базове з'єднання без участі воротаря

<div style="background: #33ccff"> 
'''[[Технологія VoIP]]''' >> 
'''[[Розділ_6._Сигналізація_Н.323|Розділ 6. Сигналізація Н.323]]'''
<center>
----
[ [[Базове_з'єднання_з_участю_воротаря|<< 6.5.1 Базове з'єднання з участю воротаря]] ]
[ [[Туннелирование_керуючих_повідомлень|6.5.3 Туннелирование керуючих повідомлень >>]] ]
----
</center>
</div>
'''6.5.2 Базове з'єднання без участі воротаря'''<br>
Тепер розглянемо випадок, коли викликається і викликає обладнання взаємодіють безпосередньо один з одним, воротар в мережі відсутня (рис.6.20). Зухвала обладнання посилає запит з'єднання Setup на відомий транспортна адреса сигнального каналу викликається обладнання. Викликаного обладнання відповідає на Setup повідомленням Call Proceeding, а потім - Alerting. Викликуваному користувачеві дається візуальний або акустичний сигнал про вхідний виклику, а тому, хто - індикація того, що користувач, що викликається не зайнятий і отримує викличний сигнал.<br>
Як тільки користувач, що викликається візьме вхідний дзвінок, передається повідомлення Connect із зазначенням транспортного адреси керуючого каналу Н.245 викликається обладнання, після чого відкривається керуючий канал Н.245.<br>
І тут, щоб пришвидшити відкриття розмовної сесії, керуючий канал теж може бути відкритий викликуваним обладнанням після отримання повідомлення Setup з транспортним адресою керуючого каналу Н.245 викликає обладнання, або викликають користувачем після отримання повідомлення Call Proceeding або Alerting, в якому міститься транспортна адреса керуючого каналу Н.245 викликається обладнання.
Після відкриття керуючого каналу виконуються всі процедури, описані в першому випадку: обмін даними про функціональні можливості, визначення ведучого / веденого обладнання, відкриття односпрямованих логічних каналів.<br>
Далі відкривається розмовна сесія. Обладнання викликає користувача передає мовну інформацію, упаковану в пакети RTP / UDP / IP, на транспортний адресу RTP-каналу обладнання викликається користувача, а воно, у свою чергу, передає пакетованих мовну інформацію на транспортний адресу RTP-каналу обладнання викликає користувача.<br>
Після закінчення розмовної фази починається фаза руйнування з'єднання. Обладнання користувача, що ініціює роз'єднання, припиняє передачу мовної інформації, закриває логічні канали і передає по керуючому каналу повідомлення Н.245 endSessionCommand, що означає, що користувач хоче завершити з'єднання. Очікується повідомлення endSessionCommand від зустрічного обладнання, після чого керуючий канал Н.245 закривається. Наступним кроком передається повідомлення Release Complete, і сигнальний канал закривається.<br>
<center>
[[Файл:VoIP_6.20.png]]<br>
'''Рис. 6.20.''' Приклад з'єднання без участі воротаря
</center><br>
Користувач, що отримав команду endSessionCommand від користувача, який ініціював роз'єднання, повинен припинити передачу мовної інформації, закрити логічні канали і передати повідомлення endSessionCommand. Далі, якщо сигнальний канал залишився відкритим, передає побажання Release Complete, сигнальний канал закривається, і обслуговування виклику вважається завершеним.<br>
<div style="background: #33ccff"> 
<center>
----
[ [[Базове_з'єднання_з_участю_воротаря|<< 6.5.1 Базове з'єднання з участю воротаря]] ]
[ [[Туннелирование_керуючих_повідомлень|6.5.3 Туннелирование керуючих повідомлень >>]] ]
----
</center>
</div>
----
--[[Користувач:Козінцев Олексій|Козінцев Олексій  36 гр.]] 16:06, 29 листопада 2010 (EET)