Sip options что это

RFC SIP

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

SIP- запросы

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

Адресация SIP

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

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

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

IP-интеграция

Подобные сервисы могут создавать три группы людей: производители SIP- оборудования, сервис-провайдеры и сами конечные пользователи. Язык CPL несложен, так что, видимо, многие будут способны реализовать вполне изощренную схему работы автоответчика: скажем, если позвонивший набирает цифру 1, он переключается на домашний телефон абонента, если 2 – на сотовый, если 3 – на телефон его родителей и т. д. А почему бы не написать скрипт, который, когда раздастся звонок, показывал бы вам лицо (фотографию) звонящего? Телефон ресторана мог бы, скажем, сразу выдавать на дисплей сегодняшнее меню, – короче говоря, возможности здесь ограничены только фантазией пользователя.

Поскольку все современные ERP-, CRM- и т. п. системы работают по протоколу IP, SIP без особых проблем интегрируется с ними (в отличие от H.323, которому его телефонная природа мешает взаимодействовать с большинством приложений).

Сценарий установления соединения

между пользователями

Первый пользователь снимает трубку и набирает номер, SIP-клиент генерирует сигнал INVITE (приглашение), у второго пользователя звонит телефон, его SIP-клиент выдает сообщение 180 (Ringing, звонок), затем пользователь берет трубку, SIP-клиент выдает сообщение 200 (OK), первый SIP-клиент посылает второму сигнал ACK (подтверждение) – и далее начинается передача голосового потока по протоколу RTP (Real-time Transport Protocol). Когда разговор окончен и один из пользователей вешает трубку, SIP-клиент посылает сигнал BYE. Вот и все.

в сети предприятия

Но такая схема абсолютно неэффективна, когда клиентов в сети не два, а два миллиарда. SIP-сетям с большим числом пользователей необходима инфраструктура, и ее создают различные серверы SIP. Сервер регистрации (registrar) занимается учетом и авторизацией пользователей, сервер локализации (allocation) ищет их и определяет их местонахождение, сервер переадресации (redirect) переводит звонки абонентам туда, где они фактически находятся в данный момент, – если меня, например, нет в Москве, потому что я уехал в Америку, сервер переведет звонок на мой американский номер. Наиболее сложные функции ложатся на прокси-сервер (SIP Proxy), обеспечивающий взаимодействие внутренней (например, учрежденческой) IP-телефонной сети с внешним миром, – именно он определяет все политики, правила общения и т. д. Существуют и другие серверы SIP (например, сервер конференций), но они менее важны. На рисунке показано, как может работать SIP в сети предприятия.

Пользователь Алиса приходит на свое рабочее место в компании Example, включает в корпоративную сеть ноутбук и активизирует имеющийся на нем программный телефон, который автоматически регистрируется на сервере регистрации. Тот, в свою очередь, запрашивает информацию о пользователе в корпоративной базе данных и сообщает о том, как с ним контактировать, серверу локализации. (Оба сервера могут интегрироваться с различными базами данных, службами каталогов типа LDAP или MS Active Directory и т. д.) Теперь, когда кто-нибудь позвонит Алисе, прокси-сервер, запросив сервер локализации, установит связь с ее рабочим местом.

Аутентификация и авторизация SIP 2.0

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

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

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

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

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

Источник

Asterisk sip.conf General SIP Options

Полный список параметров general sip.conf

Следующие параметры используются в общей [general] секции sip.conf:

allowexternalinvites

Если установлено ‘no’, запрещает INVITE и REFER от внешних (не из localnet) доменов. См domain

allowguest

Если ‘no’, запрещает гостевые(без аутентификации) подключения. По умолчанию sipguest подключения разрешены.

allowoverlap

Вкл. или Выкл набор по одной цифре (т.е. каждая набранная цифра будет сразу отправляться в канал)

allowsubscribe

allowtransfers

Когда установлено ‘no’, запрещает любые трансферы, если не переопределено в настройках пира.

alwaysauthreject

autodomain

Установите эту опцию ‘yes’, чтобы добавить локальное HOSTNAME и локальный IP адрес в список доменов:

bindaddr and bindport

Эти параметры определяют IP адрес и порт на которых Asterisk будет слушать SIP запросы. Для драйвера канала SIP Asterisk ‘chan_sip’ можно назначить только один адрес и порт для всех подключений для UDP и один порт для TCP транспорта, в отличии от нового драйвера PJSIP. По умолчанию адрес не задан и лучше так и оставить. Некоторые рекомендуют изменять порт по умолчанию 5060, на другой, в целях безопасности. Но помните, что это только одна из мер безопасности, не самая важная, и не гарантирует вам полной защиты от злоумышленников.

Вы можете задать независимые для UDP, TCP и TLS транспорта значения udpbindadd, tcpbindaddr и tlsbindaddr

buggymwi

Вкл. эту опцию, чтобы избежать ошибок при сообщении с некоторыми ip телефонами при отправке MWI сообщений.

callevents

Установите ‘yes’, если хотите генерировать информацию о SIP событиях для AMI (asterisk manager interface)

checkmwi

Время в секундах, между проверками голосовой почты :

compactheaders

Использовать или нет компактные SIP заголовки.

defaultexpiry

Срок действия регистрации в секундах для входящих и исходящих регистраций. При входящей регистрации, этот параметр задается клиентской стороной, и заданное здесь значение используется, только если клиент не сообщил свое занчение. Для исходящих регистраций этот параметр сообщается удаленной стороне UAS (user agent server)

directrtpsetup

domain

Задает имя домена сервера Asterisk по умолчанию. Командой CLI ‘sip show domains’ выводится список локальных доменов.

dumphistory

externhost

externip

externrefresh

g726nonstandard

Значения: yes/no, по умолчанию: no. Если клиент собирается для сеанса связи «договориться» использовать звуковой кодек G726-32, с использованием компрессии AAL2, вместо RFC3551 (что требуется для аппаратов фирмы Sipura и шлюзов от Grandstream, и может другим). То это противоречит спецификации RFC3551, клиент должен вместо этого «договориться» использовать AAL2-G726-32

ignoreregexpire (global)

Если ignoreregexpire установлен ‘yes’, Asterisk сделает одно из двух, в зависимости от настроек пиров: 1)Non-realtime peer Когда регистрация истекает, информация не удаляется из памяти или БД Asterisk и вызовы будут разрешены несмотря на то, что время регистрации истекло.

2)Realtime peers Когда peer сконфигурирован в режиме реального времени, информация о регистрации используется независимо от defaultexpiry

jbenable

jbforce

Принудительное использование jitter buffer принимающей стороной SIP канала.

jbimpl

Использовать фиксированный или подстраиваемый (адаптивный) jitter buffer. fixed jitter buffer всегда использует значение из jbmaxsize adaptive может принимать значение больше jbmaxsize По умолчанию ‘fixed’:

Из личного опыта, вкл. ‘adaptive’ может приводить к весьма плачевным результатам.

jblog

Вкл./выкл jitter buffer frame лог. По умолчанию ‘no’:

jbmaxsize

Установите максимальную длину буфера в миллисекундах:

jbresyncthreshold

Джиттер буфер порог синхронизации. По умолчанию 1000:

icesupport

limitonpeers

Применять call-limit только для type=peer Это улучшит использование call-limit для устройств настроенных, как type=friend, отделив ограничение call-limit от входящих вызовов.

localnet

укажет серверу Asterisk какие подсети являются локальными, прозрачными для использования IP адресов сервера, SIP запросы к которым не требуют модификации поля Contact: c использованием externip или externhost

matchexterniplocally

Сверять ‘externip’ с ‘localnet’ и производить подстановку, только если ‘externip’ из локальной подсети. Не совсем ясно, зачем это может понадобиться? Возможно при очень нестандартной топологии сети.

maxexpiry

Максимальная продолжительность регистрации в секундах.

minexpiry

Минимальная продолжительность регистрации в секундах.

notifymimetype

Указывает MIME тип используемый для message-waiting indication (MWI) в SIP NOTIFY сообщении.

notifyringing

Сообщать подписчикам о состоянии вызов (RINGING):

notifyhold

Сообщать подписчикам (subscribers) о состоянии удержание (HOLD):

pedantic

realm

recordhistory

Вкл. или Выкл историю sip для всех каналов.

registerattempts

Сколько попыток внешних регистраций произведет Asterisk, прежде чем откажется от продолжения. По умолчанию стоит ‘0’, что значит бесконечно.

registertimeout

Таймаут между попытками регистрации на другом устройстве.

relaxdtmf

rtautoclear

(global) Конфигурация Realtime Peers Указывает должен ли Asterisk обнулять созданные на лету friends по истечении времени регистрации. Если установлено ‘yes’, по истечении срока регистрации, удалять friends до нового запроса. Если задано число, то оно используется вместо обычного времени регистрации.

rtcachefriends

Если rtcachefriends включен, Asterisk будет кэшировать friends(реалтайм пиры), которые приходят из realtime engine, так же, как если бы они сконфигурированы в «sip.conf».

rtsavesysname

(global) Определяет, должен ли Asterisk сохранить SystemName в базе данных в режиме реального времени во время регистрации:

rtupdate

(global) Если установлено ‘yes’ Asterisk будет обновлять IP-адрес, порт и период регистрации пиров при регистрации. По умолчанию ‘yes’:

sipdebug

sendrpid

ОТправлять или нет Remote-Party-ID header:

srvlookup

transport

Задает транспорт по умолчанию. По умолчанию ‘udp’, но может быть ‘tcp’, ‘tls’, ‘ws’ или ‘wss’. Если задано TCP а tcpenable=no будет использован UDP транспорт.

tcpenable

Включить поддержку TCP транспорта chan_sip Asterisk.

tcpbindaddr

Адрес на котором Asterisk «слушает» TCP подключения.

tcpauthtimeout

tcpauthtimeout указывает максимальное время в секундах данное клиенту на аутентификацию. Если за заданное время клиент не прошел проверку он отключается. (По умолчаннию 30 секунд)

tcpauthlimit

Максимальное кол-во неаутентифицированных сессий в момент любой времени.

t1min

Минимальная задержка туда-обратно (minimum round-trip) для сообщения контролируемого хоста. По умолчанию 100 миллисеунд:

subscribecontext

Ограничить запросы SUBSCRIBE только указанным контекстом, если не переопределено в настройках пира.

t38pt_udptl

tos_sip, tos_audio, andtos_video

trustrpid

Доверять или нет Remote-Party-ID header: Asterisk SIP trustrpid

useragent

Если вы не желаете сообщать, что используете Asterisk, напишите Cisco или Avaya, или abyrvalg v2.0.

usereqphone

usereqphone опция говорит Asterisk добавить «user=phone» в SIP URIs которые содержат действующий номер телефона:

Источник

Анализ SIP пакета, на примерах рабочего вызова и со сбоем

В период работы с астериском рано или поздно задумываешься о том, почему не получается прозвониться и обычное чтение лога не помогает. На помощь приходит снятый дамп. В этой статье рассмотрим разные дампы SIP сообщений и постараемся разобрать на примерах причины неисправностей, а также найти виновника найденной неполадки. Структура SIP SIP – это структурированный многоуровневый протокол […]

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

Структура SIP

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

В одинарные запросы входят пакеты со следующими методами:

К диалоговым методам можно отнести:

Пакет INVITE

Структура сообщений в SIP одинакова. Стартовая строка → Заголовки → Пустая строка → Тело сообщения. Для примера рассмотрим Пакет INVITE:

Далее следует основное тело пакета с полями заголовков. В основной своей части используются заголовки:

В заголовоке Via записывается адрес устройства, отправившего сообщение, Транспортный протокол, номер порта на который нужно отправить обратно и идентификатор транзакции.

Поле Max-Forwards указывает максимальное количество полей Via может быть в пакете.

Заголовок From предназначен для обозначения инициатора запроса с указанием адреса uri и отображаемого имени.

В заголовок To подставляется информация о получателе сообщения. Зачастую формируется из значения Ruri. Т.к. в дальнейшем на клиентской стороне может быть изменена.

Заголовок Call—ID – это уникальный идентификатор, сохраняющийся на протяжении всего диалога.

В Cseq записывается порядковый номер запроса и имя метода, которое передается,

В поле Contact записывается URI адрес того устройства, на которое должен прийти ответ. Т.е. в приведенном выше примере, ответ прийдет из всех зарегистрированных устройств пользователя 102 на устройство

Т.е. сравните поля From и Contact в нашем примере:

В поле From указан адрес сервера астериска, а в поле Contact указан адрес устройства.

Причины отбоя INVITE

Причиной данной неполадки может быть:

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

Схема вызова в данном случае читается следующим образом:

Примеры вызовов

Рассмотрим корректный вызов:

Вызов на не зарегистрированного пользователя.

В пакете мы видим причину разъединения в полях X-Asterisk-HangupCause и X-Asterisk-HangupCauseCode (в данном примере это пользователь не найден).

7. Инициатор, подтверждает завершение вызова.

Пакет REGISTER

Рассмотрим пример пакета REGISTER и опишем его работу

Заголовки пакета и их назначение

Основные заголовки пакета:

Поле Via содержит адреса устройств, через которые маршрутизировался этот пакет, это могут быть различные АТС, proxy сервера и т. д.

Max-Forwards – указывается максимальное колличество хопов (прыжков/переадресаций) которые может пройти пакет до пункта назначения

Заголовок From предназначен для обозначения инициатора запроса с указанием адреса uri и отображаемого имени.

В заголовок To подставляется информация о получателе сообщения. Зачастую формируется из значения Ruri.

Заголовок Call—ID – это уникальный идентификатор, сохраняющийся на протяжении всего диалога.

В Cseq записывается порядковый номер запроса и имя метода, которое передается.

Возможные причины отбоя регистрации

В этом блоке будем рассматривать самые распространенные причины сбоев в регистрации

Причинами этой ситуации может быть:

Смотреть лог или консоль астериска

Смотреть лог или консоль астериска.

Смотреть лог или консоль астериска.

Примеры регистрации

Рассмотрим корректную регистрацию:

Рассмотрим не верную авторизацию:

Источник

Прямая маршрутия — протокол SIP

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

Обработка входящих запросов: поиск клиента и пользователя

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

Заглавные данные SIP не содержат userinfo в используемом URI SIP. В соответствии с RFC 3261, разделом 19.1.1userinfo URI является необязательным и может отсутствовать, если конечного хоста нет представления о пользователях или когда хост является идентифицированным ресурсом. Если знак @ присутствует в URI SIP, поле пользователя НЕ ДОЛЖНО быть пустым. Обратите внимание, что URI SIPS не следует использовать с direct Routing, так как он не поддерживается. Проверьте конфигурацию контроллера границы сеанса и убедитесь, что в запросах SIP не используется заглавная «Замена». Прямая маршрутия отклоняет запросы SIP с задаваемой заменой.

Во время входящих зовов прокси-сервер SIP должен найти клиент, на который он перенапрался, и конкретного пользователя в этом клиенте. Администратор клиента может настроить номера без DID, например +1001, в нескольких клиентах. Поэтому важно найти конкретный клиент, для которого нужно выполнить поиск номеров, так как неИдационные числа могут быть одинаковыми в Microsoft 365 или Office 365 организациях.

В этом разделе описано, как прокси-сервер SIP находит клиента и пользователя, а также выполняет проверку подлинности SBC при входящих подключениях.

Ниже приводится пример приглашения SIP во входящий звонок:

При получении приглашения прокси-сервер SIP выполняет следующие действия:

Проверьте сертификат. По первоначальному подключению служба прямой маршрутизовывания принимает имя FQDN, которое представлено в заглавной части контакта, и совпадает с именем «Общее имя» или «Тема альтернативы» для представленного сертификата. Имя SBC должно соответствовать одному из следующих вариантов:

Вариант 1. Полное полное имя FQDN, которое есть в заглавном тексте контакта, должно совпадать с именем «Общее имя/тема» для сертификата.

Вариант 2. Часть домена имени FQDN, представленная в заглавной части контакта (например, adatum.biz имени FQDN sbc1.adatum.biz), должна соответствовать поддеревной знаку в названии «Общее имя» или «Альтернативное имя субъекта» (например, *.adatum.biz).

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

Проверьте, зарегистрировано ли имя FQDN из заглавного sbc1.adatum.biz контакта в любой организации Microsoft 365 или Office 365 DNS. При обнаружении выполняется подсмотр пользователя в клиенте, в доменном имени которого зарегистрированО FQDN SBC. Если она не найдена, применяется шаг 3.

Шаг 3 применяется только в случае сбойного шага 2.

Удалите часть хоста из FQDN, представленную в заглавном имени контакта (FQDN: sbc12.adatum.biz, после удаления части хоста: adatum.biz) и проверьте, зарегистрировано ли это имя как имя DNS в любой организации Microsoft 365 или Office 365. При обнаружении в этом клиенте выполняется пользовательский просмотр. Если он не найден, звонок не удастся найти.

Используя номер телефона, представленный в URI-запроса, выполните обратный просмотр номера в клиенте, найденном в шаге 2 или 3. Сопопошать представленный номер телефона с пользовательским URI SIP в клиенте, найденном на предыдущем шаге.

Применим параметры туловища. Найдите параметры, заданные администратором клиента для этого SBC.

Корпорация Майкрософт не поддерживает наличие прокси-сервера SIP сторонних пользователей или сервера агента пользователя между прокси-сервером SIP Майкрософт и сопряженным сервером SBC, который может изменить URI запроса, созданный парным SBC.

Требования для двух подысков (этапов 2 и 3), необходимых для сценария, в котором один SBC взаимосвязан с множеством клиентов (сценарий оператора связи), см. далее в этой статье.

Подробные требования для загона контактов и запроса URI

Заглавная связь с контактом

Для всех входящих сообщений SIP (OPTIONS, INVITE) на прокси-сервер SIP Майкрософт закаглавная запись контакта должна иметь сопряженное FQDN SBC в имени хоста URI следующим образом:

В соответствии с RFC 3261, раздел 11.1, поле заглавного поля контакта может присутствовать в сообщении OPTIONS. В прямой маршрутике требуется заглавная линия контакта. Для сообщений INVITE в формате выше для сообщений OPTIONS, которые userinfo можно удалить из SIP URI и только FQDN, отправленных в формате:

Это имя (FQDN) также должно быть в полях «Общее имя» или «Альтернативные имена субъекта» в сертификате. Корпорация Майкрософт поддерживает использование поддеревных значений имен в полях «Общее имя» или «Альтернативное имя субъекта» сертификата.

Поддержка поддеревных знаков описана в разделе 3.1 RFC 2818. Специально:

Если SBC отправляет несколько значений в заглавном сообщении контакта, используемой SBC, используется только часть FQDN первого значения в заглавном сообщении контакта.

Как правило, при прямой маршрутике для заполнения URI SIP вместо IP-адреса используется FQDN. Сообщение о входящих ПРИГЛАШЕНИЯх и параметрах на прокси-сервер SIP с названием контакта, в котором имя сервера представлено IP, а не FQDN, подключение будет отклонено с помощью параметра 403 Запрещено.

URI запроса

Для всех входящих звонков для совпадения номера телефона с пользователем используется запрос-URI.

В настоящее время номер телефона должен содержать знак «плюс» (+), как показано в примере ниже.

Из области «Заглавная»

Для всех входящих звонков закаглавка «От» используется для совпадения номера телефона звоня с заблокированным списком номеров телефонов вызываемого.

Номер телефона должен содержать +, как показано в примере ниже.

Контактные и Record-Route с Record-Route.

Прокси-сервер SIP должен вычислить FQDN следующего перехода для новых клиентских транзакций в диалоговом оке (например, Bye или Re-Invite), а также при ответе на параметры SIP. Используются контакты или Record-Route контактов.

Согласно RFC 3261, разделу 8.1.1.8в любом запросе, который может привести к новому диалоговом оклу, требуется заглавная связь контакта. Этот Record-Route требуется только в том случае, если прокси-сервер хочет оставаться на пути будущих запросов в диалоговом окке. Если прокси-сервер SBC используется с локальной оптимизацией мультимедиа для прямой маршрутизации, необходимо настроить маршрут записи, так как прокси-сервер должен оставаться в маршруте.

Корпорация Майкрософт рекомендует использовать только заглавную запись контакта, если не используется прокси-сервер SBC:

В соответствии с RFC 3261, раздел 20.30, Record-Route используется, если прокси-сервер хочет оставаться на пути будущих запросов в диалоговом окке, что не важно, если ни один прокси-сервер SBC не настроен, так как весь трафик проходит между прокси-сервером Microsoft SIP и сопряженным SBC.

Прокси-сервер SIP (Майкрософт) использует только заглавную запись контакта (а не Record-Route) для определения следующего перехода при отправке параметров исходящие связи. Настройка только одного параметра (Контакт) вместо двух (Contact и Record-Route) упрощает администрирование, если прокси-сервер SBC не используется.

Для вычисления следующего перехода прокси-сервер SIP использует:

Приоритет 1. Запись верхнего уровня. Если имя FQDN Record-Route верхнего уровня, имя FQDN используется для соединения исходящие в диалоговом окну.

Приоритет 2. Заглавная связь с контактом. Если Record-Route не существует, прокси-сервер SIP будет искать значение в заглавной части контакта, чтобы сделать исходящие подключения. (Рекомендуемая конфигурация.)

Если используются как contact, так и Record-Route, администратор SBC должен сохранить одинаковые значения, что приводит к накладным расходовам администратора.

Использование имени FQDN в контакте или Record-Route

Использование IP-адреса не поддерживается ни в Record-Route, ни в контакте. Единственным поддерживаемым вариантом является FQDN, которое должно совпадать с общим именем или альтернативным именем субъекта сертификата SBC (поддерживаются поддеревные знаки в сертификате).

Если IP-адрес присутствует в record-route или Contact, проверка сертификата не проходит, а звонок не проходит.

Если FQDN не соответствует значению общего или альтернативного имени субъекта в представляемом сертификате, вызов не происходит.

Входящий звонок: описание диалогового окно SIP

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

Поток обхода без мультимедиа

У Teams может быть несколько конечных точек одновременно. Например, Teams для Windows, Teams для iPhone и Teams Телефон (Teams клиента Android). Каждая конечная точка может сигнализировать об отстаке HTTP следующим образом:

Ход выполнения звонка — преобразуется прокси-сервером SIP в сообщение SIP 180. При получении сообщения 180 SBC должен создать локальный звонок.

Медиаотобращение— преобразуется прокси-сервером SIP в сообщение 183 с кандидатами на мультимедиа в протоколе SDP. При получении сообщения 183 SBC рассчитывает подключиться к медиаимумам, полученным в сообщении SDP.

В некоторых случаях ответ на вопрос «Мультимедиа» может не быть создан, а конечный пункт может ответить сообщением «Звонок принят».

Звонок принят — преобразуется прокси-сервером SIP в сообщение SIP 200 с SDP. При получении сообщения 200 ожидается отправка и получение мультимедиа для предоставленных кандидатов SDP и от них.

Прямая маршрутная маршрутия не поддерживает приглашение с задержкой предложения (приглашение без SDP).

Несколько конечных точек, которые звонят с временным ответом

При получении первого приглашения из SBC прокси-сервер SIP отправляет сообщение «SIP SIP/2.0 100 Trying» и сообщает конечным точкам пользователей о входящих звонках.

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

Для каждого сообщения о ходе выполнения звонка, полученного от клиентов, прокси-сервер SIP преобразует сообщение о ходе выполнения звонка в сообщение SIP «SIP SIP/2.0 180 Trying». Интервал для отправки таких сообщений определяется интервалом получения сообщений от контроллера звонка. На приведенной ниже схеме прокси-сервером SIP создается 180 сообщений. Эти сообщения приходят из двух Teams конечных точек пользователя. У каждого клиента есть уникальный ИД тега. Каждое сообщение из другой конечной точки будет отдельным сеансом (параметр «тег» в поле «To» будет разным). Однако конечная точка может не создать сообщение 180 и отправить сообщение 183 сразу, как показано на приведенной ниже схеме.

После того как конечная точка создает сообщение «Ответ на мультимедиа» с IP-адресами кандидатов на поддержку мультимедиа конечной точки, прокси-сервер SIP преобразует полученное сообщение в сообщение «Ход выполнения сеанса SIP 183», а SDP клиента будет заменена SDP-сервером из процессора мультимедиа. На приведенной ниже схеме конечная точка из Висяча 2 ответила на звонок. Если ни одна из сторон связи не обойдена, сообщение SIP 183 создается только один раз (ring bot или client end point). На 183-й может быть уже существующий висячий или новый.

Вместе с конечными кандидатами конечной точки, которые приняли звонок, будет отправлено сообщение о приеме звонка. Сообщение о приемке вызовов преобразуется в сообщение SIP 200.

Несколько конечных точек, которые звонят без предварительного ответа

При получении первого приглашения из SBC прокси-сервер SIP отправляет сообщение «SIP SIP/2.0 100 Trying» и сообщает конечным точкам пользователей о входящих звонках.

После уведомления каждая конечная точка начнет звонить и отправлять сообщение «Ход выполнения звонка» на прокси-сервер SIP. Так как Teams может иметь несколько конечных точек, прокси-сервер SIP может получать несколько сообщений о ходе выполнения зовов.

Для каждого сообщения о ходе выполнения звонка, полученного от клиентов, прокси-сервер SIP преобразует сообщение о ходе выполнения звонка в сообщение SIP «SIP SIP/2.0 180 Trying». Интервал для отправки сообщений определяется интервалом получения сообщений с контроллера звонка. На рисунке ниже 180 сообщений, созданных прокси-сервером SIP, то есть пользователь вошел в три клиента Teams и каждый клиент отправил ход выполнения звонка. Каждое сообщение будет отдельным сеансом (параметр «тег» в поле «To» отличается)

Вместе с конечными кандидатами конечной точки, которые приняли звонок, будет отправлено сообщение о приеме звонка. Сообщение о приемке вызовов преобразуется в сообщение SIP 200.

Поток обхода мультимедиа

Те же сообщения (100 trying, 180, 183) используются в сценарии обхода мультимедиа.

В приведенной ниже схеме показан пример обхода потока зова.

Кандидаты на выбор мультимедиа могут быть из разных конечных точек.

Параметр «Заменяет»

SBC должен поддерживать приглашение на замену.

Размер аспектов SDP

Интерфейс прямой маршрутизации может отправить сообщение SIP, превышающий 1500 тол. Это главным образом связано с размером SDP. Однако если за SBC находится магистраль UDP, оно может отклонить сообщение, если оно будет перенапрано с прокси-сервера SIP Майкрософт на неизмененную. Корпорация Майкрософт рекомендует обрезать некоторые значения в SDP на SBC при отправке сообщения на ленту UDP. Например, можно удалить соитли ICE или неиспользованые кодеки.

передача вызовов;

Прямая маршрутия поддерживает два способа перенаправки вызовов:

Вариант 1. Процессы прокси-сервера SIP. Они относятся к локальному клиенту и выступают в качестве посредника, как описано в разделе 7.1 RFC 3892.

При этом прокси-сервер SIP прекращает передачу и добавляет новое приглашение.

Вариант 2. Прокси-сервер SIP отправляет ссылку на SBC и выступает в качестве переносителя, как описано в разделе 6 RFC 5589.

При этом прокси-сервер SIP отправляет ссылку на SBC и ожидает, что SBC полностью обработать передачу.

Прокси-сервер SIP выбирает метод на основе возможностей, о возможностях, о которые сообщает SBC. Если SBC указывает на то, что он поддерживает метод «Refer», прокси-сервер SIP будет использовать вариант 2 для перенаправок.

Ниже по образцу SBC отправляется сообщение о том, что метод Refer поддерживается:

Если SBC не указывает на то, что «Ссылка как поддерживаемый способ», прямая маршрутия будет использовать вариант 1 (прокси-сервер SIP выступает в качестве подмножества). Кроме того, SBC должен сигнализировать о том, что он поддерживает метод Notify:

Пример SBC, указывающий на то, что метод Refer не поддерживается:

Процессы прокси-сервера SIP. Ссылаются на локального клиента и выступают в качестве посредника

Если SBC указал, что метод Refer не поддерживается, прокси-сервер SIP выступает в качестве посредника.

Запрос на ссылку, который приходит от клиента, будет прекращен на прокси-сервере SIP. (На приведенной ниже схеме запрос на передачу от клиента показан как «Передача вызовов Е. Дополнительные сведения см. в разделе 7.1 RFC 3892.

Прокси-сервер SIP отправляет ссылку на SBC и выступает в качестве посредника

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

Стандартная процедура объясняется в разделе 6 RFC 5589. Связанными будут:

Предполагается, что прокси-сервер SIP выступает в качестве переносителя и отправляет в SBC сообщение «Ссылка». SBC выступает в качестве переносимой и обрабатывает ссылку для создания нового предложения для передачи. Возможны два случая:

Если звонок переносится от одного Teams пользователя к другому через SBC, предполагается, что SBC выдает новое приглашение (начать новое диалоговое окно) для целевого Teams, используя сведения, полученные в сообщении.

Чтобы заполнить поля To/Transferor для транзакции запроса внутри нее, прокси-сервер SIP должен передавать эти сведения в заглавных полях REFER-TO/REFERRED-BY.

Прокси-сервер SIP будет формировать REFER-TO как URI SIP, состоящий из FQDN прокси-сервера SIP в имени хоста и одного из следующих uri:

Номер телефона E.164 в части URI имени пользователя, если целевым объектом передачи является номер телефона или

Параметры x-m и x-t, кодющие полную передачу параметров MRI и ИД клиента соответственно

Заглавный код REFERRED-BY — это URI SIP с кодом MRI-кода переносителя, а также кодом клиента переноса и другими параметрами контекста передачи, как показано в таблице ниже.

В этом случае размер заглавной ссылки может быть не более 400 символов. SBC должен поддерживать обработку ссылок с сообщениями размером до 400 символов.

Сеансовой timer

Прокси-сервер SIP поддерживает (всегда предлагает) время сеанса при звонках без обхода, но не предлагает его при обходе звонков. Использование SBC timer сеанса не является обязательным.

Использование параметра Request-URI user=phone

Прокси-сервер SIP анализирует запрос-URI, и если параметр user=phone присутствует, служба будет обрабатывать request-URI как номер телефона, совпадая с номером пользователя. Если параметра нет, прокси-сервер SIP применяет авристику для определения типа пользователя Request-URI (номер телефона или SIP-адрес).

Корпорация Майкрософт рекомендует всегда применять параметр user=phone, чтобы упростить настройку звонков.

History-Info загона

Заглавная History-Info используется для перенанабножать запросы SIP и «предоставлять» стандартный механизм сбора сведений об истории запросов, чтобы обеспечить поддержку широкого круга служб для сетей и конечных пользователей». Дополнительные сведения см. в разделе RFC 4244 — раздел 1.1. В Телефон (Майкрософт) система этот замещающий

При отправке History-Info включено следующим образом:

Прокси-сервер SIP вставит параметр, содержащий связанный номер телефона, в отдельные записи History-Info, которые включают History-Info, отправленные на контроллер ЗВОНКОВ. Если использовать только записи с параметром номера телефона, контроллер ЗВОНКОВ перестроит новый History-Info и передаст его поставщику услуг связи SIP через прокси-сервер SIP.

History-Info будут добавлены загон для одновременных звонка и случаев переад вызовов.

History-Info не будет добавлен для случаев перена передачи вызовов.

В восстановленном History-Info записи истории будет параметр номера телефона, предоставленный в сочетании с FQDN прямой маршрутии (sip.pstnhub.microsoft.com), заданным в качестве хост-части URI; Параметр «user=phone» будет добавлен в URI SIP. Любые другие параметры, связанные с исходным History-Info, за исключением контекстных параметров телефона, будут передаваться в повторно построенном History-Info.

Частные записи (в соответствии с механизмами, определенными в разделе 3.3 RFC 4244) будут перенаправлены так же, как и частные записи, так как поставщик услуг связи SIP является доверенным пиром.

Входящие History-Info игнорируются.

Ниже приводится формат заглавного заглавного адреса «История-сведения», отправленного прокси-сервером SIP:

Если звонок перенаправлялся несколько раз, сведения о каждом перенаправлении включаются с соответствующей причиной в хронологическом порядке.

Пример заглавного за

Этот History-Info защищен с помощью обязательного механизма TLS.

Подключение SBC к прямой маршрутике и механизму отбойного управления

См. раздел Механизм отрезка для сигнального сигнала SIP в статье Планирование прямой маршрутизации.

Retry-After

Если центр обработки данных Direct Routing занят, служба может отправить Retry-After с интервалом в одну секунду в SBC. Когда SBC получает сообщение 503 с Retry-After в ответ на приглашение, он должен прекратить подключение и попробовать следующий доступный центр обработки данных Майкрософт.

Обработка ирисовки (603 ответа)

Если конечный пользователь наблюдает несколько пропущенных звонков для одного звонка после отступа, это означает, что механизм повторной работы поставщика услуг связи SBC или STN неправильно сконфигурировали. Чтобы остановить попытку ответа 603, необходимо перенастроить SBC.

Перезапуск ICE: звонок «Обход мультимедиа» переносится на конечную точку, которая не поддерживает обход мультимедиа

SBC должен поддерживать перезапуски ICE, как описано в разделе 9.1.1.1.1 RFC 5245.

Перезапуск в прямой маршрутике выполняется в соответствии со следующими абзацами RFC:

Чтобы перезапустить ICE, агент должен изменить в предложении как льдовый, так и льдовый уфраг для потока мультимедиа. Обратите внимание, что атрибуты уровня сеанса можно использовать в одном предложении, но использовать тот же атрибут ice-pwd или ice-ufrag, что и атрибуты уровня мультимедиа в последующих предложениях. Это не изменение пароля, а изменение его представления и не приведет к перезапуску ICE.

Агент задает остальные поля в SDP для этого потока мультимедиа так же, как в первоначальном предложении этого потока мультимедиа (см. раздел 4.3). Следовательно, в набор кандидатов могут быть некоторые, никто или все предыдущие кандидаты для этого потока, а также новый набор кандидатов, собранный в соответствии с разделом 4.1.1.

Если звонок был изначально установлен с помощью обхода мультимедиа и перенаправлен в клиент Skype для бизнеса, необходимо вставить процессор мультимедиа, так как прямая маршрутия не может использоваться с клиентом Skype для бизнеса с обходом мультимедиа. Прямая маршрутизации запускает процесс перезапуска ICE, изменяя льдом и льдом-ufrag и предлагая новых кандидатов мультимедиа в повторной обработке.

Источник