Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

SIP на “поверке”

Шон Дохерти

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

Будучи стандартизированным инженерной проблемной группой Интернет (IETF), этот протокол предназначен для обеспечения обмена сообщениями в реальном масштабе времени. Он устанавливает, поддерживает в рабочем состоянии и завершает сеансы связи между оконечными точками сети, или агентами пользователя (User Agent — UA), причем между ними могут передаваться любые типы мультимедийной информации. Многие приложения, применяющиеся современными предприятиями, уже поддерживают протокол SIP. Это, в частности, приложения IP-телефонии (VoIP), мгновенного обмена сообщениями (Instant Messaging — IM), видео-конференц-связи. Часто они дополняются средствами контроля присутствия/статуса пользователя (presence), которые информируют пользователей о том, находится ли их коллега в режиме онлайн и готов ли он к удаленному общению через сеть.

Сигнализация SIP

Как и протокол HTTP, SIP основан на обмене текстовыми сообщениями (с заголовком и “телом” с информацией) по схеме “запрос—ответ”. Первым делом протокол определяет наличие агента UA в конечной системе. Затем сервер-посредник регистрирует UA c помощью универсального идентификатора ресурсов URI (Uniform Resource Identifier), который выглядит подобно адресу электронной почты — например, SIP:sdoherty@skyey.nwc.com. Этот идентификатор определяет имена хоста и домена конечной системы, которые будут использоваться, скажем, для IP-телефонной или видео-конференц-связи. Один агент UA может найти другого по его идентификатору URI, а потом инициировать сеанс связи, послав серверу-посреднику запрос SIP INVITE. (В функции сервера-посредника входит также поддержание сеанса связи между двумя агентами UA, которые при этом взаимодействуют в одноранговом режиме, peer-to-peer.)

Сервер-посредник SIP способен осуществлять “интеллектуальную” маршрутизацию вызовов. Если агент-получатель UA, например SIP-телефон, недоступен в настоящий момент — при попытке установления связи с ним возвращается сигнал BUSY HERE (486), то сервер-посред-ник может послать приглашение INVITE серверу голосовой почты получателя, инициировать вызов сразу нескольких оконечных точек или начать перебирать номера, указанные алгоритмом “Найди меня, следуй за мной” системы унифицированной обработки сообщений. Кроме того, он распространяет информацию о том, готов ли UA-агент участвовать в мультимедийном сеансе связи, онлайновом чате или IM-сессии, и о том, какие типы информации (аудио, видео) агент способен поддерживать.

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

В полях заголовков служебных SIP-сообщений перечисляются атрибуты, идентифицирующие участников сеанса связи, и указывается формат информационных сообщений (для этого используется протокол описания сеанса связи SDP — Session Description Protocol). Так, в запросе INVITE содержится уникальный идентификатор вызова, адрес назначения (URI) и тип сеанса связи, который “хочет” установить UA-агент (данный тип может определяться указанием приложения или протокола). Согласно алгоритму SDP, “тело” SIP-сообщения может содержать подробные сведения о мультимедийных составляющих устанавливаемого сеанса связи и возможностях UA-агента по поддержке этих составляющих. Протокол SIP функционирует независимо от нижележащих протоколов, обеспечивающих транспортные функции по доставке потоков аудио- и видеоинформации. В качестве таких протоколов обычно используют RTP (Real-Time Transport) или RTSP (Real-Time Streaming Protocol).

Организация IETF разработала расширения к SIP. К ним относятся так называемые события UA, в рамках которых могут передаваться, например, сообщения о том, находится ли пользователь в сети и доступен ли он. Но даже с этими расширениями протокол SIP остается простым в реализации и последующем применении. Поддержка SIP-расширений имеется в продуктах таких компаний, как Avaya, Interactive Intelligence, Siemens и Zultys Technologies.

Наблюдая за “наблюдателями”

Сервис контроля присутствия работает по схеме клиент—сервер (как и любое Web-приложение): сервер получает, хранит и распространяет информацию о состоянии потенциального участника сеанса связи. “Наблюдателями” являются пользователи, которые ищут, скажем, собеседника для общения по телефону или партнера по обмену IM-сообщениями. “Наблюдатели” должны подписаться на получение информации о статусе интересующих их пользователей.

Для работы сервиса контроля присутствия применяются стандартные протоколы, такие, как XMPP (Extensible Messaging and Presence Protocol), или фирменные, используемые, в частности, в системах Live Communication Server компании Microsoft и AOL Messenger. Эти протоколы и служат для указания статуса пользователя.

Много предприятий развертывают сейчас основанные на протоколе SIP системы IP-телефонии, в которых используются серверы-посредники компаний Avaya, Interactive Intelligence, Siemens и др. В состав таких серверов уже включены службы по определению местонахождения конечных точек (с информацией о их доступности), например службы регистрации URI-индентификатора агента пользователя. Протокол SIP также может маршрутизировать запрос INVITE к любому пользователю, зарегистрированному на том же или на другом сервере-посреднике. Поскольку указание состояния регистрации — один из основных компонентов сервиса контроля состояния, то SIP является идеальным протоколом для его реализации.

Вместе с тем расширения SIP задействуют инструментальные средства, работающие на специальных серверах, предоставляющих более подробную информацию о состоянии абонента. С их помощью вы можете сообщить своим коллегам, что находитесь “на совещании”, “на обеде” или, скажем, “доступны, но очень рассержены”. Эти расширения используют агент присутствия (Presence Agent — PA) — основанное на протоколе SIP программное обеспечение типа сервера Live Communication Server 2005 компании Microsoft. Указанный агент принимает и хранит информацию о пользователях; он также может рассылать своим подписчикам уведомления — например, когда интересующий их пользователь вышел из режима онлайн. Агент PA — это логический объект, и физически он может существовать на сервере-посреднике SIP или в виде отдельного сервера PS (Presence Server). При взаимодействии с агентом PA можно использовать те же самые URI-идентификаторы, как и при любых других запросах SIP — в частности, уже приведенный выше идентификатор sip:sdoherty@skyey.nwc.com.

Пользовательский агент контроля присутствия (Presence User Agent — PUA) — это тоже программное обеспечение, например Microsoft Communicator 2005 или Microsoft Windows Messenger, управляющее информацией о статусе пользователя. Данный статус меняется, когда пользователь подключает (log on) или отключает (log off) свое SIP-устройство, но он (пользователь) может и сам менять свой статус с помощью средств PUA.

Сразу несколько пользовательских устройств, например карманный ПК (КПК), портативный компьютер или сотовый телефон, могут распространять информацию о статусе своего “хозяина”. Агенты PUA каждого устройства сообщают эту информацию агенту PA, совмещенному с сервером-посредником SIP или реализованному на выделенном сервере PS.

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

Агент PA должен проверить подлинность поступившего запроса и права пославшего его подписчика на получение информации о состоянии другого пользователя. (Примерно то же самое происходит, когда AOL Instant Messenger или другая интернетовская IM-служба запрашивает: “Хотите ли вы, чтобы информация о том, что вы на связи, была доступна другим пользователям?”) Агент PA посылает своему подписчику ответ “200 OK”, если все в порядке и тот авторизован на получение информации о статусе интересующих его пользователей. Ответ “202 Pending” означает, что авторизация оказалась неудачной.

О безопасности

Агент PA должен проверить подлинность всех запросов SUBSCRIBE, используя дайджест-аутентификацию (digest authentication) или другие алгоритмы, указанные в документе RFC 3261. Если подписчик, получающий информацию о статусе другого пользователя, и сам этот пользователь находятся в одном домене, они имеют общие секретные коды (secrets) для аутентификации через агент PA. Безопасная проверка может быть обеспечена с помощью алгоритма дайджест-аутентификации и технологии TLS (Transport Layer Securi0ty).

В случае, когда системой охватывается несколько доменов и запросы на доступ к информации о статусе и подтверждение их правомочности проходят через несколько сетей, с целью обеспечения безопасной аутентификации должны быть установлены доверительные отношения (trust relationships) между серверами-посредниками и агентами PA с использовани-ем технологии TLS. Для определения идентичности потенциальных подписчиков при аутентификации в режиме пользователь—пользователь (peer-to-peer) также возможно использование алгоритма S/MIME.

Системы SIP могут оказаться уязвимыми при атаках типа “отказ в обслуживании” (Denial of Service — DoS), особенно если эти атаки носят распределенный характер (Distributed DoS — DDoS). Запрос SUBSCRIBE способен привести к генерации большого числа уведомлений. Злоумышленник может воспользоваться этим, сформировав запрос на доступ к информации о большом числе пользователей и указав в поле заголовка

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

Атаки DoS также могут быть организованы против агентов PA c целью повреждения информации о статусе сразу большого числа пользователей. От этого SIP “защищается” с помощью четырехэтапной процедуры дайджест-аутентификации. Если общие секретные коды недоступны потенциальному подписчику (он находится вне локального домена), протокол SIP может проверить источник запроса, задействовав алгоритм аутентификации анонимного пользователя. Кроме того, специальное сообщение сервера (код 503) способно заставить клиентов прекратить подачи запросов SUBSCRIBE, что спасет его от наплыва таких запросов, а значит, и от атак DoS.

SIP не только является простым протоколом для сигнализации и предоставления информации о статусе пользователя — он способен эффективно защитить сам себя от угроз безопасности. Если вы уже разработали стратегию использования функций presense в информационной системе вашего предприятия, ориентируйтесь на SIP, который к тому же поможет вам задействовать преимущества таких приложений, как мгновенный обмен сообщениями, IP-телефония, видео-конференц-связь, а также построить эффективную систему управления документами и Web-порталы..





  
5 '2006
СОДЕРЖАНИЕ

бизнес

• Управляем конфигурационными зависимостями

• «Наглядное пособие» по конвергенции

инфраструктура

• Пришло время сетевых систем хранения данных

информационные системы

• Business Intelligence: один продукт, чтобы угодить всем

• Хостируемые CRM-системы на службе заказчика

• Семь основных принципов эффективного общения

• Электронный регион в «электронном государстве»

сети связи

• Обмен сообщениями на любой вкус

• SIP на «поверке»

кабельные системы

• Экранированным медным кабелям — путевку в новую жизнь!

• Стандартизация промышленных кабельных систем

защита данных

• Снова тестируем фильтры спама

новые продукты

• Производительная безопасность от Juniper; Мультисервисная платформа «Зелакс-ММ»; Системы электропитания Actura; Серверы Mr.ROBO


• Калейдоскоп



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх