Протокол установления сеанса

Запрос «SIP» перенаправляется сюда; см. также другие значения.

Пример сети на базе протокола SIP

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

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

Разработчики протокола SIP

Разработкой SIP занималась организация IETF MMUSIC Working Group. Протокол начал разрабатываться в 1996 году Хенингом Шулзри (Henning Schulzrinne, Колумбийский университет) и Марком Хэндли (Университетский колледж Лондона). В ноябре 2000 года SIP был утверждён как протокол сигнализации проекта 3GPP и основной протокол архитектуры IMS (модификация 3GPP TS.24.229). SIP — один из протоколов, активно использующихся для передачи речи через интернет (Voice over IP), наряду с H.323.

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

В основу протокола рабочая группа MMUSIC заложила следующие принципы:

• Простота: включает в себя только шесть методов (функций)
• Независимость от транспортного уровня, может использовать UDP, TCP, ATM и т. д.
• Персональная мобильность пользователей. Пользователи могут перемещаться в пределах сети без ограничений. Это достигается путём присвоения пользователю уникального идентификатора. При этом набор предоставляемых услуг остается неизменным. О своих перемещениях пользователь сообщает с помощью сообщения REGISTER своему серверу.
• Масштабируемость сети. Структура сети на базе протокола SIP позволяет легко её расширять и увеличивать число элементов.
• Расширяемость протокола. Протокол характеризуется возможностью дополнять его новыми функциями при появлении новых услуг.
• Интеграция в стек существующих протоколов Интернет. Протокол SIP является частью глобальной архитектуры мультимедиа, разработанной комитетом IETF. Кроме SIP, эта архитектура включает в себя протоколы RSVP, RTP, RTSP, SDP.
• Взаимодействие с другими протоколами сигнализации. Протокол SIP может быть использован совместно с другими протоколами IP-телефонии, протоколами ТфОП, и для связи с интеллектуальными сетями.

Дизайн протокола

Клиенты SIP традиционно используют порт 5060 TCP или UDP для соединения элементов SIP-сети. В основном, SIP используется для установления и разъединения голосовых и видеозвонков. При этом он может использоваться и в любых других приложениях, где требуется установка соединения, таких, как системы оповещения, мобильные терминалы и так далее. Существует большое количество рекомендаций RFC, относящихся к SIP и определяющих поведение таких приложений. Для передачи самих голосовых и видеоданных используют другие транспортные протоколы, чаще всего RTP.

Главной задачей разработки SIP было создание сигнального протокола на базе IP, который мог бы поддерживать расширенный набор функций обработки вызова и услуг, представленных в существующей ТфОП. Сам протокол SIP не определяет этих функций, а сосредоточен только на процедурах регистрации пользователя, установления и завершения вызова и соответствующей сигнализации. При этом он был спроектирован с поддержкой таких функциональных элементов сети, как прокси-серверы (Proxy Servers) и Пользовательские Агенты (User Agents). Эти элементы обеспечивают базовый набор услуг: набор номера, вызов телефонного аппарата, звуковое информирование абонента о статусе вызова.

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

SIP используется вместе с несколькими другими протоколами и участвует только в сигнальной части сессии связи. SIP выполняет роль носителя для SDP, который описывает параметры передачи медиаданных в рамках сессии, например используемые порты IP и кодеки. В типичном применении сессии SIP — это просто потоки пакетов RTP. RTP является непосредственным носителем голосовых и видео данных.

Первая предложенная версия стандарта (SIP 2.0) была определена в RFC 2543. Протокол был дополнительно уточнён в RFC 3261, хотя многие реализации по-прежнему основаны на промежуточных версиях стандарта. Обратите внимание, что номер версии остался 2.0.

Адресация

Для организации взаимодействия с существующими приложениями сетей IP и для обеспечения мобильности пользователей, SIP использует адрес, подобный адресу электронной почты. В качестве вызываемых и вызывающих адресов используются универсальные указатели ресурсов URI, так называемые SIP URI, обычно имеющие формат sip:идентификатор@домен, где «идентификатор» представляет собой имя или номер телефона абонента, а «домен» определяет сервер или IP-АТС, которые могут быть заданы доменным именем или адресом IP.
Примеры:

• логин_абонента@Доменное.имя
• доменное.имя.устройства@IP-адрес
• № телефона@адрес. VoIP.шлюза.

Стандарт URI задан в RFC 3986.

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

Имена пользователей представляют собой обычные алфавитно-цифровые идентификаторы. В IP-телефонии, как правило, используют чисто цифровые идентификаторы («номера») для удобства расширения/замены классических телефонных сетей. Номера местной связи, как правило, 2-3-4-значные.

Номер телефона, передаваемый шлюзу — любой доступный через него, он может быть как номером местной связи, так и номером мобильного или городского телефона. Адрес шлюза (адрес IP или доменное имя) задаётся в настройках телефона или программы-клиента, а пользователю для совершения звонка достаточно только набора номера.

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

Протокол SIP имеет клиент-серверную архитектуру.

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

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

Терминал

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

Сервер (UAS) и клиент (UAC) имеют возможность непосредственно взаимодействовать с пользователем. Другие клиенты и серверы SIP этого делать не могут.

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

Прокси-сервер (от англ. proxy — «представитель») представляет интересы пользователя в сети. Он принимает запросы, обрабатывает их и выполняет соответствующие действия. Прокси-сервер состоит из клиентской и серверной частей, поэтому может принимать вызовы, инициировать запросы и возвращать ответы.
Прокси-сервер может не изменять структуру и содержимое передаваемых сообщений, лишь добавляя свою адресную информацию в специальное поле Via.

Предусмотрено два типа прокси-серверов

• с сохранением состояний (stateful). Такой сервер хранит в своей памяти все полученные запросы и связанные с ним новые сформированные запросы до окончания транзакции.
• без сохранения состояний (stateless). Такой сервер просто обрабатывает получаемые запросы. Но на его базе нельзя реализовать сложные, интеллектуальные услуги.

Прокси может указать пользователю в ответ на первый запрос, на необходимость дополнительных для аутентификации — как минимум логина (ответ 407 Proxy authentification required), а также параметров цифровой аутентификации для обеспечения безопасности.

Сервер B2BUA

B2BUA — (англ. back-to-back user agent, буквально: «пользовательский агент спина-к-спине») — вариант серверного логического элемента в приложениях, работающих с протоколом SIP. По идеологии работы B2BUA похож на прокси-сервер SIP, однако есть принципиальные различия. Сервер B2BUA работает одновременно с несколькими (как правило, двумя) конечными устройствами — терминалами, разделяя вызов или сеанс на разные плечи-участки. С каждым участком B2BUA работает индивидуально, как UAS — по отношению к инициатору и как UAC — по отношению к терминалу, принимающему вызов. При этом сигнальные сообщения передаются в рамках сеанса в обе стороны синхронно, хотя решение о необходимости передачи сообщения и его формате принимается B2BUA для каждого участка в индивидуальном порядке. Каждый из участников соединения (сеанса связи) на уровне сигнализации взаимодействует с B2BUA как с оконечным устройством, хотя в действительности сервер является посредником. Это отражается в адресных полях (таких как From, To и Contact) сообщений, отправляемых сервером B2BUA. Таким образом, ключевое отличие B2BUA — полностью независимая сигнализация всех участков вызова. Это означает, в частности, что для взаимодействия с каждым отдельным пользователем в рамках сеанса связи используются уникальные идентификаторы, а содержимое одних и тех же сообщений для разных участков будет различным. Пользовательские агенты оконечных терминалов могут взаимодействовать с B2BUA и при участии прокси-серверов.

Сервер B2BUA может предоставлять следующие функции:

• Управление звонками (биллинг, перевод звонка, автоматическое разъединение и т. д.)
• Сопряжение разных сетей (в частности, для адаптации разных диалектов протокола, зависимых от производителей)
• Сокрытие структуры сети (частные адреса, сетевая топология и т. п.)

Довольно часто B2BUA является частью медиашлюза для того, чтобы полностью управлять медиапотоками в рамках сессии. Сигнальный шлюз, являющийся частью пограничного контроллера соединений/сеансов — наглядный пример применения B2BUA.

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

Сервер переадресации (Redirect Server) используется для перенаправления вызова по адресу текущего местоположения пользователя. Сервер переадресации не терминирует вызовы и не инициирует собственные запросы, а только сообщает новый номер для переадресации, или адрес необходимого терминала или адрес прокси-сервера при помощи ответов класса 3XX (301 Moved Permanently, 302 Moved Temporarily или 300 Multiple Choice). Дополнительная информация о вызываемом пользователе — новый адрес и/или номер телефона для последующего перенаправления запроса далее передается в ответе от сервера переадресации в поле Contact (например ответ 300 Multiple choice может содержать несколько строк типа Contact с новой информацией для перенаправления вызова).

Для целей получения информации для перенаправления сервер переадресации может взаимодействовать с SIP-регистратором или сервером определения местоположения.

Однако, для осуществления соединения пользователь может не использовать сервер переадресации, если он сам знает текущий адрес требуемого пользователя.

Сервер регистрации (регистратор)

Процесс регистрации SIP User Agent на SIP регистраторе с аутентификацией по логину

Протокол SIP подразумевает мобильность пользователя, то есть пользователь может перемещаться в пределах сети, получая новый адрес. Поэтому в SIP существует механизм регистрации — уведомление о новом адресе со стороны пользовательского агента. Сервер регистрации или регистратор (registrar) служит для фиксации и хранения текущего адреса пользователя и представляет собой регулярно обновляемую базу данных адресной информации. В общем случае, пользователь сообщает серверу регистрации свою адресную информацию, такую как IP-адрес или доменное имя и абонентский телефонный номер — при помощи запроса REGISTER. Сервер может подтвердить успешную регистрацию (200 OK) или отклонить в случае, если есть проверка данных и учётная запись пользователя не найдена (404 Not found) или регистрация для пользователя запрещена в данный момент (403 Forbidden). Регистратор может указать на необходимость логина пользователя для проверки (401 Unauthorized), при этом может предложить клиенту провести аутентификацию на основе зашифрованного пароля. В качестве источника информации для аутентификации пользователя может выступать устройство или ПО, не использующее протокол SIP (например СУБД, MS Exchange, RADIUS-сервер и т. п.).

Регистрация терминала пользователя на сервере имеет определённый «срок жизни» и должна подтверждаться новым запросом REGISTER со стороны клиента, в противном случае адресная информация может быть удалена. Информация о продолжительности таймера «срока жизни» регистрации в секундах передается каждой стороной в поле Expires. Сервер выбирает наименьшее значение таймера из информации полученной от клиента и из собственных параметров, определяет таким образом время действия регистрация и передает окончательное значение таймера клиенту в поле Expires в 200 OK при подтверждении регистрации. Клиент может также прислать запрос с нулевым временем жизни регистрации в поле Expires' — это запрос на принудительное удаление адресной информации из сервера (т.е. завершение или удаление регистрации по инициативе клиента).

В различных реализациях SIP-сетей может встречаться сочетание сервера регистрации и других серверов в едином приложении или устройстве, работающем через один сокет на одном порту (обычно UDP/5060) — то есть единую точку получения и обработки запросов. Так зачастую регистраторы совмещаются с сервером переадресации, B2BUA или SIP-прокси. Например, многие программные АТС (например, Asterisk, Yate, РТУ) содержат функционал SIP-регистратора с проверкой регистрационных данных каждого пользователя. Информация о возможностях пользователя зарегистрироваться и устанавливать соединения определяются в данном случае его единой учётной записью. В свою очередь абонентское оборудование IP-телефонии (телефоны, абонентские шлюзы) в большинстве случаев требуют обязательной предварительной регистрации на сервере для дальнейшей работы в телефонной сети.

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

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

Пользователь может перемещаться в пределах разных сетей, кроме того, подлинный адрес пользователя может быть и неизвестным, даже если его номер известен. Это актуально, в частности для услуги переносимости номера (LNP/MNP). Для решения таких задач существует механизм определения местоположения пользователя при помощи сторонних средств, не имеющих прямого отношения к SIP — сервер определения местоположения (англ. Location Server), который хранит текущий адрес пользователя и представляет собой регулярно обновляемую базу данных адресной информации.

Пользователь, которому нужна адресная информация другого пользователя для установления соединения, не связывается с сервером определения местоположения напрямую. Эту функцию выполняют другие SIP-серверы при помощи протоколов LDAP, RWHOIS, ENUM, RADIUS или других протоколов.

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

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

Структура сообщений протокола SIP
Стартовая строка
Заголовки
Пустая строка
Тело сообщения

• Стартовая строка начинает любое SIP-сообщение. Если сообщение является запросом, в ней указывается тип запроса, адресат и номер версии протокола. Если сообщение является ответом на запрос, в ней указывается номер версии протокола, тип ответа и его короткая расшифровка.
• Заголовки сообщений содержат информацию, необходимую для обработки сообщения (информация об отправителе, адресате, пути следования и пр.)
• Пустая строка (CL-RF) отделяет заголовок SIP сообщения от содержания, которое включает информацию по описанию будущей сессии при помощи протоколов SDP (RFC2327)
• Тело сообщения содержит описание сеансов связи. Не все запросы содержат тело сообщения (например, запрос BYE). Все ответы могут содержать тело сообщения, но содержимое тела в них бывает разным.

Пример запроса INVITE:

INVITE sip:nikolia@example.ru SIP/2.0
Record-Route: <sip:nikolia@10.0.0.10;lr>
Via: SIP/2.0/UDP 10.0.0.10;branch=z9hG4bK3af7.0a6e92f4.0
Via: SIP/2.0/UDP 192.168.0.2:5060;branch=z9hG4bK12ee92cb;rport=5060
From: "78128210000" <sip:78128210000@neutral.ru>;tag=as149b2d97
To: <sip:nikolia@example.ru>
Contact: <sip:78128210000@neutral.ru>
Call-ID: 3cbf958e6f43d91905c3fa964a373dcb@example.ru
CSeq: 103 INVITE
Max-Forwards: 16
Date: Wed, 10 Jan 2001 13:16:23 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 394

v=0
o=root 3303 3304 IN IP4 10.0.0.10
s=session
c=IN IP4 10.0.0.10
t=0 0
m=audio 40358 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=sendrecv

Запросы

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

1. INVITE — приглашает пользователя к сеансу связи. Обычно содержит SDP-описание сеанса.
2. ACK — подтверждает приём ответа на запрос INVITE.
3. BYE — завершает сеанс связи. Может быть передан любой из сторон, участвующих в сеансе.
4. CANCEL — отменяет обработку ранее переданных запросов, но не влияет на запросы, которые уже закончили обрабатываться.
5. REGISTER — переносит адресную информацию для регистрации пользователя на сервере определения местоположения.
6. OPTIONS — запрашивает информацию о функциональных возможностях сервера.

В дальнейшем протокол был расширен, в него добавили ещё несколько типов запросов:

1. PRACK — временное подтверждение (RFC 3262).
2. SUBSCRIBE — подписка на получение уведомлений о событии (RFC 3265).
3. NOTIFY — уведомление подписчика о событии (RFC 3265).
4. PUBLISH — публикация события на сервере (RFC 3903).
5. INFO — передача информации, которая не изменяет состояние сессии (RFC 2976).
6. REFER — запрос получателя о передаче запроса SIP (RFC 3515).
7. MESSAGE — передача мгновенных сообщений средствами SIP (RFC 3428).
8. UPDATE — модификация состояния сессии без изменения состояния диалога (RFC 3311).

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

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

1. 1ХХ — информационные ответы; показывают, что запрос находится в стадии обработки. Наиболее распространённые ответы данного типа — 100 Trying, 180 Ringing, 183 Session Progress.
2. 2ХХ — финальные ответы, означающие, что запрос был успешно обработан. В настоящее время в данном типе определены только два ответа — 200 OK и 202 Accepted(прим. 202 кода нет в RFC 3261).
3. 3ХХ — финальные ответы, информирующие оборудование вызывающего пользователя о новом местоположении вызываемого пользователя, например, ответ 302 Moved Temporary.
4. 4ХХ — финальные ответы, информирующие об отклонении или ошибке при обработке или выполнении запроса, например, 403 Forbidden или классический для протокола HTTP ответ 404 Not Found. Другие примеры: 406 Not Acceptable — неприемлемый (по содержанию) запрос, 486 Busy Here — абонент занят или 487 Request Terminated — вызывающий пользователь разорвал соединение не дожидаясь ответа (отмена запроса).
5. 5ХХ — финальные ответы, информирующие о том, что запрос не может быть обработан из-за отказа сервера, 500 Server Internal Error.
6. 6ХХ — финальные ответы, информирующие о том, что соединение с вызываемым пользователем установить невозможно, например, ответ 603 Decline означает, что вызываемый пользователь отклонил входящий вызов.

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

Протокол SIP является управляющим протоколом для установления, модификации и разрыва соединения, ориентированного на передачу потоковых данных. Параметры передачи медиапотоков описываются в протоколе SIP посредством SDP (протокол описания сессии). Потоковые медиаданные могут передаваться различными средствами, среди которых наиболее популярны транспортные протоколы RTP и RTCP.

Протокол SIP определяет 3 основных сценария установления соединения: с участием прокси-сервера, с участием сервера переадресации и непосредственно между пользователями. Сценарии различаются по тому, как осуществляется поиск и приглашение вызываемого пользователя. Основные алгоритмы установления соединения описаны в RFC 3665.

Пример сценария установления соединения с участием SIP сервера переадресации и SIP Proxy

Алиса делает запрос на своем терминале и осуществляет поиск информации о терминале Бориса. Сервер переадресации выдает информацию о том, что связаться с Борисом можно через другой адрес - адрес прокси-сервера. Терминал Алисы делает запрос на прокси-сервер, тот в, свою очередь пересылает запрос на терминал Бориса. От терминала Бориса поступает информация о том, что пользователь найден и он получил звуковой сигнал о том, что его вызывают (180 Ringing), что прокси-сервер передает терминалу Алисы. Далее, когда Борис принимает вызов, соответствующее сообщение 200 OK прокси-сервер также передает терминалу Алисы и в результате устанавливается сеанс связи с передачей медиа-данных по протоколу RTP.

Пример сценария установления соединения с участием сервера B2BUA

В примере ниже медиатрафик проксируется через сервер. Сигнальные сообщения для участков Алиса — B2BUA и B2BUA — Борис являются полностью независимыми и выполняются в рамках разных сессий (изменятся как минимум адреса назначения и отправка, а также Call ID сессий). Терминал Алисы не знает реального местоположения терминала Бориса и наоборот. Так может выглядеть взаимодействие через некоторые софтсвичи или пограничные контроллеры сессий (SBC).

SIP-T и SIP-I

Для взаимодействия с традиционными телефонными сетями, использующими сигнализацию ОКС-7, были разработаны модификации протокола SIP для телефонии: Session Initiation Protocol for Telephones (SIP-T) и Session Initiation Protocol Internetworking (SIP-I). Протокол SIP-I разработан организацией ITU-T, рекомендация Q.1912.5, а SIP-T — IETF и описан в документе RFC 3372. Основная задача данных модификаций протокола SIP заключается в прозрачной передаче сообщений ISUP по IP-сети. Данная задача осуществляется путём инкапсуляции сигнальных единиц ОКС в сообщения SIP. Все требуемые задачи по взаимодействию между протоколами были решены на базе протокола SIP:

Требование по взаимодействию	Функция SIP-T
Прозрачность сигнализации ISUP	Инкапсуляция ISUP в тело сообщения SIP
Возможность маршрутизировать сообщения SIP в зависимости от параметров ISUP	Трансляция параметров ISUP в заголовке сообщения SIP
Трансляция адресной информации при установленном соединении	Использование метода INFO

Сравнение с H.323

SIP пригоден для чтения человеком и структурирован в отношении запросов и откликов. Сторонники SIP также заявляют о нём как о более простом, по сравнению с H.323. Однако некоторые эксперты склонны считать, что, в то время как первоначальной целью SIP была простота, в своём сегодняшнем виде он стал так же сложен, как и H.323. Другие эксперты обоснованно считают, что SIP, как протокол без состояний, даёт возможность легко реализовать восстановление при отказе и другие возможности, которые затруднены в протоколах с состояниями, таких как H.323. Как SIP, так и H.323, не ограничены голосовой связью, они обслуживают любой сеанс связи, от голосового до видеосеанса или приложений будущего.

Параметр сравнения	SIP	H.323
Дополнительные услуги	Набор услуг, поддерживаемых обоими протоколами примерно одинаков
Персональная мобильность пользователей	Имеется хороший набор средств поддержки мобильности	Персональная мобильность поддерживается, но менее гибко
Расширяемость протокола	Удобная расширяемость, простая совместимость с предыдущими версиями	Расширяемость поддерживается, но существует ряд сложностей
Масштабируемость сети	Оба протокола обеспечивают хорошую масштабируемость сети
Время установления соединения	Достаточно одной транзакции	Требуется несколько транзакций
Сложность протокола	Простой, мало запросов, текстовый формат сообщений	Сложный, много запросов и протоколов, двоичное представление сообщений
Совместимость оборудования	Практически никакой. Каждый производитель SIP устройств соблюдает только тот набор рекомендаций (RFC) который ему нравится, ибо набор этих рекомендаций очень велик. Совместим фактически только базовый вызов	Практически полная. Стандарты устоявшиеся и имеют чёткий набор спецификаций

Безопасность

Вопросам безопасности использования протокола SIP посвящён отдельный раздел RFC 3261. Шифрование сигнального трафика возможно на транспортном уровне через использование TLS поверх TCP/UDP. Кроме того, разработан стандарт SIPS (англ. SIPS), накладывающий дополнительные соглашения по безопасной передаче данных посредством SIP. Для шифрования мультимедийного контента применяется протокол SRTP.

См. также

• Сравнение программ для IP-телефонии
• SDP
• SCTP
• RTP
• NGN
• Softswitch
• SIMPLE
• ZRTP
• Компьютерная телефония
• Mobile VoIP

Литература

• Гольдштейн, Б. С. Протокол SIP : справочник. — СПб. : BHV-Санкт-Петербург, 2005. — 456 с. — ISBN 5-8206-0123-8.
• Гольдштейн, Б. С. IP телефония. — М. : Радио и связь, 2001. — 336  с. : ил . — ISBN 5-256-01585-0.
• Шнепс-Шнеппе, М.А. Интернет-телефония : протокол SIP и его применения. — М. : МАКС Пресс, 2002. — 286 с. — 500 экз. — ISBN 5-317-00537-X.

Ссылки

• Аношкин, С. SIP-телефония : [арх. 17 июля 2006] // iXBT.com. — 2006. — 14 июля.
• Протокол SIP // VoIp Справочник на русском языке. — 2008. — 28 ноября.