Sip refer что это

Взаимодействие клиентов SIP. Часть 1

Месяц назад я начал свое знакомство с IP-телефонией, а именно с Lync и Asterisk. И заметил следующую картину: в сети очень много интересных статей по практической стороне вопроса (как и что делать) и очень мало внимания уделено теории (в конце статьи приведены ссылки). Если Вы хотите разобраться с SIP, то извольте либо читать RFC 3261, либо одну из «этих толстых книг». Это, естественно, полезно, но многим хочется в начале изучить некую выжимку, а уж потом бросаться в омут с головой. Эта статья как раз для таких людей.

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

Простое взаимодействие клиентов

Взаимодействие клиентов в рамках SIP чаще всего осуществляется в виде диалога.

Диалог – это равноправное взаимодействие двух User Agent (UA) в виде последовательности SIP-сообщений между ними. При этом, существуют запросы, не образующие диалогов. Однако обо всем по-порядку.

Ниже приведен пример простого взаимодействия между двумя устройствами с поддержкой SIP:

Петр хочет начать обмен сообщениями с Иваном, для этого он посылает INVITE-сообщение с данными о типе сессии (простая, мультимедиа и т.д.). Сообщения имеют следующий формат: стартовая строка, одно или несколько полей заголовка, пустая строка, обозначающая конец полей заголовка и необязательное тело сообщения.

Стартовая строка содержит метод, Request-URI и версию SIP (актуальная – 2.0). Request-URI – это SIP-адрес ресурса, которому посылается запрос.

Поля заголовков имеют следующий формат: :

Первая строка начинается с заголовка Via. Каждое SIP-устройство, создающее или пересылающее сообщение, добавляет свой адрес в поле Via (как это происходит, я планирую показать в следующей части статьи). Обычно адрес представляет собой имя хоста, которое может быть разрешено с помощью DNS-запроса. Поле Via содержит версию SIP, знак “/”, пробел, транспортный протокол (UDP, TCP, TLS, SCTP), двоеточие, номер порта и branch – идентификатор транзакции. Ответы на этот запрос будут содержать такой же номер транзакции.

Чаще всего, значение branch начинается с “z9hG4bK”. Это значит, что запрос был сгенерирован клиентом, поддерживающим RFC 3261 и параметр уникален для каждой транзакции этого клиента.

Следующее поле, Max-Forwards, содержит относительно большое целое число. Каждый сервер SIP, который пересылает сообщение, уменьшает это число на единицу. Данное поле обеспечивает простой механизм обнаружение петель (loop).

Следом идут поля From и To, которые описывают отправителя и получателя запроса. Важно, что SIP-запросы маршрутизируются исходя из Request-URI, указанного в стартовой строке (см. выше). Это объясняется тем, что поля From и To могут быть изменены при пересылке. Если используется отображаемое имя (например, Ivan Ivanov), то SIP URI помещается внутрь пары угловых скобок. Параметр tag в поле From генерирует отправляющая сторона. В свою очередь принимающая сторона поместит свой tag в поле To.

Поле Call-ID – идентификатор вызова. Совокупность tag’ов из полей From и To и Call-ID однозначно идентифицируют данный диалог. Это необходимо, так как между клиентами может идти сразу несколько диалогов.

Следующее поле, Cseq, содержит порядковый номер запроса и название метода. В данном случае – INVTITE. Номер увеличивается с каждым новым запросом.

Поля Via, Max-Forwards, To, From, Call-ID и CSeq составляют минимальный необходимый набор полей заголовков SIP-сообщения.

Для сообщения INVITE также необходимо поле заголовка Contact, в котором содержится SIP URI, относящийся к коммуникационному устройству отправляющей стороны. Это поле используется, чтобы из всех устройств, которыми одновременно может пользоваться Петр, ответ был отправлен именно на данное устройство. Обратите внимание на значения полей From и Contact. Первый раз я не заметил разницу:

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

Поля Content-Type и Content-Length отвечают за описание тела сообщения. В данном случае будет использоваться Session Description Protocol (SDP). Размер сообщения вычисляется с учетом символов перевода строки:

Детальное описание работы протокола SDP заслуживает отдельной статьи, поэтому ниже приведена только краткая расшифровка:

В ответ на INVITE SIP-клиент Ивана отправляет два сообщения: 180 Ringing и 200 OK. Первое сообщает, что на стороне Ивана SIP-клиент подает звуковой сигнал звонка, второе – подтверждает установку диалога. Разберемся с каждым из них.

Так будет выглядеть сообщение 180 Ringing:

Бледным выделен текст, который не изменился по сравнению с сообщением INVITE.

Обратите внимание на поля заголовков To и From. Несмотря на то, что данное сообщение идет со стороны Ивана, значения полей остаются такими же, как были в первоначальном запросе (от Петра к Ивану). Это объясняется тем, что данные поля определяют направление запроса, а не сообщения.

Строка Via также перекочевала из исходного запроса, в конце строки добавлен параметр received этот параметр содержит IP-адрес, с которого пришел запрос. Обычно это адрес, который может быть получен путем разрешения URI, содержащегося в Via.

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

Наконец, в поле Contact содержится актуальный адрес Ивана.

Так выглядит сообщение 200 ОК, которое отправил SIP-клиент Ивана:

Думаю, смысл всех полей, относящихся к протоколу SIP теперь ясен.

В ответ на 200 ОК клиент Петра отправляет подтверждение:

Данное сообщение подтверждает, что клиента Петра успешно получил ответ от клиента Ивана. Оба клиента договорились о параметрах меди-сессии, которая будет осуществляться по протоколу RTP.

Обратите внимание, что номер последовательности CSeq все еще равен единице, но в качестве метода уже стоит ACK. Параметр Branch в поле Via содержит новый идентификатор транзакции, так как ACK, отправляемый в ответ на 200 OK считает новой транзакцией.

Теперь давайте рассмотрим, как происходит завершение медиа-сессии. Клиент Петра посылает BYE-запрос для завершение сессии:

Получив запрос на завершение сессии, клиент Ивана посылает подтверждение:

Мы рассмотрели простой вариант работы протокола SIP. Обратите внимание, что в разные моменты времени клиенты Ивана и Петра выступали то в роли сервера, то в роли клиента, поэтому во всех SIP-клиентах должна функционировать как серверная (User Agent Server или UAS), так и клиентская часть (User Agent Client или UAC).

В следующей статье я планирую рассмотреть взаимодействие клиентов SIP с использованием Proxy-сервера и регистрацию клиентов на Proxy-сервере.

Источник

RFC SIP

Тем, кто соберётся делать собственную реализацию протокола SIP, пригодится список RFC, описывающих протокол и его дополнения:

SIP- запросы

Но в процессе развития, в протокол было добавлено еще несколько типов запросов, которые дополнили его функциональность:

Адресация SIP

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

В начале SIP- адреса ставится слово «sip:», указывающее, что это именно SIP- адрес. Примеры SIP- адресов:

В SIP поддерживает функции messaging и presence. Первая обеспечивает обмен в реальном времени короткими сообщениями (как ICQ на ПК или SMS в сетях GSM), вторая позволяет определять состояние абонента, т. е. на месте ли он, не занят ли и т. д. (в ICQ тоже есть такая возможность). Благодаря этим двум функциям SIP позволяет реагировать на события, а также рассылать сообщения «по событию».

IP-интеграция

Подобные сервисы могут создавать три группы людей: производители SIP- оборудования, сервис-провайдеры и сами конечные пользователи. Язык CPL несложен, так что, видимо, многие будут способны реализовать вполне изощренную схему работы автоответчика: скажем, если позвонивший набирает цифру 1, он переключается на домашний телефон абонента, если 2 – на сотовый, если 3 – на телефон его родителей и т. д. А почему бы не написать скрипт, который, когда раздастся звонок, показывал бы вам лицо (фотографию) звонящего? Телефон ресторана мог бы, скажем, сразу выдавать на дисплей сегодняшнее меню, – короче говоря, возможности здесь ограничены только фантазией пользователя.

Поскольку все современные ERP-, CRM- и т. п. системы работают по протоколу IP, SIP без особых проблем интегрируется с ними (в отличие от H.323, которому его телефонная природа мешает взаимодействовать с большинством приложений).

Сценарий установления соединения

между пользователями

Первый пользователь снимает трубку и набирает номер, SIP-клиент генерирует сигнал INVITE (приглашение), у второго пользователя звонит телефон, его SIP-клиент выдает сообщение 180 (Ringing, звонок), затем пользователь берет трубку, SIP-клиент выдает сообщение 200 (OK), первый SIP-клиент посылает второму сигнал ACK (подтверждение) – и далее начинается передача голосового потока по протоколу RTP (Real-time Transport Protocol). Когда разговор окончен и один из пользователей вешает трубку, SIP-клиент посылает сигнал BYE. Вот и все.

в сети предприятия

Но такая схема абсолютно неэффективна, когда клиентов в сети не два, а два миллиарда. SIP-сетям с большим числом пользователей необходима инфраструктура, и ее создают различные серверы SIP. Сервер регистрации (registrar) занимается учетом и авторизацией пользователей, сервер локализации (allocation) ищет их и определяет их местонахождение, сервер переадресации (redirect) переводит звонки абонентам туда, где они фактически находятся в данный момент, – если меня, например, нет в Москве, потому что я уехал в Америку, сервер переведет звонок на мой американский номер. Наиболее сложные функции ложатся на прокси-сервер (SIP Proxy), обеспечивающий взаимодействие внутренней (например, учрежденческой) IP-телефонной сети с внешним миром, – именно он определяет все политики, правила общения и т. д. Существуют и другие серверы SIP (например, сервер конференций), но они менее важны. На рисунке показано, как может работать SIP в сети предприятия.

Пользователь Алиса приходит на свое рабочее место в компании Example, включает в корпоративную сеть ноутбук и активизирует имеющийся на нем программный телефон, который автоматически регистрируется на сервере регистрации. Тот, в свою очередь, запрашивает информацию о пользователе в корпоративной базе данных и сообщает о том, как с ним контактировать, серверу локализации. (Оба сервера могут интегрироваться с различными базами данных, службами каталогов типа LDAP или MS Active Directory и т. д.) Теперь, когда кто-нибудь позвонит Алисе, прокси-сервер, запросив сервер локализации, установит связь с ее рабочим местом.

Аутентификация и авторизация SIP 2.0

Прохождение авторизации в SIP протоколе зависит от «Что такое realm sip?», различного для каждого защищаемого домена.

md5 алгоритм на входе принимает любую длину символов и на выходе выдать 128-битный отпечаток (finger-print) или профиль сообщения (message digest), которое было подано на вход алгоритма. Гипотетически считается, что два сообщения, которые имеют один и тот же профиль сообщения или выработаны любым сообщением, имеют определенный профиль сообщения.

Message digest — коротка цифровая строка фиксированной длины, формируется из более длинного сообщения с использованием специального алгоритма. Алгоритм md5 назначен для цифровой подписи (digital signature) приложений, где большие файлы должны быть «сжаты» в безопасный способ, до того как они будут закриптованы с помощью публичного или скрытого ключа с помощью криптосистемы с открытым ключом, например RSA. Digital signature — цифровая подпись, которая является уникальным электронным идентификатором, обеспечивающим проверку сообщения с установлением подлинности отправителя и гарантии то, что документ не был изменен с момента подписания.

Последовательность действий для авторизации клиентского оборудования на сервере.

На третьем этапе абонент высылает серверу строку в сообщении REGISTER

Источник

SIP протокол

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

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

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

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

Запросы

АСК — Подтверждает приём ответа на запрос INVITE.

BYE — Завершает сеанс связи. Может быть передан любой из сторон, участвующих в сеансе.

CANCEL — Отменяет обработку ранее переданных запросов, но не влияет на запросы, которые уже закончили обрабатываться.

REGISTER — Переносит адресную информацию для регистрации пользователя на сервере определения местоположения.

OPTION — Запрашивает информацию о функциональных возможностях терминала.

Но в процессе развития, в протокол было добавлено еще несколько типов запросов, которые дополнили его функциональность:

PRACK — временное подтверждение

SUBSCRIBE — подписка на получение уведомлений о событии

NOTIFY — уведомление подписчика о событии

PUBLISH — публикация события на сервере

INFO — передача информации, которая не изменяет состояние сессии

REFER — запрос получателя о передаче запроса SIP

MESSAGE — передача мгновенных сообщений средствами SIP

UPDATE — модификация состояния сессии без изменения состояния диалога

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

1ХХ — Информативные ответы показывают, что запрос находится в стадии обработки. Наиболее распространённые ответы данного типа 100 Trying, 180 Ringing, 183 Session Progress.

2ХХ — Финальные ответы означающие, что запрос был успешно обработан. В настоящее время в данном типе определён только один ответ — 200 OK.

3ХХ — Финальные ответы информирующие оборудование вызывающего пользователя о новом местоположении вызываемого пользователя, например ответ 302 Moved Temporary.

4ХХ — Финальные ответы информирующие об ошибке при обработке или выполнении запроса, например 403 Forbidden или классический для протокола HTTP, ответ 404 Not Found.

5ХХ — Финальные ответы информирующие о том, что запрос не может быть обработан из-за отказа сервера, 500 Server Internal Error.

6ХХ — Финальные ответы информирующие о том, что соединение с вызываемым пользователем установить невозможно, например ответ 603 Decline означает, что вызываемый пользователь отклонил входящий вызов.

Источник

База знаний

Протокол SIP

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

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

Также, протокол SIP может преодолевать ограничение, связанные с использованием NAT или файрволов. (Обратите внимание на раздел: NAT and VOIP)

Протокол SIP

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

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

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

Расширение функций протокола 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. Возможно также взаимодействие протокола SIP с системами сигнализации ТфОП – DSS1 и ОКС7. Для упрощения такого взаимодействия сигнальные сообщения протокола SIP могут переносить не только специфический SIP адрес, но и телефонный номер формата Е.164 или любого другого формата. Кроме того, протокол SIP, наравне с протоколами H.323 и ISUP/IP, может применяться для синхронизации работы устройств управления шлюзами; в этом случае он должен взаимодействовать с протоколом MGCP. Другой важной особенностью протокола SIP является то, что он приспособлен к организации доступа пользователей сетей IP телефонии к услугам интеллектуальных сетей, и существует мнение, что именно этот протокол станет основным при организации связи между указанными сетями.

Методы SIP протокола, определенные в SIP RFC.

В протоколе SIP определено несколько методов, используемых при коммуникации.

Расширенные методы SIP протокола из других RFC:

Ответы на SIP сообщения

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

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

Источник

Методы и заголовки протокола SIP

Accept
Accept-Encoding
Accept-Language
Alert-Info
Call-ID
Call-Info
CSeq
Contact

Date
Expires
From
To
Record-Route
Route
Timestamp
Via

Content-Disposition
Content-Encoding
Content-Language

Authorization
Max-Forwards
Organization Priority
Proxy-Authorization

Proxy-Require
Route Require
Subject
User-Agent

Allow
Error-Info
Proxy-Authenticate
Retry-After

Unsupported
Server
Warning
WWW-Authenticate

Источник