SIP (Session Initiation Protocol) разрабатывается специальной рабочей группой IETF. Этот протокол прикладного уровня предназначен для установления, модификации и завершения мультимедийных сеансов в сетях IP. SIP прозрачно поддерживает сервисы, присущие сетям ISDN и интеллектуальным сетям, в том числе и те, что обеспечивают персональную мобильность. Пока что стандарт (т. е. RFC) находится в состоянии принятия очередного промежуточного варианта, который, впрочем, вполне работоспособен. Вследствие этого, а также потому, что в скором принятии окончательной версии никто не сомневается, разработки решений на базе SIP ведутся весьма активно. SIP создается в рамках целого направления, объединяющего несколько стандартов IETF, предназначенных для решения вопросов передачи через Internet (или, обобщая, через общедоступные сети IP) конвергированного трафика, таких, например, как протоколы RSVP, RTSP, RTP и др. Но при этом SIP функционально никак не связан с вышеупомянутыми протоколами, поскольку работает на другом уровне.
С функциональной точки зрения SIP отвечает за пять ключевых вопросов при открытии и завершении мультимедийных сеансов. Во-первых, — это определение местонахождения пользователя, т. е. конечного устройства, которое должно принять вызов (связано с персональной мобильностью). Во-вторых, — определение технических возможностей конечного устройства, т. е. поддерживаемых типов трафика и их параметров. В-третьих, — доступность пользователя, в том числе и получение его согласия принять участие в сеансе. В-четвертых, — открытие сеанса, что сводится к заданию технических параметров сеанса и организации вызова. И. наконец, поддержка сеанса — собственно передача трафика и прекращение диалога.
SIP является полностью текстовым протоколом. в чем-то аналогичным НИР и другим протоколам, используемым в Internet. И это неудивительно, поскольку IETF старается придерживаться одной и той же идеологии, согласно которой интерфейс Web, очевидно, рассматривается если не как основной, то как приоритетный для различных мультимедийных приложений. Поскольку сам SIP непосредственно за передачу трафика не отвечает, а только обслуживает работу сеансов, накладные расходы на сам протокол все равно будут незначительными, зато использование текста позволяет интегрировать SIP с такими средствами. как Java или Perl, а также легко расширять протокол при необходимости.
SIP оперирует многими понятиями, принятыми в HTTP: например, для SIP также существует понятие «URL». Адресат SIP всегда представляется как user@host, и его адрес может быть, аналогично тегу mailto представлен в виде гиперссылки. Точно так же. как в электронной почте. sip:someone@somewhere может означать и одного пользователя, и группу пользователей, а также — первого доступного пользователя из группы. Очевидно, что URL SIP (собственно адрес) может совпадать и с адресом электронной почты — это заложено идейно в концепцию единого универсального адреса, которой придерживается и SIP. Однако буквальное совпадение необязательно, так как почтовый адрес может быть автоматически преобразован в адрес SIP путем добавления соответствующего префикса к домену. Это, впрочем, уже детали, которые свидетельствуют о том, что механизмы установления связи и. в частности, поиска абонента или сервера SIP чрезвычайно близки к уже используемым в Web: в качестве основного средства поиска применяется DNS (для SIP вводится дополнительный идентификатор сервиса).
Основными элементами архитектуры SIP являются UAC (User Agent Client) — клиентское приложение, инициирующее запрос SIP. UAS (User Agent Server) — приложение, принимающее запрос и отвечающее на него от имени пользователя (и оповещающее пользователя) и UA-комбинация двух предыдущих приложений (User Agent). Кроме того, в архитектуре SIP функционально выделяются серверы определения местонахождения абонентов, серверы переадресации и proxy-серверы. Различия между двумя последними заключаются в том, что proxy-сервер, как и обычно, может «притвориться» как сервером, так и клиентом — т. е. инициировать запросы или отвечать на них. а сервер переадресации работает прозрачно. Наличие такого большого количества элементов с дублированием многих функций обуславливается тем, что предназначение SIP состоит в установлении и поддержке сеансов максимально эффективным и надежным (в том числе и с точки зрения защищенности) способом.
Работа SIP реально мало зависит от того, какие протоколы используются в качестве транспорта — UDP или TCP. UDP дает приложениям возможность более точно отслеживать время передачи сообщений и производить параллельный поиск абонентов, a TCP. например. проще обрабатывается межсетевыми экранами. Один сеанс SIP может задействовать одновременно как одно, так и несколько соединений TCP для различных запросов. Это позволяет, в частности, динамично менять состав конференции (в случае многостороннего сеанса) или другие ее параметры. Хотя SIP, в принципе, ориентирован на среду Internet, он может работать непосредственно в сетях ATM. frame relay. IPX и др. За исключением требования поддержки основных элементов, стандарт пока явно не определяет, как именно должна осуществляться реализация протокола.
Как можно видеть, в отличие от Н.323. SIP не отвечает сразу за все — от кодирования речи и видео до управления сеансами связи. Его предназначение — организация мультимедийных сеансов вне зависимости от их типа. Очевидно, что в конкретных приложениях разработчики будут использовать помимо SIP многие уже зарекомендовавшие себя технологии. например те же кодеки или алгоритмы подавления эха. Благодаря этому не существует проблем, связанных с организацией шлюзов между SIP и тем же Н.323. поэтому многие операторы существующих сетей 1Р-теле-фонии на базе Н.323 твердо заявляют, что готовы к переходу на SIP. Под переходом, правда. понимается выбор SIP в качестве решения для новых сетей (или участков сетей), уже существующие сети вряд ли будут так радикально модернизироваться.
