 |
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Всё, что вы хотели знать о протоколе SIP
Всё, что вы хотели знать о протоколе SIP Что общего у Microsoft Exchange 2007, Asterisk и Google Talk? А общим здесь является использование протокола SIP, который обещает единое решение задач как реализации мультимедийных функций в веб-приложениях, так и переноса сигнального трафика в сетях операторов связи. В одном из писем своим компаньонам Александер Грэм Белл впервые в истории и при этом весьма подробно изложил план создания в большом городе телефонной сети, базирующейся на центральном коммутаторе. В письме он настаивал на том, что в целях рекламы было бы желательно бесплатно установить телефонные аппараты в центральных магазинах города. Это письмо стало первоисточником привычной телефонной лексики, в том числе фразы «алло, центральная», которая умерла лишь при появлении автоматических телефонных станций. В течение более чем 100 лет все значимые изменения, происходившие с телефонной станцией, касались именно телефонной станции. И лишь в эпоху Интернета стало возможным говорить о действительно новом направлении коммуникаций. Путь будущего развития коммуникаций лежит через разделение логики работы сетей и предоставления услуг. Новые услуги будут предоставляться опорной сетью, т.е. независимо от сети доступа. Таким образом, в любом месте, при использовании любого метода доступа к сети и с любого оконечного устройства пользователь может обращаться к одним и тем же услугам. В опорных сетях уже сейчас происходит переход от сетей с коммутацией каналов и мультиплексированием с разделением по времени (Time-division Multiplexing, TDM), на которых реализована вся традиционная телефония, к пакетным сетям. Дополняет картину Fixed Mobile Convergence – идея интеграции функционала мобильных и фиксированных сетей. Операторы готовят инфраструктуру к предоставлению услуг следующего поколения путем применения программных коммутаторов, отличающихся большой гибкостью. Программные коммутаторы реализуют функции сопряжения с телефонной сетью общего пользования (ТфОП), обеспечивают централизованный биллинг, управление и интеллектуальную динамическую маршрутизацию звонков. Их применение означает для операторов фиксированной и мобильной связи возможность предоставления услуг транзита голосового трафика через опорную сеть IP/MPLS (Internet Protocol/Multiprotocol Label Switching), подключения корпоративных клиентов, управления вызовами и обслуживания клиентских устройств – и всё это, как правило, с меньшими затратами в сравнении с сетями TDM. Происходящие в последние годы изменения на мировом рынке услуг телефонной связи сравнимы по своей значимости с переходом телефонии на автоматическую коммутацию. Эти изменения не в последнюю очередь связаны с появлением так называемых услуг SIP-телефонии, активно обсуждаемых в телекоммуникационном сообществе. Протокол SIP был стандартизирован в апреле 1999 года, а актуальная спецификация (версия 2.0 протокола SIP) датирована 2002 годом. Назначение SIP Session Initiation Protocol (SIP) – это клиент-серверный протокол прикладного уровня, предназначенный для установления, изменения и окончания сеансов связи с одним или несколькими участниками для обмена интерактивным трафиком: голосом, видео, мгновенными сообщениями. SIP относится к классу протоколов сигнализации; его задачи аналогичны тем, которые выполняет протокол общеканальной сигнализации №7 (ОКС7 или SS7) в обычной телефонии, а протоколы H.323 и MGCP (Media Gateway Control Protocol) – в IP-телефонии. Основными функциями SIP являются:
Непосредственным носителем голосовых или видеоданных является протокол RTP (Real-time Transport Protocol), SIP-сообщение же выполняет роль контейнера для сообщений протокола описания сеансов связи SDP (Session Description Protocol). Сообщение SDP описывает медиаданные в рамках сессии: тип медиаданных, транспортный протокол, формат данных и пр. RTP и SDP будут рассмотрены в следующей статье цикла, сейчас же сделаем акцент на том, что SIP был расширен для поддержки функций обмена мгновенными сообщениями и информацией о присутствии и статусе абонента. Последнее позволяет выполнять более совершенное управление голосовыми вывозами с переадресациями и продвинутой маршрутизацией. SIP поддерживает также приглашение участников к текущим сеансам наподобие многоточечных конференций, добавление к текущему сеансу или удаление из него мультимедийных данных, прозрачное распределение имён и перенаправление услуг, включая персональную мобильность пользователя. Так что, хотя о протоколе SIP чаще всего говорят в контексте IP-телефонии, на самом деле он может применяться для установки поверх IP самых разнообразных сеансов связи, порой не имеющих ничего общего с телефонным звонком (что неудивительно для протокола, разработанного IETF, а не телекоммуникационной индустрией, как H.323). Впрочем, H.323 сегодня также не ограничен голосовой связью и может обслуживать любой сеанс связи. Традиционно H.323 называли более зрелым протоколом, а SIP – более динамичным, расширяемым, масштабируемым и, главное, простым в сравнении с H.323. Впрочем, эти границы постепенно размываются: в своём сегодняшнем виде SIP так же сложен, как и H.323. Так или иначе, кажется, что отрасль уже сделала свой выбор в пользу SIP (хотя позиции H.323 в операторской среде по-прежнему прочны). Выбор SIP консорциумом 3GPP (3G Partnership Project) в качестве фундамента для строительства сетей мобильной связи следующего поколения в ноябре 2000 года способствовал появлению сервисной архитектуры подсистемы IP-мультимедиа (IP Multimedia Subsystem, IMS). Протоколу SIP, который уже сегодня получил распространение в корпоративных и операторских сетях, уготовано центральное место в унифицированной модульной архитектуре сетей нового поколения (Next Generation Networks, NGN) – фактически то место, которое cистема сигнализации SS7 сегодня занимает в сетях TDM. SIP предполагает простую (и, следовательно, хорошо масштабируемую) сеть с интеллектом, встроенным в конечные элементы (пользовательские агенты). Другими словами, функции SIP реализованы в конечных устройствах, в отличие от традиционных возможностей SS7, которые поддерживаются самой сетью. Протокол SIP по структуре напоминает протоколы HTTP и SMTP. Из HTTP он взял клиент-серверную архитектуру и использование URL и URI, а из SMTP – способ кодировки текста и стиль заголовков. SIP ориентирован в первую очередь на взаимосвязи точка-точка, но поддерживает и режим многоадресной рассылки (multicast). Последний может использоваться для организации конференций, когда информация передается на один multicast-адрес, а затем доставляется сетью конечным адресатам. Другие два варианта организации конференций – соединение каждого пользователя с каждым в режиме точка-точка и соединение каждого пользователя с устройством управления конференцией. Впрочем, «точка-точка» – это слегка идеализированный сценарий, возможный лишь в рамках одного домена. Типичная сеть SIP содержит и другие элементы: сервер регистрации, прокси-серверы, а иногда и сервер переадресации. SIP работает в среде IPv4 и IPv6 с использованием транспорта протоколов UDP, TCP, TLS или SCTP. Таблицы 1, 2 помогут читателю оценить различия архитектур SIP, H.323 и MGCP. Таблица 1. Компоненты и сервисы протоколов сигнализации
Таблица 2. Сравнительные характеристики протоколов сигнализации
Структура сообщений Теперь пора перейти к рассмотрению «строительных блоков» протокола SIP: методов, запросов и ответов, заголовков и т. д. SIP использует набор символов ISO 10646 в кодировке UTF-8. Запросы и ответы SIP имеют одинаковый базовый формат сообщения и различаются наборами символов и синтаксисом. Сообщение состоит из:
Возьмём небольшой пример в виде запроса INVITE:
Теперь детально рассмотрим каждую строку запроса. Первая, или стартовая, строка запроса имеет следующий формат: <Имя метода> <Request-URI (адресат)> <Номер версии SIP> Заметим, что имя метода указывает на назначение данного сообщения. Под этим термином понимают как запросы, так и ответы. Все последующие строки запроса несут дополнительную информацию о сообщении. Обязательный заголовок(ки) Via содержит список всех SIP-устройств на пути сообщения. Часть заголовка, следующая после точки с запятой, является параметром. Параметр branch самого верхнего заголовка Via служит для идентификации транзакции. Заголовок Max-Forwards указывает максимальное количество серверов SIP, разрешённое на сигнальном пути. Он обязателен во всех запросах SIP, кроме INFO. Поля заголовков From и To идентифицируют отправителя и получателя сообщения; они обязательны во всех без исключения запросах. Параметр tag заголовков From и To содержит псевдослучайное значение, применяемое (наряду с заголовком Call-ID) для идентификации диалога на уровне сгенерировавшего сообщение пользовательского агента. Call-ID – это идентификатор вызова, глобально уникальный в рамках домена. CSeq – это заголовок, помогающий идентифицировать транзакцию в рамках диалога; содержит последовательно увеличивающийся порядковый номер сообщения и название метода, породившего транзакцию. Contact содержит прямой путь к отправителю сообщения – FQDN или IP-адрес. Заголовков Contact может быть несколько. Наконец, поле заголовка Content-Type содержит описание тела сообщения, а Content-Length – длину содержимого тела сообщения в октетах. После пробела следует тело сообщения. Тело сообщения несёт описание сеанса либо текстовые или двоичные данные, относящиеся определённым образом к нему. Тело сообщения может присутствовать как в запросе, так и в отклике. Обычно телом сообщения выступает SDP- или MIME-часть. Выше показано тело сообщения SDP. Пока мы пропустим его разбор; SDP будет рассмотрен в следующей части статьи. В таблице 3 сведены основные методы SIP вместе с их описаниями. По своему типу заголовки SIP можно разделить на несколько категорий, см. таблицу 4. Таблица 3. Методы SIP
Таблица 4. Заголовки SIP
На каждый запрос отправителю направляется ответ, содержащий код результата выполнения запроса. Например, положительный ответ на приведённый выше INVITE может быть таким:
SDP-часть не показана для экономии пространства. Все заголовки кроме стартовой строки вам уже знакомы, а стартовая строка ответа имеет следующий формат: <Номер версии SIP> <Код статуса> <Текст причины> Код статуса – это 3-значное число, первая цифра которого указывает на класс ответа, а остальные две – идентифицируют конкретный ответ в каждом классе. Устройство может не знать, что означает код ответа, но должно обязательно знать класс ответа. Всего существует 6 классов ответов (таблица 5). Информационные ответы сообщают о стадии выполнения запроса, они не являются завершением транзакции. Остальные же классы ответов завершают транзакцию. Таблица 5. Ответы SIP
Адресация в SIP Для идентификации абонентов и ресурсов в протоколе SIP используются SIP URI-идентификаторы, описанные в RCF 2396. SIP URI состоит из двух частей: первая часть – это имя пользователя, зарегистрировавшегося в домене или на рабочей станции. Во второй части указывается имя домена, рабочей станции или шлюза. Если вторая часть адреса идентифицирует какой-либо шлюз, то в первой указывается телефонный номер абонента. В начале адреса ставится слово «sip:», указывающее, что это именно SIP URI (бывают и другие, например «sips:» для SIPS URI или «tel:» для номеров в формате E.164). Таким образом, возможны SIP URI следующего вида:
Если во второй части указывается доменное имя, для определения IP-адреса устройства необходимо обратиться к службе DNS. RFC 3263 описывает процедуры DNS, с помощью которых можно транслировать SIP URI в IP-адрес, порт и транспортный протокол, необходимые для связи с абонентом. RFC также специфицирует использование для этой цели ресурсных записей DNS SRV и NAPTR. Уровни протокола SIP. Понятия транзакции и диалога SIP представляет собой многоуровневый протокол, но не каждый элемент, работающий по протоколу SIP, содержит все уровни, а сами элементы, работающие в сети SIP, являются скорее логическими, нежели физическими. На рис. 1 показаны уровни протокола SIP; он также послужит нам иллюстрацией того, из каких логических компонентов состоит каждый элемент сети SIP. Самый нижний уровень отвечает за синтаксис и кодирование сообщений. Вторым уровнем протокола является транспортный уровень – он определяет, как клиент передаёт запросы и получает ответы от сервера и как сервер получает запросы и передаёт ответы клиенту; эти функции свойственны всем элементам сети, следовательно, все они содержат транспортный уровень.
Рисунок 1. Многоуровневая структура протокола SIP Следующий уровень – это уровень транзакций. О SIP говорят как о транзакционном протоколе. Транзакцией называют совокупность соообщений, состоящую из запроса, отправленного клиентом серверу, и всех ответов сервера на этот запрос (см. рис. 2). Уровень транзакций содержит клиентскую часть, называемую клиентской транзакцией, и серверную часть, называемую серверной транзакцией. Уровень транзакций предпринимает повторную передачу сообщений, определяет соответствие ответов запросу и уведомляет верхний уровень протокола о срабатывании таймеров. И на самом верху находится уровень пользователя транзакций (Transaction User, TU), который управляет созданием транзакций. Все элементы сети SIP, за исключением прокси-сервера без хранения состояния, обязательно содержат уровни транзакций и пользователя транзакций.
Рисунок 2. Понятия транзакции и диалога Правила проверки соответствия запроса серверной транзакции таковы: сервер анализирует верхний заголовок Via на предмет наличия параметра branch. Если он присутствует и в начале его значения стоит набор символов «z9hG4bK», как в рассмотренном выше примере:
следовательно запрос был сгенерирован клиентом, поддерживающим RFC 3261 в полной мере, и параметр branch уникален в каждой транзакции данного клиента. Запрос принадлежит транзакции в том случае, если значение параметра branch запроса совпадает с таковым из запроса, образовавшего транзакцию, а имя метода из поля заголовка CSeq совпадает с таковым из запроса, образовавшего транзакцию. Если же параметр branch отсутствует, как показано ниже:
сервер руководствуется следующими правилами. Запрос принадлежит транзакции в том случае, если Request-URI (часть стартовой строки, указывающая на адресата данного запроса), теги заголовков From и To, заголовки Call-ID и Cseq (включая название метода) и верхний заголовок Via совпадают с соответствующими полями запроса, образовавшего транзакцию. В случае проверки соответствия запроса ACK серверной транзакции, Request-URI, теги заголовков From и To, заголовки Call-ID, Cseq и Via запроса ACK сравниваются с таковыми в изначальном INVITE, а To-тег – с тегом первого ответа серверной транзакции на INVITE. Аналогично выполняется проверка соответствия ответа клиентской транзакции. Наконец, диалог – это равноправное взаимодействие двух элементов сети SIP в виде последовательности SIP-сообщений между ними. Диалог всегда инициируется пользовательским агентом, но другие элементы сети также в нём участвуют. Сообщения в рамках одного диалога отличаются одинаковыми Call-ID и тегами заголовков From и To, а порядковый номер в поле CSeq монотонно возрастает. Фактически CSeq идентифицирует транзакцию в рамках диалога, а диалог является последовательностью транзакций, из которых только одна может быть активна в каждый момент времени. Однако, кроме диалогообразующих запросов, существуют и запросы, не образующие диалогов. Здесь также уместно разъяснить значение заголовка Call-ID и From- и To-тегов:
Компоненты SIP. Пользовательские агенты (User Agent – UA) Этим термином называют конечное устройство сети SIP или приложение, способное установить сеанс, управлять им и разорвать его, а также производить обмен медиаданными с другими пользовательскими агентами. Поскольку SIP – это одновременно и протокол типа «точка-точка», и клиент-серверный протокол, конечная точка SIP должна быть способна отвечать на запросы сессии SIP и инициировать их. Следовательно, конечная точка должна содержать два SIP-стека одновременно:
Для UA существует также другое название – SIP-клиент. Сообщение SIP – это или запрос от UAC к UAS, или ответ UAS компоненту UAC. В оригинальной спецификации SIP описано шесть возможных типов запросов (или методов), которые может выдать UAC: INVITE, ACK, OPTIONS, BYE, CANCEL и REGISTER. Расширения SIP, описанные в RFC, определяют дополнительные методы – такие, как MESSAGE, INFO и NOTIFY. Когда UAC инициирует SIP-сессию, он определяет протокол, порт и IP-адрес UAS, которому посылается запрос. При отсутствии любой информации о локально настроенном прокси-сервере, UAC использует данные в URI запроса для определения маршрута SIP-запроса. Данный URI запроса всегда определяет хост, но не всегда – порт и протокол. Если хост через адрес IP указан явным образом, UAC пытается связаться с UAS по этому адресу. Если URI запроса специфицирует полностью определенное доменное имя Fully Qualified Domain Name (FQDN), UAC опрашивает службы DNS для разрешения имен, используя для этого ADDRESS, CNAME или другие данные в ресурсной записи. Если URI запроса содержит номер порта, UAC пытается установить соединение с UAS, используя данный номер; если же URI запроса не указывает номер порта, UAC по умолчанию использует в качестве порта назначения 5060. Если URI запроса указывает транспортный протокол (TCP или UDP), UAC использует его. В противном случае UAC предпринимает попытку связи по UDP, а в случае ошибки UAC пытается задействовать TCP. Каждый UA должен хранить состояние диалога, а именно: помнить теги From и To, локальный и удалённый номера CSeq, Call-ID, маршрутные заголовки и характеристики медиапотоков. Шлюзы, выполняющие преобразование H.323 в SIP, ISDN в SIP или SS7 в SIP, с точки зрения SIP функционально ничем не отличаются от пользовательских агентов (ведь другие элементы сети SIP не «знают», действует ли UA, руководствуясь командами пользователя или сообщениями/событиями других протоколов). Серверы регистрации Архитектура SIP поддерживает персональную мобильность пользователей. Пользователи могут перемещаться без ограничений в пределах сети, поэтому услуги связи должны предоставляться им в любом месте этой сети. Пользователю присваивается уникальный идентификатор, а сеть предоставляет ему услуги связи вне зависимости от того, где он находится. Пользователь косвенно информирует прокси-сервер или сервер переадресации, по какому адресу следует обращаться для установления сеанса связи. Обработкой этой информации и занимается сервер регистрации: получая от пользовательского агента запрос REGISTER, он создаёт временную связку из присвоенного пользователю SIP URI (называемого также Address of Record – AOR) и URI заголовка Contact, который указывает на адрес, куда следует направлять запросы (см. рис. 3). База данных с информацией о местоположении пользователей доступна для всех серверов в рамках данного административного домена (для прокси-серверов и серверов перенаправления), что делает возможной маршрутизацию входящих вызовов. Сам запрос REGISTER может использоваться для получения списка текущих привязок, удаления всех привязок или добавления новой. Отклик 200 OK на запрос REGISTER содержит заголовок Expires, указывающий, через сколько секунд нужно обновлять регистрацию, а также один или несколько заголовков Contact со всеми текущими привязками.
Рисунок 3. Работа сервера регистрации Сервер переадресации Сервер переадресации возвращает пользовательскому агенту новый адрес для прямой маршрутизации вызова по этому адресу, иными словами – производит перенаправление вызывающей стороны к другому серверу (см. рис. 4). Сервер переадресации отвечает на запрос, но никогда не пересылает запрос дальше и не хранит состояние. Впрочем, нельзя сказать, что он применяется часто: каждый оператор предпочитает полностью контролировать сеанс связи.
Рисунок 4. Переадресация вызова Прокси-серверы Наличие прокси-сервера является обязательным атрибутом каждой корпоративной или операторской сети. Прокси-сервер действует как посредник, который обслуживает запросы пользовательских агентов и пересылает их дальше, выполняя маршрутизацию сообщений. Прокси-серверы играют ключевую роль в сетях SIP, поскольку связывают вместе пользовательские агенты и другие элементы SIP-сети в одном или множественных доменах, реализуя логику маршрутизации. Прокси-сервер не генерирует запросы самостоятельно (за исключением CANCEL), а лишь отвечает или пересылает запросы, полученные от UAC. Также он выполняет интерпретацию, удаление, добавление или модификацию заголовков, касающихся прямых функций прокси-сервера (таких, как Record-Route или Via), но ничего не «знает» о SDP-части. А основные функции прокси-сервера следующие:
Алгоритм маршрутизации не поддаётся формализации, поскольку определяется архитектурой и политикой конкретной сети, но мы рассмотрим некий усреднённый пример. Итак,
Запись типа SRV предоставляет механизм для получения списка хостов, предоставляющих некоторую службу посредством разных транспортных протоколов, с упорядочиванием по предпочтению. Для примера, пусть клиент пытается разрешить URI sip:user@example.com. Клиент производит DNS-запрос и выбирает ресурсные записи типа NAPTR для данного домена:
В примере видно, что сервер поддерживает TCP, UDP и TCP через ТLS. Затем, обрабатывая записи SRV, клиент определяет сервер назначения (или список серверов) для предпочитаемого им типа транспортного протокола:
Дальнейшее разрешение имён производится с помощью привычных ресурсных записей адреса узла (A). Когда proxy-сервер пересылает SIP-запрос, он добавляет своё имя (имя сервера) в начало списка в поле Via в заголовке SIP-сообщения. Это поле позволяет возвращать ответы по тому же маршруту, по которому проходил запрос. На «обратном» пути каждый proxy-сервер удаляет своё имя из поля Via после обработки SIP-ответа (см. рис. 5).
Рисунок 5. Маршрутизация вызова между доменами при посредничестве прокси-серверов Обобщённый же алгоритм работы прокси-сервера можно представить следующим образом: 1) Проверка корректности составления входящего запроса. 2) Приведение номера вызываемой стороны к формату E.164. 3) Аутентификация отправителя запроса. 4) Выполнение запрошенных вызывающей стороной процедур, таких как удаление из запроса или изменение идентифицирующих вызывающую сторону заголовков. 5) Авторизация вызова. 6) Обращение к серверу регистрации для поиска подходящего получателя запроса. 7) Если получатель найден – направить запрос ему (и при необходимости – выполнить такие действия, как перенаправление вызова). 8) Если получатель не найден – отправить звонок в ТфОП. Различные типы прокси-серверов Прокси-сервер без хранения состояния (Transaction Stateless) – прокси-сервер, который не хранит состояние сеанса и руководствуется лишь внутренней логикой маршрутизации сообщения, применяя её к каждому отдельно взятому запросу. Такой прокси-сервер не выполняет повторную передачу сообщений (а следовательно, неприменим в рамках модели SIP/TCP). Целесообразным применение такого прокси-сервера является при очень высокой нагрузке или в балансировщиках нагрузки прикладного уровня. Прокси-сервер с хранением состояния транзакции (Transaction Stateful) – прокси-сервер, который запоминает входящие и исходящие сообщения в рамках данной транзакции до получения (или отправки) финального ответа. Прокси-сервер с хранением состояния транзакции ничего не «знает» о запросах UPDATE, REFER и BYE, но уже способен эффективно выполнять отправку учётной информации, разветвление, перенаправление вызова и некоторые другие расширенные функции. Прокси-сервер с хранением состояния диалога (Dialog Stateful) – прокси-сервер, который вставляет заголовок Record-Route в самый первый запрос SIP для того, чтобы все последующие сообщения в рамках данного диалога проходили через этот же сервер; это относится к каждому прокси-серверу на пути между пользовательскими агентами. Такой прокси-сервер способен предоставить полный набор функций программного коммутатора классов 4 и 5. Back-to-Back UA (B2BUA) «Back-to-back user agent» – это компонент, состоящий из двух SIP UA, которые общаются между собой строго на прикладном уровне (с помощью SIP-сообщений). B2BUA образует своего рода периметр безопасности между SIP UA, находящимися по обе стороны от B2BUA: он скрывает детали реализации SIP на каждом из конечных устройств. В типичном случае B2BUA используется для форсирования обрыва звонков в сетях операторов связи по истечении предоплаченного объема услуг и вообще какого-либа контроля диалога третьей стороной, а также скрытия топологии сети и обеспечения определённых функций безопасности (кстати говоря, шлюз уровня приложений, ALG, с поддержкой SIP, архитектурно представляет собой не что иное, как B2BUA). Также B2BUA делает возможным реализацию перекодирования медиапотока, его перехвата и т. д. Пользуясь лишь критерием хранения состояния, B2BUA можно было бы отнести к классу прокси-серверов с хранением состояния диалога. На самом деле это не прокси-сервер в привычном смысле этого слова: он выполняет несвойственные для прокси-сервера операции по удалению и модификации заголовков (а иногда и модификацию SDP-части). Есть и другая характерная черта: B2BUA фактически никогда не бывает реальным адресатом запроса, а лишь пересылает его другой стороне. Такая функциональность выходит за рамки RFC 3261: RFC специфицирует лишь то, что SIP-прокси маршрутизирует один диалог, т.е. сообщения с одинаковыми Call-ID и тегами заголовков From и To, между конечными устройствами, не изменяя их (кроме заголовков, используемых для маршрутизации, включая неизвестные заголовки), а B2BUA же создаёт новый диалог и может модифицировать любую содержающуюся в запросе информацию перед отправкой сообщения адресату. Разработчики могли бы для реализации каждого подмножества набора расширенных услуг предлагать некий «расширенный» прокси-сервер, нарушающий отдельные аспекты RFC 3261, но такой подход вряд ли можно счесть практичным и расширяемым. Объединение же стеков UAC и UAS в одном устройстве позволяет в точности придерживаться требований спецификаций, а тщательный подход к реализации самих стеков – сделать B2BUA максимально прозрачным для конечных абонентов. В следующий раз мы рассмотрим реальный пример вызовов в сети SIP, поговорим о предоставлении спектра расширенных услуг на базе протокола, протокол описания сеанса SDP и транспортный протокол реального времени RTP. Приложение История разработки SIP Проект, который со временем стал стандартом SIP, был начат в 1996 году Хенингом Шулзри (Колумбийский университет) и Марком Хэндли (UCL), участниками рабочей группы MMUSIC (Multi-Party Multimedia Session Control) ассоциации IETF. Черновик IETF, описывающий SIP версии 1.0, увидел свет в 1997 году. В следующем году был издан уже черновик версии 2.0. Статус предложенного стандарта SIP получил в марте 1999 года, а в апреле того же года был опубликован RFC первой предложенной версии стандарта – RFC 2543. В сентябре 1999 года была образована SIP Working Group, работающая с тех пор над самим протоколом и его расширениями. В июле 2000 года был опубликован RFC 2543 «bis», содержащий множественные поправки и улучшения к оригинальной спецификации. Этот документ лёг в основу RFC 3261 (2002 года), являющегося и на сегодняшний день основным SIP RFC. Заметьте, что номер версии всё ещё равен 2.0. Постепенно были образованы и другие рабочие группы IETF, работа которых так или иначе касается SIP. Так, рабочая группа SIPPING (SIP Investigation) была сформирована для исследования новых областей применения SIP, выработки требований к расширениям SIP и документов рекомендательного характера касательно применения SIP в приложениях. Рабочая группа SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) была сформирована для стандартизации расширений SIP для обмена мгновенными сообщениями и информацией о статусе состояния абонента. Другие рабочие группы по SIP – ENUM (работающая над интеграцией SIP-адресации и принятых в ТфОП номерных планов), SIGTRAN (Signaling Transport, перенос сигнализации SS7 поверх IP) и AVT (Audio/Video Transport (RTP), отвечающая за поддержку и расширение протокола RTP). MMUSIC же ответственна за SDP (Session Description Protocol), SAP (Session Announcement Protocol), RTSP (Real Time Streaming Protocol) и исследование возможностей применения SIP для мультимедиа-конференций. ENUM Как быть, когда при развёртывании SIP-сети необходимо предусмотреть возможность приёма входящих вызовов от абонентов ТфОП, но использование DID-номеров (Direct Inward Dial) по тем или иным причинам невозможно? Адреса E.164 могут храниться в особой зоне, e164.arpa, службы DNS с помощью протокола ENUM (TElephone NUmber Mapping). Любой телефонный номер, например +878102233350332, может быть преобразован в доменное имя записью цифр в обратном порядке, разделением их точками и добавлением суффикса e164.arpa, для нашего примера: +878102233350332 -> 2.3.3.0.5.3.3.3.2.2.0.1.8.7.8.e164.arpa. Это преобразование выполняется на так называемом ENUM-шлюзе (физически им может являться шлюз, UA или даже веб-браузер). Полученное доменное имя можно использовать в запросе к DNS-серверу для получения ресурсной записи типа NAPTR (Naming Authority Pointer DNS Resource Records, RFC 3403), которая содержит предпочтения пользователя касательно того, как и куда следует терминировать вызов. Сама запись типа NAPTR поддерживает регулярные выражения, а алгоритм DDDS (Dynamic Delegation Discovery System, RFC 3401 – RFC 3405) используется для преобразования доменного имени в адрес того или иного сервиса с использованием данных регулярных выражений. Например, возьмём NAPTR-запись такого вида:
Числа 100, 101, 102 указывают порядок, в котором записи должны быть обработаны для образования упорядоченного списка правил, поэтому мы сначала выбираем первую запись. Число 10 (Preference) для нас не имеет значения, поскольку других записей с порядковым номером 100 нет. Если бы записей с порядковым номером 100 было несколько, более приоритетной стала бы запись с меньшим значением Preference. Затем «u» – это флаг, который контролирует интерпретацию последующих полей; «u» предписывает выполнить преобразование и не анализировать последующие правила записи. Соответственно, если мы поддерживаем сервис, на который указывает поле «E2U+sip», правила с более высокими порядковыми номерами анализироваться не будут. Если приложение не поддерживает SIP, протокол mailto: поддерживается наверняка (как видите, ENUM не является протоколом, специфичным исключительно для VoIP). Заметим, что набор сервисов не ограничен только этими тремя. Наконец, последнее поле задаёт регулярное выражение (синтаксиса регулярных выражений Perl, только вместо прямого слэша используется знак восклицания), которое нужно применить к указанному в запросе доменному имени, чтобы получить результат запроса. Как только результат получен, дальнейшая маршрутизация выполняется обычными для данного протокола методами, а всё, о чём мы говорили до сих пор, абсолютно прозрачно для конечного пользователя. К тому же подписчик ENUM имеет возможность задать под одним E.164-номером множество протоколов и адресов, запрограммировать перенаправление вызовов и т. д. За работу зоны e164.arpa отвечает RIPE NCC: http://www.ripe.net/enum, но ответственность за отдельные страны поручена локальным NIC (nic.at, nic.cz, …) или компаниям, работающим с ENUM (Neustar, Verisign). Владелец ENUM-номера обычно имеет возможность изменять связанный с номером SIP URI через веб-интерфейс. Кроме уже упомянутых RFC, данной теме посвящён RFC 3761.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Андрей Погребенник
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
