/books/ip-telephony/71-ip6 2021-06-25T01:40:24+03:00 Мини-Сервер singlwolf@mini-server.ru Joomla! - Open Source Content Management 2011-11-27T21:09:00+04:00 2011-11-27T21:09:00+04:00 /books/ip-telephony/71-ip6/1040-4-6-mezhsetevoe-vzaimodejstvie-chast-2

<br/> <p>S1: Обмен информацией разрешения запроса между терминалом и gatekeeper 1.</p> <p>S2: Обмен информацией разрешения запроса между gatekeeper I и сервером авторизации.</p> <p>S3: Обмен информацией разрешения запроса между gatekeeper 1 и шлюзом.</p> <p>S4: Обмен информацией разрешения запроса между шлюзом и его gatekeeper.</p> <p>S5: Обмен информацией разрешения запроса между gatekeeper 2 и <a href="/">сервер</a> от третьего лица.</p> <p>S6: Обмен информацией разрешения запроса между gatekeeper 1 и gatekeeper 2.</p> <p>Следует особо отметить, что реализация передачи сигнальной информации между раз­личными административными доменами в <strong>сети</strong> IP-телефонии требует обеспечения соответ­ствующей степени <i>защиты</i> информации.</p> <br/> <p></p>

<br/> <p>S1: Обмен информацией разрешения запроса между терминалом и gatekeeper 1.</p> <p>S2: Обмен информацией разрешения запроса между gatekeeper I и сервером авторизации.</p> <p>S3: Обмен информацией разрешения запроса между gatekeeper 1 и шлюзом.</p> <p>S4: Обмен информацией разрешения запроса между шлюзом и его gatekeeper.</p> <p>S5: Обмен информацией разрешения запроса между gatekeeper 2 и <a href="/">сервер</a> от третьего лица.</p> <p>S6: Обмен информацией разрешения запроса между gatekeeper 1 и gatekeeper 2.</p> <p>Следует особо отметить, что реализация передачи сигнальной информации между раз­личными административными доменами в <strong>сети</strong> IP-телефонии требует обеспечения соответ­ствующей степени <i>защиты</i> информации.</p> <br/> <p></p> 2011-11-18T20:49:00+04:00 2011-11-18T20:49:00+04:00 /books/ip-telephony/71-ip6/1039-4-6-mezhsetevoe-vzaimodejstvie-chast-1

<p>При внедрении систем IP-телефонии часто необходимо решать задачу обеспечения эффективного взаимодействия сетей различных операторов. Здесь существует масса про­блем, связанных с преобразованием адресов между административными доменами, взаимо­расчетами между операторами, <i>контролем</i> доступа к ресурсам сети, <strong>защитой</strong> внутренней то­пологии и т. д. Успешное решение данных задач должна обеспечивать соответствующая сис­тема сигнализации IР-телефонии.</p> <p>В третьей версии рекомендаций Н.323 появилось приложение G к Н.225. В нем описан метод взаимодействия административных доменов с помощью объекта, называемого «погра­ничным элементом» (Border Element). Этот функциональный элемент поддерживает открытый доступ к административному домену для доведения вызова до входящего в этот домен узла или предоставления других услуг, требующих установления мультимедиасвязи с его узлами.</p> <p>Взаимодействие между пограничными элементами осуществляется посредством про­<i>токола</i>, который определен в приложении G. Он может быть использован с целью обмена планами нумерации и тарификационной информацией, сведениями для авторизации и мар­шрутизации вызовов, отчетами об использовании сетевых ресурсов.</p> <p></p> <p>Подобные функции межсетевого взаимодействия реализованы и в проекте TIPHON. На рис. 4.10 показан пример передачи сигнальной информации между терминалом и шлю­зом, расположенными в различных административных доменах.</p> <p><img src="//images/stories/knigi/ip-phone/image066.jpg" width="526" height="139" class=""/></p> <p>Рис. 4.10. Пример взаимодействия двух доменов</p> <table cellspacing=0 cellpadding=0 hspace=0 vspace=0 height=371> <tr> <td> <p><img src="//images/stories/knigi/ip-phone/image068.jpg" width="502" height="371" class=""/></p> </td> </tr> </table> <br/> <table cellspacing=0 cellpadding=0 hspace=0 vspace=0 height=14> <tr> <td> <p>Рис. 4.11. Пример взаимодействия трех доменов</p> </td> </tr> </table> <br/> <p>В сценарии, показанном на рис. 4.11, ресурсы зоны Н.323 (терминал, шлюз и <a href="/">сервер</a> авторизации), требуемые для реализации вызова IP-телефонии, разделены между тремя ад­министративными доменами. В рассматриваемом случае два домена (первый и второй) не имеют установленных сигнальных отношений, но каждый должен иметь сигнальные отно­шения с третьим доменом, в котором расположен центр авторизации. На рис. 4.11 показаны следующие потоки информации:</p>

<p>При внедрении систем IP-телефонии часто необходимо решать задачу обеспечения эффективного взаимодействия сетей различных операторов. Здесь существует масса про­блем, связанных с преобразованием адресов между административными доменами, взаимо­расчетами между операторами, <i>контролем</i> доступа к ресурсам сети, <strong>защитой</strong> внутренней то­пологии и т. д. Успешное решение данных задач должна обеспечивать соответствующая сис­тема сигнализации IР-телефонии.</p> <p>В третьей версии рекомендаций Н.323 появилось приложение G к Н.225. В нем описан метод взаимодействия административных доменов с помощью объекта, называемого «погра­ничным элементом» (Border Element). Этот функциональный элемент поддерживает открытый доступ к административному домену для доведения вызова до входящего в этот домен узла или предоставления других услуг, требующих установления мультимедиасвязи с его узлами.</p> <p>Взаимодействие между пограничными элементами осуществляется посредством про­<i>токола</i>, который определен в приложении G. Он может быть использован с целью обмена планами нумерации и тарификационной информацией, сведениями для авторизации и мар­шрутизации вызовов, отчетами об использовании сетевых ресурсов.</p> <p></p> <p>Подобные функции межсетевого взаимодействия реализованы и в проекте TIPHON. На рис. 4.10 показан пример передачи сигнальной информации между терминалом и шлю­зом, расположенными в различных административных доменах.</p> <p><img src="//images/stories/knigi/ip-phone/image066.jpg" width="526" height="139" class=""/></p> <p>Рис. 4.10. Пример взаимодействия двух доменов</p> <table cellspacing=0 cellpadding=0 hspace=0 vspace=0 height=371> <tr> <td> <p><img src="//images/stories/knigi/ip-phone/image068.jpg" width="502" height="371" class=""/></p> </td> </tr> </table> <br/> <table cellspacing=0 cellpadding=0 hspace=0 vspace=0 height=14> <tr> <td> <p>Рис. 4.11. Пример взаимодействия трех доменов</p> </td> </tr> </table> <br/> <p>В сценарии, показанном на рис. 4.11, ресурсы зоны Н.323 (терминал, шлюз и <a href="/">сервер</a> авторизации), требуемые для реализации вызова IP-телефонии, разделены между тремя ад­министративными доменами. В рассматриваемом случае два домена (первый и второй) не имеют установленных сигнальных отношений, но каждый должен иметь сигнальные отно­шения с третьим доменом, в котором расположен центр авторизации. На рис. 4.11 показаны следующие потоки информации:</p> 2011-10-15T21:24:00+04:00 2011-10-15T21:24:00+04:00 /books/ip-telephony/71-ip6/1038-4-5-osobennosti-signalizacii-po-koncepcii-tiphon-chast-4

<p>Протоколы MGCP и Megaco очень похожи друг на друга, и для многих приложений не имеет значения, какой из них будет использоваться. Однако Megaco лучше интегрирован с приложениями с поддержкой нескольких сред передачи, чем MGCP, потому что в базовый протокол включены семантические элементы для конференций. Благодаря этому MGCP мо­жет быть лучшей основой для приложений, не привязанных к какой-либо среде, например для управления сеансами на базе MPLS.</p> <p>Следует отметить, что вопрос о принятии Megaco в качестве международного стан­дарта для приложений с различными средами передачи данных является пока открытым, хо­тя некоторые производители приступили к внедрению данного протокола в свои продукты. Подтверждением этого является то, что в конце августа 2000 г. в лаборатории функциональ­ной совместимости университета Нью-Гемпшира проводилось тестирование уже более деся­ти независимых разработок, использующих протокол Megaco [70].</p> <p></p>

<p>Протоколы MGCP и Megaco очень похожи друг на друга, и для многих приложений не имеет значения, какой из них будет использоваться. Однако Megaco лучше интегрирован с приложениями с поддержкой нескольких сред передачи, чем MGCP, потому что в базовый протокол включены семантические элементы для конференций. Благодаря этому MGCP мо­жет быть лучшей основой для приложений, не привязанных к какой-либо среде, например для управления сеансами на базе MPLS.</p> <p>Следует отметить, что вопрос о принятии Megaco в качестве международного стан­дарта для приложений с различными средами передачи данных является пока открытым, хо­тя некоторые производители приступили к внедрению данного протокола в свои продукты. Подтверждением этого является то, что в конце августа 2000 г. в лаборатории функциональ­ной совместимости университета Нью-Гемпшира проводилось тестирование уже более деся­ти независимых разработок, использующих протокол Megaco [70].</p> <p></p> 2011-10-05T16:10:00+04:00 2011-10-05T16:10:00+04:00 /books/ip-telephony/71-ip6/1037-4-5-osobennosti-signalizacii-po-koncepcii-tiphon-chast-3

</td> </tr> </table> <br/> <p> <table cellpadding=0 cellspacing=0 width="100%"> <tr> <td> <p>Рис. 4.9. Использование протокола Megaco в сети IP-телефонии</p> </td> </tr> </table> <table cellpadding=0 cellspacing=0> <tr> </tr> <tr> <td><img src="//images/stories/knigi/ip-phone/image064.gif" width="472" height="207" class=""/></td> </tr> </table> <br/> Дальнейшим развитием протокола MGCP является протокол управления вызовами Megaco (Media Gateway Control), известный также как стандарт ITU Н.248, который опреде­ляет взаимодействие, с одной стороны, шлюза между разными средами передачи данных (Media Gateway, MG) и, с другой, - <i>контроллера</i> шлюзов между средами передачи данных (Media Gateway Controller, MGC) (рис. 4.9). Иными словами, Megaco разработан для внутри-доменного удаленного управления устройствами, отвечающими за установление соединения! или проведение сеанса связи, включая шлюзы VoIP, серверы удаленного доступа, мультиплексоры цифровых абонентских линий (Digital Subscriber Line Access Multiplexer, DSLAM), маршрутизаторы с поддержкой многопротокольной коммутации с использованием меток (Multiprotocol Label Switching, MPLS), оптические кросс-коннекторы, модули агреги - рования сеансов РРР и другие.</p> <p>Ным протоколом реального времени (Real-Time Transport Protocol, RTP). По существу, Megaco повторяет MGCP в отношении архитектуры и взаимодействия контроллера со шлюзом, но при этом Megaco поддерживает более широкий диапазон <em>сетевых</em> технологий, в том числе ATM.</p> <p>Типичным примером работы протокола MGCP является проверка состояния конечной точки на предмет снятия трубки (которую поднимает абонент, чтобы сделать звонок). После фиксации события «снятие трубки» шлюз сообщает об этом контроллеру, после чего послед­ний может послать шлюзу команду подать в линию непрерывный гудок и ждать тональных сигналов DTMF набираемого номера абонента. После получения номера контроллер решает, по какому маршруту следует направить вызов, и, используя протокол сигнализации между контроллерами, в том числе Н.323, SIP или Q. BICC, взаимодействует с оконечным контрол­лером. Оконечный <b>контроллер</b> дает соответствующему шлюзу указание подать звонок на вызываемую линию. Когда этот шлюз определяет, что вызываемый абонент снял трубку, оба контроллера дают соответствующим шлюзам команды на установление двухсторонней голо­совой связи по сети передачи данных. Таким способом данные протоколы распознают со­стояния конечных точек, уведомляют об этих состояниях контроллер, генерируют в линии сигналы (например, непрерывный гудок), а также формируют потоки данных между под­ключенными к шлюзу конечными точками и сетью передачи данных, например потоки RTP.</p>

</td> </tr> </table> <br/> <p> <table cellpadding=0 cellspacing=0 width="100%"> <tr> <td> <p>Рис. 4.9. Использование протокола Megaco в сети IP-телефонии</p> </td> </tr> </table> <table cellpadding=0 cellspacing=0> <tr> </tr> <tr> <td><img src="//images/stories/knigi/ip-phone/image064.gif" width="472" height="207" class=""/></td> </tr> </table> <br/> Дальнейшим развитием протокола MGCP является протокол управления вызовами Megaco (Media Gateway Control), известный также как стандарт ITU Н.248, который опреде­ляет взаимодействие, с одной стороны, шлюза между разными средами передачи данных (Media Gateway, MG) и, с другой, - <i>контроллера</i> шлюзов между средами передачи данных (Media Gateway Controller, MGC) (рис. 4.9). Иными словами, Megaco разработан для внутри-доменного удаленного управления устройствами, отвечающими за установление соединения! или проведение сеанса связи, включая шлюзы VoIP, серверы удаленного доступа, мультиплексоры цифровых абонентских линий (Digital Subscriber Line Access Multiplexer, DSLAM), маршрутизаторы с поддержкой многопротокольной коммутации с использованием меток (Multiprotocol Label Switching, MPLS), оптические кросс-коннекторы, модули агреги - рования сеансов РРР и другие.</p> <p>Ным протоколом реального времени (Real-Time Transport Protocol, RTP). По существу, Megaco повторяет MGCP в отношении архитектуры и взаимодействия контроллера со шлюзом, но при этом Megaco поддерживает более широкий диапазон <em>сетевых</em> технологий, в том числе ATM.</p> <p>Типичным примером работы протокола MGCP является проверка состояния конечной точки на предмет снятия трубки (которую поднимает абонент, чтобы сделать звонок). После фиксации события «снятие трубки» шлюз сообщает об этом контроллеру, после чего послед­ний может послать шлюзу команду подать в линию непрерывный гудок и ждать тональных сигналов DTMF набираемого номера абонента. После получения номера контроллер решает, по какому маршруту следует направить вызов, и, используя протокол сигнализации между контроллерами, в том числе Н.323, SIP или Q. BICC, взаимодействует с оконечным контрол­лером. Оконечный <b>контроллер</b> дает соответствующему шлюзу указание подать звонок на вызываемую линию. Когда этот шлюз определяет, что вызываемый абонент снял трубку, оба контроллера дают соответствующим шлюзам команды на установление двухсторонней голо­совой связи по сети передачи данных. Таким способом данные протоколы распознают со­стояния конечных точек, уведомляют об этих состояниях контроллер, генерируют в линии сигналы (например, непрерывный гудок), а также формируют потоки данных между под­ключенными к шлюзу конечными точками и сетью передачи данных, например потоки RTP.</p> 2011-09-26T22:06:00+04:00 2011-09-26T22:06:00+04:00 /books/ip-telephony/71-ip6/1036-4-5-osobennosti-signalizacii-po-koncepcii-tiphon-chast-2

<p>MGC анализирует информацию сигнализации и передает управляющую информацию в транспортный шлюз посредством специального протокола управления, в задачи которого входит обеспечение управления различными ресурсами (системой интерактивного речевого отклика, мостами конференцсвязи и т. д.), приемом и формированием сигналов DTMF, фор -</p> <br/> <p>Мированием тональных сигналов (готовности к набору номера, <strong>контроля</strong> посылки вызова, «занято» и пр.), эхо-подавлением, использованием кодеков (G.711, G.723.I, G.729, GSM и т. д.), сбором статистики, тестированием конечных точек (например, испытания по шлейфу), резервированием, разъединением и блокировкой конечных точек, шифрованием.</p> <p>Протокол управления транспортными шлюзами MGCP представляет собой достаточно простой протокол клиент-<a href="/">сервер</a>. Логика управления вызовами выполняется агентом (Call Agent), находящимся вне транспортного шлюза. Сам же транспортный шлюз представляется в виде объекта, состоящего из конечных точек - точек входа/выхода информационных пото­ков и соединений - двух или более соединенных конечных точек. Модель определяет физи­ческие конечные точки (например, окончания соединительных линий) и виртуальные конеч­ные точки (например, аудиоисточники). Сам протокол MGCP использует принцип «веду­щий/ведомый», согласно которому агент управления вызовами передает транспортному шлюзу команды для управления конечными точками и соединениями, а также инициации определенных <em>действий</em>.</p> <p>MGCP является достаточно универсальным протоколом, способным обеспечить рас­пределенное управление различными типами транспортных шлюзов, в частности телефонны­ми шлюзами и серверами доступа. Он может использоваться для установления соединения и выполнения разных функций обслуживания, например тестирования шлейфа.</p> <table cellspacing=0 cellpadding=0 hspace=0 vspace=0 width=530 height=46> <tr> <td> <p>MGCP и Megaco - эти сравнительно низкоуровневые протоколы управления устройст­вами, которые сообщают шлюзу, каким образом связать потоки, поступающие в <b>сеть</b> с комму­тацией пакетов или ячеек, с потоками пакетов или ячеек, переносимыми, например, транспорт -</p>

<p>MGC анализирует информацию сигнализации и передает управляющую информацию в транспортный шлюз посредством специального протокола управления, в задачи которого входит обеспечение управления различными ресурсами (системой интерактивного речевого отклика, мостами конференцсвязи и т. д.), приемом и формированием сигналов DTMF, фор -</p> <br/> <p>Мированием тональных сигналов (готовности к набору номера, <strong>контроля</strong> посылки вызова, «занято» и пр.), эхо-подавлением, использованием кодеков (G.711, G.723.I, G.729, GSM и т. д.), сбором статистики, тестированием конечных точек (например, испытания по шлейфу), резервированием, разъединением и блокировкой конечных точек, шифрованием.</p> <p>Протокол управления транспортными шлюзами MGCP представляет собой достаточно простой протокол клиент-<a href="/">сервер</a>. Логика управления вызовами выполняется агентом (Call Agent), находящимся вне транспортного шлюза. Сам же транспортный шлюз представляется в виде объекта, состоящего из конечных точек - точек входа/выхода информационных пото­ков и соединений - двух или более соединенных конечных точек. Модель определяет физи­ческие конечные точки (например, окончания соединительных линий) и виртуальные конеч­ные точки (например, аудиоисточники). Сам протокол MGCP использует принцип «веду­щий/ведомый», согласно которому агент управления вызовами передает транспортному шлюзу команды для управления конечными точками и соединениями, а также инициации определенных <em>действий</em>.</p> <p>MGCP является достаточно универсальным протоколом, способным обеспечить рас­пределенное управление различными типами транспортных шлюзов, в частности телефонны­ми шлюзами и серверами доступа. Он может использоваться для установления соединения и выполнения разных функций обслуживания, например тестирования шлейфа.</p> <table cellspacing=0 cellpadding=0 hspace=0 vspace=0 width=530 height=46> <tr> <td> <p>MGCP и Megaco - эти сравнительно низкоуровневые протоколы управления устройст­вами, которые сообщают шлюзу, каким образом связать потоки, поступающие в <b>сеть</b> с комму­тацией пакетов или ячеек, с потоками пакетов или ячеек, переносимыми, например, транспорт -</p> 2011-08-21T06:16:00+04:00 2011-08-21T06:16:00+04:00 /books/ip-telephony/71-ip6/1035-4-5-osobennosti-signalizacii-po-koncepcii-tiphon-chast-1

<p>Базируясь на стандарте Н.323 для IP-сети, спецификация TIPHON дополняет его некоторыми обязательными процедурами, а также механизмами взаимодействия с сетями коммутации каналов. Функциональная модель TIPHON состоит из тех же компонентов - gatekeeper, шлюза и терминала, - что и модель Н.323, однако в ней предусмотрено разделе­ние шлюза на три функциональных объекта. Это шлюз сигнализации (SG - Signalling Gate­</p> <p>СИГНАЛИЗАЦИЯ В СЕТЯХ IP-ТЕЛЕФОНИИ</p> <table cellpadding=0 cellspacing=0 width="100%"> <tr> <td> <p>Way), транспортный шлюз (MG - Media Gateway) и контроллер транспортного шлюза (MGC - Media Gateway Controller) (рис. 4.8).</p> </td> </tr> </table> <img src="//images/stories/knigi/ip-phone/image062.gif" width="531" height="290" class=""/><br/> Рис. 4.8. Функциональная модель сети по проекту TIPHON</p> <p>Шлюз сигнализации служит промежуточным звеном сигнализации между <b>сетями</b> с па­кетной и канальной коммутацией. В задачи транспортного шлюза входит преобразование и/или перекодирование передаваемой информации; он обеспечивает терминирование ИКМ­трафика телефонных сетей и пакетного трафика, транслирует адреса, подавляет эхо, воспро­изводит различные сообщения для абонентов, принимает и передает цифры кодом DTMF и т. д. Контроллер сигнализации MGC выполняет процедуры сигнализации Н.323, которые оп­ределены в рекомендациях Н.323, Н.225 (RAS и Q.931) и Н.245, и преобразует сообщения сигнализации телефонных <strong>сетей</strong> в сообщения сигнализации Н.323. Основная его задача - управлять работой транспортного шлюза, т. е. осуществлять <em>контроль</em> за соединениями, ис­пользованием ресурсов, трансляцией протоколов и т. п. Следует отметить, что MGC не обес­печивает управление вызовами. Это задачи gatekeeper, который выполняет их в соответствии с рекомендациями Н.323.</p> <p>При использовании сигнализации ОКС №7 в контроллер MGC по IP-сети будут пе­редаваться сообщения ISUP (подсистемы обслуживания вызовов сети ISDN). Если же приме­няется сигнализация по выделенному каналу (CAS), сигнальные сообщения сначала вместе с информацией абонента поступят в транспортный шлюз, а затем уже будут выделены в кон­троллер MGC. При этом предполагается использовать протокол MDTP (Multi-Network Data­gram Transmission Protocol), который служит для инкапсуляции телефонных протоколов сиг­нализации (ISUP, CAS, PRI) и передачи переносимой ими информации в контроллер транс­портного шлюза.</p>

<p>Базируясь на стандарте Н.323 для IP-сети, спецификация TIPHON дополняет его некоторыми обязательными процедурами, а также механизмами взаимодействия с сетями коммутации каналов. Функциональная модель TIPHON состоит из тех же компонентов - gatekeeper, шлюза и терминала, - что и модель Н.323, однако в ней предусмотрено разделе­ние шлюза на три функциональных объекта. Это шлюз сигнализации (SG - Signalling Gate­</p> <p>СИГНАЛИЗАЦИЯ В СЕТЯХ IP-ТЕЛЕФОНИИ</p> <table cellpadding=0 cellspacing=0 width="100%"> <tr> <td> <p>Way), транспортный шлюз (MG - Media Gateway) и контроллер транспортного шлюза (MGC - Media Gateway Controller) (рис. 4.8).</p> </td> </tr> </table> <img src="//images/stories/knigi/ip-phone/image062.gif" width="531" height="290" class=""/><br/> Рис. 4.8. Функциональная модель сети по проекту TIPHON</p> <p>Шлюз сигнализации служит промежуточным звеном сигнализации между <b>сетями</b> с па­кетной и канальной коммутацией. В задачи транспортного шлюза входит преобразование и/или перекодирование передаваемой информации; он обеспечивает терминирование ИКМ­трафика телефонных сетей и пакетного трафика, транслирует адреса, подавляет эхо, воспро­изводит различные сообщения для абонентов, принимает и передает цифры кодом DTMF и т. д. Контроллер сигнализации MGC выполняет процедуры сигнализации Н.323, которые оп­ределены в рекомендациях Н.323, Н.225 (RAS и Q.931) и Н.245, и преобразует сообщения сигнализации телефонных <strong>сетей</strong> в сообщения сигнализации Н.323. Основная его задача - управлять работой транспортного шлюза, т. е. осуществлять <em>контроль</em> за соединениями, ис­пользованием ресурсов, трансляцией протоколов и т. п. Следует отметить, что MGC не обес­печивает управление вызовами. Это задачи gatekeeper, который выполняет их в соответствии с рекомендациями Н.323.</p> <p>При использовании сигнализации ОКС №7 в контроллер MGC по IP-сети будут пе­редаваться сообщения ISUP (подсистемы обслуживания вызовов сети ISDN). Если же приме­няется сигнализация по выделенному каналу (CAS), сигнальные сообщения сначала вместе с информацией абонента поступят в транспортный шлюз, а затем уже будут выделены в кон­троллер MGC. При этом предполагается использовать протокол MDTP (Multi-Network Data­gram Transmission Protocol), который служит для инкапсуляции телефонных протоколов сиг­нализации (ISUP, CAS, PRI) и передачи переносимой ими информации в контроллер транс­портного шлюза.</p> 2011-07-28T03:26:00+04:00 2011-07-28T03:26:00+04:00 /books/ip-telephony/71-ip6/1034-4-4-sravnenie-protokolov-n-323-i-sip-chast-2

<p>Систему объектов Н.323 можно рассматривать как прикладную сеть, наложенную на <br/> <em>сеть</em> передачи данных (IP-сеть), в то время как службы SIP ориентированы на интеграцию со <br/> службами Интернет. Какой из вариантов более предпочтителен, зависит от требуемых функ-<br/> циональных возможностей и целей бизнеса.</p> <p>Технология Н.323 предоставляет больше возможностей по управлению конкретной услугой в части аутентификации и учета и <em>контроля</em> за использованием сетевых ресурсов. Возможности протокола SIP здесь значительно меньшие. Выбор этого протокола компанией-поставщиком услуг фактически означает, что технологическая интеграция услуг для нее важнее возможностей гибкой тарификации и контроля за использованием сетевых ресурсов.</p> <p>В целом можно сделать вывод, что протокол SIP ориентирован на Интернет-провай­деров, которые рассматривают услугу Интернет-телефонии лишь как небольшую часть сво­его сервисного пакета. Будучи самодостаточной, технология Н.323 больше подходит для корпоративных сетей (интранет) и поставщиков услуг IP-телефонии, для которых данные услуги не являются доминирующими. В целом Н.323 и SIP не следует рассматривать как конкурирующие технологии, они являются различными подходами, предназначенными для разных сегментов рынка. Они могут работать параллельно и даже взаимодействовать через специальный пограничный шлюз.</p> <p></p>

<p>Систему объектов Н.323 можно рассматривать как прикладную сеть, наложенную на <br/> <em>сеть</em> передачи данных (IP-сеть), в то время как службы SIP ориентированы на интеграцию со <br/> службами Интернет. Какой из вариантов более предпочтителен, зависит от требуемых функ-<br/> циональных возможностей и целей бизнеса.</p> <p>Технология Н.323 предоставляет больше возможностей по управлению конкретной услугой в части аутентификации и учета и <em>контроля</em> за использованием сетевых ресурсов. Возможности протокола SIP здесь значительно меньшие. Выбор этого протокола компанией-поставщиком услуг фактически означает, что технологическая интеграция услуг для нее важнее возможностей гибкой тарификации и контроля за использованием сетевых ресурсов.</p> <p>В целом можно сделать вывод, что протокол SIP ориентирован на Интернет-провай­деров, которые рассматривают услугу Интернет-телефонии лишь как небольшую часть сво­его сервисного пакета. Будучи самодостаточной, технология Н.323 больше подходит для корпоративных сетей (интранет) и поставщиков услуг IP-телефонии, для которых данные услуги не являются доминирующими. В целом Н.323 и SIP не следует рассматривать как конкурирующие технологии, они являются различными подходами, предназначенными для разных сегментов рынка. Они могут работать параллельно и даже взаимодействовать через специальный пограничный шлюз.</p> <p></p> 2011-07-12T07:13:00+04:00 2011-07-12T07:13:00+04:00 /books/ip-telephony/71-ip6/1033-4-4-sravnenie-protokolov-n-323-i-sip-chast-1

<p>Протоколы Н.323 и SIP представляют существенно различные подходы к решению одних и тех же задач: если Н.323 близок к традиционным системам сигнализации (с комму­тацией каналов на основе протокола Q.931 или более ранних рекомендаций серии Н), то SIP реализует более простой, интернетовский подход на основе HTTP.</p> <br/> <p>Следует отметить, что стандарт Н.323 не решает проблемы, связанные с <i>защитой</i> вы­зова от несанкционированного доступа, взаимодействием между шлюзами и gatekeeper раз­ных сетей, между телефонами и персональными компьютерами, роумингом и интеграцией с телефонной сигнализацией ОКС №7. Протокол Н.323 может лишь гарантировать взаимодей­ствие типа шлюз-шлюз и телефон-телефон, поскольку ориентирован на транспортные серви-сы в середине сети и не способен что-либо улучшить на уровне конечных узлов. Он не пре­дусматривает каких-либо средств, облегчающих разработку новых приложений. Алгоритмы Н.323 не оптимизированы для реальных сетей, они сложны в реализации и требуют больших ресурсов на клиентской стороне. Тем не менее, рекомендация неплохо подходит для попу­лярных сегодня магистральных приложений IP-телефонии в виде Интернет-телефонии, обес­печивающих существенное снижение расходов на междугородную и международную связь.</p> <p>По сравнению с Н.323 протокол SIP базируется на текстовом формате, более прост для реализации и добавления новых функций. Простота SIP не означает скудность его функцио-нальных возможностей. Протокол обеспечивает реализацию важных для систем Интернет-телефонии функций, включая шифрование и аутентификация. То, что SIP базируется на ар-хитектуре клиент-<a href="/">сервер</a>, позволяет обеспечить управление вызовами на уровне сервера (по­добное невозможно в одноранговых <strong>схемах</strong> обслуживания вызовов, используемых большин-ством конечных точек Н.323). В настоящее время предложены спецификации, которые рас-ширяют протокол SIP средствами управления безопасностью вызова, запроса качества об-служивания, сигнализации изменения состояния <em>сети</em>.</p>

<p>Протоколы Н.323 и SIP представляют существенно различные подходы к решению одних и тех же задач: если Н.323 близок к традиционным системам сигнализации (с комму­тацией каналов на основе протокола Q.931 или более ранних рекомендаций серии Н), то SIP реализует более простой, интернетовский подход на основе HTTP.</p> <br/> <p>Следует отметить, что стандарт Н.323 не решает проблемы, связанные с <i>защитой</i> вы­зова от несанкционированного доступа, взаимодействием между шлюзами и gatekeeper раз­ных сетей, между телефонами и персональными компьютерами, роумингом и интеграцией с телефонной сигнализацией ОКС №7. Протокол Н.323 может лишь гарантировать взаимодей­ствие типа шлюз-шлюз и телефон-телефон, поскольку ориентирован на транспортные серви-сы в середине сети и не способен что-либо улучшить на уровне конечных узлов. Он не пре­дусматривает каких-либо средств, облегчающих разработку новых приложений. Алгоритмы Н.323 не оптимизированы для реальных сетей, они сложны в реализации и требуют больших ресурсов на клиентской стороне. Тем не менее, рекомендация неплохо подходит для попу­лярных сегодня магистральных приложений IP-телефонии в виде Интернет-телефонии, обес­печивающих существенное снижение расходов на междугородную и международную связь.</p> <p>По сравнению с Н.323 протокол SIP базируется на текстовом формате, более прост для реализации и добавления новых функций. Простота SIP не означает скудность его функцио-нальных возможностей. Протокол обеспечивает реализацию важных для систем Интернет-телефонии функций, включая шифрование и аутентификация. То, что SIP базируется на ар-хитектуре клиент-<a href="/">сервер</a>, позволяет обеспечить управление вызовами на уровне сервера (по­добное невозможно в одноранговых <strong>схемах</strong> обслуживания вызовов, используемых большин-ством конечных точек Н.323). В настоящее время предложены спецификации, которые рас-ширяют протокол SIP средствами управления безопасностью вызова, запроса качества об-служивания, сигнализации изменения состояния <em>сети</em>.</p> 2011-06-17T10:51:00+04:00 2011-06-17T10:51:00+04:00 /books/ip-telephony/71-ip6/1032-4-3-signalizaciya-na-osnove-protokola-sip-chast-3

<p>В работах над протоколом SIP участвуют ведущие производители <b>сетевого</b> и телеком­муникационного оборудования (Cisco Systems, Lucent Technologies, 3Com) и крупнейшие операторы (AT&amp;T, MCI, Level 3). О своих планах по его поддержке заявили и многие компа­нии, в частности, CableLabs, Telcordia, General Instrument, Com21.</p> <p>Примером реализации протокола SIP может служить программная платформа еСоп-vergence Server Solutions фирмы Dynamicsoft, включающая следующие продукты:</p> <p>• SIP Proxy Server - маршрутизатор между конечными точками, каждая из которых оп­ределена как UAC или UAS; в дополнение к функциям обеспечения взаимодействия между различными серверами платформы он предоставляет услуги перенаправления и регистрации/определения местоположения пользователей;</p> <p>• SIP Location Server - обеспечивает безопасную сигнализацию вызовов, хранит инфор­мацию о пользователях, необходимую сервис-провайдерам для гибкого управления доступом пользователей и маршрутизации вызовов с целью предоставления наилуч­шего качества услуги;</p> <p>• SIP User Agent - управляет соединениями между исходящей и входящей сторонами, обеспечивая поддержку необходимого качества услуг;</p> <p>• SIP CallAccounting Server - выполняет функции сбора и обработки информации в виде детальных отчетов о транзакциях TDR, получаемых от SIP Proxy Server, которая в дальнейшем может быть использована в системах биллинга и менеджмента пользова­телей.</p> <br/> <p> <table cellpadding=0 cellspacing=0 width="100%"> <tr> <td> <p>PAGE 43</p> </td> </tr> </table> <table cellpadding=0 cellspacing=0> <tr> </tr> <tr> <td><img src="//images/stories/knigi/ip-phone/image057.gif" alt="подпись: 43" width="18" height="19" class=""/></td> </tr> </table> <br/> СИГНАЛИЗАЦИЯ В <strong>СЕТЯХ</strong> IP-ТЕЛЕФОНИИ</p> <br/> <p><img src="//images/stories/knigi/ip-phone/image059.jpg" width="534" height="586" class=""/></p> <p>Рис. 4.7. Возможный сценарий установления и завершения сеанса связи</p> <p>По протоколу SIP</p> <p></p>

<p>В работах над протоколом SIP участвуют ведущие производители <b>сетевого</b> и телеком­муникационного оборудования (Cisco Systems, Lucent Technologies, 3Com) и крупнейшие операторы (AT&amp;T, MCI, Level 3). О своих планах по его поддержке заявили и многие компа­нии, в частности, CableLabs, Telcordia, General Instrument, Com21.</p> <p>Примером реализации протокола SIP может служить программная платформа еСоп-vergence Server Solutions фирмы Dynamicsoft, включающая следующие продукты:</p> <p>• SIP Proxy Server - маршрутизатор между конечными точками, каждая из которых оп­ределена как UAC или UAS; в дополнение к функциям обеспечения взаимодействия между различными серверами платформы он предоставляет услуги перенаправления и регистрации/определения местоположения пользователей;</p> <p>• SIP Location Server - обеспечивает безопасную сигнализацию вызовов, хранит инфор­мацию о пользователях, необходимую сервис-провайдерам для гибкого управления доступом пользователей и маршрутизации вызовов с целью предоставления наилуч­шего качества услуги;</p> <p>• SIP User Agent - управляет соединениями между исходящей и входящей сторонами, обеспечивая поддержку необходимого качества услуг;</p> <p>• SIP CallAccounting Server - выполняет функции сбора и обработки информации в виде детальных отчетов о транзакциях TDR, получаемых от SIP Proxy Server, которая в дальнейшем может быть использована в системах биллинга и менеджмента пользова­телей.</p> <br/> <p> <table cellpadding=0 cellspacing=0 width="100%"> <tr> <td> <p>PAGE 43</p> </td> </tr> </table> <table cellpadding=0 cellspacing=0> <tr> </tr> <tr> <td><img src="//images/stories/knigi/ip-phone/image057.gif" alt="подпись: 43" width="18" height="19" class=""/></td> </tr> </table> <br/> СИГНАЛИЗАЦИЯ В <strong>СЕТЯХ</strong> IP-ТЕЛЕФОНИИ</p> <br/> <p><img src="//images/stories/knigi/ip-phone/image059.jpg" width="534" height="586" class=""/></p> <p>Рис. 4.7. Возможный сценарий установления и завершения сеанса связи</p> <p>По протоколу SIP</p> <p></p> 2011-06-13T13:43:00+04:00 2011-06-13T13:43:00+04:00 /books/ip-telephony/71-ip6/1031-4-3-signalizaciya-na-osnove-protokola-sip-chast-2

<p>• INVITE - приглашает пользователя принять участие в сеансе связи (служит для уста­новления нового соединения; может содержать параметры для согласования);</p> <p>• BYE - завершает соединение между двумя пользователями;</p> <p>• OPTIONS используется для передачи информации о поддерживаемых характеристи­ках (эта передача может осуществляться напрямую между двумя агентами пользовате­лей или через сервер SIP);</p> <br/> <p>• АСК - используется для подтверждения получения сообщения или для положительно­го ответа на команду INVITE;</p> <p>• CANCEL - прекращает поиск пользователя;</p> <p>• REGISTER - передает информацию о местоположении пользователя на сервер SIP, который может транслировать ее на <a href="/">сервер</a> адресов (Location Server).</p> <p>Оба протокола SAP и SIP используют механизм SDP (Session Description Protocol) для описания характеристик сеанса: время проведения, требуемые ресурсы и т. д. (Реко­мендация RFC 2327). SDP используется исключительно для текстового описания сеанса и не имеет ни транспортных механизмов, ни средств согласования требуемых для сеанса параметров. Эти функции должны выполнять протоколы, применяемые для передачи ин­формации SDP.</p> <p>Сообщения-ответы могут содержать шесть типов возможных результатов: запрос в процессе выполнения (1хх), успешный запрос (2хх), переадресация (Зхх), неправильный за­прос (4хх), отказ сервера (5хх) и глобальный отказ (6хх).</p> <p>Используемая в SIP адресация основана на унифицированном указателе ресурсов SIP URL, в котором может быть записано имя домена (user@domain) или IP-адрес (user@IPadress) пользователя. Цель использования подобного формата - интеграция SIP-услуг с существую­щими службами Интернет. Сервер имен доменов (DNS) преобразует доменные имена в IP-адреса конечной точки (рис. 4.7). Вся маршрутизация и передача мультимедийных потоков выполняется нижележащей IP-сетью. Таким образом, услуги SIP хорошо интегрируются в традиционную модель Web-коммуникаций с сервером DNS, обеспечивающим преобразование доменного имени в <b>сетевой</b> адрес.</p> <p>Предназначенный для инициации сеансов протокол SIP обеспечивает определение ад­реса пользователя и установление соединения с ним. Кроме этого, он служит основой для применения других протоколов, реализующих функции <strong>защиты</strong>, аутентификации, описания канала мультимедийной связи и т. д. Для биллинга, например, может использоваться прото­кол Radius.</p>

<p>• INVITE - приглашает пользователя принять участие в сеансе связи (служит для уста­новления нового соединения; может содержать параметры для согласования);</p> <p>• BYE - завершает соединение между двумя пользователями;</p> <p>• OPTIONS используется для передачи информации о поддерживаемых характеристи­ках (эта передача может осуществляться напрямую между двумя агентами пользовате­лей или через сервер SIP);</p> <br/> <p>• АСК - используется для подтверждения получения сообщения или для положительно­го ответа на команду INVITE;</p> <p>• CANCEL - прекращает поиск пользователя;</p> <p>• REGISTER - передает информацию о местоположении пользователя на сервер SIP, который может транслировать ее на <a href="/">сервер</a> адресов (Location Server).</p> <p>Оба протокола SAP и SIP используют механизм SDP (Session Description Protocol) для описания характеристик сеанса: время проведения, требуемые ресурсы и т. д. (Реко­мендация RFC 2327). SDP используется исключительно для текстового описания сеанса и не имеет ни транспортных механизмов, ни средств согласования требуемых для сеанса параметров. Эти функции должны выполнять протоколы, применяемые для передачи ин­формации SDP.</p> <p>Сообщения-ответы могут содержать шесть типов возможных результатов: запрос в процессе выполнения (1хх), успешный запрос (2хх), переадресация (Зхх), неправильный за­прос (4хх), отказ сервера (5хх) и глобальный отказ (6хх).</p> <p>Используемая в SIP адресация основана на унифицированном указателе ресурсов SIP URL, в котором может быть записано имя домена (user@domain) или IP-адрес (user@IPadress) пользователя. Цель использования подобного формата - интеграция SIP-услуг с существую­щими службами Интернет. Сервер имен доменов (DNS) преобразует доменные имена в IP-адреса конечной точки (рис. 4.7). Вся маршрутизация и передача мультимедийных потоков выполняется нижележащей IP-сетью. Таким образом, услуги SIP хорошо интегрируются в традиционную модель Web-коммуникаций с сервером DNS, обеспечивающим преобразование доменного имени в <b>сетевой</b> адрес.</p> <p>Предназначенный для инициации сеансов протокол SIP обеспечивает определение ад­реса пользователя и установление соединения с ним. Кроме этого, он служит основой для применения других протоколов, реализующих функции <strong>защиты</strong>, аутентификации, описания канала мультимедийной связи и т. д. Для биллинга, например, может использоваться прото­кол Radius.</p>