Мини-Сервер своими руками - это просто! - IP телефония

4.6. Межсетевое взаимодействие - Часть 2

Sun, 27 Nov 2011 21:09:00 +0400

S1: Обмен информацией разрешения запроса между терминалом и gatekeeper 1.

S2: Обмен информацией разрешения запроса между gatekeeper I и сервером авторизации.

S3: Обмен информацией разрешения запроса между gatekeeper 1 и шлюзом.

S4: Обмен информацией разрешения запроса между шлюзом и его gatekeeper.

S5: Обмен информацией разрешения запроса между gatekeeper 2 и сервер от третьего лица.

S6: Обмен информацией разрешения запроса между gatekeeper 1 и gatekeeper 2.

Следует особо отметить, что реализация передачи сигнальной информации между различными административными доменами в сети IP-телефонии требует обеспечения соответствующей степени защиты информации.

4.6. Межсетевое взаимодействие - Часть 1

Fri, 18 Nov 2011 20:49:00 +0400

При внедрении систем IP-телефонии часто необходимо решать задачу обеспечения эффективного взаимодействия сетей различных операторов. Здесь существует масса проблем, связанных с преобразованием адресов между административными доменами, взаиморасчетами между операторами, контролем доступа к ресурсам сети, защитой внутренней топологии и т. д. Успешное решение данных задач должна обеспечивать соответствующая система сигнализации IР-телефонии.

В третьей версии рекомендаций Н.323 появилось приложение G к Н.225. В нем описан метод взаимодействия административных доменов с помощью объекта, называемого «пограничным элементом» (Border Element). Этот функциональный элемент поддерживает открытый доступ к административному домену для доведения вызова до входящего в этот домен узла или предоставления других услуг, требующих установления мультимедиасвязи с его узлами.

Взаимодействие между пограничными элементами осуществляется посредством протокола, который определен в приложении G. Он может быть использован с целью обмена планами нумерации и тарификационной информацией, сведениями для авторизации и маршрутизации вызовов, отчетами об использовании сетевых ресурсов.

Подобные функции межсетевого взаимодействия реализованы и в проекте TIPHON. На рис. 4.10 показан пример передачи сигнальной информации между терминалом и шлюзом, расположенными в различных административных доменах.

Рис. 4.10. Пример взаимодействия двух доменов

Рис. 4.11. Пример взаимодействия трех доменов

В сценарии, показанном на рис. 4.11, ресурсы зоны Н.323 (терминал, шлюз и сервер авторизации), требуемые для реализации вызова IP-телефонии, разделены между тремя административными доменами. В рассматриваемом случае два домена (первый и второй) не имеют установленных сигнальных отношений, но каждый должен иметь сигнальные отношения с третьим доменом, в котором расположен центр авторизации. На рис. 4.11 показаны следующие потоки информации:

4.5. Особенности сигнализации по концепции TIPHON - Часть 4

Sat, 15 Oct 2011 21:24:00 +0400

Протоколы MGCP и Megaco очень похожи друг на друга, и для многих приложений не имеет значения, какой из них будет использоваться. Однако Megaco лучше интегрирован с приложениями с поддержкой нескольких сред передачи, чем MGCP, потому что в базовый протокол включены семантические элементы для конференций. Благодаря этому MGCP может быть лучшей основой для приложений, не привязанных к какой-либо среде, например для управления сеансами на базе MPLS.

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

4.5. Особенности сигнализации по концепции TIPHON - Часть 3

Wed, 05 Oct 2011 16:10:00 +0400

Рис. 4.9. Использование протокола Megaco в сети IP-телефонии

Дальнейшим развитием протокола MGCP является протокол управления вызовами Megaco (Media Gateway Control), известный также как стандарт ITU Н.248, который определяет взаимодействие, с одной стороны, шлюза между разными средами передачи данных (Media Gateway, MG) и, с другой, - контроллера шлюзов между средами передачи данных (Media Gateway Controller, MGC) (рис. 4.9). Иными словами, Megaco разработан для внутри-доменного удаленного управления устройствами, отвечающими за установление соединения! или проведение сеанса связи, включая шлюзы VoIP, серверы удаленного доступа, мультиплексоры цифровых абонентских линий (Digital Subscriber Line Access Multiplexer, DSLAM), маршрутизаторы с поддержкой многопротокольной коммутации с использованием меток (Multiprotocol Label Switching, MPLS), оптические кросс-коннекторы, модули агреги - рования сеансов РРР и другие.

Ным протоколом реального времени (Real-Time Transport Protocol, RTP). По существу, Megaco повторяет MGCP в отношении архитектуры и взаимодействия контроллера со шлюзом, но при этом Megaco поддерживает более широкий диапазон сетевых технологий, в том числе ATM.

Типичным примером работы протокола MGCP является проверка состояния конечной точки на предмет снятия трубки (которую поднимает абонент, чтобы сделать звонок). После фиксации события «снятие трубки» шлюз сообщает об этом контроллеру, после чего последний может послать шлюзу команду подать в линию непрерывный гудок и ждать тональных сигналов DTMF набираемого номера абонента. После получения номера контроллер решает, по какому маршруту следует направить вызов, и, используя протокол сигнализации между контроллерами, в том числе Н.323, SIP или Q. BICC, взаимодействует с оконечным контроллером. Оконечный контроллер дает соответствующему шлюзу указание подать звонок на вызываемую линию. Когда этот шлюз определяет, что вызываемый абонент снял трубку, оба контроллера дают соответствующим шлюзам команды на установление двухсторонней голосовой связи по сети передачи данных. Таким способом данные протоколы распознают состояния конечных точек, уведомляют об этих состояниях контроллер, генерируют в линии сигналы (например, непрерывный гудок), а также формируют потоки данных между подключенными к шлюзу конечными точками и сетью передачи данных, например потоки RTP.

4.5. Особенности сигнализации по концепции TIPHON - Часть 2

Mon, 26 Sep 2011 22:06:00 +0400

MGC анализирует информацию сигнализации и передает управляющую информацию в транспортный шлюз посредством специального протокола управления, в задачи которого входит обеспечение управления различными ресурсами (системой интерактивного речевого отклика, мостами конференцсвязи и т. д.), приемом и формированием сигналов DTMF, фор -

Мированием тональных сигналов (готовности к набору номера, контроля посылки вызова, «занято» и пр.), эхо-подавлением, использованием кодеков (G.711, G.723.I, G.729, GSM и т. д.), сбором статистики, тестированием конечных точек (например, испытания по шлейфу), резервированием, разъединением и блокировкой конечных точек, шифрованием.

Протокол управления транспортными шлюзами MGCP представляет собой достаточно простой протокол клиент-сервер. Логика управления вызовами выполняется агентом (Call Agent), находящимся вне транспортного шлюза. Сам же транспортный шлюз представляется в виде объекта, состоящего из конечных точек - точек входа/выхода информационных потоков и соединений - двух или более соединенных конечных точек. Модель определяет физические конечные точки (например, окончания соединительных линий) и виртуальные конечные точки (например, аудиоисточники). Сам протокол MGCP использует принцип «ведущий/ведомый», согласно которому агент управления вызовами передает транспортному шлюзу команды для управления конечными точками и соединениями, а также инициации определенных действий.

MGCP является достаточно универсальным протоколом, способным обеспечить распределенное управление различными типами транспортных шлюзов, в частности телефонными шлюзами и серверами доступа. Он может использоваться для установления соединения и выполнения разных функций обслуживания, например тестирования шлейфа.

MGCP и Megaco - эти сравнительно низкоуровневые протоколы управления устройствами, которые сообщают шлюзу, каким образом связать потоки, поступающие в сеть с коммутацией пакетов или ячеек, с потоками пакетов или ячеек, переносимыми, например, транспорт -

4.5. Особенности сигнализации по концепции TIPHON - Часть 1

Sun, 21 Aug 2011 06:16:00 +0400

Базируясь на стандарте Н.323 для IP-сети, спецификация TIPHON дополняет его некоторыми обязательными процедурами, а также механизмами взаимодействия с сетями коммутации каналов. Функциональная модель TIPHON состоит из тех же компонентов - gatekeeper, шлюза и терминала, - что и модель Н.323, однако в ней предусмотрено разделение шлюза на три функциональных объекта. Это шлюз сигнализации (SG - Signalling Gate

СИГНАЛИЗАЦИЯ В СЕТЯХ IP-ТЕЛЕФОНИИ

Way), транспортный шлюз (MG - Media Gateway) и контроллер транспортного шлюза (MGC - Media Gateway Controller) (рис. 4.8).

Рис. 4.8. Функциональная модель сети по проекту TIPHON

Шлюз сигнализации служит промежуточным звеном сигнализации между сетями с пакетной и канальной коммутацией. В задачи транспортного шлюза входит преобразование и/или перекодирование передаваемой информации; он обеспечивает терминирование ИКМтрафика телефонных сетей и пакетного трафика, транслирует адреса, подавляет эхо, воспроизводит различные сообщения для абонентов, принимает и передает цифры кодом DTMF и т. д. Контроллер сигнализации MGC выполняет процедуры сигнализации Н.323, которые определены в рекомендациях Н.323, Н.225 (RAS и Q.931) и Н.245, и преобразует сообщения сигнализации телефонных сетей в сообщения сигнализации Н.323. Основная его задача - управлять работой транспортного шлюза, т. е. осуществлять контроль за соединениями, использованием ресурсов, трансляцией протоколов и т. п. Следует отметить, что MGC не обеспечивает управление вызовами. Это задачи gatekeeper, который выполняет их в соответствии с рекомендациями Н.323.

При использовании сигнализации ОКС №7 в контроллер MGC по IP-сети будут передаваться сообщения ISUP (подсистемы обслуживания вызовов сети ISDN). Если же применяется сигнализация по выделенному каналу (CAS), сигнальные сообщения сначала вместе с информацией абонента поступят в транспортный шлюз, а затем уже будут выделены в контроллер MGC. При этом предполагается использовать протокол MDTP (Multi-Network Datagram Transmission Protocol), который служит для инкапсуляции телефонных протоколов сигнализации (ISUP, CAS, PRI) и передачи переносимой ими информации в контроллер транспортного шлюза.

4.4. Сравнение протоколов Н.323 и SIP - Часть 2

Thu, 28 Jul 2011 03:26:00 +0400

Систему объектов Н.323 можно рассматривать как прикладную сеть, наложенную на
сеть передачи данных (IP-сеть), в то время как службы SIP ориентированы на интеграцию со
службами Интернет. Какой из вариантов более предпочтителен, зависит от требуемых функ-
циональных возможностей и целей бизнеса.

Технология Н.323 предоставляет больше возможностей по управлению конкретной услугой в части аутентификации и учета и контроля за использованием сетевых ресурсов. Возможности протокола SIP здесь значительно меньшие. Выбор этого протокола компанией-поставщиком услуг фактически означает, что технологическая интеграция услуг для нее важнее возможностей гибкой тарификации и контроля за использованием сетевых ресурсов.

В целом можно сделать вывод, что протокол SIP ориентирован на Интернет-провайдеров, которые рассматривают услугу Интернет-телефонии лишь как небольшую часть своего сервисного пакета. Будучи самодостаточной, технология Н.323 больше подходит для корпоративных сетей (интранет) и поставщиков услуг IP-телефонии, для которых данные услуги не являются доминирующими. В целом Н.323 и SIP не следует рассматривать как конкурирующие технологии, они являются различными подходами, предназначенными для разных сегментов рынка. Они могут работать параллельно и даже взаимодействовать через специальный пограничный шлюз.

4.4. Сравнение протоколов Н.323 и SIP - Часть 1

Tue, 12 Jul 2011 07:13:00 +0400

Протоколы Н.323 и SIP представляют существенно различные подходы к решению одних и тех же задач: если Н.323 близок к традиционным системам сигнализации (с коммутацией каналов на основе протокола Q.931 или более ранних рекомендаций серии Н), то SIP реализует более простой, интернетовский подход на основе HTTP.

Следует отметить, что стандарт Н.323 не решает проблемы, связанные с защитой вызова от несанкционированного доступа, взаимодействием между шлюзами и gatekeeper разных сетей, между телефонами и персональными компьютерами, роумингом и интеграцией с телефонной сигнализацией ОКС №7. Протокол Н.323 может лишь гарантировать взаимодействие типа шлюз-шлюз и телефон-телефон, поскольку ориентирован на транспортные серви-сы в середине сети и не способен что-либо улучшить на уровне конечных узлов. Он не предусматривает каких-либо средств, облегчающих разработку новых приложений. Алгоритмы Н.323 не оптимизированы для реальных сетей, они сложны в реализации и требуют больших ресурсов на клиентской стороне. Тем не менее, рекомендация неплохо подходит для популярных сегодня магистральных приложений IP-телефонии в виде Интернет-телефонии, обеспечивающих существенное снижение расходов на междугородную и международную связь.

По сравнению с Н.323 протокол SIP базируется на текстовом формате, более прост для реализации и добавления новых функций. Простота SIP не означает скудность его функцио-нальных возможностей. Протокол обеспечивает реализацию важных для систем Интернет-телефонии функций, включая шифрование и аутентификация. То, что SIP базируется на ар-хитектуре клиент-сервер, позволяет обеспечить управление вызовами на уровне сервера (подобное невозможно в одноранговых схемах обслуживания вызовов, используемых большин-ством конечных точек Н.323). В настоящее время предложены спецификации, которые рас-ширяют протокол SIP средствами управления безопасностью вызова, запроса качества об-служивания, сигнализации изменения состояния сети.

4.3. Сигнализация на основе протокола SIP - Часть 3

Fri, 17 Jun 2011 10:51:00 +0400

В работах над протоколом SIP участвуют ведущие производители сетевого и телекоммуникационного оборудования (Cisco Systems, Lucent Technologies, 3Com) и крупнейшие операторы (AT&T, MCI, Level 3). О своих планах по его поддержке заявили и многие компании, в частности, CableLabs, Telcordia, General Instrument, Com21.

Примером реализации протокола SIP может служить программная платформа еСоп-vergence Server Solutions фирмы Dynamicsoft, включающая следующие продукты:

• SIP Proxy Server - маршрутизатор между конечными точками, каждая из которых определена как UAC или UAS; в дополнение к функциям обеспечения взаимодействия между различными серверами платформы он предоставляет услуги перенаправления и регистрации/определения местоположения пользователей;

• SIP Location Server - обеспечивает безопасную сигнализацию вызовов, хранит информацию о пользователях, необходимую сервис-провайдерам для гибкого управления доступом пользователей и маршрутизации вызовов с целью предоставления наилучшего качества услуги;

• SIP User Agent - управляет соединениями между исходящей и входящей сторонами, обеспечивая поддержку необходимого качества услуг;

• SIP CallAccounting Server - выполняет функции сбора и обработки информации в виде детальных отчетов о транзакциях TDR, получаемых от SIP Proxy Server, которая в дальнейшем может быть использована в системах биллинга и менеджмента пользователей.

PAGE 43

СИГНАЛИЗАЦИЯ В СЕТЯХ IP-ТЕЛЕФОНИИ

Рис. 4.7. Возможный сценарий установления и завершения сеанса связи

По протоколу SIP

4.3. Сигнализация на основе протокола SIP - Часть 2

Mon, 13 Jun 2011 13:43:00 +0400

• INVITE - приглашает пользователя принять участие в сеансе связи (служит для установления нового соединения; может содержать параметры для согласования);

• BYE - завершает соединение между двумя пользователями;

• OPTIONS используется для передачи информации о поддерживаемых характеристиках (эта передача может осуществляться напрямую между двумя агентами пользователей или через сервер SIP);

• АСК - используется для подтверждения получения сообщения или для положительного ответа на команду INVITE;

• CANCEL - прекращает поиск пользователя;

• REGISTER - передает информацию о местоположении пользователя на сервер SIP, который может транслировать ее на сервер адресов (Location Server).

Оба протокола SAP и SIP используют механизм SDP (Session Description Protocol) для описания характеристик сеанса: время проведения, требуемые ресурсы и т. д. (Рекомендация RFC 2327). SDP используется исключительно для текстового описания сеанса и не имеет ни транспортных механизмов, ни средств согласования требуемых для сеанса параметров. Эти функции должны выполнять протоколы, применяемые для передачи информации SDP.

Сообщения-ответы могут содержать шесть типов возможных результатов: запрос в процессе выполнения (1хх), успешный запрос (2хх), переадресация (Зхх), неправильный запрос (4хх), отказ сервера (5хх) и глобальный отказ (6хх).

Используемая в SIP адресация основана на унифицированном указателе ресурсов SIP URL, в котором может быть записано имя домена (user@domain) или IP-адрес (user@IPadress) пользователя. Цель использования подобного формата - интеграция SIP-услуг с существующими службами Интернет. Сервер имен доменов (DNS) преобразует доменные имена в IP-адреса конечной точки (рис. 4.7). Вся маршрутизация и передача мультимедийных потоков выполняется нижележащей IP-сетью. Таким образом, услуги SIP хорошо интегрируются в традиционную модель Web-коммуникаций с сервером DNS, обеспечивающим преобразование доменного имени в сетевой адрес.

Предназначенный для инициации сеансов протокол SIP обеспечивает определение адреса пользователя и установление соединения с ним. Кроме этого, он служит основой для применения других протоколов, реализующих функции защиты, аутентификации, описания канала мультимедийной связи и т. д. Для биллинга, например, может использоваться протокол Radius.