Sip rfc: RFC 3261: SIP: Session Initiation Protocol

Содержание

Описание RFC протокола SIP [АйТи бубен]

  • SIP

  • voip-info: SIP

  • SIP ответы и их значения

  • Семенов Ю.А. Протокол запуска сессий SIP

  • SIP метод OPTIONS

  • Трансляция сетевых адресов (NAT) и SIP

Протокол Session Initiation Protocol (SIP), обычно применяемый в VoIP-телефонах (как аппаратных, так и программных), отвечает за установку и разъединение соединения, а также за любые изменения, происходящие во время соединения, такие как переадресации. Назначение SIP – помочь двум конечным точкам поговорить друг с другом (по возможности напрямую). Протокол SIP – это просто протокол обмена сигналами, то есть его задачей является лишь обеспечить возможность двум конечным точкам говорить друг с другом, но не работа с носителем вызова (голосом). Передача голоса осуществляется с помощью другого протокола – Real-Time Transport Protocol (транспортный протокол реального времени – RTP; RFC 3550) – для передачи медиа-данных непосредственно между двумя конечными точками.

VoIP (Voice over IP; IP-телефония) — система связи, обеспечивающая передачу речевого сигнала по сети Интернет или по любым другим IP-сетям. Сигнал по каналу связи передаётся в цифровом виде и, как правило, перед передачей преобразовывается (сжимается) с тем, чтобы удалить избыточность.

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

  • 2543: Первоначальное описание SIP/2.0

  • RFC 2976: передача информации, не изменяющей состояние сессии (метод INFO)

  • RFC 2279: Сообщения протокола SIP (запросы и ответы)

  • RFC 3261: Уточнения SIP/2.0

  • RFC 3262: Расширение протокола SIP: метод Provisional Response ACKnowledgement (PRACK) и тэг 100rel

  • RFC 3263: поиск SIP серверов с помощью DNS (записи SRV)

  • RFC 3265: подписка на получение уведомлений о событии (методы SUBSCRIBE и NOTIFY)

  • RFC 3311: Обновление сессии без изменения диалога (метод UPDATE)

  • RFC 3372: модификация SIP-T (интерконнект ISUP — SIP)

  • RFC 3398: сопоставление параметров ISUP и SIP (Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping)

  • RFC 3428: Расширение SIP для передачи мгновенных сообщений (Instant Messaging) и метод MESSAGE

  • RFC 3515: метод REFER

  • RFC 3903: публикация события на сервере (метод PUBLISH)

  • RFC 4235: Пакет событий, инициируемых по INVITE (An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP))

  • RFC 4262: SIP Event Lists (SUBSCRIBE, NOTIFY, Presence)

  • RFC 5806: Diversion Indication in SIP

SIP- запросы

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

  • INVITE — Приглашает пользователя к сеансу связи. Обычно содержит Протокол SDP -описание сеанса. Запрос INVITE, который отправлен для уже установленного сеанса связи, называется методом re-INVITE. re-INVITE позволяет менять адреса или порты сеансов, может добавлять поток медиаданных, удалять поток медиаданных, и т.д.

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

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

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

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

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

    Передача информации о возможностях вызывающего и вызываемого SIP телефонов.

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

  • PRACK — временное подтверждение (RFC 3262)

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

  • NOTIFY — уведомление подписчика о событии (RFC 3265)

  • PUBLISH — публикация события на сервере (RFC 3903)

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

  • REFER — запрос получателя о передаче запроса SIP (RFC 3515)

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

  • UPDATE — модификация состояния сессии без изменения состояния диалога (RFC 3311)

Адресация SIP логическая, того же типа, что Что такое ссылка URL в Методы и структура протокола HTTP. Для организации взаимодействия с существующими приложениями IP-сетей и для обеспечения мобильности пользователей протокол SIP использует адрес, подобный адресу электронной почты. В качестве адресов рабочих станций используются специальные универсальные указатели ресурсов — так называемые SIP URL (Universal Resource Locators).

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

  • имя@домен;

  • имя@хост;

  • имя@IР-адрес;

  • №телефона@шлюз

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

Во второй части адреса указывается имя домена, рабочей станции или шлюза. Для определения IP- адреса устройства необходимо обратиться к службе доменных имен — Раздел DNS: Что такое DNS. Если же во второй части SIP- адреса размещается IP- адрес, то с рабочей станцией можно связаться напрямую.

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

sip: als@rts.loniis.ru
sip: user1@192.168.100.152
sip: 294-75-47@gateway.ru

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

SIP поддерживает специальный довольно мощный язык CPL (Call Processing Language -язык обработки звонков) на основе Введение в XML, предназначенный для написания телефонных скриптов, позволяющий указать, кто кому когда и зачем звонит, что делать, если трубку не берут или берут не там, и т. д. В силу всего этого в рамках SIP легко строить самые разнообразные сервисы.

Подобные сервисы могут создавать три группы людей: производители 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 RFC 3261

  • SIP peers external authentication in Asterisk / OpenPBX

  • SIP Registration + Wireshark

  • Asterisk в роли SIP клиента

  • Гольдштейн Б.С., Зарубин А.А., Саморезов В.В. Протокол SIP. Глава 2.6. Процедуры функционирования HTTP аутентификации

  • Настройка базовой и дайджест HTTP аутентификации в Apache, Nginx

До выхода SIP 2.0, который поддерживается любым современным оборудованием и ПО, разрешалась передача паролей чуть ли не открытым текстом (HTTP Basic Authentication), что в настоящее время вообще немыслимо. Однако, применяемая в SIP 2.0 авторизация на основе дайджеста от случайной строки и пароля (HTTP Хеш-сумма (digest — дайджест) Authentication), также относительно уязвима. Ведь если злоумышленник перехватывает случайную строку и полученный дайджест (Алгоритм MD5 или SHA-1), он имеет возможность автономно подобрать пароль (по словарю или перебором), и ему не понадобится даже подключаться к SIP-серверу. Это главная причина, по которой настоятельно рекомендуется использовать сложные пароли длиной не менее 10 символов.

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

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

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

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

  • Вариант №1. Абонент: высылает серверу сообщение с заголовком REGISTER. Если в настройках абонента не указан secret, то этого достаточно, сервер присылает ответ SIP/2.0 200 OK и процесс регистрации заканчивается.

  • Вариант №2. Если secret указан. Сервер на запрос REGISTER присылает ответ SIP/2.0 401 Unauthorized (нормальный ответ сервера о том, что пользователь еще не авторизировался; обычно после этого абонентское оборудование отправляет на сервер новый запрос, содержащий логин и пароль).

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

Authorization: Digest username="203",realm="asterisk",nonce="29b8191d",uri="sip:local",
   response="7306cfba1b131f2f04363b68d908f855",algorithm=MD5

Где параметр response — строка, состоящая из 32 шестнадцатиричных разрядов и удостоверяющая, что пользователю известен пароль. Формируется с помощью применения функции хеширования к значениям nonce, nc, cnonce, qop, uri, username, realm, типу запроса и паролю password. По умолчанию хеширование производится по алгоритму Алгоритм MD5.

  • Вариант №3. Если используется внешний сервер для аутентификации (процедура проверки подлинности) по протоколу RADIUS сервер. Сервер на запрос REGISTER присылает ответ SIP/2.0 407 Proxy Authentication Required — необходима аутентификация на прокси-сервере).

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

SIP URI = sip:x@y:Port Где x=имя пользователя и y=хост (домен или IP)

Примеры:

sip:joe. bloggs@10.123.17.213
sip:support@phonesystem.com
sip:7422444032@phonesystem.com

Приложение Е. Исходные документы по протоколу SIP

RFC: 3261, 1321, 2617, 2806, 2833, 2976, 3050, 3262, 3263, 3265, 3311, 3323, 3326, 3329, 3581, 3665, 3666, 3372, 3398, 3420, 3515, 3608, 3702, 3768, 3853, 3856, 3891, 3892, 3903, 4028, 4411, 5079, 5090, 5168, 5589, 5806, 6086
ITU: Q.1912.5, Q.850
Приказ Министерства Связи №10 от 27.01.2009.

3261 Session Initiation Protocol
1321 The MD5 Message-Digest Algorithm
2617 Basic and Digest Access Authentication
2806 URLs for Telephone Calls
2833 RTP Payload for DTMF Digits Telephony Tones and Telephony Signals
2976 The SIP INFO Method
3050 Common Gateway Interface for SIP
3262 Reliability of Provisional Responses in the SIP
3263 SIP Locating SIP Servers
3265 SIP Specific Event Notification
3311 The SIP UPDATE Method
3323 A Privacy Mechanism for the SIP
3326 The Reason Header Field for the SIP
3329 Security Mechanism Agreement for the SIP
3581 An Extension to the Session Initiation Protocol for Symmetric Response Routing
3665 SIP Basic Call Flow Examples
3666 SIP PSTN Call Flows
3372 SIP-T Context and Architectures
3398 ISDN ISUP to SIP mapping
3420 Internet Media Type message-sipfrag
3515 The SIP REFER Method
3608 SIP Extention Header Field for Service Route Discovery During Registration
3702 Authentication, Authorization, and Accounting for SIP
3768 VRRP — Virtual Router Redundancy Protocol
3853 S-MIME Advanced Encryption Standard AES
3856 SUBSCRIBE NOTIFY A Presence Event Package for the Session Initiation Protocol
3891 The SIP Replaces Header
3892 The SIP Referred-By Mechanism
3903 PUBLISH Event State Publication
4028 Session Timers in the Session Initiation Protocol
4411 Extending SIP Reason Header for Preemption Events
5079 Rejecting Anonymous Requests in SIP
5090 RADIUS Extension for Digest Authentication
5168 XML Schema for Media Control
5589 SIP Call Control-Transfer
5806 Diversion Indication in SIP
6086 SIP INFO Method and Package Framework

Протоколы SIP-T, SIP-I являются расширенными версиями протокола SIP и дополняют его в части процедур передачи сообщений протокола ISUP по сети электросвязи с коммутацией пакетов посредством механизмов трансляции и инкапсуляции.

SIP-I определен рекомендацией ITU Q.1912.5 (англ / рус, дополнение англ / рус)
SIP-T определен IETF RFC 3372.

Отличия в основном касаются трансляции прогрессов и релизов.
Требования к параметрам протоколов сигнализации SIP-T, SIP-I на сетях России приведены в приказе Министерства Связи №10 от 27.01.2009.

Трансляция причин и локации релизов приведены в рекомендации ITU Q.850.

Справочник по протоколу SIP. Гольдштейн

Механизмы переезда TCP коннекции:
TCP Connection Migration, Alex C. Snoeren and Hari Balakrishnan
Migratory TCP: Connection Migration for Service Continuity in the Internet, Florin Sultan, Kiran Srinivasan, Deepa Iyer, and Liviu Iftode
Transparent TCP Connection Failover, R. R. Koch, S. Hortikar, L. E. Moser, P. M. Melliar-Smith
SockMi: a solution for migrating TCP/IP connections, Massimo Bernaschi, Francesco Casadei, Paolo Tassotti

Механизмы отработки предупреждений на SIP:
SockMi: a solution for migrating TCP/IP connections, Massimo Bernaschi, Francesco Casadei, Paolo Tassotti

SIP: протокол инициирования сеанса

SIP: протокол инициирования сеанса
Архив
Архив черновиков
Архив списка рассылки
HTML, до марта 1998 г.
Все проекты, связанные с SIP
http://www.cs.columbia.edu/sip/drafts/
RFC, относящиеся к SIP:
RFC 3524 Сопоставление медиапотоков с резервированием ресурсов Потоки Этот документ определяет расширение сеанса Структура группировки протокола описания (SDP). Он позволяет запросить группа медиапотоков, которые должны быть сопоставлены с одним резервированием ресурсов поток. Определен необходимый синтаксис SDP, а также новая «семантика». атрибут под названием Single Reservation Flow (SRF).
RFC 3515 Протокол инициации сеанса (SIP), см. метод Определяет метод REFER. Инициация этого сеанса Расширение протокола (SIP) запрашивает, чтобы получатель ОБРАЩАЛСЯ к ресурсу предоставлено в запросе. Он обеспечивает механизм, позволяющий стороне отправка REFER, чтобы быть уведомленным о результатах указанного запрос. Это можно использовать для включения многих приложений, включая вызов передача. В дополнение к методу REFER этот документ определяет пакет события refer и заголовок запроса Refer-To.
RFC 3487 Требования к механизмам приоритета ресурсов для сеанса Протокол инициации (SIP) Обобщает требования по установлению приоритетов доступа к ресурсы сети, конечной системы и прокси-сервера для обеспечения готовности к чрезвычайным ситуациям связи с использованием протокола инициации сеанса (SIP).
RFC 3486 Сжатие протокола инициации сеанса (SIP) Описывает механизм, сигнализирующий о необходимости сжатия для одного или более сообщений протокола инициации сеанса (SIP). Также указывается, когда уместно отправлять сжатые сообщения SIP объекту SIP.
RFC 3485 Протокол инициации сеанса (SIP) и описание сеанса Статический словарь протокола (SDP) для сжатия сигналов (SigComp) Протокол инициации сеанса (SIP) — это текстовый протокол для инициирование и управление сеансами связи. Протокол может быть сжаты с помощью Signaling Compression (SigComp). Точно так же Протокол описания сеанса (SDP) — это текстовый протокол, предназначенный для описание мультимедийных сеансов для целей объявления сеанса, приглашение на сеанс и другие формы инициирования мультимедийного сеанса. Этот меморандум определяет статический словарь SIP/SDP, который SigComp может использовать для достижения более высокой эффективности. Словарь алгоритм сжатия независимый.
RFC 3428 Расширение протокола инициации сеанса (SIP) для Instant Обмен сообщениями Обмен мгновенными сообщениями (IM) относится к передаче сообщений между пользователей практически в режиме реального времени. Эти сообщения обычно, но не обязательны быть, короче. IM часто используются в разговорном режиме, т. передача сообщений туда и обратно происходит достаточно быстро, чтобы участники могли поддерживать интерактивную беседу. В этом документе предлагается Метод MESSAGE, расширение протокола инициации сеанса (SIP). что позволяет передавать мгновенные сообщения. Поскольку запрос MESSAGE является расширением SIP, оно наследует всю маршрутизацию запросов и безопасность особенности этого протокола. Запросы MESSAGE несут содержимое в форма частей тела MIME. Запросы MESSAGE сами по себе не инициируют SIP-диалог; при обычном использовании каждое Мгновенное сообщение стоит отдельно, намного как сообщения пейджера. Запросы MESSAGE могут быть отправлены в контексте диалог, инициированный другим SIP-запросом.
RFC 3420 Internet Media Тип сообщения/sipfrag Этот документ регистрирует сообщение/sipfrag Многоцелевой Интернет Тип носителя Mail Extensions (MIME). Этот тип аналогичен message/sip, но допускает определенные подмножества хорошо сформированного протокола инициации сеанса (SIP) сообщения должны быть представлены вместо того, чтобы требовать полного SIP сообщение. В дополнение к сквозной безопасности используется message/sipfrag. используется с методом REFER для передачи информации о статусе ссылочный запрос.
RFC 3388 Группировка медиа-линий в протоколе описания сеанса (SDP) Расширения SDP, позволяющие группировать медиапотоки для губ синхронизация и представление одного и того же контента в другой сети адреса
RFC 3361 Протокол динамической конфигурации хоста (DHCP-for-IPv4) Опция для Серверы протокола инициации сеанса (SIP) Определяет параметр DHCP для обнаружения исходящего прокси-сервера SIP.
RFC 3319 Протокол динамической конфигурации хоста (DHCPv6) Опции для протокола инициации сеанса (SIP) Серверы Определяет параметры DHCPv6 для обнаружения исходящего прокси-сервера SIP.
RFC 3327 Поле заголовка расширения протокола инициации сеанса (SIP) для Регистрация несмежных контактов Определяет поле заголовка Path, в котором регистрируется список прокси между ПА и регистратором
RFC 3326 Поле заголовка Reason для протокола инициации сеанса (SIP) Для создания сервисов часто полезно знать, почему сеанс Выдан запрос протокола инициации (SIP). Этот документ определяет поле заголовка Reason, которое предоставляет эту информацию. Заголовок причины Поле также предназначено для инкапсуляции конечного кода состояния в предварительный ответ. Эта функция необходима для решения «Проблема разветвления гетерогенных ответов на ошибки» или HERFP.
RFC 3325 Частные расширения протокола инициации сеанса (SIP) для Подтвержденная личность в доверенных сетях Определяет P-Asserted-Identity и P-Preferred-Identity поля заголовков, позволяя SIP-прокси добавлять идентификационную информацию пользователя и звонящие с просьбой о конфиденциальности
RFC 3324 Краткосрочные требования для сетевой идентификации Определяет требования к идентификаторам вызывающего абонента, установленным сетью. сущности
RFC 3323 Механизм конфиденциальности для протокола инициации сеанса (SIP) Описывает проблемы конфиденциальности SIP-вызова и определяет конфиденциальность поле заголовка
RFC 3329 Соглашение о механизме безопасности для протокола инициации сеанса (SIP) Этот документ определяет новые функции для согласования безопасности механизмы, используемые между пользовательским агентом протокола инициации сеанса (SIP) и его объект SIP следующего перехода. Эта новая функциональность дополняет существующие методы выбора механизмов безопасности между объектами SIP.
RFC 3313 Расширения протокола инициации частного сеанса (SIP) для мультимедиа Авторизация Описывает потребность в качестве обслуживания (QoS) и мультимедиа авторизация и определяет расширение протокола инициации сеанса (SIP) который можно использовать для интеграции управления допуском QoS с сигнализацией вызова и помогают защититься от атак типа «отказ в обслуживании». Использование этого расширение применимо только в административных доменах или среди федерации административных доменов с заранее согласованными политики, где и прокси-сервер SIP, авторизующий QoS, и политика управление базовой сетью, обеспечивающей QoS, принадлежит этому административный домен или федерация доменов.
RFC 3312 Интеграция управления ресурсами и SIP Каркас для предварительных условий
RFC 3311 Метод обновления протокола инициации сеанса (SIP) Эта спецификация определяет новый метод UPDATE для сеанса Протокол инициации (SIP). UPDATE позволяет клиенту обновлять параметры сеанса (например, набор медиапотоков и их кодеков), но имеет не влияет на состояние диалога. В этом смысле он подобен re-INVITE, но, в отличие от re-INVITE, его можно отправить до первоначального ПРИГЛАШЕНИЕ завершено. Это делает его очень полезным для обновления параметры сеанса в ранних диалогах.
RFC 3261 (Закладки любезно предоставлены Александром Жилем) SIP: протокол инициации сеанса Спецификация основного протокола; устарел RFC 2543.
RFC 3262 Надежность предварительных ответов при инициации сеанса Протокол (SIP) Обеспечение надежности ответов 1xx; представляет метод PRACK
RFC 3263 Протокол инициации сеанса (SIP): поиск SIP-серверов Описывает механизмы DNS (NAPTR, SRV) для обнаружения серверов SIP.
RFC 3264 Модель предложения/ответа с протоколом описания сеанса (СДП) Как SDP используется в SIP для согласования сеансов
RFC 3265 Протокол инициации сеанса (SIP) — уведомление о событии Модель события SIP; определяет ПОДПИСАТЬСЯ и УВЕДОМИТЬ
RFC 3087 Управление контекстом службы с использованием SIP Request-URI Определяет, как можно использовать SIP URI для вызова таких служб, как голосовая почта
RFC 3050 Общий интерфейс шлюза для SIP sip-cgi, как интерфейс сценариев
RFC 2976 Метод SIP INFO Определяет метод INFO для передачи информации, связанной с SIP.
RFC 2848 Сервисный протокол PINT: расширения SIP и SDP для IP-доступ к службам телефонных звонков Определяет, как события SIP могут использоваться для вызова служб PSTN, таких как Ожидание интернет-вызова

Краткий обзор усилий по стандартизации, связанных с SIP

Существует ряд расширений для добавления функций в SIP. Текущий черновики перечислены ниже. Только черновики, названия которых начинаются с draft-ietf-sip- и draft-ietf-sipping- являются SIP (или SIPPING) рабочие группы рабочих элементов, в то время как другие являются индивидуальными представления их авторов. Индивидуальные представления могут позже стать элементы рабочей группы. Черновик не обязательно должен быть помечен как элемент WG, чтобы прогрессировать.

Учитывая количество черновиков, может быть трудно отследить, какие черновики значимы для различных приложений. Ниже приведены некоторые из усилий подытожены и даны указатели на текущие черновики. Все эти усилия считаются активными. Часть текста ниже была предоставлено Джонатаном Розенбергом.

Основная спецификация SIP

Основной спецификацией SIP является RFC 3261, который устарел RFC 2543. Отличия от последней версии Internet Draft, bis09, незначительны. Связанные спецификации: RFC 3262 ( Надежность предварительных ответов в протоколе инициации сеанса (SIP) ), RFC 3263 ( Протокол инициации сеанса (SIP): обнаружение SIP Серверы ), RFC 3264 ( An Модель предложения/ответа с протоколом описания сеанса (SDP) ), RFC 3265 ( Протокол инициации сеанса (SIP) — уведомление о конкретном событии ), и RFC 3266 ( Поддержка IPv6 в протоколе описания сеанса (SDP) ).

Информационные документы

Потоки вызовов

Чтобы помочь разработчикам, набор потоков вызовов имеет были опубликованы, которые дают примеры общей настройки вызова и регистрации сценарии.

Рекомендации по написанию расширений SIP

Предлагается ряд расширений для добавления заголовков или методов. потягивать. Расширения должны следовать набору правил, чтобы максимизировать вероятность того, что различные расширения могут сосуществовать. Проект предлагает критерии для оценки того, что является и что не является хорошим SIP extension и описывает вещи, которые должны обсуждать все расширения. Так и будет в конечном итоге стать BCP RFC. Это рабочий элемент SIP WG.

SIP через NAT и брандмауэры

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

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

Конфигурация пользовательского агента

пользовательские агенты SIP должны определить, использовать ли исходящий прокси-сервер и куда присылать регистрационные обновления. Адрес исходящего прокси можно настроить вручную и регистрацию можно отправить через мультикаст. DHCP есть дополнительный метод настройки этой информации. DHCP используется расширенные возможности для настройки информации о времени загрузки на хостах, подключенных к IP-адресу. (Это рабочий элемент рабочей группы SIP. В настоящее время он находится на рассмотрении IESG.)

Для более сложного выбора прокси-сервера Протокол позволяет прокси и регистраторам рекламировать свои возможности. В больших сетях у пользователей может быть выбор SIP. сервер, к которому они подключаются. Разные серверы могут предоставлять разные услуги своим пользователям; например, некоторые могут поддерживать выполнение CPL, а другие не могут. Некоторые могут поддерживать IPSec, а некоторые нет. Этот work определяет способ, с помощью которого конечные системы SIP могут обнаруживать серверы SIP. предоставление конкретных возможностей. Это делается через Сервис Протокол определения местоположения (SLP), указанный в RFC2608. Чтобы включить SIP-сервер обнаружение с помощью SLP, необходимо определить шаблон, который в основном определяет схему для SIP-серверов. Работа превратится в Регистрация IANA в соответствии с обычными процедурами SLP. Это позволит существующие серверы SLP для обеспечения обнаружения серверов SIP.

Управление сетью

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

Улучшения инфраструктуры

Надежные предварительные ответы

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

Поддерживается Заголовок

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

Таймер сеанса
Сеансы

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

Сервисные активаторы

В нескольких проектах предлагается новая услуга, позволяющая ГЛОТОК. Это не сами сервисы, а примитивы, которые позволяют группы услуг.

Стороннее управление вызовами

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

Предпочтения вызывающего абонента

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

Предварительные условия

В некоторых случаях необходимо отложить звонок вызываемого абонента до набор предварительных условий было установлено. Один экземпляр основан на резервировании качество обслуживания. Там отдельный протокол резервирования ресурсов определяет, доступны ли достаточные сетевые ресурсы. Только когда этот шаг увенчается успехом, должен зазвонить телефон. Точно так же звонок может зависеть от возможности установить безопасный медиа-сеанс. Этот расширение добавляет предварительные условия к SDP, так что установление сеанса может быть поставлено в зависимость от QoS или обеспечения безопасности. Он добавляет новый SIP метод COMET, чтобы подтвердить, что условия были выполнены. Это SIP Рабочий элемент рабочей группы, который считается стабильным.

Перевод вызова

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

Подключение к ТСОП

Системы на основе

SIP часто подключаются к шлюзам PSTN. Для аналоговых каналов и каналов ISDN особых дополнений не требуется, но взаимосвязь с системой сигнализации № 7 (SS7) требует поддержки дополнительного протокола для прозрачного взаимодействия и мост. Помимо прочих задач, этот набор черновиков описывает новый SIP. метод INFO для переноса ISUP и QSIG в середине вызова без изменения состояния вызова сообщения в облаке SIP в виде вложений MIME. Существует также черновик, описывающий, как сообщения ISUP и сообщения SIP связаны друг с другом на шлюзе.

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

Интернет-телефония должна обеспечивать экстренный вызов, т. е. 911.

Качество обслуживания

SIP не резервирует сетевые ресурсы, но может быть полезен в предоставление. авторизация, аутентификация и учет (AAA), возможно, в сочетании с Открыто Протокол расчетов.

Присутствие, события и обмен мгновенными сообщениями

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

Это расширение также может сделать SIP подходящим для управления бытовая техника.

Создание служб SIP

Ряд API и других механизмов для предоставления услуг, связанных с SIP. были разработаны, в том числе интерфейс, аналогичный веб-общему интерфейс шлюза (CGI), называемый sip-cgi, язык программирования, CPL, для ограниченного набора возможностей прокси-серверов и сервлетов Java. В Кроме того, существуют API-интерфейсы, такие как JAIN и Parlay, которые предоставляют программируемые Сервисы.

Серверы могут быть настроены с использованием сценариев CPL и SIP-CGI в различных способов. Одним из механизмов является загрузка скриптов через «>РЕГИСТРАЦИЯ». запросы от пользовательских агентов SIP.

Мобильные хосты

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

Другие усилия

Ниже приведен неполный список других усилий по стандартизации SIP; никто из них входят в устав SIP WG.
  • Соответствие спецификациям PacketCable DCS;
  • Изучение приложений SIP в мобильной среде;
  • Включение SIP для эмуляции обслуживания домашней телефонной связи
  • Взаимодействие конечных автоматов SIP и моделей вызовов IN;
  • Взаимодействие с многоуровневыми приоритетными спецификациями MLPP военный ИСУП;
  • Интеграция QoS, политики и сигнализации;
  • Связь между SIP, QoS и OSP, а также архитектурой AAA;
  • SIP для выбора маршрутов MPLS.

Текущие документы

  • Расширения базовой спецификации для обработки надежных сообщений 1xx, потоков вызовов, управления вызовами;
  • SIP для присутствия;
  • Расширения SIP для управления устройствами;
  • Использование DHCP и SLP для настройки SIP серверы и клиенты
  • Обеспечение работы SIP через брандмауэры и NAT
  • Распределенная сигнализация вызова, a набор предложений PacketCable;
  • Связанные с мобильностью;
  • SIP API, такие как sip-cgi и сервлеты;
  • Параметры вызывающего абонента позволяют вызывающим абонентам управлять поведением прокси и пользовательских агентов;
  • согласование QoS;
  • Взаимодействие PSTN, например, передача сообщений ППЦС, промежуточная сигнализация;
  • Взаимодействие H.323;
  • Безопасность (аутентификация, проблемы с шифрованием;
  • Только исторический интерес.
  • SIPstone: сравнительный анализ SIP серверы

Последнее обновление Хеннинг Шульцринн

Прямая маршрутизация телефонной системы Teams: определения и стандарты RFC — Microsoft Teams

Обратная связь Редактировать

Твиттер LinkedIn Фейсбук Эл. адрес

  • Статья
  • 3 минуты на чтение
  • Применимо к:
    Команды Майкрософт

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

Клиентский SBC взаимодействует со следующими компонентами серверной части Microsoft Teams:

  • Прокси-сервер SIP для сигнализации. Это компонент прямой маршрутизации с выходом в Интернет, который обрабатывает соединения SIP (TLS) между SBC и прямой маршрутизацией.

  • Медиапроцессоры для мультимедиа. Это компонент прямой маршрутизации с выходом в Интернет, который обрабатывает мультимедийный трафик. Этот компонент использует протоколы SRTP и SRTCP.

Дополнительные сведения о прямой маршрутизации см. в разделе Прямая маршрутизация телефонной системы.

Дополнительные сведения о том, как прямая маршрутизация реализует протокол SIP, см. в разделе Прямая маршрутизация — протокол SIP.

Стандарты RFC

Прямая маршрутизация соответствует стандартам RFC. SBC, подключенный к прямой маршрутизации, также должен соответствовать следующим RFC (или их преемникам).

Стандарты, применимые к устройствам, поддерживающим режим обхода без носителя

Следующие стандарты применимы к устройствам, поддерживающим только режим обхода без носителя:

  • RFC 3261 SIP: протокол инициации сеанса
  • RFC 3325. Частное расширение протокола инициации сеанса для подтвержденной идентификации в доверенных сетях — разделы об обработке заголовка P-Asserted-Identity. Прямая маршрутизация отправляет P-Asserted-Identity с заголовками идентификатора конфиденциальности.
  • RFC 4244 Расширение протокола инициации сеанса (SIP) для необходимой информации истории. См. также: Описание протокола маршрутизации SIP для получения дополнительной информации.
  • RFC 3892 Протокол инициации сеанса, указанный механизмом
  • RFC 3891 Протокол инициации сеанса (SIP) «заменяет» заголовок
  • RFC 6337 Протокол инициации сеанса (SIP) Использование модели предложения/ответа. См. раздел «Отклонения от RFC».
  • RFC 3711 и RFC 4771. Защитите трафик RTP с помощью SRTP. SBC должен иметь возможность устанавливать ключи с помощью SDES.
  • RFC 8035 Разъяснения предложения/ответа протокола описания сеанса (SDP) для мультиплексирования RTP/RTCP

Стандарты, применимые к устройствам, поддерживающим режим обхода среды

В дополнение к стандартам, перечисленным как применимые к режиму без обхода, для режима обхода среды используются следующие стандарты:

  • RFC 5245 Interactive Connectivity Establishment (ICE) для среды обход. SBC должен поддерживать следующее:
    • ICE Lite — клиенты Teams являются полноценными клиентами ICE
    • Перезапуск ICE. Дополнительные сведения о вариантах использования и примерах перезапуска ICE см. в статье Перезапуск ICE: вызов обхода мультимедиа, переданный на конечную точку, которая не поддерживает обход мультимедиа
    • .
  • RFC RFC 5589 Управление вызовами по протоколу инициации сеанса (SIP) — передача.
  • RFC 3960 Early Media и генерация мелодии вызова в протоколе инициации сеанса (SIP), см. разделы 3.1, Разветвление и 3.2, Генерация мелодии вызова
  • RFC 5389 Утилиты обхода сеанса для NAT (STUN)
  • RFC 5766 Обход с использованием ретрансляции вокруг NAT (TURN): расширения ретрансляции для утилит обхода сеанса для NAT (STUN)

Стандарты, применимые для поддержки передачи информации о местоположении провайдерам E911

  • RFC 6442, Передача местоположения для протокола инициации сеанса

Отклонения от RFC

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

RFC и разделы Описание Отклонение
RFC 6337, раздел 5. 3 Удержание и возобновление мультимедиа RFC позволяет использовать «a=inactive», «a=sendonly», a=recvonly для перевода вызова на удержание. Прокси-сервер SIP поддерживает только «a=inactive» и не понимает, отправляет ли SBC «a=sendonly» или «a=recvonly».
RFC 6337, раздел 5.4 «Поведение при получении SDP с c=0.0.0.0 RFC3264 требует, чтобы агент мог получать SDP с адресом соединения 0.0.0.0, и в этом случае это означает, что ни RTP, ни RTCP не должны отправляться одноранговому узлу. Прокси-сервер SIP не поддерживает этот параметр.

Режимы работы

Существует два режима работы для прямой маршрутизации:

  • Без обхода мультимедиа , в котором весь трафик RTP проходит между клиентом Teams, процессорами мультимедиа и SBC.

  • С обходом мультимедиа , в котором все мультимедиа RTP передаются между конечными точками Teams и SBC.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *