WikiDer > Протокол инициирования сеанса

Session Initiation Protocol

В Протокол инициирования сеанса (ГЛОТОК) это протокол сигнализации используется для инициирования, поддержания и завершения сеансов в реальном времени, которые включают приложения для передачи голоса, видео и обмена сообщениями.[1] SIP используется для сигнализация и управление мультимедиа сеансы связи в приложениях Интернет-телефония для голосовых и видеозвонков, в частных IP-телефонных системах, в мгновенное сообщение над протокол Интернета (IP) сети, а также звонки с мобильных телефонов через LTE (VoLTE).

Протокол определяет конкретный формат обмена сообщениями и последовательность обмена сообщениями для взаимодействия участников. SIP - это текстовый протокол, включающий многие элементы Протокол передачи гипертекста (HTTP) и Простой протокол передачи почты (SMTP).[2] Вызов, установленный с помощью SIP, может состоять из нескольких медиапотоки, но для приложений, таких как текстовых сообщений, которые обмениваются данными в качестве полезной нагрузки в сообщении SIP.

SIP работает вместе с несколькими другими протоколами, которые определяют и переносят среду сеанса. Чаще всего согласование типа и параметров носителя, а также настройка носителя выполняется с помощью Протокол описания сеанса (SDP), который передается как полезная нагрузка в сообщениях SIP. SIP разработан, чтобы быть независимым от базового транспортный уровень протокол, и может использоваться с Протокол пользовательских датаграмм (UDP), Протокол управления передачей (TCP), а Протокол передачи управления потоком (SCTP). Для безопасной передачи сообщений SIP по незащищенным сетевым каналам протокол может быть зашифрован с помощью Безопасность транспортного уровня (TLS). Для передачи медиапотоков (голос, видео) полезная нагрузка SDP, переносимая в сообщениях SIP, обычно использует Транспортный протокол в реальном времени (RTP) или Безопасный транспортный протокол в реальном времени (SRTP).

История

SIP был первоначально разработан Марк Хэндли, Хеннинг Шульцринне, Eve Schooler и Джонатан Розенберг в 1996 году для содействия созданию многоадресная передача мультимедийные сессии на Mbone. Протокол был стандартизирован как RFC 2543 в 1999 году. В ноябре 2000 года SIP был принят в качестве 3GPP протокол сигнализации и постоянный элемент Подсистема IP-мультимедиа (IMS) архитектура для потоковых мультимедийных услуг на основе IP в сотовые сети. В июне 2002 года спецификация была пересмотрена в RFC 3261[3] и с тех пор были опубликованы различные дополнения и пояснения.[4]

SIP был разработан для обеспечения протокола сигнализации и установки вызова для IP-связи, поддерживающей функции обработки вызовов и функции, присутствующие в телефонная сеть общего пользования (PSTN) с целью поддержки новых мультимедийных приложений. Он был продлен на видео-конференция, потоковое мультимедиа распределение, мгновенное сообщение, информация о присутствии, передача файла, Интернет-факс и онлайн игры.[1][5][6]

Сторонники протокола SIP отличаются тем, что уходят корнями в Интернет-сообщество, а не в телекоммуникационная промышленность. SIP был стандартизирован в первую очередь Инженерная группа Интернета (IETF), тогда как другие протоколы, такие как H.323, традиционно ассоциировались с Международный союз электросвязи (ITU).

Работа протокола

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

SIP работает вместе с несколькими другими протоколами, которые определяют формат и кодирование мультимедийных данных и передают мультимедийные данные после установления вызова. Для настройки вызова тело сообщения SIP содержит Протокол описания сеанса (SDP) блок данных, который определяет формат мультимедиа, кодек и протокол обмена данными. Голосовые и видеопотоки обычно передаются между терминалами с помощью Транспортный протокол в реальном времени (RTP) или Безопасный транспортный протокол в реальном времени (SRTP).[2][7]

Каждый ресурс сети SIP, такой как пользовательские агенты, маршрутизаторы вызовов и ящики голосовой почты, идентифицируется Единый идентификатор ресурса (URI). Синтаксис URI соответствует общему стандартному синтаксису, также используемому в Веб-сервисы и электронная почта.[8] Схема URI, используемая для SIP: глоток а типичный SIP URI имеет вид sip: имя пользователя @ имя домена или же sip: имя пользователя @ hostport, куда доменное имя требуется DNS Записи SRV найти серверы для SIP-домена, пока hostport может быть айпи адрес или полное доменное имя хоста и порта. Если безопасная передача требуется, схема глотки используется.[9][10]

SIP использует элементы дизайна, аналогичные модели транзакции HTTP-запроса и ответа.[11] Каждая транзакция состоит из клиентского запроса, который вызывает определенный метод или функцию на сервере, и по крайней мере одного ответа. SIP повторно использует большинство полей заголовков, правил кодирования и кодов состояния HTTP, обеспечивая читаемый текстовый формат.

SIP может передаваться несколькими транспортный уровень протоколы, включая Протокол управления передачей (TCP), Протокол пользовательских датаграмм (UDP) и Протокол передачи управления потоком (SCTP).[12][13] SIP-клиенты обычно используют TCP или UDP на номера портов 5060 или 5061 для SIP-трафика к серверам и другим конечным точкам. Порт 5060 обычно используется для незашифрованного сигнального трафика, тогда как порт 5061 обычно используется для трафика, зашифрованного с помощью Безопасность транспортного уровня (TLS).

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

Сетевые элементы

Сетевые элементы, которые используют протокол инициации сеанса для связи, называются Пользовательские агенты SIP. Каждый пользовательский агент (UA) выполняет функцию клиент агента пользователя (UAC), когда он запрашивает сервисную функцию, а сервер пользовательского агента (UAS) при ответе на запрос. Таким образом, любые две конечные точки SIP могут в принципе работать без какой-либо промежуточной инфраструктуры SIP. Однако по причинам эксплуатации сети, для предоставления общедоступных услуг пользователям и для служб каталогов SIP определяет несколько конкретных типов элементов сетевого сервера. Каждый из этих элементов службы также взаимодействует в рамках модели клиент-сервер, реализованной в клиентах и ​​серверах пользовательских агентов.[14]

Пользовательский агент

Пользовательский агент - это логическая конечная точка сети, которая отправляет или принимает сообщения SIP и управляет сеансами SIP. У пользовательских агентов есть клиентские и серверные компоненты. Клиент пользовательского агента (UAC) отправляет SIP-запросы. Сервер пользовательского агента (UAS) получает запросы и возвращает ответ SIP. В отличие от других сетевых протоколов, которые фиксируют роли клиента и сервера, например, в HTTP, в котором веб-браузер действует только как клиент, а не как сервер, SIP требует, чтобы оба партнера реализовали обе роли. Роли UAC и UAS действуют только на время транзакции SIP.[5]

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

В SIP, как и в HTTP, пользовательский агент может идентифицировать себя с помощью поля заголовка сообщения (Пользователь-агент), содержащий текстовое описание программного обеспечения, оборудования или название продукта. Поле пользовательского агента отправляется в сообщениях запроса, что означает, что принимающий сервер SIP может оценивать эту информацию для выполнения конфигурации устройства или активации функции. Операторы сетевых элементов SIP иногда хранят эту информацию на порталах учетных записей клиентов,[17] где это может быть полезно при диагностике проблем совместимости с SIP или при отображении статуса службы.

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

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

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

Сервер перенаправления

Сервер перенаправления - это сервер пользовательского агента, который генерирует 3хх (перенаправление) ответов для запросов, которые он получает, направляя клиента на контакт с альтернативным набором URI. Сервер перенаправления позволяет прокси-серверам направлять приглашения сеанса SIP во внешние домены.

Регистратор

Регистрация пользовательского агента SIP в SIP-регистраторе с аутентификацией.

Регистратор - это конечная точка SIP, которая предоставляет службу определения местоположения. Он принимает запросы REGISTER, записывая адрес и другие параметры от пользовательского агента. Для последующих запросов он предоставляет важные средства для обнаружения возможных одноранговых узлов связи в сети. Служба определения местоположения связывает один или несколько IP-адресов с SIP URI агента регистрации. Несколько пользовательских агентов могут зарегистрироваться для одного и того же URI, в результате все зарегистрированные пользовательские агенты будут получать вызовы к URI.

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

Пограничный контроллер сеанса

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

Шлюз

Шлюзы может использоваться для соединения сети SIP с другими сетями, такими как PSTN, которые используют другие протоколы или технологии.

SIP сообщения

SIP - это текстовый протокол с синтаксисом, аналогичным HTTP. Есть два разных типа SIP-сообщений: запросы и ответы. В первой строке запроса есть метод, определяющий характер запроса, и Request-URI, указывающий, куда следует отправить запрос.[18] В первой строке ответа есть код ответа.

Запросы

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

SIP запросы
Имя запросаОписаниеПримечанияСсылки на RFC
РЕГИСТРЗарегистрируйте URI, указанный в поле To-header, с сервером местоположения и свяжите его с сетевым адресом, указанным в Контакт поле заголовка.Команда реализует службу определения местоположения.RFC 3261
ПРИГЛАШАТЬЗапустите диалог для установления вызова. Запрос отправляется клиентом пользовательского агента на сервер пользовательского агента.При отправке во время установленного диалога (вновь пригласить) он изменяет сеансы, например помещает вызов в режим ожидания.RFC 3261
ACKПодтвердите, что объект получил окончательный ответ на запрос INVITE.RFC 3261
ДО СВИДАНИЯСигнал о завершении диалога и завершении разговора.Это сообщение может быть отправлено любой конечной точкой диалога.RFC 3261
ОТМЕНАОтмените любой ожидающий запрос.Обычно означает завершение вызова, пока он еще звонит, до ответа.RFC 3261
ОБНОВИТЬИзмените состояние сеанса без изменения состояния диалогового окна.RFC 3311
ССЫЛАТЬСЯПопросите получателя оформить запрос на перевод вызова.RFC 3515
PRACKПредварительное подтверждение.PRACK отправляется в ответ на предварительный ответ (1xx).RFC 3262
ПОДПИСЫВАТЬСЯИнициирует подписку на уведомление о событиях от уведомителя.RFC 6665
УВЕДОМЛЯТЬСообщите подписчику уведомления о новом событии.RFC 6665
ПУБЛИКОВАТЬОпубликуйте событие на сервере уведомлений.RFC 3903
СООБЩЕНИЕОтправьте текстовое сообщение.Используется в приложениях для обмена мгновенными сообщениями.RFC 3428
ИНФОРМАЦИЯОтправлять информацию в середине сеанса, которая не изменяет состояние сеанса.Этот метод часто используется для ретрансляции DTMF.RFC 6086
ОПЦИИЗапросите возможности конечной точки.Часто используется для NAT поддерживать активность целей.RFC 3261

Ответы

Ответы отправляются сервером пользовательского агента с указанием результата полученного запроса. Распознаются несколько классов ответов, определяемых числовым диапазоном кодов результатов:[19]

  • 1xx: предварительные ответы на запросы показывают, что запрос действителен и обрабатывается.
  • 2xx: Успешное завершение запроса. В ответ на ПРИГЛАШЕНИЕ он указывает, что вызов установлен. Самый распространенный код - 200, что означает безоговорочный отчет об успехе.
  • 3xx: для завершения запроса требуется перенаправление вызова. Запрос должен быть заполнен с новым адресатом.
  • 4xx: запрос не может быть выполнен на сервере по разным причинам, включая неправильный синтаксис запроса (код 400).
  • 5xx: серверу не удалось выполнить явно действительный запрос, включая внутренние ошибки сервера (код 500).
  • 6xx: запрос не может быть выполнен ни на одном сервере. Это указывает на глобальный сбой, включая отклонение вызова адресатом.

Сделки

Пример: UAC User1 использует пригласить клиентскую транзакцию для отправки начального сообщения INVITE (1). Если после периода ожидания, управляемого таймером, ответ не получен, UAC может решить завершить транзакцию или повторно передать сообщение INVITE. После получения ответа Пользователь 1 уверен, что ПРИГЛАШЕНИЕ было доставлено надежно. Затем UAC пользователя User1 должен подтвердить ответ. После доставки ACK (2) обе стороны транзакции завершены. В этом случае может быть установлен диалог.[20]

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

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

Обмен мгновенными сообщениями и присутствие

В Протокол инициирования сеанса для мгновенного обмена сообщениями и расширений с использованием информации о присутствии (SIMPLE) - это набор стандартов на основе SIP для мгновенное сообщение и информация о присутствии. Протокол передачи сеанса сообщений (MSRP) позволяет сеансы обмена мгновенными сообщениями и передачу файлов.

Тестирование на соответствие

Сообщество разработчиков SIP регулярно встречается на конференциях, организуемых SIP Forum, для тестирования совместимости реализаций SIP.[21] В TTCN-3 язык спецификации тестов, разработанный рабочей группой в ETSI (STF 196), используется для определения тестов на соответствие для реализаций SIP.[22]

Тестирование производительности

При разработке программного обеспечения SIP или развертывании новой инфраструктуры SIP важно проверить способность серверов и IP-сетей обрабатывать определенную нагрузку на вызовы: количество одновременных вызовов и количество вызовов в секунду. Программное обеспечение для проверки производительности SIP используется для моделирования трафика SIP и RTP, чтобы проверить, стабильны ли сервер и IP-сеть при нагрузке на вызовы.[23] Программное обеспечение измеряет такие показатели производительности, как задержка ответа, соотношение ответ / захват, RTP дрожь и потеря пакета, время задержки туда и обратно.

Приложения

SIP соединение это маркетинговый термин для передача голоса по интернет-протоколу (VoIP) услуги, предлагаемые многими Поставщики услуг интернет-телефонии (ИТСП). Услуга обеспечивает маршрутизацию телефонных звонков от клиента. частная телефонная станция (PBX) телефонная система в PSTN. Такие услуги могут упростить инфраструктуру корпоративной информационной системы за счет совместного использования доступ в Интернет для голоса и данных, и снятие затрат на Интерфейс базовой скорости (BRI) или Интерфейс первичной скорости (PRI) телефонные сети.

SIP-транкинг - аналогичный маркетинговый термин, предпочтительный для случаев, когда услуга используется для упрощения телекоммуникационной инфраструктуры путем совместного использования канала доступа оператора связи для передачи голоса, данных и Интернет-трафика, устраняя при этом необходимость в каналах PRI.[24][25]

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

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

Реализации

Соединенные штаты. Национальный институт стандартов и технологий (NIST), Подразделение передовых сетевых технологий предоставляет общественное достояние Ява выполнение[27] что служит эталонная реализация для стандарта. Реализация может работать в сценариях прокси-сервера или пользовательского агента и использовалась во многих коммерческих и исследовательских проектах. Он поддерживает RFC 3261 в полном объеме и ряд дополнительных RFC, включая RFC 6665 (уведомление о событии) и RFC 3262 (надежные предварительные ответы).

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

Взаимодействие SIP-ISUP

SIP-I, протокол инициации сеанса с инкапсулированным ISUP, это протокол, используемый для создания, изменения и завершения сеансов связи на основе ISUP с использованием сетей SIP и IP. Услуги, использующие SIP-I, включают голосовую связь, видеотелефонию, факс и передачу данных. SIP-I и SIP-T[28] - это два протокола со схожими функциями, в частности, позволяющие передавать сообщения ISUP по сетям SIP. Это сохраняет все подробности, доступные в заголовке ППЦС.[а] SIP-I был определен ITU-T, тогда как SIP-T был определен IETF.[29]

Шифрование

Опасения по поводу безопасности звонков через общедоступный Интернет были устранены путем шифрования протокола SIP для безопасная передача. Схема URI SIPS используется для обеспечения безопасности связи SIP с помощью Безопасность транспортного уровня (TLS). URI SIPS имеют форму sips: [email protected].

Сквозное шифрование SIP возможен только при наличии прямого соединения между конечными точками связи. Хотя прямое соединение может быть выполнено через Одноранговый SIP или через VPN между конечными точками большая часть SIP-коммуникаций включает в себя несколько переходов, причем первый переход от пользовательского агента к пользовательскому агенту ITSP. В случае с несколькими пересылками SIPS будет защищать только первый переход; оставшиеся переходы обычно не будут защищены с помощью TLS, и связь SIP будет небезопасной. Напротив, HTTPS Протокол обеспечивает сквозную безопасность, поскольку это делается с прямым подключением и не включает понятие переходов.

Потоки мультимедиа (аудио и видео), которые представляют собой отдельные соединения от потока сигнализации SIPS, могут быть зашифрованы с помощью SRTP. Обмен ключами для SRTP осуществляется с SDES (RFC 4568) или с ZRTP (RFC 6189). Когда используется SDES, ключи будут передаваться через небезопасный SIP, если не используется SIPS. Также можно добавить Майки (RFC 3830) обменяться на SIP, чтобы определить ключи сеанса для использования с SRTP.

Смотрите также

Примечания

  1. ^ Детали ППЦС важны, поскольку существует множество вариантов ППЦС для конкретных стран, которые были реализованы за последние 30 лет, и не всегда возможно выразить все те же детали с помощью собственного сообщения SIP.

Рекомендации

  1. ^ а б "Что такое SIP?". Сетевой мир. 11 мая 2004 г.
  2. ^ а б Джонстон, Алан Б. (2004). SIP: понимание протокола инициирования сеанса (Второе изд.). Артек Хаус. ISBN 978-1-58053-168-9.
  3. ^ «Устав основной рабочей группы SIP». Инженерная группа Интернета. 2010-12-07. Получено 2011-01-11.
  4. ^ "Искать в Интернет-проектах и ​​RFC". Инженерная группа Интернета.
  5. ^ а б SIP: протокол инициирования сеанса. 2002. Дои:10.17487 / RFC3261. RFC 3261.
  6. ^ Маргарет Роуз. «Протокол инициации сеанса (SIP)». TechTarget.
  7. ^ Колл, Эрик (2016). Телеком 101. Учебный институт Тераком. С. 77–79. ISBN 9781894887038.
  8. ^ Универсальные идентификаторы ресурсов (URI): универсальный синтаксис. 2005. Дои:10.17487 / RFC3986. RFC 3986.
  9. ^ Miikka Poikselkä et al. 2004 г..
  10. ^ Брайан Рид и Стив Гудман 2015.
  11. ^ «SIP: протокол инициирования сеанса». IETF.
  12. ^ Протокол передачи управления потоком (SCTP) как транспорт для протокола инициирования сеанса (SIP). 2005. Дои:10.17487 / RFC4168. RFC 4168.
  13. ^ Монтазеролгам, Ахмадреза; Хоссейни Сено, Сейед Амин; Ягмаи, Мохаммад Хоссейн; Таштарян, Фарзад (2016-06-01). «Механизм смягчения перегрузки для сетей VoIP: подход транспортного уровня, основанный на управлении ресурсами». Сделки по развивающимся телекоммуникационным технологиям. 27 (6): 857–873. Дои:10.1002 / ett.3038. ISSN 2161-3915.
  14. ^ Montazerolghaem, A .; Moghaddam, M.H.Y .; Леон-Гарсия, А. (март 2018 г.). «OpenSIP: к программно-определяемой сети SIP». IEEE Transactions по управлению сетью и услугами. 15 (1): 184–199. arXiv:1709.01320. Дои:10.1109 / TNSM.2017.2741258. ISSN 1932-4537.
  15. ^ Аззедин (2006). Справочник алгоритмов для беспроводных сетей и мобильных вычислений. CRC Press. п. 774. ISBN 978-1-58488-465-1.
  16. ^ Портер, Томас; Энди Змолек; Ян Канклирц; Антонио Розела (2006). Практическая безопасность VoIP. Syngress. С. 76–77. ISBN 978-1-59749-060-3.
  17. ^ «Известные нам пользовательские агенты». Пользователь VoIP. Архивировано из оригинал на 2011-07-16.
  18. ^ Стойки, стр.214
  19. ^ Сталлингс, стр 216-217
  20. ^ Джеймс Райт. «SIP - Введение» (PDF). Konnetic. Получено 2011-01-11.
  21. ^ "SIPit Wiki". Получено 2017-10-07.
  22. ^ Опыт использования TTCN-3 для тестирования SIP, а также OSP (PDF), заархивировано из оригинал (PDF) 30 марта 2014 г.
  23. ^ «Производительность и стресс-тестирование SIP-серверов, клиентов и IP-сетей». StarTrinity. 2016-08-13.
  24. ^ «AT&T обсуждает свою архитектуру пиринга SIP». sip-trunking.tmcnet.com. Получено 2017-03-20.
  25. ^ «С конференции и выставки IIT VoIP: слайды PowerPoint для транспорта SIP компании AT&T». Новости HD Voice. 2010-10-19. Получено 2017-03-20.
  26. ^ Йонссон, Ларс; Матиас Коинчон (2008). «Потоковое аудио по IP» (PDF). Технический обзор EBU. Получено 2010-12-27.
  27. ^ "JAIN SIP проект". Получено 2011-07-26.
  28. ^ Контекст и архитектура SIP-T. Сентябрь 2002 г. Дои:10.17487 / RFC3372. RFC 3372.
  29. ^ «Почему SIP-I? Рекомендация по протоколу ядра коммутации» (PDF). Архивировано из оригинал (PDF) 17 марта 2012 г.

Библиография

  • Брайан Рид; Стив Гудман (22 января 2015 г.), Экзамен Ref 70-342 Advanced Solutions of Microsoft Exchange Server 2013 (MCSE), Microsoft Press, стр. 24, ISBN 978-0-73-569790-4
  • Миикка Пойкселькя; Георг Майер; Хишам Хартабил; Аки Ниеми (19 ноября 2004 г.), IMS: концепции и услуги IP-мультимедиа в мобильной сфере, John Wiley & Sons, стр. 268, ISBN 978-0-47-087114-0

внешняя ссылка