Описание 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: [email protected]
sip: [email protected]
sip: [email protected]

В 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. [email protected]
sip:[email protected]
sip:[email protected]

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

Twitter LinkedIn Facebook Адрес электронной почты

• Статья
• 04/07/2023

• Применяется к:

  Microsoft Teams

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

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

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

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

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

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

Стандарты RFC

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

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

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

• ПРОТОКОЛ SIP RFC 3261: протокол инициации сеанса
• RFC 3325. Частное расширение протокола инициации сеанса для утверждения удостоверения в доверенных сетях — разделы об обработке заголовка P-Asserted-Identity. Прямая маршрутизация отправляет P-Asserted-Identity с заголовками идентификатора конфиденциальности.
• RFC 4244 Расширение протокола SIP для необходимых сведений журнала. Дополнительные сведения см. в статье Описание протокола SIP маршрутизации.
• RFC 3892 Механизм Referred-By протокола инициации сеанса
• RFC 3891 Заголовок «Replaces» для протокола sip (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: вызов обхода мультимедиа, перенесенный в конечную точку, которая не поддерживает обход мультимедиа
• Управление вызовами протокола SIP RFC RFC 5589 — передача.
• RfC 3960 Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP), см. разделы 3.1, Forking, and 3.2, Ringing Tone Generation
• Программы обхода сеансов RFC 5389 для NAT (STUN)
• Обход RFC 5766 с использованием ретрансляторов вокруг NAT (TURN): расширения ретранслятора для служебных программ обхода сеансов для NAT (STUN)

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

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

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

В следующей таблице перечислены разделы RFC, в которых реализация 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 не поддерживает этот параметр.
RFC 3261, раздел 25 Дополненная BNF для протокола SIP	Символ «#» должен быть отправлен как «%23»	Прокси-сервер SIP отправляет символ «#» в запросе URI без экранирования.

Рекомендации по транспортировке TCP/TLS

При отправке SIP-запроса (нового или в диалоге) прокси-сервер Microsoft SIP может открыть новое подключение TCP/TLS или повторно использовать существующее подключение, если оно существует.

• Существует не более двух подключений TCP/TLS для каждого удаленного полного доменного имени или IP-адреса на каждую виртуальную машину прокси-сервера SIP. Перед отправкой запроса SIP прокси-сервер SIP проверяет наличие активных TCP-подключений с разрешенным IP-адресом целевого SBC/Trunk FQDN. Если два подключения существуют, они используются повторно. Если два подключения не существуют, открывается новое подключение.

  • Эта логика соответствует виртуальной машине прокси-сервера SIP.

  • IP-адреса прокси SIP обслуживаются несколькими виртуальными машинами в каждом регионе.

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

• Подключения TCP/TLS, открытые прокси-сервером SIP, не обязательно остаются открытыми до тех пор, пока выполняется вызов. Однако подключение не закрывается сразу после ответа на sip-запрос. Если время ожидания подключения не истекает, его можно повторно использовать для других SIP-запросов.

• Прокси-сервер SIP не поддерживает псевдонимы подключений, как описано в статье RFC 5923: повторное использование подключения в протоколе инициации сеанса (SIP).

  • Исходящие TCP-подключения прокси SIP только для исходящих запросов SIP-прокси (к SBC) и связанных ответов.

  • Входящий прокси-сервер SIP TCP-подключений (из SBC) обслуживает только входящие SIP-запросы и связанные ответы.

Политики времени ожидания

• Время ожидания простоя TCP прокси-сервера SIP составляет две минуты. Таймер сбрасывается при выполнении транзакции SIP через подключение.

• Прокси-сервер SIP отправляет приложение CRLF в соответствии с RFC 5626: управление подключениями Client-Initiated в протоколе инициации сеанса (SIP).

  • При сохранении активности таймер простоя TCP не сбрасывается.

  • CrLF keep-alive, отправленный поставщиком SBC, сбросит таймер простоя TCP.

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

• После двух минут простоя (FIN, ACK) передается в upplier SBC через ПРОКСИ-сервер SIP примерно в течение 10–20 секунд.

Notes

• Рекомендуется, чтобы SBC повторно использовал подключения, например прокси-сервер SIP. Этот метод экономит время, необходимое для подключений TCP и TLS.

• SBC должен обновлять подключение по крайней мере один раз в час.

• При отправке нового сертификата SBC он должен обновить все подключения.

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

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

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

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

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

Обратите внимание, что трафик SIP всегда проходит через прокси-сервер SIP.

DTMF

Стек мультимедиа не поддерживает встроенный DTMF.

Прямая маршрутизация телефонной системы

Teams: определения и стандарты RFC — Microsoft Teams

Редактировать

Твиттер LinkedIn Фейсбук Электронная почта

• Статья
• 15.02.2023

• Применимо к:

  Команды Майкрософт

В этой статье описывается, как прямая маршрутизация телефонной системы 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: вызов обхода мультимедиа, переданный на конечную точку, которая не поддерживает обход мультимедиа 9.0008
• RFC RFC 5589 Управление вызовами по протоколу инициации сеанса (SIP) — передача.
• RFC 3960 Early Media и генерация мелодии вызова в протоколе инициации сеанса (SIP), см. разделы 3.1, Разветвление и 3.2, Генерация мелодии вызова
• RFC 5389 Утилиты обхода сеанса для NAT (STUN)
• RFC 5766 Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for 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 не поддерживает этот параметр.
RFC 3261, раздел 25 Расширенный BNF для протокола SIP	Символ «#» следует отправлять как «%23»	Прокси-сервер SIP отправляет символ «#» в Request-URI без экранирования.

Вопросы транспорта TCP/TLS

При отправке запроса SIP (нового или в диалоге) прокси-сервер Microsoft SIP может открыть новое соединение TCP/TLS или повторно использовать существующее соединение, если оно существует.

• Максимум два соединения TCP/TLS на удаленное полное доменное имя/IP-адрес для каждой виртуальной машины прокси-сервера SIP. Перед отправкой SIP-запроса прокси-сервер SIP проверяет наличие активных TCP-соединений с разрешенным IP-адресом целевого SBC/магистрального полного доменного имени. Если существуют два соединения, они используются повторно. Если двух соединений не существует, открывается новое соединение.

  • Эта логика предназначена для каждой виртуальной машины прокси-сервера SIP.

  • IP-адреса прокси-сервера SIP обслуживаются несколькими виртуальными машинами в каждом регионе.

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

• Соединения TCP/TLS, открытые прокси-сервером SIP, не обязательно остаются открытыми, пока действует вызов. Однако соединение не закрывается сразу после ответа на SIP-запрос. Если время ожидания соединения не истекло, оно может быть повторно использовано для других запросов SIP.

• Прокси-сервер SIP не поддерживает псевдоним соединения, как описано в RFC 59.23: Повторное использование соединения в протоколе инициации сеанса (SIP).

  • Исходящие прокси-серверы SIP TCP-подключения обслуживают только исходящие запросы прокси-сервера SIP (к SBC) и соответствующие ответы.

  • Входящие TCP-соединения прокси-сервера SIP (от SBC) обслуживают только входящие запросы SIP и соответствующие ответы.

Политики тайм-аута

• Тайм-аут простоя TCP прокси-сервера SIP составляет две минуты. Таймер сбрасывается, когда по соединению происходит транзакция SIP.

• Прокси-сервер SIP отправляет подтверждение активности приложения CRLF в соответствии с RFC 5626: Управление подключениями, инициируемыми клиентом, в протоколе инициации сеанса (SIP).

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

• После двух минут простоя (FIN, ACK) передается на вышестоящий SBC с помощью прокси-сервера SIP в течение примерно 10–20 секунд.

Примечания

• Рекомендуется, чтобы SBC активно повторно использовал соединения, такие как SIP-прокси. Этот метод экономит время, необходимое для соединений TCP и TLS.

• SBC должен обновлять соединение не реже одного раза в час.

• При загрузке нового сертификата SBC SBC должен обновить все соединения.

• При обновлении конфигураций домена рекомендуется обновить соединения SBC. В противном случае новая конфигурация будет применена после обновления внутреннего кеша прокси-сервера SIP — до четырех часов.

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

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

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

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

Обратите внимание, что трафик SIP всегда проходит через прокси-сервер SIP.

DTMF

Внутриполосный DTMF не поддерживается медиастеком.

Обратная связь

Просмотреть все отзывы о странице

Адаптер ресурсов SIP 2.5.0 :: Руководство по адаптеру ресурсов SIP :: RFC 3263: Аварийное переключение и балансировка нагрузки

RFC SIP точно следует процедурам RFC 3263, но с некоторыми адаптациями, описанными ниже.

Использование клиентских транзакций

RFC 3263 указывает, что для каждого резервного адреса используется новая клиентская транзакция. СИП РА Означает ли это; однако эти дополнительные клиентские транзакции скрыты от приложения. приложение просто создает одну JAIN SIP ClientTransaction для отправки запроса, как и раньше. Если происходит сбой и есть резервные адреса, RA автоматически создает новую клиентскую транзакцию и отправляет запрос на резервный адрес. РА заботится о маршрутизация ответов и других событий до действия ClientTransaction приложения так что это выглядит так, как будто использовалась одна клиентская транзакция.

Каждая новая клиентская транзакция, созданная для связи с резервными серверами, будет иметь новый Via идентификатор ветки (согласно RFC), но они получены из исходного идентификатора ветки с другим суффикс для каждой новой транзакции. Например, если исходная ветвь была z9hG4bK776asdhds , любые последующие транзакции будут иметь ветки z9hG4bK776asdhds%1 , z9hG4bK776asdhds%2 скоро. Таким образом, ветки для каждой транзакции по-прежнему уникальны в RA и сети. но можно сопоставить при просмотре журналов или захватов пакетов. Приложение увидит только исходный идентификатор ветки в ответах.

Первый окончательный ответ, который будет получен, завершит транзакцию, и больше не будет резервных адресов. будет опробован. Если все доступные адреса не удались, приложение увидит последний ответ об ошибке, полученный от сервера (ответ 503 или 408), или RA сгенерирует 503 ответ и передать его приложению.

Таймер аварийного переключения

Аварийное переключение на сервер резервного копирования инициируется тайм-аутом транзакции, ошибками транспорта или ответами 503. Если сервер полностью вышел из строя, результирующая транспортная ошибка (например, ICMP Port Unreachable) может не быть непосредственно видимым для RA, особенно при использовании UDP. Или может вообще не быть отказов ICMP в случае сетевого раздела. Это означает, что отработка отказа не произойдет до тех пор, пока не истечет время ожидания транзакции. (Таймеры B или F в RFC 3261), что обычно составляет 32 секунды!

Для многих приложений желательно обнаруживать сбои немного быстрее. SIP RA определяет дополнительный таймер аварийного переключения, который может истечь до истечения времени ожидания транзакции по умолчанию. инициировать аварийное переключение быстрее. Значение по умолчанию этого таймера составляет 10 секунд.

Таймер аварийного переключения запускается только при наличии нескольких адресов для проверки. Если есть только один адрес, применяется обычное поведение тайм-аута транзакции. Таймер останавливается как как только будет получен любой ответ (включая 100 Trying), так как это указывает на то, что следующий переход сервер работает. Если этот таймер истекает, а ответы не получены, RA переходит к следующему этапу. на следующий адрес.

Черный список серверов и восстановление

Сам по себе DNS не сообщает вам, доступен ли сервер. При использовании описанного выше процесса DNS то же самое набор серверов всегда будет возвращаться, независимо от того, доступны они в данный момент или нет. Чтобы избежать связи с серверами, которые могут выйти из строя, SIP RA ведет «черный список».

Всякий раз, когда обнаруживается сбой сервера из-за тайм-аута, ошибки транспорта или ответа 503, RA добавляет неудачный адрес в черный список, чтобы адрес не пробовался снова в течение некоторого времени.