На сегодняшний день существует множество путей пакетной телефонии.

Более выгодным с экономической точки зрения вариантом развития ПТ, является построение сети на базе технологии VoIP , но при этом важным элементом такой сети является наличие существующей ЛВС и/или СПД.

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

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

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

Первое поколение систем IP-телефонии имели, с точки зрения удобства эксплуатации, один существенный недостаток - они требовали местного электропитания. Сейчас найдено решение этой проблемы - производители активного сетевого оборудования стали предлагать модели коммутаторов, обеспечивающие дистанционное питание IP-телефонов по Ethernet-проводке (PoE) и большинство моделей IP-телефонов также поддерживают питание по стандарту IEEE 802.3af. Кроме дорогостоящих коммутаторов с поддержкой PoE некоторые производители предлагают много портовые инжекторы питания PoE по разумным ценам.

Современные системы IP-телефонии поддерживают все основные сервисные функции УАТС. Однако главным преимуществом IP-телефонии, делающим ее популярной в глазах абонентов, являются новые виды сервиса, реализация которых на базе традиционных УАТС была затруднительна. Примером может служить универсальный операторский центр, сопряженный с web-сайтом электронной коммерции компании. Благодаря протоколу IP интеграция телефонных и компьютерных приложений становится прозрачной . Другим примером может служить система обработки унифицированных сообщений (unified messaging). Благодаря этой обработке абонент телефонной системы может обмениваться голосовыми сообщениями, посланиями электронной почты или факсами с помощью одного терминального устройства, которым может служить даже сотовый телефон абонента. Пройдя процедуру авторизации в системе, абонент может узнать содержимое своего почтового ящика с помощью речевого синтезатора или послать факс, используя функции автоматического распознавания речи.

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

Перечислим некоторые недостатки IP-телефонии:

· Неоспоримым преимуществом стандартной телефонной сети до сих пор остаётся возможность звонить даже при отсутствии электропитания. Для телефонов VoIP нужно не только электропитание, но и широкополосный доступ в Интернет.

· Передача голоса через VoIP обеспечивает качество передачи голоса, сравнимое с наивысшим уровнем, предоставляемым сетями ISDN. В то же время, качество зависит от множества факторов, часть из которых можно контролировать (в собственной локальной сети), а другие - нет (передача данных по Интернету и качество услуг VoIP-провайдера).

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

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

1.3 Компоненты и протоколы сетей IP-телефонии

Возможность передачи голосовых сообщений через сеть с пакетной коммутацией впервые была реализована в 1993 году. Данная технология получила название VoIP (Voice over IP). VoIP - система связи, при которой аналоговый звуковой сигнал от одного абонента дискретизируется (кодируется) в цифровой вид, компрессируется и пересылается по цифровым каналам связи до второго абонента, где производится обратная операция - декомпрессия, декодирование и воспроизведение аналогового сигнала. Одним из частных приложений данной технологии является IP-телефония - услуга по передаче телефонных разговоров абонентов по протоколу IP.

По существу эта технология представляет собой средство для передачи не только речи, но и произвольной информации с использованием протокола IP, а обобщающим термином стало определение «мультимедийная». Соответствующая структура данных может включать речь, изображение и данные в любых комбинациях. Эту триаду обычно называют Triple Play.

Архитектура сети VoIP может быть представлена в виде двух плоскостей. Нижняя отображает транспортный механизм негарантированной доставки мультимедийного трафика в виде иерархии протоколов RTP/UDP/IP, а верхняя - механизм управления обслуживанием вызовов. Ее ключевыми протоколами являются H.323 ITU-T, SIP, MGCP и MEGACO , представляющие собой различные реализации обслуживания вызовов в сетях IP-телефонии.

Транспортный протокол реального времени (Real-time Transport Protocol, RTP) предоставляет транспортные услуги мультимедийным приложениям. Он не гарантирует доставку и правильный порядок пакетов, но позволяет приложениям обнаружить потерю или нарушение порядка следования пакетов за счет присвоения каждому из них номера. Протокол предназначен для работы в режимах передачи «точка-точка» или «точка-множество точек» и не зависит от транспортного механизма. Однако в качестве такового обычно используется протокол UDP.

RTP работает совместно с протоколом управления реального времени (Real Time Control Protocol, RTСP), обеспечивающим управление потоком данных и контроль перегрузки канала. Участники сеанса RTP периодически обмениваются пакетами RTCP со статистическими данными (количество отправленных пакетов, число потерянных и т. д.), которые могут быть использованы отправителем мультимедиа, например, для динамической коррекции скорости передачи и даже изменения типа нагрузки.

При проектировании ПТ на начальном этапе необходимо выбрать протокол из четырех упомянутых, при этом, соответственно этим протоколам, будет использован способ построения.

Первый способ построения сети опирается на протокол H.323, краткое описание которого приведено ниже.

Второй способ соответствует построению сети на базе протокола SIP, чье более подробное описание приведено ниже.

Третий способ построения сети IP-телефонии опирается на протокол Media Gateway Control Protocol (MGCP) , предложенный рабочей группой MEGACO комитета IETF. Архитектура этого протокола, пожалуй, наиболее проста с точки зрения функциональности. Сеть MGCP содержит шлюз (Media Gateway, MG), выполняющий преобразование речевой информации между сетями ТфОП и IP-телефонии, шлюз сигнализации (Signaling Gateway, SG), обеспечивающий обработку сигнальной информации, а также схожий с привратником сети H.323 контроллер шлюзов (Call Agent), осуществляющий функции управления шлюзами.

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

Четвертый способ построения сети IP, представляющий собой усовершенствование MGCP, разработан группой MEGACO комитета IETF вместе с 16 SG ITU-T, поэтому его называют протоколом MEGACO/H.248. От своего старшего брата он отличается прежде всего иной схемой организации связи. Благодаря ей контроллер MEGACO/H.248 способен изменять топологию связи портов, что позволяет гибко управлять конференциями. Протокол MEGACO поддерживает два способа бинарного кодирования.

1.3.1 H.323

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

· цифровое аудио;

· цифровое видео;

· данные (обмен файлами или изображениями);

· управление соединением (обмен информацией о поддерживаемых функциях, управление логическими каналами и т. д.);

· управление установлением и разъединением соединений и сеансов связи.

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

Рекомендации Н.323 определяет следующие элементы архитектуры сети IP-телефонии:

l Терминал

l Шлюз (Gateway)

l Контроллер (Gatekeeper), иногда называемый как ПО управления соединениями или привратник

l Устройство многоточечной конференц-связи (MCU)

l Терминал Н.323

Рисунок 1.1 Схема взаимодействия Н.323-системы с другими стандартными Н.Зхх-системами

Терминал

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

Все Н.323-терминалы для оценки возможностей канала связи должны поддерживать функции управления логическим каналом, определенные рекомендациями Н.245. Поскольку стандарт Н.245 является чрезвычайно громоздким, так как описывает многочисленные возможные варианты реализации функций управления, то несколько производителей оборудования для конференцсвязи объединились и разработали более компактную версию этого стандарта - рекомендации Н.245.1 (H.245 profile 1).

Н.323-терминалы должны также обязательно поддерживать упрощенную версию протокола Q.931, для сигнализации и вызова, содержать модуль, называемый RAS (Registration/Admission/Status), обеспечивающий функции контроля доступа, регистрации участников и определение их текущего состояния, а также иметь возможность реализации протокола RTP/RTCP для передачи аудио- и видеоинформации по сетям с коммутацией пакетов.

Опционально терминал может поддерживать видеообмен, документ-конференции по протоколам серии Т.120 и выполнять функции многовходового моста для организации групповых конференций (MCU).

Рисунок 1.2 Функции шлюза между ISDN и ЛВС-терминалами

Шлюз

Шлюз является необязательным элементом в Н.323-системе. Это устройство обеспечивает целый ряд сервисов, включая обмен информацией между Н.323-терминалом и терминалами, определяемыми другими ITU-стандартами серии Н для электронных конференций. Реализация такой функции требует трансляцию формата кадров и преобразование коммуникационных процедур (например, Н.225.0 в Н.221 и Н.245 в Н.242 при обмене информацией Н.323-терминала с Н.320-терминалом). Кроме этого, шлюз выполняет перекодировку аудио и видеопотоков, а также обеспечивает функцию установления и разрыва соединения между ЛВС и сетями с коммутацией каналов. Рисунок 1.2 иллюстрирует функции шлюза между Н.323- и Н.320-терминалами.

В общем случае задачей шлюза является взаимное отражение свойств и характеристик оконечного конференц-оборудования ЛВС и терминалов сетей с коммутацией каналов. Основные функции шлюза следующие:

l установление соединения с аналоговым терминалом в телефонной сети общего пользования

l установление соединения с удаленным Н.320-терминалом в сети ISDN

l установление соединения с удаленным Н.324-терминалом в телефонной сети общего пользования.

Заметим, что шлюз не нужен, если нет необходимости установления соединений из ЛВС с удалёнными терминалами в сетях с коммутацией каналов, ибо Н.323-терминалы имеют механизм установлена непосредственных соединений. Для этого используются процедуры протоколов Н.245 и Q.931.

С соответствующими транскодерами Н.323-шлюз обеспечивает взаимодействие Н.333-терминала терминалами, определенными рекомендациями Н.320, Н.321 (АТМ ЛВС), Н.322 (ЛВС с гарантированным QoS) и V.70.

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

Еще один элемент сети H.323, называемый прокси-сервером (т. е. посредником), работает на прикладном уровне, он определяет тип приложения и выполняет нужное соединение.

Плоскость обслуживания вызовов стандарта H.323 включает три основных протокола, продемонстрировано на рисунок 1.3: протокол взаимодействия оконечного оборудования с привратником RAS (Registration, Admission and Status), протокол управления соединениями H.225 и протокол управления логическими каналами H.245. Для передачи сигнальных сообщений RAS используется протокол UDP, а для передачи сигнальных сообщений H.225 и H.245 - протокол TCP с гарантированной доставкой информации. UDP не обеспечивает гарантированной доставки информации, поэтому, если подтверждение не было получено в установленное время, сообщение передается повторно.

Рисунок 1.3 Основные протоколы стека Н.323.

Процесс установления соединения состоит из трех этапов. На первом решаются задачи обнаружения привратника, регистрации привратником терминалов, контроля доступа терминалов к сетевым ресурсам, для чего привлекается протокол RAS. На двух следующих этапах выполняются процессы сигнализации H.225 и обмен управляющими сообщениями H.245.

Рекомендация H.225 регламентирует процедуры управления соединением в сетях H.323 с использованием ряда сигнальных сообщений из рекомендации Q.931 ITU-T.

Рекомендация H.245 описывает процедуры управления информационными каналами: определение ведущего и ведомого устройств, а также обмен данными о функциональных возможностях терминалов и открытии и закрытии однонаправленных и двунаправленных каналов, вносимой задержке, режиме обработки информации, состоянии информационных каналов путем организации шлейфов.

Этот обмен сигнальными сообщениями между взаимодействующими устройствами сети H.323 осуществляется по логическим каналам H.245, причем нулевой логический канал, по которому передаются управляющие сообщения, должен быть открыт в течение всего времени существования соединения.

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

1.3.2 SIP

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

Протокол SIP разработан группой MMUSIC (Multiparty Multimedia Session Control) комитета IETF (Internet Engineering Task Force), а спецификации протокола представлены в документе RFC 2543. В основу протокола рабочая группа MMUSIC заложила следующие принципы:

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

Масштабируемость сети. Она характеризуется, в первую очередь, возможностью увеличения количества элементов сети при её расширении. Серверная структура сети, построенной на базе протокола SIP, в полной мере отвечает этому требованию.

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

В качестве примера можно привести ситуацию, когда протокол SIP используется для установления соединения между шлюзами, взаимодействующими с ТфОП при помощи сигнализации ОКС7 или DSS1. В настоящее время SIP не поддерживает прозрачную передачу сигнальной информации телефонных систем сигнализации. Вследствие этого дополнительные услуги ISDN оказываются недоступными для пользователей IP-сетей .

Интеграция в стек существующих протоколов Интернет, разработанных IETF. Протокол SIP является частью глобальной архитектуры мультимедиа, разработанной комитетом 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). Однако функции протокола SIP не зависят ни от одного из этих протоколов.

Взаимодействие с другими протоколами сигнализации. Протокол SIP может быть использован совместно с протоколом Н.323. Возможно также взаимодействие протокола SIP с системами сигнализации ТфОП - DSS1 и ОКС7. Для упрощения такого взаимодействия сигнальные сообщения протокола SIP могут переносить не только специфический SIP-адрес, но и телефонный номер формата Е.164 или любого другого формата. Кроме того, протокол SIP, наравне с протоколами Н.323 и ISUP/IP, может применяться для синхронизации работы устройств управления шлюзами, в этом случае он должен взаимодействовать с протоколом MGCP. Другой важной особенностью протокола SIP является то, что он приспособлен к организации доступа пользователей сетей IP-телефонии к услугам интеллектуальных сетей, и существует мнение, что именно этот протокол станет основным при организации связи между указанными сетями.

1.4 Интеграция протокола SIP с IP-сетями

Одной из важнейших особенностей протокола SIP является его независимость от транспортных технологий. В качестве транспорта могут использоваться протоколы Х.25, Frame Relay, AAL5/ATM, IPX и др. Структура сообщений SIP не зависит от выбранной транспортной технологии. Но, в то же время, предпочтение отдается технологии маршрутизации пакетов IP и протоколу UDP. При этом, правда, необходимо создать дополнительные механизмы для надежной доставки сигнальной информации. К таким механизмам относятся повторная передача информации при ее потере, подтверждение приема и др.

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

Рисунок 1.4 Место протокола SIP в стеке протоколов TCP/IP

По сети с маршрутизацией пакетов IP может передаваться пользовательская информация практически любого вида: речь, видео и данные, а также любая их комбинация, называемая мультимедийной информацией. При организации связи между терминалами пользователей необходимо известить встречную сторону, какого рода информация может приниматься (передаваться), алгоритм ее кодирования и адрес, на который следует передавать информацию. Таким образом, одним из обязательных условий организации связи при помощи протокола SIP является обмен между сторонами данными об их функциональных возможностях. Для этой цели чаще всего используется протокол описания сеансов связи - SDP (Session Description Protocol). Поскольку в течение сеанса связи может производиться его модификация, предусмотрена передача сообщений SIP с новыми описаниями сеанса средствами SDP.

Для передачи речевой информации комитет IETF предлагает использовать протокол RTP, но сам протокол SIP не исключает возможность применения для этих целей других протоколов.

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

Протокол SIP предусматривает организацию конференций трех видов:

* в режиме многоадресной рассылки (multicasting), когда информация передается на один multicast-адрес, а затем доставляется сетью конечным адресатам;

* при помощи устройства управления конференции (MCU), к которому участники конференции передают информацию в режиме точка-точка, а оно, в свою очередь, обрабатывает ее (т.е. смешивает или коммутирует) и рассылает участникам конференции;

* путем соединения каждого пользователя с каждым в режиме точка-точка.

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

И, в заключение рассказа об интеграции протокола SIP с IP-сетями, следует отметить то. что разработаны методы совместной работы этого протокола с преобразователем сетевых адресов - Network Address Translator (NAT).

Адресация

Для организации взаимодействия с существующими приложениями IP-сетей и для обеспечения мобильности пользователей протокол SIP использует адрес, подобный адресу электронной почты. В качестве адресов рабочих станций используются специальные универсальные указатели ресурсов - URL (Universal Resource Locators), так называемые SIP URL

SIP-адреса бывают четырех типов:

* имя@домен;

* имя@хост,

* имя@IР-адрес;

* №телефона@шлюз.

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

Во второй части адреса указывается имя домена, рабочей станции или шлюза. Для определения IP-адреса устройства необходимо обратиться к службе доменных имен - Domain Name Service (DNS). Если же во второй части SIP-адреса размещается IP-адрес, то с рабочей станцией можно связаться напрямую.

В начале SIP-адреса ставится слово «sip:», указывающее, что это именно SIP-адрес, т.к. бывают и другие (например, «mailto:»). Ниже приводятся примеры SIP-адресов:

sip: als@rts.loniis.ru

sip: user1@192.168.100.152

sip: 294-75-47@gateway.ru

1.5 Архитектура сети SIP

В некотором смысле прародителем протокола SIP является протокол переноса гипертекста - HTTP (Hypertext Transfer Protocol, RFC 2068). Протокол SIP унаследовал от него синтаксис и архитектуру «клиент-сервер», которую иллюстрирует рисунок 1.5.

Рисунок 1.5 Архитектура "клиент-сервер"

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

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

1.5.1 Терминал

В случае, когда клиент и сервер взаимодействуют непосредственно с пользователем (т.е. реализованы в оконечном оборудовании пользователя), они называются, соответственно, клиентом агента пользователя - User Agent Client (UAC) - и сервером агента пользователя - User Agent Server (UAS).

Следует особо отметить, что сервер UAS и клиент UAC могут (но не обязаны) непосредственно взаимодействовать с пользователем, а другие клиенты и серверы SIP этого делать не могут. Если в устройстве присутствуют и сервер UAS, и клиент UAC, то оно называется агентом пользователя - User Agent (UA), а по своей сути представляет собой терминальное оборудование SIP.

Кроме терминалов определены два основных типа сетевых элементов SIP: прокси-сервер (proxy server) и сервер переадресации (redirect server).

1.5.2 Прокси-сервер

Прокси-сервер (от английского proxy - представитель) представляет интересы пользователя в сети. Он принимает запросы, обрабатывает их и, в зависимости от типа запроса, выполняет определенные действия. Это может быть поиск и вызов пользователя, маршрутизация запроса, предоставление услуг и т.д. Прокси-сервер состоит из клиентской и серверной частей, поэтому может принимать вызовы, инициировать собственные запросы и возвращать ответы. Прокси - сервер может быть физически совмещен с сервером определения местоположения (в этом случае он называется registrar) или существовать отдельно от этого сервера, но иметь возможность взаимодействовать с ним по протоколам LDAP (RFC 1777), rwhois (RFC 2167) и по любым другим протоколам.

Предусмотрено два типа прокси-серверов - с сохранением состояний (stateful) и без сохранения состояний (stateless).

Сервер первого типа хранит в памяти входящий запрос, который явился причиной генерации одного или нескольких исходящих запросов. Эти исходящие запросы сервер также запоминает. Все запросы хранятся в памяти сервера только до окончания транзакции, т.е. до получения ответов на запросы.

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

- использует протокол TCP для передачи сигнальной информации;

- работает в режиме многоадресной рассылки сигнальной информации;

- размножает запросы.

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

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

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

1.5.3 Сервер переадресации

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

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

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

1.5.4 Сообщения протокола SIP

Согласно архитектуре «клиент-сервер» все сообщения делятся на запросы, передаваемые от клиента к серверу, и на ответы сервера клиенту.

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

Все сообщения протокола SIP (запросы и ответы), представляют собой последовательности текстовых строк, закодированных в соответствии с документом RFC 2279. Структура и синтаксис сообщений SIP, как уже упоминалось ранее, идентичны используемым в протоколе HTTP. На рисунке 1.6 представлена структура сообщений протокола SIP.

Стартовая строка

Заголовки

Пустая строка

Тело сообщения

Рисунок 1.6 Структура сообщений протокола SIP

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

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

Сообщения протокола SIP могут содержать так называемое тело сообщения. В запросах АСК, INVITE и OPTIONS тело сообщения содержит описание сеансов связи, например, в формате протокола SDP. Запрос BYE тела сообщения не содержит, а ситуация с запросом REGISTER подлежит дальнейшему изучению. С ответами дело обстоит иначе: любые ответы могут содержать тело сообщения, но содержимое тела в них бывает разным.

1.5.5 Заголовки сообщений

В протоколе SIP определено четыре вида заголовков :

* Общие заголовки, присутствующие в запросах и ответах;

* Заголовки содержания, переносят информацию о размере тела сообщения или об источнике запроса (начинаются со слова «Content»);

* Заголовки запросов, передающие дополнительную информацию о запросе;

* Заголовки ответов, передающие дополнительную информацию об ответе.

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

Ниже представлены наиболее часто используемые заголовки.

Заголовок Call-ID - уникальный идентификатор сеанса связи или всех регистрации отдельного клиента, он подобен метке соединения (call reference) в сигнализации DSS-1. Значение идентификатору присваивает сторона, которая инициирует вызов. Заголовок Call-ID состоит из буквенно-числового значения и имени рабочей станции, которая присвоила значение этому идентификатору. Между ними должен стоять символ @, например, 2345call@rts.loniis.ru Возможна следующая ситуация: к одной мультимедийной конференции относятся несколько соединений, тогда все они будут иметь разные идентификаторы Call-ID.

Заголовок То - определяет адресата. Кроме SIP-адреса здесь может стоять параметр «tag» для идентификации конкретного терминала пользователя (например, домашнего, рабочего или сотового телефона) в том случае, когда все его терминалы зарегистрированы под одним адресом SIP URL. Запрос может множиться и достичь разных терминалов пользователя; чтобы их различать, необходимо иметь метку tag. Ее вставляет в заголовок терминальное оборудование вызванного пользователя при ответе на принятый запрос.

Если необходим визуальный вывод имени пользователя, например, на дисплей, то имя пользователя также размещается в поле То.

Заголовок From - идентифицирует отправителя запроса; по структуре аналогичен полю То.

Заголовок CSeq - уникальный идентификатор запроса, относящегося к одному соединению. Он служит для корреляции запроса с ответом на него. Заголовок состоит из двух частей: натурального числа из диапазона от 1 до 232 и типа запроса. Сервер должен проверять значение CSeq в каждом принимаемом запросе и считать запрос новым, если значение CSeq больше предыдущего. Пример заголовка: CSeq: 2 INVITE.

Заголовок Via служит для того, чтобы избежать ситуации, в которых запрос пойдет по замкнутому пути, а также для тех случаев, когда необходимо, чтобы запросы и ответы обязательно проходили по одному и тому же пути (например, в случае использования межсетевого экрана - firewall). Дело в том, что запрос может проходить через несколько прокси-сервером, каждый из которых принимает, обрабатывает и переправляет запрос к следующему прокси-серверу, и так до тех пор, пока запрос не достигнет адресата. Таким образом, в заголовке Via указывается весь путь, пройденный запросом: каждый прокси-сервер добавляет поле со своим адресом. При необходимости (например, чтобы обеспечить секретность) действительный адрес может скрываться.

Содержимое полей Via копируется из запросов в ответы на них, и каждый сервер, через который проходит ответ, удаляет поле Via со своим именем.

В заголовок Record-route прокси-сервер вписывает свой адрес - SIP URL, - если хочет, чтобы последующие запросы прошли через него.

Заголовок Content-Type определяет формат описания сеанса связи. Само описание сеанса, например, в формате протокола SDP, включается в тело сообщения.

Заголовок Content-Length указывает размер тела сообщения.

1.5.6 Запросы

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

Все запросы, с их кратким описанием, указаны в таблице 1.1.

Таблица 1.1 Запросы SIP

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

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

Запрос АСК подтверждает прием ответа на запрос INVITE. Следует отметить, что запрос АСК используется только совместно с запросом INVITE, т.е. этим сообщением оборудование вызывающего пользователя показывает, что оно получило окончательный ответ на свой запрос INVITE. В сообщении АСК может содержаться окончательное описание сеанса связи, передаваемое вызывающим пользователем.

Запрос CANCEL отменяет обработку ранее переданных запросов с теми же, что и в запросе CANCEL, значениями полей Call-ID, To, From и CSeq, но не влияет на те запросы, обработка которых уже завершена. Например, запрос CANCEL применяется тогда, когда прокси-сервер размножает запросы для поиска пользователя по нескольким направлениям и в одном из них его находит. Обработку запросов, разосланных во всех остальных направлениях, сервер отменяет при помощи сообщения CANCEL.

Запросом BYE оборудование вызываемого или вызывающего пользователя завершает соединение. Сторона, получившая запрос BYE, должна прекратить передачу речевой (мультимедийной) информации и подтвердить его выполнение ответом 200 ОК.

При помощи запроса типа REGISTER пользователь сообщает свое текущее местоположение. В этом сообщении содержатся следующие поля:

* Поле То содержит адресную информацию, которую надо сохранить или модифицировать на сервере;

* Поле From содержит адрес инициатора регистрации. Зарегистрировать пользователя может либо он сам, либо другое лицо, например, секретарь может зарегистрировать своего начальника;

* Поле Contact содержит новый адрес пользователя, по которому должны передаваться все дальнейшие запросы INVITE. Если в запросе REGISTER поле Contact отсутствует, то регистрация остается прежней. В случае отмены регистрации здесь помещается символ «*»;

* В поле Expires указывается время в секундах, в течение которого регистрация действительна. Если данное поле отсутствует, то по умолчанию назначается время - 1 час, после чего регистрация отменяется.

После испытаний протокола SIP в реальных сетях оказалось, что для решения ряда задач вышеуказанных шести типов запросов недостаточно . Поэтому возможно, что в протокол будут введены новые сообщения.

Завершив описание запросов протокола SIР, рассмотрим, в качестве примера, типичный запрос типа INVITE (рисунок 1.7).

Рисунок 1.7 Пример запроса INVITE

В этом примере пользователь Bell (a.g.bell@bell-tel.com) вызывает пользователя Watson (watson@bell-tel.com). Запрос передается к прокси-серверу (boston.bell-tel.com). В полях То и From перед адресом стоит запись, которую вызывающий пользователь желает вывести на дисплей вызываемого пользователя. В теле сообщения оборудование вызывающего пользователя указывает в формате протокола SDP, что оно может принимать в порту 3456 речевую информацию, упакованную в пакеты RTP и закодированную по одному из следующих алгоритмов кодирования: 0 - PCMU, 3 - GSM, 4 - G.723 и 5 - DVI4.

При передаче сообщений протокола SIP, упакованных в сигнальные сообщения протокола UDP, существует вероятность того, что размер запроса или ответа окажется больше максимально допустимого для данной сети, и произойдет фрагментация пакета. Чтобы избежать этого, используется сжатый формат имен основных заголовков, подобно тому, как это делается в протоколе SDP, более подробный список приведен таких заголовков в (Таблица 1.2).

Таблица 1.2 Сжатые имена заголовков

1.5.7 Ответы на запросы

После приема и интерпретации запроса, адресат (прокси-сервер) передает ответ на этот запрос. Содержание ответов бывает разным:

подтверждение установления соединения, передача запрошенной информации, сведения о неисправностях и т.д. Структуру ответов и их виды протокол SIP унаследовал от протокола HTTP .

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

Все ответы делятся на две группы: информационные и финальные. Информационные ответы показывают, что запрос находится в стадии обработки. Они кодируются трехзначным числом, начинающимся с единицы, - 1хх. Некоторые информационные ответы, например, 100 Trying, предназначены для установки на нуль таймеров, которые запускаются в оборудовании, передавшем запрос. Если к моменту срабатывания таймера ответ на запрос не получен, то считается, что этот запрос потерян и может (по усмотрению производителя) быть передан повторно. Один из распространенных ответов -180 Ringing; по назначению он идентичен сигналу «Контроль посылки вызова» в ТфОП и означает, что вызываемый пользователь получает сигнал о входящем вызове.

Финальные ответы кодируются трехзначными числами, начинающимися с цифр 2, 3, 4, 5 и 6. Они означают завершение обработки запроса и содержат, когда это нужно, результат обработки запроса. Назначение финальных ответов каждого типа рассматривается ниже.

Ответы 2хх означают, что запрос был успешно обработан. В настоящее время из всех ответов типа 2хх определен лишь один -200 ОК. Его значение зависит от того, на какой запрос он отвечает:

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

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

Ответы 5хх информируют о том, что запрос не может быть обработан из-за отказа сервера:

Ответы 6хх информируют о том, что соединение с вызываемым пользователем установить невозможно:

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