Sip uri что это
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 URI и URL. Часть 1 (URI, URL и URN)
В предыдущих двух статьях мы рассмотрели основы взаимодействия по протоколу SIP.
Далее я предлагаю разобраться с такой важной составляющей SIP, как SIP URI. Мы сталкивались с ними раньше, когда говорили о полях From, To и других, однако не уделяли им должного внимания.
В рамках этой короткой статьи мы рассмотрим, какие бывают URI и из чего они состоят. В следующей статье остановимся на URI и URL в протоколе SIP.
Викепедия говорит следующее: URI (англ. Uniform Resource Identifier) — унифицированный (единообразный) идентификатор ресурса. На английский манер произносится как [ю-ар-ай], по-русски чаще говорят [ури]. URI — это последовательность символов, идентифицирующая абстрактный или физический ресурс. Ранее назывался Universal Resource Identifier — универсальный идентификатор ресурса.
При этом URI может указывать как местоположение ресурса (URL), так и его имя (URN). А может содержать и то и другое. То есть URL и URN — это частные случаи URI.
URI строится по определенным правилам и состоит из обязательных схемы и иерархической части, а также опциональных запроса (ему предшествет знак «?») и фрагмента (ему предшествует знак «#»). Иерархическая часть в свою очередь состоит из необязательного Authority (думаю, перевод только усложнит понимание) и обязательного пути. Authority включает в себя Userinfo (логин и пароль), хост и порт. Кроме того, путь может содержать так называемые параметры. Параметры используются не часто, но нам повезло — в SIP URI они присутствуют. На схеме это выглядит вот так: 
Выглядит довольно запутанно, поэтому приведу пример: 
URL (Uniform Resource Locator) указывает путь (локацию) объекта и метод получения доступа к нему. Например, en.wikipedia.org/wiki/Main_Page указывает на главную страницу английской Википедии и в качестве метода доступа предлагает использовать протокол http.
URL описывается в RFC 1738. В этом RFC указаны описаны различные схемы для протоколов ftp, http, nntp и т.д. Послкольку URL — это частный случай URI, схема в общем случае выглядит точно так же, однако для разных протоколов актуальны те или иные ее части. Например, для протокола telnet, схема URL выглядит следующим образом: 
Интересный факт: Тим Бернерс-Ли, основоположник URL в последствии сожалел, что разделил точкой доменные имена в рамках URL. URL мог бы выглядеть вот так: 
URN не используется в рамках SIP, однако без него рассказ был бы неполным.
URN (Uniform Resource Name) является уникальным именем объекта. URN включает в себя название пространства имен и идентификатора в этом пространстве. Типичный пример URN — это ISDN-Имя книги. URN состоит из NID (namespace identifier или идентификатор пространства имен) и NSS (namespace-specific string или уникального для данного пространства имен имени). Схематично это выглядит следующим образом: 
Чтобы стало совсем понятно, приведу следующий пример. Допустим, мы хотим описать некого Ивана.
С помощью этого URN мы одназначно идентифицируем Ивана, но не сможем определить его местоположение. Здесь нам поможет URL. Выглядеть это может примерно так: машина: город N/улица M/квартира L. Где «машина» — это метод получения доступа, а «город N. » — путь.
Подведем итог. URN отвечает идентифицирует ресурс по имени и отвечает на вопрос «Что?». URL — указывает путь и метод доступа к ресурсу и отвечает на вопросы «Где?» и «Как?». При этом URN и URL — это частные случаи URI.
Звонки с помощью SIP URI
Задача:Обеспечить возможность входящих звонков по протоколу SIP без авторизации, используя адресацию SIP URI. Звонки могут осуществлять softphone, которые могут звонить без регистрации (например: PhoneLite) или различные веб-сервисы. Что такое SIP URI? SIP URI – это схема адресации SIP, используемая для вызова абонента с помощью SIP. Другими словами, SIP URI является номером SIP-телефона пользователя. SIP URI […]
Задача:
Обеспечить возможность входящих звонков по протоколу SIP без авторизации, используя адресацию SIP URI. Звонки могут осуществлять softphone, которые могут звонить без регистрации (например: PhoneLite) или различные веб-сервисы.
Что такое SIP URI?
SIP URI – это схема адресации SIP, используемая для вызова абонента с помощью SIP. Другими словами, SIP URI является номером SIP-телефона пользователя. SIP URI похож на адрес электронной почты и записывается в следующем формате.
Запись SRV, заданная на сервере доменных имен (DNS), помогает соединиться с SIP пользователем, так же как MX запись помогает доставить электронную почту на сервер адресата. Когда вы отправляете почту на адрес «john@example.com», тогда MX запись для домена example.com может указать агенту, отвечающему за доставку почты, совсем другую машину, которая является почтовым сервером для этого домена, например, «zaphod.foobar.com». Подобным образом, когда вы хотите совершить вызов на SIP телефон: запись типа SRV, может сказать Вашему компьютеру, что для этого следует подключиться к хосту «galaxy.starsystem.tw».
Target — адрес вашего сервера
В Asterisk есть мощный механизм для хранения значений, который называется базой данных Asterisk (AstDB). AstDB обеспечивает простой способ хранения данных для использования в диалплане. AstDB хранит данные в группах, которые называются семействами. Семейства определяются ключами. Например, у нас есть семейство cids, мы бы могли хранить только одно значение с ключом tamik. Каждое хранящееся значение должно быть соотносимо с каким-то семейством.
Заходим в консоль asterisk
tamik – key, имя сотрудника на которое будут звонить
102 — значение, внутренний номер сотрудника.
database show cids
В файле /etc/asterisk/sip.conf добавим строки:
Context = outcolling — контекст в котором будут обрабатываться неавторизованные пользователи
Allowguest = yes — разрешение гостевых вызовов
В файле /etc/asterisk/extensions.conf пропишем следующие:
[outcolling] — название контекста
exten => tamik,1,GoSub(sub-name,s,1($
exten => s,1,NoOp($
same => n,NoOp($
same => n,GotoIf($[«$
same => n,Dial(SIP/$
same => n,Hangup() — а тут мы сбрасываем вызов.
Сохраняем все и снова заходим в консоль астериска и перезагружаем настройки:
sip reload — перезагружает настройки sip
dialplan reload — перезагружает настройки диалплана из файла extensions.conf
Вывод: Мы поняли что такое sip uri, настроили сервер Asterisk на принятие вызовов по sip uri, научились работать с AstDB.
Взаимодействие клиентов 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 URI и URL. Часть 2 (Схема SIP URI)
SIP и SIPS URI
Поскольку схемы SIP и SIPS URI идентичны, дальше в тексте мы будем говорить только о SIP URI, подразумевая, что все это относится также и к SIPS URI.
Как вы помните из предыдущих статей, SIP URI используются в ряде мест в SIP-сообщении, в частности в заголовочных полях To, From, Contact и т.д. Кроме того sip URI, точно также, как и mailto URI могут быть использованы на сайтах в качестве гиперссылок.
В общем случае, схема sip выглядит следующим образом:
Обратите внимание, что URI не должны содержать пробелов или переводов строки.
USER и PASSWORD
Как мы помним из первой части статьи, в схеме URI совокупность user и password называется userinfo. В рамках sip, userinfo завершается знаком «@». Userinfo часть является опциональной и может отсутствовать; знак «@» при этом также должен отсутствовать.
Согласно RFC 3261, user идентифицирует определенный ресурс на хосте, При этом под хостом чаще всего подразумевается домен.
Если хост поддерживает работу с телефонными номерами, то в качестве пользователя может быть указан телефонный номер, с которым мы хотим связаться. Это актуально, например, при использовании SIP trunk.
Password позволяет передать пароль. делать это не рекомендуется, так как в данном случае пароль будет передан в открытом виде.
Хост, предоставляющий ресурс. Используется или полное доменное имя (FQDN) или IPv4/IPv6-адрес. При этом рекомендуется использовать FQDN везде, где это возможно — это позволит избежать проблем, связанных с изменением IP-адреса хоста.
Порт, на который следует отправлять запрос. Если данное поле отсутствует, то используется 5060 для SIP и 5061 для SIPS.
Параметры
Параметры воздействуют на запрос, который будет отправлен на URI.
Количество параметров может быть произвольным, но каждый из них может встречаться только один раз. Каждый новый параметр начинается со знака «;» и имеет следующий синтаксис:
transport
Определят протокол, который следует использовать для отправки сообщений. Обычно используются UDP, TCP или SCTP, однако схема позволяет указывать любой поддерживаемый SIP-клиентом протокол транспортного уровня. По умолчанию для SIP используется UDP. Для SIPS должен использоваться любой надежный протокол; по усмолчанию — TCP.
maddr
Определяет адрес сервера, но который следует посылать запросы для данного пользователя. Соответственно перезаписывает значение поля host. В случае, если в URI присутствует msddr, порт и транспорт будут относиться к нему. Обычно в maddr содержится multicast-адрес.
Определяет TTL (Time-To-Live) UDP multicast-пакета. Должен быть использован только в том случае, если в качестве транспорта используется UDP и maddr содержит multicast-адрес.
Не путать с userinfo->user. Поскольку в качестве имени пользователя может быть использован телефонный номер, следует отличать случай, когда «+79211234567» — это номер телефона, с которым нас свяжет хост, от случая, когда та же самая строчка — это имя пользователя на хосте (да, мы вполне можем создать пользователя с именем «+79211234567»). Для этого используют параметр user. По умолчанию user=ip. Это значит, что userinfo->user содержит имя пользователя на хосте. Если же user=phone, то userinfo->user — это номер телефона, с которым нас должен связать хост.
При этом важно учитывать, что данный параметр никаким образом не говорит о возможностях и характеристиках абонента, представленного данным URI. То есть, user=phone не должно нас наталкивать на мысль, что User Agent — это телефон, который не умеет работать с видео-звонками.
method
Определяет метод, который следует использовать в запросе. По умолчанию — INVITE.
Используется при маршрутизации. О нем мы поговорим в отдельной статье.
Заголовки
Заголовки, которые могут быть добавлены в запрос. Это могут быть Subject и Priority.
Ниже приведена таблица использования составных частей SIP URI схемы для различных случаев: 
В следующей статье мы рассмотрим схемы tel для телефонных номеров и pres для присутствия.