Sip branch что это

Tao, Zen, and Tomorrow

Every once in a while I feel the need to get away from SIP the architecture and write about SIP the protocol (which is a little bit like the department of redundancy department – Session Initiation Protocol Protocol). Yes, I adore all those servers and services, but it’s the bits and bytes that attracted me to SIP in the first place.

Waylon Jennings said it best in his song, “Luckenbach, Texas.”

Maybe it’s time we got back to the basics of love.

Today, I want to share the love and write about an extremely important, but sometimes misunderstood SIP header.

When a user agent client (UAC) creates a SIP request, it must insert a Via header into that request. The Via header identifies the protocol name (SIP), protocol version (2.0), transport type (e.g. UDP or TCP), IP address of the UAC, and the protocol port (typically 5060) used for the request. This information allows the recipient of the request (a user agent server) to return SIP responses to the correct device. For example, if my SIP soft-phone were to send an INVITE request, it would contain a Via similar to the following.

Via: SIP/2.0/UDP 10.11.228.67:5060

If I were operating in a point-to-point configuration, the soft-phone that received the INVITE would inspect the Via header to determine the location of my PC. It would then use that information to return a “100 Trying” response. Of course, unless I am in a lab environment, I never use SIP in a point-to-point fashion. Here at work, there are all sorts of SIP components between my soft-phone and the soft-phone I am calling. There is a Session Manager, Communication Manager, and perhaps a Session Border Controller between us. Thankfully, via headers are not reserved for endpoints. Every SIP entity uses them.

The rules for processing Via headers are very simple. Every UAC must add its own Via header before sending a SIP request. If there is already a Via header in the message, the UAC adds the new one at the top of the list before sending it to the next hop.

Remember that INVITE I sent in my example? When it ends up on the called party’s device, it might contain several Via headers. When the called party is ready to send the “100 Trying,” it simply removes the top Via header and sends the response to the indicated party. In my work configuration, that top Via would most likely identify a Session Manager. However, if the soft client was a remote user, it would be my company’s SBC. It doesn’t matter, though. Whoever receives the response will remove the top Via header and send it to the next hop. This keeps happening until the Trying message lands on my PC.

This Via stacking allows a SIP request to pass through any number of intermediaries and every recipient of that message will know exactly how to pass back any subsequent responses.

Ah, but there’s more

To keep things simple I failed to mention something important about Via headers. Along with the protocol and IP information, every Via header contains a “branch” parameter. Here is that Via again with a branch parameter I pulled from a Wireshark trace.

Via: SIP/2.0/UDP 10.11.228.67:5060; branch=z9hG4bK10_16a83292baa1de54e0b7843_I

The branch parameter must be unique across space and time for all requests sent by a user agent. The exceptions to this rule are CANCEL and ACK for non-2xx responses. A CANCEL will have the same branch parameter as the request it cancels. An ACK for a non-2xx response will have the same branch parameter as the INVITE whose response it acknowledges.

The uniqueness of the branch header is used to facilitate its use as a transaction ID. A SIP transaction is a message exchange between two user agents that starts with a request and ends with a final response. For a simple call, the INVITE through final response is one transaction, the ACK is another transaction, and the Bye through the 200 OK is yet another transaction. All these transactions combine to make a single dialog.

If you crave more knowledge about SIP message uniqueness, please see my blog, Let’s Play (SIP) Tag.

The branch parameter always begins with the same string of seven characters — “z9hG4bK.” This requirement was added to identify that the branch was created in accordance with RFC 3261 and not the older RFC 2543 which did not require global uniqueness.

Okay, that’s it. I got my protocol fix for the day. I hope you are as thrilled as I am.

Take me on out, Waylon…

So, Baby let’s sell your diamond ring

Источник

Взаимодействие клиентов 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-сервере.

Источник

Sip branch что это

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

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

Содержание

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

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

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

Клиенты 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 использует адрес, подобный адресу электронной почты. В качестве адресов рабочих станций используются универсальные указатели ресурсов URL, так называемые SIP URL:

В начале SIP-адреса (в тексте) ставится слово sip:, указывающее, что это именно SIP-адрес, так как бывают и другие c таким же форматом (например, адреса электронной почты, обозначаемые mailto:).

Адрес состоит из двух частей. Первая часть — имя пользователя, зарегистрированного в домене или на рабочей станции. Если вторая часть идентифицирует какой-либо шлюз, то в первой указывается телефонный номер абонента. Во второй части адреса указывается имя домена сети, хоста или 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 — «представитель») представляет интересы пользователя в сети. Он принимает запросы, обрабатывает их и выполняет соответствующие действия. Прокси-сервер состоит из клиентской и серверной частей, поэтому может принимать вызовы, инициировать запросы и возвращать ответы.

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

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

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

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

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

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

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

B2BUA

B2BUA — (англ. back-to-back user agent, буквально: пользовательские-агенты-спина-к-спине) — вариант логического элемента в приложениях, работающих с протоколом SIP. B2BUA работает одновременно с двумя оконечными устройствами — терминалами, разделяя звонок или сессию на два плеча-участка. С каждым участком B2BUA работает индивидуально, хотя сигнальные сообщения передаются в рамках сессии в обе стороны синхронизировано. Таким образом каждый из участников сессии, на уровне сигнализации взаимодействует с B2BUA, как с оконечным устройством, хотя в действительности он является посредником.

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

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

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

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

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

Запросы

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

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

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

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

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

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

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

SIP-T и SIP-I

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

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

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

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

Источник