Глава 7

 

Протокол инициирования сеансов связи – SIP

 

7.1    Принципы протокола SIP

 

 

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

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

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

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

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

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

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

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

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

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

 

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

 

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

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

Рис. 7.1   Место протокола SIP в стеке протоколов TCP/IP

 

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

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

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

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

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

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

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

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

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

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

 

7.3   Адресация

 

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

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

•   имя@домен;

•   имя@хост;

•   имя@1Р-адрес;

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

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

Во второй части адреса указывается имя домена, рабочей стан­ции или шлюза. Для определения 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

 

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

 

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

 

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

 

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

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

 

7.4.1   Терминал

 

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

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

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

 

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

 

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

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

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

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

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

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

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

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

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

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

 

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

 

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

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

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

 

7.4.4   Сервер определения местоположения пользователей

 

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

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

Этот сервер может быть совмещен с прокси-сервером (в таком случае он называется registrar) или быть реализован отдельно от про­кси-сервера, но иметь возможность связываться с ним.

В RFC 2543 сервер определения местоположения представлен как отдельный сетевой элемент, но принципы его работы в этом доку­менте не регламентированы. Стоит обратить внимание на то, что вызывающ*' й пользователь, которому нужен текущий адрес вызывае­мого пользователя, не связывается с сервером определения место­положения напрямую. Эту функцию выполняют SIP-серверы при по­мощи протоколов LDAP (RFC 1777), rwhois (RFC 2167), или других протоколов.

 

7.4.5  Пример SIP-сети

 

Резюмируя все сказанное выше, отметим, что сети SIP строятся из элементов трех основных типов: терминалов, прокси-серверов и серверов переадресации. На рис. 7.3 приведен пример возмож­ного построения сети SIR

Стоит обратить внимание на то что, что SIP-серверы, представ­ленные на рис. 7.3, являются отдельными функциональными сете­выми элементами. Физически они могут быть реализованы на базе серверов локальной сети, которые, помимо выполнения своих ос­новных функций, будут также обрабатывать SIP-сообщения. Терми­налы же могут быть двух типов: персональный компьютер со звуко­вой платой и программным обеспечением SIP-клиента (UA) или SIP-телефон, подключающийся непосредственно к ЛВС Ethernet (SIP-телефоны, производимые компанией Cisco Systems, недавно появились на российском рынке). Таким образом, пользователь ло­кальной вычислительной сети передает все запросы к своему SIP-серверу, а тот обрабатывает их и обеспечивает установление со­единений. Путем программирования сервер можно настроить на раз­ные алгоритмы работы: он может обслуживать часть пользователей (например, руководство предприятия или особо важных лиц) по од­ним правилам, а другую часть - по иным. Возможно также, что сер­вер будет учитывать категорию и срочность вызовов, а также вести начисление платы за разговоры.

Структурная схема организации услуг SIP-сервера представлена на рисунке 7.4.

Рис. 7.4 Структурная схема организации услуг SIP-сервера

 

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

 

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

 

7.5.1   Структура сообщений

 

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

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

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

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

 

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

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

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

 

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

 

В протоколе SIP определено четыре вида заголовков (Таблица 7.1):

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

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

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

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

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

 

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

 

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

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

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

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

 

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

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

Например, запрос на своем пути обрабатывался двумя прокси-серверами: сначала сервером loniis.ru, потом sip.telecom.com. Тогда в запросе появятся следующие поля:

 

Via: SIP/2.0/UDP sip.telecom.com:5060;branch=721e418c4.1

Via: SIP/2.0/UDP loniis.ru:5060,

 

где параметр «branch» означает, что на сервере sip.telecom.com за­прос был размножен и направлен одновременно по разным направ­лениям, и наш запрос был передан по направлению, которое иден­тифицируется следующим образом: 721 е418с4.1.

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

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

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

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

После того, как мы рассмотрели наиболее часто встречающиеся заголовки сообщений протокола SIP, следует обратить внимание на то, что запросы и ответы на них могут включать в себя лишь опреде­ленный набор заголовков (Таблица 7.2). Здесь опять буква «М» озна­чает обязательное присутствие заголовка в сообщении, буква «О» -необязательное присутствие, буква «F» запрещает присутствие за­головка.

 

7.5.3  Запросы

 

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

Запрос 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 час, после чего регистрация  отменяется. Регистрацию можно также отменить, передав сооб­щение REGISTER с полем Expires, которому присвоено значение 0и с соответствующим полем Contact.

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

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

•   для переноса сигнальных сообщений ТфОП/ISDN/coтовых сетей между шлюзами в течение разговорной сессии;

•   для переноса сигналов DTMF в течение разговорной сессии;

•   для переноса биллинговой информации.

Завершив описание запросов протокола SIP, рассмотрим, в каче­стве примера, типичный запрос типа INVITE (рис. 7.6).

Рис. 7.6  Пример запроса 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.

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

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

При написании имен заголовков в сжатом виде сообщение INVITE, показанное ранее на рисунке 6, будет выглядеть следующим обра­зом (рис. 7.7):

Рис. 7.7  Пример запроса INVITE с сокращенными заголовками

 

В заключение параграфа, как и в предыдущих главах, сведем все запросы, с их кратким описанием, в таблицу 7.4.

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

 

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

 

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

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

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

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

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

•   ответ 200 ОК на запрос INVITE означает, что вызываемое обору­дование согласно на участие в сеансе связи; в теле ответа указы­ваются функциональные возможности этого оборудования;

•   ответ 200 ОК на запрос BYE означает завершение сеанса связи, в теле ответа никакой информации не содержится;

•   ответ 200 ОК на запрос CANCEL означает отмену поиска, в теле ответа никакой информации не содержится;

•   ответ 200 ОК на запрос REGISTER означает, что регистрация про­шла успешно;

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

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

•   в ответе 300 Multiple Choices указывается несколько SIP-адресов, по которым можно найти вызываемого пользователя, и вы­зывающему пользователю предлагается выбрать один из них;

•   ответ 301 Moved Permanently означает, что вызываемый поль­зователь больше не находится по адресу, указанному в запросе, и направлять запросы нужно на адрес, указанный в поле Contact;

•   ответ 302 Moved Temporary означает, что пользователь времен­но (промежуток времени может быть указан в поле Expires) нахо­дится по другому адресу, который указывается в поле Contact.

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

•   ответ 400 Bad Request означает, что запрос не понят из-за нали­чия в нем синтаксических ошибок;

•   ответ 401 Unauthorized означает, что запрос требует проведе­ния процедуры аутентификации пользователя. Существуют раз­ные варианты аутентификации, и в ответе может быть указано, какой из них использовать в данном случае;

•   ответ 403 Forbidden означает, что сервер понял запрос, но отка­зался его обслуживать. Повторный запрос посылать не следует. Причины могут быть разными, например, запросы с этого адреса не обслуживаются и т.д.;

•   ответ 485 Ambiguous означает, что адрес в запросе не определя­ет вызываемого пользователя однозначно;

•   ответ 486 Busy Here означает, что вызываемый пользователь в на­стоящий момент не может принять входящий вызов по данному адресу. Ответ не исключает возможности связаться с пользова­телем по другому адресу или, к примеру, оставить сообщение в ре­чевом почтовом ящике.

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

•   ответ S00 Server Internal Error означает, что сервер не имеет возможности обслужить запрос из-за внутренней ошибки. Кли­ент может попытаться повторно послать запрос через некото­рое время;

•   ответ 501 Not Implemented означает, что в сервере не реализо­ваны функции, необходимые для обслуживания этого запроса. Ответ передается, например в том случае, когда сервер не может распознать тип запроса;

•   ответ 502 Bad Gateway информирует о том, что сервер, функ­ционирующий в качестве шлюза или прокси-сервера, принял не­корректный ответ от сервера, к которому он направил запрос;

•   ответ 503 Service Unavailable говорит от том, что сервер не мо­жет в данный момент обслужить вызов вследствие перегрузки или проведения технического обслуживания.

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

•   ответ 600 Busy Everywhere сообщает, что вызываемый пользо­ватель занят и не может принять вызов в данный момент ни по одному из имеющихся у него адресов. Ответ может указывать вре­мя, подходящее для вызова пользователя;

•   ответ 603 Decline означает, что вызываемый пользователь не может или не желает принять входящий вызов. В ответе может быть указано подходящее для вызова время;

•   ответ 604 Does Not Exist Anywhere означает, что вызываемого пользователя не существует.

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

На рисунке 7.8 представлен пример ответа на запрос INVITE.

Рис. 7.8  Пример SIP-ответа 200 ОК

 

В этом примере приведен ответ пользователя Watson на пригла­шение принять участие в сеансе связи, полученное от пользователя Bell. Наиболее вероятный формат приглашения рассмотрен нами ранее (рис. 7.7). Вызываемая сторона информирует вызывающую о том, что она может принимать в порту 5004 речевую информацию, закодированную в соответствии с алгоритмами кодирования PCMU, GSM, Поля From, To, Via, Call-ID взяты из запроса, показанного на рисунке 7.7. Из примера видно, что это ответ на запрос INVITE с по­лем CSeq:1.

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

 

7.6   Алгоритмы установления соединения

 

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

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

 

7.6.1  Установление соединения с участием сервера переадресации

 

В этом параграфе описан алгоритм установления соединения с участием сервера переадресации вызовов. Администратор сети со­общает пользователям адрес сервера переадресации. Вызывающий пользователь передает запрос INVITE (1) на известный ему адрес сервера переадресации и порт 5060, используемый по умолчанию (Рисунок 7.9). В запросе вызывающий пользователь указывает ад­рес вызываемого пользователя. Сервер переадресации запрашивает текущий адрес нужного пользователя у сервера определения место­положения (2), который сообщает ему этот адрес (3). Сервер пере­адресации в ответе 302 Moved temporarily передает вызывающей стороне текущий адрес вызываемого пользователя (4), или он мо­жет сообщить список зарегистрированных адресов вызываемого пользователя и предложить вызывающему пользователю самому вы­брать один из них. Вызывающая сторона подтверждает прием отве­та 302 посылкой сообщения АСК (5).

Рис. 7.9  Сценарий установления соединения через сервер переадресации

 

Теперь вызывающая сторона может связаться непосредственно с вызываемой стороной. Для этого она передает новый запрос INVITE (6) с тем же идентификатором Call-ID, но другим номером CSeq. В теле сообщения INVITE указываются данные о функциональ­ных возможностях вызывающей стороны в формате протокола SDR Вызываемая сторона принимает запрос INVITE и начинает его обра­ботку, о чем сообщает ответом 100 Trying (7) встречному оборудо­ванию для перезапуска его таймеров. После завершения обработки поступившего запроса оборудование вызываемой стороны сообщает своему пользователю о входящем вызове, а встречной стороне пе­редает ответ 180 Ringing (8). После приема вызываемым пользова­телем входящего вызова удаленной стороне передается сообщение 200 ОК (9), в котором содержатся данные о функциональных воз­можностях вызываемого терминала в формате протокола SDP. Тер­минал вызывающего пользователя подтверждает прием ответа за­просом АСК (10). На этом фаза установления соединения закончена и начинается разговорная фаза.

По завершении разговорной фазы любой из сторон передается запрос BYE (11), который подтверждается ответом 200 ОК (12).

 

7.6.2. Установление соединения с участием прокси-сервера

 

В этом параграфе описан алгоритм установления соединения с участием прокси-сервера. Администратор сети сообщает адрес

этого сервера пользователям. Вызывающий пользователь передает запрос INVITE (1) на адрес прокси-сервера и порт 5060, используе­мый по умолчанию (Рисунок 7.10). В запросе пользователь указыва­ет известный ему адрес вызываемого пользователя. Прокси-сервер запрашивает текущий адрес вызываемого пользователя у сервера определения местоположения (2), который и сообщает ему этот ад­рес (3). Далее прокси-сервер передает запрос INVITE непосредст­венно вызываемому оборудованию (4). Опять в запросе содержатся данные о функциональных возможностях вызывающего терминала, но при этом в запрос добавляется поле Via с адресом прокси-серве­ра для того, чтобы ответы на обратном пути шли через него. После приема и обработки запроса вызываемое оборудование сообщает своему пользователю о входящем вызове, а встречной стороне пе­редает ответ 180 Ringing (5), копируя в него из запроса поля То, From, Call-ID, CSeq и Via. После приема вызова пользователем встречной стороне передается сообщение 200 ОК (6), содержащее данные о функциональных возможностях вызываемого терминала в формате протокола SDP. Терминал вызывающего пользователя под­тверждает прием ответа запросом АСК (7). На этом фаза установле­ния соединения закончена и начинается разговорная фаза.

По завершении разговорной фазы одной из сторон передается запрос BYE (8), который подтверждается ответом 200 ОК (9).

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

7.7    Реализация дополнительных услуг на базе протокола SIP

 

В этом параграфе рассматриваются примеры реализация допол­нительных услуг на базе протокола SIR

Дополнительная услуга «Переключение связи» позволяет пользо­вателю переключить установленное соединение к третьей стороне. На рисунке 7.11 приведен пример реализации этой услуги. Пользователь В устанавливает связь с пользователем А, который, переговорив с В, переключает эту связь к пользователю С, а сам отключается.

Рис. 7.11   Дополнительная услуга "Переключение связи"

 

Дополнительная услуга «Переадресация вызова» позволяет поль­зователю назначить адрес, на который, при определенных условиях, следует направлять входящие к нему вызовы. Такими условиями мо­гут быть занятость пользователя, отсутствие его ответа в течение заданного времени или и то, и другое; возможна также безусловная переадресация. Оборудование пользователя, заказавшего эту услу­гу, получив сообщение INVITE В, проверяет условия, в которых оно получено, и если условия требуют переадресации, передает сооб­щение INVITE с заголовком Also, указывая в нем адрес пользовате­ля, к которому следует направить вызов. Терминал вызывающего пользователя, получив сообщение INVITE с таким заголовком, ини­циирует новый вызов по адресу, указанному в поле Also. В нашем случае пользователь А вызывает пользователя В, а терминал послед­него переадресует вызов к пользователю С (Рисунок 7.12).

Дополнительная услуга «Уведомление о вызове во время связи» позволяет пользователю, участвующему в телефонном разговоре, получить уведомление о том, что к нему поступил входящий вызов (Рисунок7.13).

Рис. 7.13  Дополнительная услуга "Уведомление о вызове во время связи"

 

Услуга реализуется с помощью заголовка Call-Disposition, в ко­тором содержится инструкция по обслуживанию вызова. Вызываю­щий пользователь передает запрос INVITE с заголовком Call-Dispo­sition: Queue, который интерпретируется следующим образом: вы­зывающий пользователь хочет, чтобы вызов был поставлен в очередь, если вызываемый пользователь будет занят. Вызываемая сторона подтверждает исполнение запроса ответом 182 Queued, который может передаваться неоднократно в течение периода ожидания. Вызываемый пользователь получает уведомление о входящем вы­зове, а когда он освобождается, вызывающей стороне передается финальный ответ 200 ОК.

 

7.8   Сравнительный анализ протоколов Н.323 и SIP

 

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

И последнее. Оба протокола являются результатом решения од­них и тех же задач специалистами ITU-T и комитета IETF. Естествен­но, что решение ITU-T оказалось ближе к традиционным телефон­ным сетям, а решение комитета IETF базируется на принципах, со­ставляющих основу сети Internet.

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

Дополнительные услуги. Набор услуг, поддерживаемых обои­ми протоколами, примерно одинаков.

Дополнительные услуги, предоставляемые протоколом Н.323, стан­дартизированы в серии рекомендаций ITU-T H.450.x. Протоколом SIP правила предоставления дополнительных услуг не определены, что является его серьезным недостатком, так как вызывает проблемы при организации взаимодействия оборудования разных фирм-произво­дителей. Некоторые специалисты предлагают решения названных проблем, но эти решения пока не стандартизированы.

Примеры услуг, предоставляемых обоими протоколами:

•   Перевод соединения в режим удержания (Call hold);

•   Переключение связи (Call Transfer);

•   Переадресация (Call Forwarding);

•   Уведомление о новом вызове во время связи (Call Waiting);

•    Конференция.

Рассмотрим последнюю услугу несколько более подробно. Прото­кол SIP предусматривает три способа организации конференции: с ис­пользованием устройства управления конференциями MCU, режима многоадресной рассылки и соединений участников друг с другом. В последних двух случаях функции управления конференциями могут быть распределены между терминалами, т.е. центральный контрол­лер конференций не нужен. Это позволяет организовывать конферен­ции с практически неограниченным количеством участников.

Рекомендация Н.323 предусматривает те же три способа, но управление конференцией во всех случаях производится централи­зованно контроллером конференций МС (Multipoint Controller), ко­торый обрабатывает все сигнальные сообщения. Поэтому для орга­низации конференции, во-первых, необходимо наличие контролле­ра МС у одного из терминалов, во-вторых, участник с активным кон­троллером МС не может выйти из конференции. Кроме того, при большом числе участников конференции МС может стать «узким ме­стом». Правда, в третьей версии рекомендации ITU-T Н.323 принято положение о каскадном соединении контроллеров, однако произво­дители эту версию в своем оборудовании пока не реализовали. Пре­имуществом протокола Н.323 в части организации конференций яв­ляются более мощные средства контроля конференций.

Протокол SIP изначально ориентирован на использование в IP-се­тях с поддержкой режима многоадресной рассылки информации (примером может служить сеть Mbone, имеющая тысячи постоянных пользователей). Этот механизм используется в протоколе S1P не только для доставки речевой информации (как в протоколе Н.323), ной для переноса сигнальных сообщений. Например, в режиме многоадресной рассылки может передаваться сообщение INVITE, что облегчает определение местоположения пользователя и является очень удобным для центров обслуживания вызовов (Call-center) при организации групповых оповещений.

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

Протокол SIP предусматривает возможность организации связи третьей стороной (third-party call control). Эта функция позволяет реализовать такие услуги, как набор номера секретарем для менед­жера и сопровождение вызова оператором центра обслуживания вызовов. Подобные услуги предусмотрены и протоколом Н.323, но реализация их несколько сложнее.

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

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

Расширяемость протокола. Необходимой и важной в условиях эволюционирующего рынка является возможность введения новых версий протоколов и обеспечение совместимости различных версий одного протокола. Расширяемость (extensibility) протокола обеспе­чивается:

-   согласованием параметров;

-   стандартизацией кодеков;

-   модульностью архитектуры.

Протокол SIP достаточно просто обеспечивает совместимость разных версий. Поля, которые не понятны оборудованию, просто игнорируются. Это уменьшает сложность протокола, а также облег­чает обработку сообщений и внедрение новых услуг. Клиент может запросить какую-либо услугу с помощью заголовка Require. Сервер, получивший запрос с таким заголовком, проверяет, поддерживает ли он эту услугу, и если не поддерживает, то сообщает об этом в сво­ем ответе, содержащем список поддерживаемых услуг

В случае необходимости, в организации IANA (Internet Assigned Numbers Authority) могут быть зарегистрированы новые заголовки. Для регистрации в IANA отправляется запрос с именем заголовка и его назначением. Название заголовка выбирается таким образом, чтобы оно говорило об его назначении. Указанным образом разра­ботчик может внедрять новые услуги.

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

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

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

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

В протоколе Н.323 все кодеки должны быть стандартизированы. Поэтому приложения с нестандартными алгоритмами кодирования могут столкнуться с проблемами при реализации их на базе прото­кола Н.323.

Протокол SIP состоит из набора законченных компонентов (мо­дулей), которые могут заменяться в зависимости от требований и мо­гут работать независимо друг от друга. Этот набор включает в себя  модули поддержки сигнализации для базового соединения, для ре­гистрации и для определения местоположения пользователя, кото­рые не зависят от модулей поддержки качества обслуживания (QoS), работы с директориями, описания сеансов связи, развертывания услуг (service discovery) и управления конфигурацией.

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

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

Необходимо также иметь в виду зоновую архитектуру сети Н.323, позволяющую обеспечить расширяемость сети путем увеличения количества зон.

Время установления соединения. Следующей существенной характеристикой протоколов является время, которое требуется, чтобы установить соединение. В запросе INVITE протокола SIP со­держится вся необходимая для установления соединения информа­ция, включая описание функциональных возможностей терминала. Таким образом, в протоколе SIP для установления соединения тре­буется одна транзакция, а в протоколе Н.323 необходимо произво­дить обмен сообщениями несколько раз. По этим причинам затраты времени на установление соединения в протоколе SIP значительно меньше затрат времени в протоколе Н.323. Правда, при использо­вании инкапсуляции сообщений Н.245 в сообщения Н.225 или про­цедуры Fast Connect время установления соединения значительно уменьшается.

Кроме того, на время установления соединения влияет также и ни­жележащий транспортный протокол, переносящий сигнальную ин­формацию. Ранние версии протокола Н.323 предусматривали ис­пользование для переноса сигнальных сообщений Н.225 и Н.245 толь­ко протокол TCP, и лишь третья версия протокола предусматривает возможность использования протокола UDP. Протоколом SIP исполь­зование протоколов TCP и UDP предусматривалось с самого начала.

Оценка времени установления соединения производится в услов­ных единицах - RTT (round trip time) - и составляет для протокола SIP 1,5 + 2,5 RTT, а для протокола Н.323 6-7 RTT.

Адресация. К числу системных характеристик, несомненно, от­носится и предусматриваемая протоколами адресация. Использо­вание URL является сильной стороной протокола SIP и позволяет легко интегрировать его в существующую систему DNS-серверов и внедрять в оборудование, работающее в IP-сетях. Пользователь по­лучает возможность переправлять вызовы на Web-страницы или ис­пользовать электронную почту. Адресом в SIP может также служить телефонный номер с адресом используемого шлюза.

В протоколе Н.323 используются транспортные адреса и alias-ад­реса. В качестве последнего может использоваться телефонный но­мер, имя пользователя или адрес электронной почты. Для преобра­зования alias-адреса в транспортный адрес обязательно участие при­вратника.

Сложность протокола. Протокол Н.323, несомненно, сложнее протокола SIR Общий объем спецификаций протокола Н.323 состав­ляет примерно 700 страниц. Объем спецификаций протокола SIP составляет 150 страниц. Протокол Н.323 использует большое коли­чество информационных полей в сообщениях (до 100), при несколь­ких десятках таких же полей в протоколе SIP. При этом для организа­ции базового соединения в протоколе SIP достаточно использовать всего три типа запросов (INVITE, BYE и АСК) и несколько полей (То, From, Call-ID, CSeq).

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

Протокол Н.323 использует двоичное представление своих сооб­щений на базе языка ASN.1, поэтому их непосредственное чтение затруднительно. Для кодирования и декодирования сообщений не­обходимо использовать компилятор ASN.1. Но, в то же время, обра­ботка сообщений, представленных в двоичном виде, производится быстрее.

Довольно сложным представляется взаимодействие протокола Н.323 с межсетевым экраном (firewall). Кроме того, в протоколе Н.323 существует дублирование функций. Так, например, оба протокола Н.245 и RTCP имеют средства управления конференцией и осущест­вления обратной связи.

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

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

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

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

 

Таблица 7.6 Алгоритм установления соединения с участием шлюза H.323/SIP

 

Если в течение разговорной фазы оборудованию Н.323 необхо­димо открыть новые логические каналы, шлюз передает новое сооб­щение INVITE терминалу SIP, как это показано в таблице 7.7.

 

Таблица 7.7  Открытие новых логических каналов

 

Глава 8

 

Протокол управления шлюзами MGCP

 

8.1 Принцип декомпозиции шлюза

 

В недавнем прошлом рабочая группа MEGACO комитета IETF раз­работала протокол управления шлюзами - Media Gateway Control Pro­tocol (MGCP). Ранее подобный протокол под названием SGCP - Sim­ple Gateway Control Protocol (простой протокол управления шлюза­ми) - был разработан компанией Telecordia (бывшая компания Bellcore). Фирма Level 3 предложила сходный протокол управления оборудованием, реализующим технологию маршрутизации пакетов IP, - ЮСР (IP Device Control Protocol). Оба они впоследствии были объединены в протокол MGCP.

При разработке протокола управления шлюзами рабочая группа MEGACO опиралась на принцип декомпозиции, согласно которому шлюз разбивается на отдельные функциональные блоки (рис. 8.1):

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

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

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

Рис. 8.1   Архитектура сети, базирующейся на протоколе MGCP

 

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

Перенос сообщений протокола MGCP обеспечивает протокол негарантированной доставки - UDP. Кроме того, рабочая группа SIGTRAN комитета IETF в настоящее время разрабатывает механизм взаимодействия устройства управления и шлюза сигнализации. По­следний должен принимать поступающие из ТфОП сигнальные еди­ницы подсистемы МТР системы сигнализации ОКС7 и передавать сигнальные сообщения верхнего, пользовательского уровня к уст­ройству управления. Основное внимание рабочей группы SIGTRAN уделено вопросам разработки наиболее эффективного механизма передачи сигнальной информации по IP-сетям. Следует отметить, что существует несколько причин, уже упонинавшихся ранее, по которым пришлось отказаться от использования для этой цели протокола TCP. Вместо него рабочая группа SIGTRAN предлагает использовать про­токол Stream Control Transport Protocol (SCTP), который имеет ряд преимуществ перед протоколом TCP. Основным из этих преимуществ является значительное снижение времени доставки сигнальной ин­формации и, следовательно, времени установления соединения -одного из важнейших параметров качества обслуживания.

Рис. 8.2  Синхронизация работы устройств управления

 

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

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

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

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

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

Рис. 8.3  Управление терминалами в сети, базирующейся на протоколе MGCP

 

8.2   Классификация шлюзов

 

Рабочей группой MEGACO предложена следующая классифика­ция транспортных шлюзов (Media Gateways):

•   Trunking Gateway - шлюз между ТфОП и сетью с маршрутизацией пакетов IP, ориентированный на подключение к телефонной сети посредством большого количества цифровых трактов (от 10 до не­скольких тысяч) с использованием системы сигнализации ОКС 7;

•   Voice over ATM Gateway - шлюз между ТфОП и ATM-сетью, кото­рый также подключается к телефонной сети посредством боль­шого количества цифровых трактов (от 10 до нескольких тысяч);

•   Residential Gateway- шлюз, подключающий к IP-сети аналоговые, кабельные модемы, линии xDSL и широкополосные устройства беспроводного доступа;

•   Access Gateway- шлюз для подключения к сети IP-телефонии не­большой учрежденческой АТС через аналоговый или цифровой интерфейс;

•   Business Gateway - шлюз с цифровым интерфейсом для подклю­чения к сети с маршрутизацией IP-пакетов учрежденческой АТС при использовании, например, системы сигнализации DSS1;

•   Network Access Server - сервер доступа к IP-сети для передачи

данных;

•   Circuit switch или packet switch- коммутационные устройства с ин­терфейсом для управления от внешнего устройства.  

 

8.3. Модель организации связи

 

Для описания процесса обслуживания вызова с использованием протокола MGCP рабочей группой MEGACO разработана модель ор­ганизации соединения - Connection model. Базой модели являются компоненты двух основных видов: порты (Endpoints) и подключения (Connections).

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

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

На рисунке 8.4 представлены примеры использования этих двух компонентов. Отметим, что порты некоторых видов могут участво­вать в нескольких соединениях одновременно.

Рис. 8.4  Примеры использования компонентов модели

 

Подключения создаются устройством управления Call Agent для каждого порта, участвующего в соединении. На рисунке 8.5 показа­на ситуация, когда одно устройство управления контролирует работу двух портов разных шлюзов при организации соединения между этими портами.

Рис. 8.5  Соединение в сети, построенной на базе протокола MGCP

 

8.4   Команды протокола MGCP

 

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

При помощи команды EndpointConfiguration устройство управле­ния инструктирует шлюз, каким образом он должен обрабатывать получаемые речевые сигналы, например, использовать для преоб­разования цифрового сигнала в аналоговую форму закон А или за­кон μ.

 

Команда EndpointConfiguration содержит ряд параметров:

где Endpointld - идентификатор порта шлюза, к которому относится данная команда;

Bearerlnformation - параметр, определяющий закон (А или ц) де­кодирования принятой речевой информации.

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

Call Agent при помощи команды Notification Request может дать ука­зание шлюзу выявлять определенные события или сигналы и инфор­мировать о них устройство управления. В число детектируемых собы­тий (сигналов) входит изменение сопротивления абонентского шлей­фа, происходящее, когда абонент поднимает иликладет трубку, атак-же получение сигналов факсимильных аппаратов и сигналов DTMF.

Команда NotificationRequest включает в себя следующие парамет­ры (в квадратных скобках указаны те из них, которые не являются обя­зательными).

Здесь NotifiedEntity - идентификатор устройства, которому дол­жен быть передан ответ на команду. При отсутствии этого парамет­ра ответ передается тому устройству, от которого получен запрос NotificationRequest.

RequestedEvents - список событий, о которых следует оповестить управляющее устройство. Кроме того, в этом параметре может быть указано, как шлюз должен реагировать на событие. Определены сле­дующие действия шлюза: оповестить Call Agent о событии немедлен­но; ожидать дальнейших событий; если событие состоит в получе­нии сигнала DTMF, то накапливать такие сигналы в соответствии с требованиями параметра DigitMap; в определенных ситуациях пе­редавать в телефонный канал акустические или вызывные сигналы; обработать инкапсулированную команду EndpointConfiguration; игно­рировать событие и т.д.

Requestldentifier - идентификатор запроса, в ответ на который передается команда.

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

SignalRequests - сигналы, которые должны быть переданы в ка­нал, например, сигнал посылки вызова.

QuarantineHandling - необязательный параметр, определяющий правила обработки событий, которые были обнаружены до момента получения данной команды в период так называемого карантина (quarantine period) и о которых Call Agent еще не был оповещен.

DetectEvents - необязательный параметр, определяющий собы­тия, которые нужно выявить в период карантина, но не оповещать о них Call Agent до получения следующей команды NotificationRequest с включенным в нее параметром QuarantineHandling.

Encapsulated EndpointConfiguration - команда EndpointConfigura­tion, инкапсулированная в команду NotificationRequest.

Остальные параметры команды тождественны описанным выше.

При помощи команды Notify шлюз информирует устройство управления о том, что произошло событие из числа указанных в ко­манде NotificationRequest. Команда Notify содержит следующие па­раметры:

Здесь ObservedEvents - параметр, в котором описываются про­изошедшие события, например, передаются набранные цифры но­мера. Остальные параметры были описаны ранее.

При помощи команды CreateConnection управляющее устройст­во может дать шлюзу указание создать соединение двух портов од­ного и того же шлюза или разных шлюзов.

Структура этой команды приведена ниже.

Callld - уникальный параметр, идентифицирующий сессию, к ко­торой относится данное соединение.

NotifiedEntity - необязательный параметр, идентифицирующий устройство, к которому должны быть переданы команды Notify или DeleteConnection.

LocalConnectionOptions - параметр, используемый Call Agent, что­бы дать шлюзу указания в отношении характеристик подключения порта к соединению. В параметр могут входить следующие поля; метод кодирования, размер речевых пакетов, полоса пропускания, тип обслуживания, использование эхокомпенсатора, использование режима подавления пауз в разговоре, использование режима подав­ления шума, использование резервирования ресурсов и другие поля. Кодирование трех первых полей должно производиться в соответ­ствии с протоколом описания сессий SDP (Session Description Proto­col), причем Call Agent может указать только полосу пропускания и ос­тавить за шлюзом право выбора метода кодирования и размеров ре­чевых пакетов.

Mode - параметр, определяющий режим работы для данного кон­ца соединения. Определены следующие режимы: передача, прием, прием/передача, конференция, данные, отсутствие активности, пет­ля, тестовый режим и другие. RemoteConnectionDescriptor - описание подключения к соедине­нию на другом его конце. Данный параметр содержит те же поля, что и параметр LocalConnectionOptions. Эти поля также должны кодиро­ваться в соответствии с протоколом SDR Стоит отметить, что при создании соединения между двумя шлюзами, при передаче первой команды CreateConnection параметр RemoteConnectionDescriptor отсутствует (ему присваивается нулевое значение), так как инфор­мация о подключении к соединению на другом его конце в этот мо­мент отсутствует. Не имея такой информации, т.е. не получив коман­ду ModifyConnection, шлюз может только принимать информацию (работать в режиме receive only).

Second En dpointlci - этот параметр может включаться в команду CreateConnection вместо параметра RemoteConnectionDescriptor при установлении соединения между двумя портами одного и того же шлюза.

Encapsulated NotificationRequest - инкапсулированная команда NotificationRequest.

В ответ на команду CreateConnection, кроме описанного выше параметра ReturnCode, шлюз возвращает следующие параметры:

Connectionld - уникальный идентификатор подключения данного порта к соединению.

SpecificEndPointld - необязательный параметр, идентифицирую­щий порт, который отвечает на команду CreateConnection, если он не

был специфицирован устройством управления.

LocalConnectionDescriptor - параметр, содержащий информацию об IP-адресе и номере порта RTP в соответствии с протоколом SDR

SecondEndPointld - параметр, означающий, что команда Create­Connection создала два соединения.

SecondConnectionld - идентификатор подключения для второго соединения,

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

Здесь используются такие же параметры, как и в команде Create­Connection, но добавляется обязательный параметр Connectionld, оторый идентифицирует подключение к соединению данного пор­та оборудования, так как один порт может одновременно иметь под­ключения к нескольким соединениям.

Данная команда может использоваться для передачи информа­ции о другом конце соединения в параметре RemoteConnectionDe­scriptor, для активизации/деактивизации соединения при помощи параметра Mode, для изменения алгоритма кодирования, периода пакетизации передаваемой информации или для управления подав­лением эха.

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

Если параметры соединения на ближнем конце были изменены, например, был изменен номер порта RTP, то в ответе на команду ModifyConnection может возвращаться параметр LocalConnection­Descriptor.

Устройство управления может разрушить существующее соеди­нение при помощи команды DeteteConnection. Кроме того, при по­мощи этой команды шлюз может передать к Call Agent индикацию того, что существующее соединение больше поддерживаться не может.

Команда DeleteConnection, передаваемая устройством управле­ния, имеет следующий вид:

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

В общем случае, команда DeleteConnection передается обоим шлюзам, подключенным к соединению. После завершения соеди­нения в ответ на команду DeleteConnection шлюз возвращает ста­тистические данные, собранные за время соединения - connection-parameters:

•   количество переданных RTP-пакетов,

•   количество переданных байтов информации, не считая служеб­ной информации (заголовков IP/UDP/RTP),

•   количество полученных RTP-пакетов,

•   количество принятых байтов информации, не считая служебной информации (заголовков IP/UDP/RTP),

•   количество потерянных RTP-пакетов,

•   вариация времени между поступлениями RTP-пакетов,

•   средняя задержка RTP-пакетов.

В некоторых случаях, таких как неисправность порта, участвую­щего в соединении, или отсутствие ресурсов для поддержания су­ществующего соединения, шлюз должен сам инициировать разру­шение соединения при помощи команды DeleteConnection, которая имеет следующий вид:

 

В параметре Reason-code указывается причина, по которой шлюз передает данное сообщение. Остальные параметры были описаны ранее.

Чтобы получить информацию о статусе какого-либо порта шлю­за, управляющее устройство может передать запрос Audit EndPoint, который имеет следующий вид:

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

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

SignalRequests - необязательный параметр, в котором указыва­ется список сигналов, обрабатываемых в настоящий момент;

Observed Events - необязательный параметр, в котором приводит­ся текущий список обнаруженных событий;

RestartReason - необязательный параметр, в котором содержит­ся причина рестарта порта, указанная в последней переданной шлю­зом команде RestartlnProgress;

RestartDelay - необязательный параметр, в котором содержится величина задержки рестарта, указанная в последней переданной шлюзом команде RestartlnProgress;

Capabilities - необязательный параметр, содержащий такую же информацию, как и параметр LocalConnectionOptions.

При помощи команды AuditConnection устройство управления за­прашивает параметры соединения, в котором участвует порт шлюза.

Команда имеет следующий вид:

Все параметры команды уже были описаны ранее. Если никакой информации не требуется и указанный порт существует, то шлюз проверяет, что соединение существует, и возвращает подтвержде­ние.

Команда RestartlnProgress передается шлюзом для индикации того, что один или группа портов выводятся из рабочего состояния или возвращаются в рабочее состояние. Данная команда имеет сле­дующий вид:

 

Параметр RestartMethod специфицирует вид рестарта. Опреде­лено несколько видов рестарта:

•   Graceful restart - постепенный рестарт, при котором порты обору­дования выводятся из обслуживания после определенной задержки. Установленные соединения не разрушаются, но и новые не создаются.

•    Forced restart - принудительный рестарт, при котором разруша­ются установленные соединения.

•   Restart - рестарт, при котором порт оборудования возвращается в обслуживание после определенной задержки. При этом порт в момент рестарта не участвует ни в каких соединениях.

•   Disconnected -данное значение присваивается параметру Restart-Method, когда порт находился вне обслуживания, но в данный мо­мент пытается вернуться в обслуживание.

•   Cancel-graceful - данное значение присваивается параметру RestartMethod, когда шлюз отменяет предшествовавшую команду Restart с параметром RestartMethod, которому было присвоено значение Graceful.

Параметр RestartDelay определяет задержку рестарта в секундах.

По аналогии с предыдущими главами в таблицу 8.1 сведены все команды протокола MGCP.

Таблица 8.1   Команды протокола MGCP

 

8.5   Структура команд

Команда протокола MGCP обязательно содержит заголовок, за которым может следовать описание сеанса связи (session descrip­tion). Заголовок команды и описание сеанса связи представляют со­бой набор текстовых строк. Описание сеанса отделено от заголовка команды пустой строкой.

Заголовок содержит список параметров и командную строку вида CRCX 1204 ts/l@protei.loniis.net MGCP 0.1. Командная строка, в свою очередь, состоит из нескольких информационных полей:

1.                Название команды представлено в виде кода из четырех букв (табл.8.2)

 

Таблица 8.2  Кодировка команд протокола MGCP

 

 

2.  Идентификатор транзакции. Протокол MGCP предусматривает корреляцию команд и ответов. Команда и ответ на нее образуют транзакцию, имеющую уникальный идентификатор (Transaction-Identifier). Идентификатор транзакции включается в заголовок и команды, и ответа. Значения идентификаторов выбираются из диапазона чисел 1 -999999999, причем значение идентификато­ра текущей транзакции на единицу больше идентификатора пре­дыдущей транзакции.

3.  Идентификатор порта определяет тот порт шлюза, которому над­лежит выполнить команду, за исключением команд Notify и Re-tartlnProgress, в которых идентификатор определяет порт, пе­редавший команду. Идентификаторы портов кодируются также, как кодируются адреса электронной почты в соответствии с до­кументом RFC 821 комитета IETF. Например, возможен иденти­фикатор ts/1@protei.loniis.net, который идентифицирует первый порт (временной канал) шлюза «protei», расположенного в доме­не loniis.

4.   Версия протокола кодируется следующим образом:   MGCP 1.0.

Выше указывалось, что заголовок команды, кроме командной строки, содержит список параметров. Параметры команд протоко­ла MGCP сведены в таблицу 8.3.

 

Таблица 8.3  Параметры команд протокола MGCP

Не все параметры, приведенные в таблице 8,3, должны обязатель­но присутствовать во всех командах протокола MGCP. В таблице 8.4 представлены возможные комбинации параметров в командах про­токола MGCP. Буква «М» означает обязательное присутствие пара­метра в команде, буква «О - не обязательное присутствие, буква «F» запрещает присутствие параметра.

8.6   Структура ответов на команды

 

Протокол MGCP предусматривает подтверждение получения всех команд. Структура ответов на команды в протоколе MGCP идентич­на вышеописанной структуре самих команд. Ответ на команду также представляет собой набор текстовых строк и обязательно содержит заголовок ответа, за которым (после пустой строки) может следо­вать описание сеанса связи.

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

В таблице 8.5 приведены возможные варианты кода ответа на ко­манды протокола MGCP.

Таблица 8.5 Коды ответов на команды протокола MGCP

Из представленного в таблице 8.5 перечня кодов ответов видно, что их основная роль заключается в защите от ошибок протокола, конфигурации или функциональных возможностей. На основании информации, предоставляемой этими кодами ошибок, невозможно реализовать осмысленный механизм диагностики. Для получения диагностической информации от шлюзов и портов шлюза нужны дру­гие методы. Одним из возможных методов является упоминавшийся в главе 4 протокол SNMP (простой протокол эксплуатационного управления сетью), который, безусловно, найдёт применение в транспортных шлюзах IР- телефонии.

В заключение рассмотрения структуры ответов на команды про­токола MGCP приведем возможные комбинации параметров в отве­тах (таблица 8.6.)

8.7   Описания сеансов связи

 

При установлении соединений Call Agent предоставляет портам шлюзов, участвующим в этих соединениях, необходимую информа­цию друг о друге - описание сеансов связи. Описание сеанса связи вводится в состав некоторых команд и ответов протокола MGCP и включает в себя IP-адрес, UDP/RTP порт, вид информации, алго­ритм кодирования информации, размер речевых пакетов и т.д. Син­таксис описания сеанса связи в протоколе MGCP соответствует синтаксису протокола описания сеансов связи - session description pro­tocol (SDP), предложенному для использования в вышеуказанных це­лях комитетом IETF в документе RFC 2327 [53].

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

Так как книга посвящена анализу технологии передачи речевой информации по сетям с маршрутизацией пакетов IR в данном пара­графе мы рассмотрим синтаксис протокола SDP только в части опи­сания сеанса речевой связи. Для описания такого сеанса в протоко­ле SDP предусмотрено несколько информационных полей:

•   Версия протокола SDP. Текущая версия протокола - нулевая. Поле кодируется следующим образом: v=0.

•   IP-адрес шлюза. Это полесодержит1Р-адрес, который будет использоваться для обмена пакетами RTR .Если это поле включено в коман­ды протокола MGCP, то оно означает адрес удаленного шлюза, если поле включено в ответы, то - адрес шлюза, передающего ответ.

•   Поле описания речевого канала. Данное поле содержит индика­цию вида передаваемой или принимаемой информации (в нашем случае - речи), номер порта, используемого для приема RTP па­кетов удаленным шлюзом (если поле описания речевого канала включено в команды протокола MGCP) или локальным шлюзом (если это поле включено в ответы), индикацию использования протокола RTP для передачи речи и алгоритмы кодирования ре­чевой информации. Поле кодируется буквой «т».

•   Режим соединения. Режимы соединений представлены в таб­лице 8.7.

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

Данный пример заслуживает краткого комментария. Для описа­ния сеанса связи используется протокол SDP, версия 0, в сети ис­пользуется протокол IP, версия 4, IP адрес шлюза - 128.96.41.1, пе­редается или принимается речевая информация, упакованная в па­кеты RTP, номер порта RTP - 3456, алгоритм кодирования речи G.711, закон µ.

 

8.8    Установление, изменение и разрушение соединений

 

В данном параграфе будет показано, каким образом при помо­щи протокола MGCP устанавливаются, изменяются и завершаются речевые соединения в сетях с маршрутизацией пакетов IP. Пример охватывает взаимодействие протокола MGCP с протоколом ОКС7 (рис. 8.6).

От телефонной станции АТС1 к шлюзу сигнализации SG1 по об­щему каналу сигнализации поступает запрос соединения - сообще­ние IAM. Шлюз SG1 передает сообщение IAM устройству управления шлюзами Call Agent, которое обрабатывает запрос и определяет, что вызов должен быть направлен к телефонной станции АТС2 посред­ством шлюза TGW2.

Далее Call Agent резервирует порт шлюза TGW1 (разговорный ка­нал). С этой целью Call Agent передает шлюзу команду CreateConnection. Отметим, что порт шлюза TGW1 может только принимать инфор­мацию (режим «recvonly»), так как он еще не осведомлен о том, на ка­кой адрес и каким образом ему следует передавать информацию.

Рис. 8.6  Установление и разрушение соединения с использованием протокола MGCP

 

После приема от шлюза TGW1 подтверждения Call Agent переда­ет команду CRCX второму шлюзу TGW2 с целью зарезервировать в нем порт:

Шлюз TGW 2 выбирает порт, который будет участвовать в связи, и подтверждает прием команды CRCX.

При помощи двух команд CRCX создается однонаправленный раз­говорный канал для передачи вызываемому абоненту акустических сигналов или речевых подсказок и извещений. В то же время, порт шлюза TGW 2 уже может не только принимать, но и передавать ин­формацию, так как он получил описание сеанса связи от встречного шлюза. Далее Call Agent передает сообщение IAM к телефонной стан­ции АТС2. На сообщение IAM станция АТС2 отвечает сообщением АСМ, которое немедленно пересылается к станции АТС1.

После того как вызываемый абонент примет вызов, телефонная станция АТС2 передает к Call Agent сообщение ANM. Далее Call Agent меняет режим соединения «recvonly» в шлюзеТGW1 на полнодуплекс­ный режим:

Шлюз TGW1 выполняет и подтверждает изменение режима соеди­нения:

 

200   1206   ОК

 

Call Agent передает сообщение ANM к телефонной станции АТС 1, после чего наступает разговорная фаза соединения.

Завершение разговорной фазы происходит следующим образом. В нашем случае вызвавший абонент дает отбой первым, телефонная станция АТС1 через шлюз сигнализации передает к Call Agent сооб­щение REL. На основании этого сообщения Call Agent завершает со­единение с вызвавшим абонентом:

Шлюз подтверждает завершение соединения и передает к Call Agent собранные за время соединения статистические данные:

Далее Call Agent передает к АТС1 сообщение RLC с целью под­твердить разрушение соединения.

После приема ответа на команду DLCX Call Agent может начинать процедуру завершения соединения с АТС2, которая должна подтвер­дить разъединение, после чего соединение считается разрушенным.

 

8.9    Реализация оборудования с поддержкой протокола MGCP

 

Рассмотрим реализацию протокола MGCP на примере оборудо­вания IPConnect производства компании Nortel Networks. IPConnect -это набор совместимых аппаратно-программных средств, объеди­ненных единой идеологией и технологической базой. Он охватывает системы управления соединениями и обработки вызовов, серверы приложений, шлюзы, а также аппаратуру, устанавливаемую непо­средственно у пользователей. Масштабы сетей, создаваемых на базе этого решения, практически не ограничены.

И еще одна важная особенность: концепция построения обору­дования IPConnect дает оператору возможность выбрать то реше­ние, которое отвечает его текущим потребностям, и постепенно на­ращивать мощность сети, инвестируя средства поэтапно и соотнося этот процесс с темпами развития бизнеса и финансовыми возмож­ностями.

Как известно, до недавнего времени единственным протоколом, регулирующим процесс управления соединениями в сетях IP-теле­фонии, был протокол Н.323. Этот протокол достаточно широко рас­пространен и хорошо зарекоменовал себя в решениях 1Р-телефонии. Но, к сожалению, Н.323 не может гарантировать прозрачность со­единений с ТфОП, использующими сигнализацию ОКС7. Это обстоя­тельство предопределило выбор протокола MGCP в качество основ­ного протокола в оборудовании IPConnect (что, впрочем, не отвер­гает полностью протокол Н.323). Протокол MGCP специально опти­мизирован для нужд телефонии, и компания Nortel Networks прини­мает активное участие в его разработке и внедрении.

С точки зрения функционального построения в IPConnect можно выделить четыре основных элемента (рис. 8.7):

•   шлюз между ТфОП и IP-сетью (CVX 1800);

•   система обработки вызовов (IPConnect Call Engine - ICE);

•   шлюз сигнализации (USP);

•   различные приложения - например, IVR.

Рис. 8.7  Инфраструктура IPConnect

 

Результатом эволюции ОКС7 в направлении пакетной передачи информации стало появление семейства протоколов IPS7 (более 20), описывающих конкретные процедуры упаковки/распаковки сигналов ОКС7. В их числе - аналоги протоколов ISUP, INAP и других, исполь­зуемых в системе сигнализации ОКС7. Эти протоколы имеют различ­ные модификации, учитывающие особенности, присущие националь­ным системам сигнализации. В частности, имеются специальные разновидности и для России (например, аналог протокола ISUP-R).

 

8.10      Возможности и перспективы протокола MGCP

 

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

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

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