Построение сети IP-телефонии

Размещено на http://www.allbest.ru/

Введение

сеть телефония аутентификация

У IP-телефонии есть достаточное количество преимуществ, чтобы вскоре распространиться по всей нашей стране; учитывая экономические аспекты и послание Президента Республики Казахстан Нурсултана Абишевича Назарбаева народу Казахстана «Новое десятилетие, новый экономический подъем, новые возможности Казахстана»: «Лидирующие экономики мира будут функционировать в более сложных, конкурентных условиях и предпримут превентивные меры по подготовке к следующему экономическому циклу, наращивая производительность рабочей силы, инвестирование в инфраструктуру и телекоммуникации, укрепляя финансовые системы, повышая эффективность государственного управления, а также создавая благоприятные условия для развития бизнеса».

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

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

Если говорить о недостатках и уязвимостях IP-телефонии, прежде всего следует отметить те же «болезни», какими страдают другие службы, использующие протокол IP. Это подверженность атакам червей и вирусов, DoS-атакам, несанкционированному удаленному доступу и др. Несмотря на то, что при построении инфраструктуры IP-телефонии данную службу обычно отделяют от сегментов сети, в которых «ходят» не голосовые данные, это еще не является гарантией безопасности. Сегодня большое количество компаний интегрируют IP-телефонию с другими приложениями, например с электронной почтой. С одной стороны, таким образом появляются дополнительные удобства, но с другой -- и новые уязвимости. Кроме того, для функционирования сети IP-телефонии требуется большое число компонентов, таких, как серверы поддержки, коммутаторы, маршрутизаторы, межсетевые экраны, IP-телефоны и т. д.[2].

Среди основных угроз, которым подвергается IP-телефонная сеть, можно выделить:

- регистрацию чужого терминала, позволяющую делать звонки за чужой счет;

- подмену абонента;

- внесение изменений в голосовой или сигнальный трафик;

- снижение качества голосового трафика;

- перенаправление голосового или сигнального трафика;

- перехват голосового или сигнального трафика;

- подделка голосовых сообщений;

- завершение сеанса связи;

- отказ в обслуживании;

- удаленный несанкционированный доступ к компонентам инфраструктуры IP-телефонии;

- несанкционированное обновление ПО на IP-телефоне (например, с целью внедрения троянской или шпионской программы);

- взлом биллинговой системы (для операторской телефонии).

Это далеко не весь перечень возможных проблем, связанных с использованием IP-телефонии. Альянс по безопасности VoIP (VOIPSA) разработал документ, описывающий широкий спектр угроз IP-телефонии, который помимо технических угроз включает вымогательство через IP-телефонию, спам и т. д.

И все же основное уязвимое место IP-телефонии -- это набивший оскомину человеческий фактор. Проблема защищенности при развертывании IP-телефонной сети часто отодвигается на задний план, и выбор решения проходит без участия специалистов по безопасности. К тому же специалисты не всегда должным образом настраивают решение, даже если в нем присутствуют надлежащие защитные механизмы, либо приобретаются средства защиты, не предназначенные для эффективной обработки голосового трафика (например, межсетевые экраны могут не понимать фирменный протокол сигнализации, использующийся в решении IP-телефонии). В конце концов, организация вынуждена тратить дополнительные финансовые и людские ресурсы для защиты развернутого решения либо мириться с его незащищенностью [3].

сеть ip телефония аутентификация

1. Построение сети IP-телефонии

1.1 Транспортные технологии пакетной коммутации

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

Основные технологии пакетной передачи речи - Frame Relay, ATM и маршрутизация пакетов IP - различаются эффективностью использования каналов связи, степенью охвата разных участков сети, надежностью, управляемостью, защитой информации и доступа, а также стоимостью [3].

Транспортная технология ATM уже несколько лет успешно используется в магистральных сетях общего пользования и в корпоративных сетях, а сейчас ее начинают активно использовать и для высокоскоростного доступа по каналам xDSL (для небольших офисов) и SDH/Sonet (для крупных предприятий). Главные преимущества этой технологии - ее зрелость, надежность и наличие развитых средств эксплуатационного управления сетью. В ней имеются непревзойденные по своей эффективности механизмы управления качеством обслуживания и контроля использования сетевых ресурсов. Однако ограниченная распространенность и высокая стоимость оборудования не позволяют считать ATM лучшим выбором для организации сквозных телефонных соединений от одного конечного узла до другого.

Технологии Frame Relay суждено было сыграть в пакетной телефонии ту же роль, что и квазиэлектронным АТС в телефонии с коммутацией каналов: они показали пример эффективной программно управляемой техники, но имели ограниченные возможности дальнейшего развития. Пользователями недорогих услуг Frame Relay, обеспечивающих вполне предсказуемую производи-тельность, стали многие корпоративные сети, и большинство из них вполне довольны своим выбором. В краткосрочной перспективе технология передачи речи по Frame Relay будет вполне эффективна для организации мультисервисного доступа и каналов дальней связи. Но сети Frame Relay распространены незначительно: как правило, на практике используются некоммутируемые соединения в режиме точка-точка [3].

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

1.2 Уровни архитектуры IP-телефонии

Архитектура технологии Voice over IP может быть упрощенно представлена в виде двух плоскостей. Нижняя плоскость - это базовая сеть с маршрутизацией пакетов IP, верхняя плоскость - это открытая архитектура управления обслуживанием вызовов (запросов связи).

Нижняя плоскость, говоря упрощенно, представляет собой комбинацию известных протоколов Интернет: это - RTP (Real Time Transport Protocol), который функционирует поверх протокола UDP (User Datagram Protocol), расположенного, в свою очередь, в стеке протоколов TCP/IP над протоколом IP. Таким образом, иерархия RTP/UDP/IP представляет собой своего рода транспортный механизм для речевого трафика. Здесь же отметим, что в сетях с маршрутизацией пакетов IP для передачи данных всегда предусматриваются механизмы повторной передачи пакетов в случае их потери. При передаче информации в реальном времени использование таких механизмов только ухудшит ситуацию, поэтому для передачи информации, чувствительной к задержкам, но менее чувствительной к потерям, такой как речь и видеоинформация, используется механизм негарантированной доставки информации RTP/UDPD/IP. Рекомендации ITU-Т допускают задержки в одном направлении не превышающие 150 мс. Если приемная станция запросит повторную передачу пакета IP, то задержки при этом будут слишком велики [4].

Теперь перейдем к верхней плоскости управления обслуживанием запросов связи. Вообще говоря, управление обслуживанием вызова предусматривает принятие решений о том, куда вызов должен быть направлен, и каким образом должно быть установлено соединение между абонентами. Инструмент такого управления - телефонные системы сигнализации, начиная с систем, поддерживаемых декадно-шаговыми АТС и предусматривающих объединение функций маршрутизации и функций создания коммутируемого разговорного канала в одних и тех же декадно-шаговых искателях. Далее принципы сигнализации эволюционировали к системам сигнализации по выделенным сигнальным каналам, к многочастотной сигнализации, к протоколам общеканальной сигнализации №7 и к передаче функций маршрутизации в соответствующие узлы обработки услуг Интеллектуальной сети.

В сетях с коммутацией пакетов ситуация более сложна. Сеть с маршрутизацией пакетов IP принципиально поддерживает одновременно целый ряд разнообразных протоколов маршрутизации [5].

Такими протоколами на сегодня являются: RIP - Routing Information Protocol, IGRP - Interior Gateway Routing Protocol, EIGRP - Enhanced Interior Gateway Routing Protocol, IS-IS - Intermediate System-to- intermediate System, OSPF - Open Shortest Path First, BGP - Border Gateway Protocol и др. Точно так же и для IP-телефонии разработан целый ряд протоколов.

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

Другой протокол плоскости управления обслуживанием вызова - SIP - ориентирован на то, чтобы сделать оконечные устройства и шлюзы более интеллектуальными и поддерживать дополнительные услуги для пользователей.

Еще один протокол - SGCP - разрабатывался, начиная с 1998 года, для того, чтобы уменьшить стоимость шлюзов за счет реализации функций интеллектуальной обработки вызова в централизованном оборудовании. Протокол IPDC очень похож на SGCP, но имеет много больше, чем SGCP, механизмов эксплуатационного управления (ОАМ&Р). В конце 1998 года рабочая группа MEGACO комитета IETF разработала протокол MGCP, базирующийся, в основном, на протоколе SGCP, но с некоторыми добавлениями в части ОАМ&Р.

Рабочая группа MEGACO не остановилась на достигнутом, продолжала совершенствовать протокол управления шлюзами и разработала более функциональный, чем MGCP, протокол MEGACO [2].

1.3 Различные подходы к построению сетей IP-телефонии

Чтобы стало понятно, чем конкретно отличаются друг от друга протоколы, кратко рассмотрю архитектуру сетей, построенных на базе этих протоколов, и процедуры установления и завершения соединения с их использованием [2].

1.3.1 Построение сети по рекомендации Н.323

Первый в истории подход к построению сетей IP-телефонии на стандартизованной основе предложен Международным союзом электросвязи (ITU) в рекомендации Н.323. Сети на базе протоколов Н.323 ориентированы на интеграцию с телефонными сетями и могут рассматриваться как сети ISDN, наложенные на сети передачи данных. В частности, процедура установления соединения в таких сетях IP-телефонии базируется на рекомендации Q.931 и аналогична процедуре, используемой в сетях ISDN.

Рекомендация Н.323 предусматривает довольно сложный набор протоколов, который предназначен не просто для передачи речевой информации по IP-сетям с коммутацией пакетов. Его цель - обеспечить работу мультимедийных приложений в сетях с негарантированным качеством обслуживания. Речевой трафик - это только одно из приложений Н.323, наряду с видеоинформацией и данными.

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

На рисунке представлена архитектура сети на базе рекомендации Н.323. Основными устройствами сети являются: терминал (Terminal), шлюз (Gateway), привратник (Gatekeeper) и устройство управления конференциями (Multipoint Control Unit- MCU).

Рисунок. Архитектура сети Н.323

Терминал Н.323 - оконечное устройство пользователя сети IP-телефонии, которое обеспечивает двухстороннюю речевую (мультимедийную) связь с другим терминалом Н.323, шлюзом или устройством управления конференциями [2].

Шлюз IP-телефонии реализует передачу речевого трафика по сетям с маршрутизацией пакетов IP по протоколу Н.323. Основное назначение шлюза - преобразование речевой информации, поступающей со стороны ТФОП, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP. Кроме того, шлюз преобразует сигнальные сообщения систем сигнализации DSS1 и ОКС7 в сигнальные сообщения Н.323 и производит обратное преобразование в соответствии с рекомендацией ITU H.246.

В привратнике сосредоточен весь интеллект сети IP-телефонии.

Сеть, построенная в соответствии с рекомендацией Н.323, имеет зонную архитектуру. Привратник выполняет функции управления одной зоной сети IP-телефонии, в которую входят: терминалы, шлюзы, устройства управления конференциями, зарегистрированные у данного привратника. Отдельные фрагменты зоны сети Н.323 могут быть территориально разнесены и соединяться друг с другом через маршрутизаторы.

Рисунок Зона сети Н.323

Наиболее важными функциями привратника являются:

- регистрация оконечных и других устройств;

- контроль доступа пользователей системы к услугам IP-телефонии при помощи сигнализации RAS;

- преобразование вызываемого пользователя (объявленного имени абонента, телефонного номера, адреса электронной почты и др.) в транспортный адрес сетей с маршрутизацией пакетов IP (IP адрес + номер порта TCP);

- контроль, управление и резервирование пропускной способности сети;

- ретрансляция сигнальных сообщений Н.323 между терминалами.

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

Кроме основных функций, определенных рекомендацией Н.323, привратник может отвечать за аутентификацию пользователей и начисление платы (биллинг) за телефонные соединения. Устройство управления конференциями обеспечивает возможность организации связи между тремя или более участниками [4].

Рекомендация Н.323 предусматривает три вида конференции: централизованная (т.е. управляемая MCU, с которым каждый участник конференции соединяется в режиме точка-точка), децентрализованная (когда каждый участник конференции соединяется с остальными ее участниками в режиме точка-группа точек) и смешанная.

Преимуществом централизованной конференции является сравнительно простое терминальное оборудование, недостатком - большая стоимость устройства управления конференциями.

Для децентрализованной конференции требуется более сложное терминальное оборудование и желательно, чтобы в сети IP поддерживалась передача пакетов IP в режиме многоадресной рассылки (IP multicasting). Если этот режим в сети не поддерживается, терминал должен передавать речевую информацию каждому из остальных участников конференции в режиме точка-точка.

Устройство управления конференциями состоит из одного обязательного элемента - контроллера конференций (Multipoint Controller - МС), и, кроме того, может включать в себя один или более процессоров для обработки пользовательской информации (Multipoint Processor - МР). Контроллер может быть физически совмещен с привратником, шлюзом или устройством управления конференциями, а последнее, в свою очередь, может быть совмещено со шлюзом или привратником.

Рисунок. Виды конференции в сетях Н.323

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

Так как контроллеров в сети может быть несколько, для каждой вновь создаваемой конференции должна быть проведена специальная процедура выявления того контроллера, который будет управлять данной конференцией. При организации централизованной конференции, кроме контроллера МС, должен использоваться процессор МР, обрабатывающий пользовательскую информацию. Процессор МР отвечает за переключение или смешивание речевых потоков, видеоинформации и данных. Для децентрализованной конференции процессор не нужен [5].

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

- подключение через средства коммутируемого доступа или локальные сети терминалов, не поддерживающих протокол резервирования ресурсов (RSVP). Два таких прокси-сервера могут образовать в IP-сети туннельное соединение с заданным качеством обслуживания;

- маршрутизацию трафика Н.323 отдельно от обычного трафика данных;

- обеспечение совместимости с преобразователем сетевых адресов, поскольку допускается размещение оборудования Н.323 в сетях с пространством адресов частных сетей;

- защиту доступа - доступность только для трафика Н.323.

Протокол RAS (Registration Admission Status) обеспечивает взаимодействие оконечных и других устройств с привратником.

Основными функциями протокола являются: регистрация устройства в системе, контроль его доступа к сетевым ресурсам, изменение полосы пропускания в процессе связи, опрос и индикация текущего состояния устройства. В качестве транспортного протокола используется протокол с негарантированной доставкой информации UDP.

Протокол Н.225.0 (Q.931) поддерживает процедуры установления, поддержания и разрушения соединения. В качестве транспортного протокола используется протокол с установлением соединения и гарантированной доставкой информации TCP.

По протоколу Н.245 происходит обмен между участниками соединения информацией, которая необходима для создания логических каналов. По этим каналам передается речевая информация, упакованная в пакеты RTP/UDP/IP.

Выполнение процедур, предусмотренных протоколом RAS, является начальной фазой установления соединения с использованием сигнализации Н.323. Далее следуют фаза сигнализации Н.225.0 (Q.931) и обмен управляющими сообщениями Н.245. Разрушение соединения происходит в обратной последовательности: в первую очередь закрывается управляющий канал Н.245 и сигнальный канал Н.225.0, после чего привратник по каналу RAS оповещается об освобождении ранее занимавшейся полосы пропускания [2].

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

Рассмотрим шаг за шагом этот упрощенный сценарий.

1) Оконечное устройство пользователя А посылает запрос соединения - сообщение SETUP - к оконечному устройству пользователя В на ТСР-порт1720;

2) Оконечное устройство вызываемого пользователя В отвечает на сообщение SETUP сообщением ALERTING, означающим, что устройство свободно, а вызываемому пользователю подается сигнал о входящем вызове;

3) После того, как пользователь В принимает вызов, к вызывающей стороне А передается сообщение CONNECT с номером ТСР-порта управляющего канала Н.245;

4) Оконечные устройства обмениваются по каналу Н.245 информацией о типах используемых речевых кодеков (G.729, G.723.1 и т.д.), а также о других функциональных возможностях оборудования, и оповещают друг друга о номерах портов RTP, на которые следует передавать информацию;

5) Открываются логические каналы для передачи речевой информации;

6) Речевая информация передаётся в обе стороны в сообщениях протокола RTP; кроме того, ведется контроль передачи информации при помощи протокола RTCP.

Рисунок Упрощённый сценарий установления соединения в сети Н.323

Приведенная процедура обслуживания вызова базируется на протоколе Н.323 версии 1. Версия 2 протокола Н.323 позволяет передавать информацию, необходимую для создания логических каналов, непосредственно в сообщении SETUP протокола Н.225.0 без использования протокола Н.245. Такая процедура называется «быстрый старт» (Fast Start) и позволяет сократить количество циклов обмена информацией при установлении соединения. Кроме организации базового соединения, в сетях Н.323 предусмотрено предоставление дополнительных услуг в соответствии с рекомендациями ITU H.450.X [5].

Следует отметить еще одну важную проблему - качество обслуживания в сетях Н.323. Оконечное устройство, запрашивающее у привратника разрешение на доступ, может, используя поле transportQoS в сообщении ARQ протокола RAS, сообщить о своей способности резервировать сетевые ресурсы. Рекомендация Н.323 определяет протокол резервирования ресурсов (RSVP) как средство обеспечения гарантированного качества обслуживания, что предъявляет к терминалам требование поддержки протокола RSVP. К сожалению, протокол RSVP используется отнюдь не повсеместно, что оставляет сети Н.323 без основного механизма обеспечения гарантированного качества обслуживания. Это - общая проблема сетей IP-телефонии, характерная не только для сетей Н.323.

1.3.2 Сеть на базе протокола SIP

Второй подход к построению сетей IP-телефонии, предложенный рабочей группой MMUSIC комитета IETF в документе RFC 2543, основан на использовании протокола SIP - Session Initiation Protocol [7].

SIP представляет собой текстоориентированный протокол, который является частью глобальной архитектуры мультимедиа, разработанной комитетом Internet Engineering Task Force (IETF). Эта архитектура также включает в себя протокол резервирования ресурсов (Resource Reservation Protocol, RSVP, RFC 2205), транспортный протокол реального времени (Real-Time Transport Protocol, RTP, RFC 1889), протокол передачи потоков в реальном времени (Real-Time Streaming Protocol, RTSP, RFC 2326), протокол описания параметров связи (Session Description Protocol, SDP, RFC 2327), протокол уведомления о связи (Session Announcement Protocol, SAP). Однако функции протокола SIP не зависят от любого из этих протоколов.

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

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

Тем не менее, протокол SIP поддерживает услуги интеллектуальной сети (IN), такие как преобразование (мэппинг) имён, переадресация и маршрутизация, что существенно для использования SIP в качестве протокола сигнализации в сети общего пользования, где приоритетной задачей оператора является предоставление широкого спектра телефонных услуг. Другой важной особенностью протокола SIP является поддержка мобильности пользователя, т.е. его способности получать доступ к заказанным услугам в любом месте и с любого терминала, а также способности сети идентифицировать и аутентифицировать пользователя при его перемещении из одного места в другое. Это свойство SIP не уникально, и, например, протокол Н.323 тоже в значительной степени поддерживает такую возможность. Сейчас настал момент, когда эта возможность станет главной привлекательной чертой сетей IP-телефонии нового поколения. Данный режим работы потребует дистанционной регистрации пользователей на сервере идентификации и аутентификации [2].

Перейдем непосредственно к архитектуре сетей, базирующихся на протоколе SIP.

Рисунок Пример сети на базе протокола SIP

Сеть SIP содержит основные элементы трех видов: агенты пользователя, прокси-серверы и серверы переадресации. Агенты пользователя (User Agent или SIP client) являются приложениями терминального оборудования и включают в себя две составляющие: агент пользователя - клиент (User Agent Client - UAC) и агент пользователя - сервер (User Agent Server - UAS), иначе известные как клиент и сервер соответственно. Клиент UAC инициирует SIP-запросы, т.е. выступает в качестве вызывающей стороны. Сервер UAS принимает запросы и возвращает ответы, т.е. выступает в качестве вызываемой стороны.

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

Прокси-сервер (Proxy-server) действует «от имени других клиентов» и содержит функции клиента (UAC) и сервера (UAS). Этот сервер интерпретирует и может перезаписывать заголовки запросов перед отправкой их к другим серверам (рисунок 1.9). Ответные сообщения следуют по тому же пути обратно к прокси-серверу, а не к клиенту.

Рисунок Сеть SIP с прокси-сервером

На рисунке представлен алгоритм установления соединения с помощью протокола SIP при участии прокси-сервера:

1) Прокси-сервер принимает запрос соединения INVITE от оборудования вызывающего пользователя;

2) Прокси-сервер устанавливает местонахождение клиента с помощью сервера определения местоположения (location server);

3) Прокси-сервер передает запрос INVITE вызываемому пользователю;

4) Оборудование вызываемого пользователя уведомляет последнего о входящем вызове и возвращает прокси-серверу сообщение о том, что запрос INVITE обрабатывается (код 100). Прокси-сервер, в свою очередь, направляет эту информацию оборудованию вызывающего пользователя;

5) Когда вызываемый абонент принимает вызов, его оборудование извещает об этом прокси-сервер (код 200), который переправляет информацию о том, что вызов принят, к оборудованию вызывающего пользователя;

6) Вызывающая сторона подтверждает установление соединения передачей запроса АСК, которое прокси-сервер переправляет вызываемой стороне. Установление соединения закончено, абоненты могут обмениваться речевой информацией [2].

Сервер переадресации (Redirect server) определяет текущее местоположение вызываемого абонента и сообщает его вызывающему пользователю (рисунок 1.10). Для определения текущего местоположения вызываемого абонента сервер переадресации обращается к серверу определения местоположения, принципы работы которого в документе RFC 2543 не специфицированы.

Алгоритм установления соединения с использованием протокола SIP при участии сервера переадресации выглядит следующим образом:

1) Сервер переадресации принимает от вызывающей стороны запрос соединения INVITE и связывается с сервером определения местонахождения, который выдает текущий адрес вызываемого клиента;

2) Сервер переадресации передает этот адрес вызывающей стороне. В отличие от прокси-сервера, запрос INVITE к оборудованию вызываемого пользователя сервер переадресации не передает;

3) Оборудование вызывающего пользователя подтверждает завершение транзакции с сервером переадресации запросом АСК;

4) Далее оборудование вызывающего пользователя передает запрос INVITE на адрес, полученный от сервера переадресации;

5) Оборудование вызываемого пользователя уведомляет последнего о входящем вызове и возвращает вызывающему оборудованию сообщение о том, что запрос INVITE обрабатывается (код 100);

6) Когда вызываемый абонент принимает вызов, об этом извещается оборудование вызывающего пользователя (код 200).Установление соединения закончено, абоненты могут обмениваться речевой информацией.

Рисунок Сеть SIP с сервером переадресации

Существует также и бессерверный вариант соединения, когда один терминал может передать запрос другому терминалу непосредственно [4].

Протокол SIP предусматривает 5 запросов и ответов на них.

Сигнализация SIP дает возможность пользовательским агентам и сетевым серверам определять местоположение, выдавать запросы и управлять соединениями.

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

АСК - запрос подтверждает прием от вызываемой стороны ответа на команду INVITE и завершает транзакцию.

OPTIONS - запрос позволяет получить информацию о функциональных возможностях пользовательских агентов и сетевых серверов. Однако этот запрос не используется для организации сеансов связи.

BYE - запрос используется вызывающей и вызываемой сторонами для разрушения соединения. Перед тем как разрушить соединение, пользовательские агенты отправляют этот запрос к серверу, сообщая о намерении прекратить сеанс связи.

CANCEL - запрос позволяет пользовательским агентам и сетевым серверам отменить любой ранее переданный запрос, если ответ на нее еще не был получен [5].

1.3.3 Сеть на базе MGCP

Третий подход к построению сетей IP-телефонии, основанный на использовании протокола MGCP, также предложен комитетом IETF, рабочей группой MEGACO.

При разработке этого протокола рабочая группа MEGACO опиралась на сетевую архитектуру, содержащую основные функциональные блоки трех видов:

- шлюз - Media Gateway (MG), который выполняет функции преобразования речевой информации, поступающей со стороны ТфОП с постоянной скоростью передачи, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP (кодирование и упаковку речевой информации в пакеты RTP/UDP/IP, а также обратное преобразование);

- контроллер шлюзов - Call Agent, которой выполняет функции управления шлюзами;

- шлюз сигнализации - Signaling Gateway (SG), который обеспечивает доставку сигнальной информации, поступающей со стороны ТфОП, к контроллеру шлюзов и перенос сигнальной информации в обратном направлении.

Таким образом, весь интеллект функционально распределенного шлюза сосредоточен в контроллере, функции которого могут быть распределены между несколькими компьютерными платформами [7].

Рисунок Архитектура сети на базе протокола MGCP

Шлюз сигнализации выполняет функции 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), имеющий ряд преимуществ перед протоколом ТСР, основным из которых является значительное снижение времени доставки сигнальной информации и, следовательно, времени установления соединения - одного из важнейших параметров качества обслуживания.

Если в ТфОП используется сигнализация по выделенным сигнальным каналам (ВСК), то сигналы сначала поступают вместе с пользовательской информацией в транспортный шлюз, а затем передаются в контроллер шлюзов без посредничества шлюза сигнализации [8].

Отметим, что протокол MGCP является внутренним протоколом для обмена информацией между функциональными блоками распределенного шлюза, который извне представляется одним шлюзом. Протокол MGCP является master/slave протоколом. Это означает, что контроллер шлюзов является ведущим, а сам шлюз - ведомым устройством, которое должно выполнять все команды, поступающие от контроллера Call Agent.

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

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

Рассмотрим алгоритмы установления и разрушения соединения с использованием протокола MGCP. Первый пример охватывает взаимодействие протокола MGCP с протоколом ОКС7 (рисунок 1.12).

Рисунок Установление и разрушение соединения с использованием протокола MGCP (Пример 1)

1) От телефонной станции АТС-А к шлюзу сигнализации SG1 по общему каналу сигнализации поступает запрос соединения в виде сообщения IAM протокола ISUP. На рисунке 1.12 шлюз сигнализации 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, после чего соединение считается разрушенным [2].

Рисунок Установление и разрушение соединения с использованием протокола MGCP (Пример 2)

Второй пример иллюстрирует взаимодействие протокола MGCP с протоколами ОКС7 и Н.323 (рисунок 1.13).

1) С телефонной станции АТС-А к шлюзу сигнализации SG1 по общему каналу сигнализации поступает запрос соединения (сообщение IAM). На рисунке 1.13 шлюз сигнализации 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, после чего соединение считается разрушенным [2].

Следует заметить, что алгоритм взаимодействия протоколов SIP и MGCP не сильно отличается от вышеописанного алгоритма.

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

Международный союз электросвязи в проекте версии 4 рекомендации Н.323 ввел принцип декомпозиции шлюзов. Управление функциональными блоками распределенного шлюза будет осуществляться контроллером шлюза - Media Gateway Controller - при помощи адаптированного к Н.323 протокола MEGACO, который в рекомендации Н.248 назван Gateway Control Protocol.

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

1.4 Сравнение подходов к построению сети IP-телефонии

В настоящее время для построения хорошо функционирующих и совместимых с ТфОП сетей IP-телефонии подходят протоколы Н.323 и MGCP. Как уже отмечалось, протокол SIP несколько хуже взаимодействует с системами сигнализации, используемыми в ТфОП [9].

Подход, основанный на использовании протокола MGCP, обладает весьма важным преимуществом перед подходом, предложенным ITU в рекомендации Н.323: поддержка контроллером шлюзов сигнализации ОКС7 и других видов сигнализации, а также прозрачная трансляция сигнальной информации по сети IP-телефонии. В сети, построенной на базе рекомендации Н.323, сигнализация ОКС7, как и любая другая сигнализация, конвертируется шлюзом в сигнальные сообщения Н.225.0 (Q.931).

Основным недостатком третьего из приведенных в данном параграфе подходов является незаконченность стандартов.

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

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

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

В последнем из упомянутых подходов (в проекте версии 4 рекомендации Н.323) ITU-Т ввел принцип декомпозиции шлюзов, использованный в третьем подходе. Управление функциональными блоками распределенного шлюза будет осуществляться контроллером шлюза - MGC (Media Gateway Controller) при помощи протокола MEGACO/H.248. В проекте версии 4 рекомендации Н.323 предусмотрена также возможность прозрачной передачи сигнализации ОКС7 и других видов сигнализации по сетям IP- телефонии и обработка сигнализации всех видов привратником без преобразования в сигнальные сообщения Н.225.0.

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

1.5 Варианты систем IP-телефонии (сценарии)

Существуют три наиболее часто используемых сценария IP-телефонии:

- «компьютер-компьютер»;

- «компьютер-телефон»;

- «телефон-телефон».

Сценарий «компьютер-компьютер» реализуется на базе стандартных компьютеров, оснащенных средствами мультимедиа и подключенных к сети Интернет [10].

Компоненты модели IP-телефонии по сценарию «компьютер-компьютер» показаны на рисунке 1.14. В этом сценарии аналоговые речевые сигналы от микрофона абонента А преобразуются в цифровую форму с помощью аналого-цифрового преобразователя (АЦП), обычно при 8000 отсчетов/с, 8 битов/отсчет, в итоге - 64 Кбит/с.

Отсчеты речевых данных в цифровой форме затем сжимаются кодирующим устройством для сокращения нужной для их передачи полосы в отношении 4:1, 8:1 или 10:1. Алгоритмы сжатия речи подробно рассматриваются в следующей главе. Выходные данные после сжатия формируются в пакеты, к которым добавляются заголовки протоколов, после чего пакеты передаются через IP-сеть в систему IP-телефонии, обслуживающую абонента Б. Когда пакеты принимаются системой абонента Б, заголовки протокола удаляются, а сжатые речевые данные поступают в устройство, развертывающее их в первоначальную форму, после чего речевые данные снова преобразуются в аналоговую форму с помощью цифро-аналогового преобразователя (ЦАП) и попадают в телефон абонента Б. Для обычного соединения между двумя абонентами системы IP-телефонии на каждом конце одновременно реализуют как функции передачи, так и функции приема. Под IP-сетью, изображенной на рисунке 1.14, подразумевается либо глобальная сеть Интернет, либо корпоративная сеть предприятия Intranet. Описанию протоколов, используемых в IP-сетях, в том числе протоколов передачи речевой информации по IP-сети.

Рисунок Сценарий IP-телефонии "компьютер-компьютер"

Для поддержки сценария «компьютер - компьютер» поставщику услуг Интернет желательно иметь отдельный сервер (привратник), преобразующий имена пользователей в динамические адреса IP. Сам сценарий ориентирован на пользователя, которому сеть нужна, в основном, для передачи данных, а программное обеспечение IP-телефонии требуется лишь иногда для разговоров с коллегами.

Эффективное использование телефонной связи по сценарию «компьютер-компьютер» обычно связано с повышением продуктивности работы крупных компаний, например, при организации виртуальной презентации в корпоративной сети с возможностью не только видеть документы на Web-сервере, но и обсуждать их содержание с помощью IP-телефона. При этом между двумя IP-сетями могут использоваться элементы ТфОП, а идентификация вызываемой стороны может осуществляться как на основе Е.164, так и на основе IP-адресации. Наиболее распространенным программным обеспечением для этих целей является пакет Microsoft NetMeeting, доступный для бесплатной загрузки с узла Microsoft [12].

Рассмотрим представленный на рисунок 1.14 сценарий установления соединения «компьютер-компьютер» более подробно.

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

1) Абонент А запускает свое приложение IP-телефонии, поддерживающее протокол Н.323;

2) Абонент Б уже заранее запустил свое приложение IP-телефонии, поддерживающее протокол Н.323;

3) Абонент А знает доменное имя абонента В элемент системы имен доменов - Domain Name System (DNS), вводит это имя в раздел «кому позвонить» в своем приложении IP-телефонии и нажимает кнопку Return;

4) Приложение IP-телефонии обращается к DNS-серверу (который в данном примере реализован непосредственно в персональном компьютере абонента А для того, чтобы преобразовать доменное имя абонента Б в IP-адрес;

5) Сервер DNS возвращает IP-адрес абонента Б;

6) Приложение IP-телефонии абонента А получает IP-адрес абонента Б и отправляет ему сигнальное сообщение Н.225 Setup;

7) При получении сообщения Н.225 Setup приложение абонента Б сигнализирует ему о входящем вызове;

8) Абонент Б принимает вызов и приложение IP-телефонии отправляет ответное сообщение Н.225 Connect;