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

Статья
04/07/2023
Применяется к:

Microsoft Teams

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

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

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

Имя параметра	Пример значения
URI запроса	ПАРАМЕТРЫ sip:sip.pstnhub.microsoft.com:5061 SIP /2.0
Через заголовок	Через: SIP/2.0/TLS sbc1.adatum.biz:5058; Псевдоним; branch=z9hG4bKac2121518978
заголовок Max-Forwards	Максимальное число переадресов:68
Из заголовка	Из заголовка Из: sip:sbc1.adatum.biz:5058
До заголовка	По: sip:sip.pstnhub.microsoft.com:5061
Заголовок CSeq	CSeq: 1 INVITE
Заголовок контакта	Контакт: sip:sbc1.adatum.biz:50588; transport=tls

Примечание.

Заголовки SIP не содержат userinfo в используемом URI SIP. Согласно RFC 3261, раздел 19.1.1, часть userinfo URI является необязательной и может отсутствовать, если конечный узел не имеет понятия о пользователях или когда сам узел является идентифицируемым ресурсом. Если знак @присутствует в URI SIP, поле пользователя не должно быть пустым. URI SIPS не следует использовать с прямой маршрутизацией, так как он не поддерживается. Проверьте конфигурацию пограничного контроллера сеансов и убедитесь, что в sip-запросах не используются заголовки Replaces. Прямая маршрутизация отклоняет SIP-запросы, для которых определены заголовки Replaces.

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

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

Ниже приведен пример сообщения SIP Invite при входящем вызове:

Имя параметра	Пример значения
URI запроса	INVITE sip:+18338006777@sip.pstnhub.microsoft.com SIP /2.0
Через заголовок	Через: SIP/2.0/TLS sbc1.adatum.biz:5058; Псевдоним; branch=z9hG4bKac2121518978
заголовок Max-Forwards	Максимальное число переадресов:68
Из заголовка	Из заголовка Из: <sip:+17168712781@sbc1.adatum.biz; transport=udp; tag=1c747237679
До заголовка	Для: sip:+183338006777@sbc1.adatum.biz
Заголовок CSeq	CSeq: 1 INVITE
Заголовок контакта	Контакт: sip:+17168712781@sbc1.adatum.biz:5058; transport=tls

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

Проверьте сертификат. При первоначальном подключении служба прямой маршрутизации принимает полное доменное имя, представленное в заголовке Contact, и сопоставляет его с общим именем или альтернативным именем субъекта представленного сертификата. Имя SBC должно соответствовать одному из следующих параметров:
- Вариант 1. Полное полное доменное имя, представленное в заголовке Contact, должно соответствовать общему имени или альтернативному имени субъекта представленного сертификата.
- Вариант 2. Доменная часть имени полного доменного имени, представленная в заголовке Contact (например, adatum.biz имени полного доменного имени sbc1.adatum.biz), должна соответствовать значению подстановочного знака в разделе Общее имя или альтернативное имя субъекта (например, *.adatum.biz).
Попробуйте найти клиента, используя полное полное доменное имя, представленное в заголовке Contact.

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

Удалите часть узла из полного доменного имени, указанного в заголовке Contact (FQDN: sbc12.adatum.biz, после удаления части узла: adatum.biz), и проверка, если это имя зарегистрировано в качестве DNS-имени в любой организации Microsoft 365 или Office 365. При обнаружении поиск пользователя выполняется в этом клиенте. Если не найдено, вызов завершается ошибкой.
Используя номер телефона, указанный в запросе URI, выполните обратный поиск номера в клиенте, который находится на шаге 2 или 3. Совпадите указанный номер телефона с пользовательским URI SIP в клиенте, найденном на предыдущем шаге.
Применение параметров магистрали. Найдите параметры, заданные администратором клиента для этого SBC.

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

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

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

Заголовок контакта

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

Синтаксис: Contact: <sip:phone или sip address@FQDN SBC; transport=tls>

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

Синтаксис: Contact: <sip:FQDN SBC; transport=tls>

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

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

"Имена могут содержать подстановочный знак *, который считается соответствующим любому отдельному компоненту или фрагменту компонента доменного имени. Например, *.a.com соответствует foo.a.com, но не bar.foo.a.com. f*.com соответствует foo.com, но не bar.com".

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

Для прямой маршрутизации важно, чтобы для заполнения URI SIP вместо IP-адреса использовалось полное доменное имя. Входящее сообщение INVITE или OPTIONS к прокси-серверу SIP с заголовком Contact, где имя узла представлено IP-адресом, а не полным доменным именем. Подключение отказано с 403 Запрещено.

URI запроса

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

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

INVITE sip:+18338006777@sip.pstnhub.microsoft.com SIP /2.0

Из заголовка

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

Чтобы эти поиски работали, номер телефона должен содержать значение +, как показано в следующем примере.

From: <sip:+17168712781@sbc1.adatum.biz;transport=udp;tag=1c747237679

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

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

Имя параметра	Режим без обхода	Режим обхода
Кандидаты в сми в 183 и 200 сообщениях, поступающих от	Обработчики мультимедиа	Клиенты
Число 183 сообщений, которые может получать SBC	По одному на сеанс	Несколько
Вызов может быть с предварительным ответом (183)	Да	Да
Звонок может быть без предварительного ответа (183)	Да	Да

Поток обхода без посредника

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

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

Примечание.

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

Примечание.

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

Несколько конечных точек с предварительным ответом

При получении первого приглашения от SBC прокси-сервер SIP отправляет сообщение SIP SIP/2.0 100 Trying и уведомляет все конечные точки конечного пользователя о входящем вызове.
После уведомления каждая конечная точка начинает звонить и отправлять сообщения "Ход вызова" прокси-серверу SIP. Так как пользователь Teams может иметь несколько конечных точек, прокси-сервер SIP может получать несколько сообщений о ходе вызова.
Для каждого сообщения о ходе выполнения вызова, полученного от клиентов, прокси-сервер SIP преобразует сообщение о ходе выполнения вызова в sip-сообщение "SIP/2.0 180 Ringing". Интервал для отправки таких сообщений определяется интервалом получения сообщений от контроллера вызовов. На следующей схеме представлены два 180 сообщений, созданных прокси-сервером SIP. Эти сообщения поступают от двух конечных точек Teams пользователя. Каждый клиент имеет уникальный идентификатор тега. Каждое сообщение, поступающее из другой конечной точки, является отдельным сеансом (параметр tag в поле "Кому" отличается). Но конечная точка может не создать сообщение 180 и сразу отправить сообщение 183, как показано на следующей схеме.
После того как конечная точка создает сообщение Media Answer с IP-адресами кандидатов на носитель конечной точки, прокси-сервер SIP преобразует полученное сообщение в сообщение "Ход сеанса SIP 183" с SDP от клиента, замененным SDP из обработчика мультимедиа. На следующей схеме конечная точка из Fork 2 ответила на вызов. Если магистраль не обходить стороной, сообщение SIP 183 создается только один раз (кольцевой бот или конечная точка клиента). 183 может прийти на существующую вилку или начать новую.
Отправляется сообщение о принятии звонка с окончательными кандидатами конечной точки, которая приняла вызов. Сообщение о приеме звонка преобразуется в sip-сообщение 200.

Схема, показывающая несколько конечных точек с предварительным ответом.

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

При получении первого приглашения от SBC прокси-сервер SIP отправляет сообщение SIP SIP/2.0 100 Trying и уведомляет все конечные точки конечного пользователя о входящем вызове.
После уведомления каждая конечная точка начинает звонить и отправлять сообщение "Ход вызова" прокси-серверу SIP. Так как пользователь Teams может иметь несколько конечных точек, прокси-сервер SIP может получать несколько сообщений о ходе выполнения вызова.
Для каждого сообщения о ходе выполнения звонка, полученного от клиентов, прокси-сервер SIP преобразует сообщение о ходе выполнения вызова в сообщение SIP "SIP/2.0 180 Trying". Интервал отправки сообщений определяется интервалом получения сообщений от контроллера вызовов. На следующей схеме есть два 180 сообщений, созданных прокси-сервером SIP, что означает, что пользователь вошел в три клиента Teams и каждый клиент отправляет ход выполнения вызова. Каждое сообщение является отдельным сеансом (параметр "tag" в поле "Кому" отличается)
Отправляется сообщение о принятии звонка с окончательными кандидатами конечной точки, которая приняла вызов. Сообщение о приеме звонка преобразуется в sip-сообщение 200.

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

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

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

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

Примечание.

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

Схема, показывающая поток обхода мультимедиа.

Параметр "Заменяет"

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

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

Прямая маршрутизация поддерживает два метода передачи вызовов:

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

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

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

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

Ниже приведен пример SBC, отправляющий сообщение о поддержке метода Refer:

ALLOW: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

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

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

ALLOW: INVITE, ACK, CANCEL, BYE, INFO, NOTIFY, PRACK, UPDATE, OPTIONS

Прокси-сервер SIP обрабатывает Запрос от клиента локально и выступает в качестве рефери

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

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

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

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

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

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

Этот параметр предполагает, что прокси-сервер SIP выступает в качестве передателя и отправляет сообщение Refer в SBC. SBC выступает в качестве получателя и обрабатывает ссылку, чтобы создать новое предложение для передачи. Возможны два варианта:

Вызов передается внешнему участнику ТСОП.
Вызов передается от одного пользователя Teams другому пользователю Teams в том же клиенте через SBC.

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

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

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

Номер телефона E.164 в части URI имени пользователя, если целевой объект передачи является номером телефона, или
Параметры x-m и x-t, кодирующие МРТ полного целевого объекта передачи и идентификатор клиента соответственно

Заголовок REFERRED-BY — это URI SIP с закодированными в нем МРТ передателя, идентификатором клиента и другими параметрами контекста передачи, как показано в следующей таблице:

Параметр	Значение	Описание
x-m	МРТ	Полная МРТ передателя/целевого объекта передачи, заполненная CC
x-t	Идентификатор клиента	X-t Идентификатор клиента Необязательный идентификатор клиента, заполненный CC
x-ti	Идентификатор корреляции передателя	Идентификатор корреляции вызова передателя
x-tt	URI целевого вызова для передачи	Кодированный URI замены вызова

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

Схема, показывающая процесс ссылки на.

Переадресация звонков

Пользователь Teams может переадресовать входящие звонки другому номеру или пользователю Teams, позвонить другим пользователям или пользователям параллельно (одновременный звонок) или позвонить группе пользователей или номеров. Примите во внимание следующее:

Request-URI в запросе INVITE от прокси-сервера SIP к пользователю C содержит параметр cause .
В зависимости от конфигураций магистрали (параметр ForwardCallHistory ) заполняется заголовок History-Info.
Если пользователь A является другим пользователем ТСОП, прокси-сервер SIP создает предварительный ответ "SIP SIP/2.0 181 Call is переадресован" пользователю A.
Если пользователь A и пользователь C являются пользователями ТСОП, прокси-сервер SIP сохраняет предварительный ответ "SIP SIP/2.0 181 Call is forwarded".
Заголовок History-Info следует использовать для предотвращения циклов.

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

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

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

Прокси-сервер SIP анализирует URI запроса и, если параметр user=phone присутствует, служба обрабатывает 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 сохраняется при включении параметра ForwardCallHistory. Сохраненные History-Info можно использовать для предотвращения циклов.

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

<sip:UserB@sip.pstnhub.microsoft.com?Privacy=history&Reason=SIP%3Bcause%3D486>;index=1.2

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

Пример заголовка:

History-Info:
  <sip:+14257123456@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D302%3Btext%3D%22Moved%20temporarily%22>;index=1,
  <sip:+14257123456@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D496%3Btext%3D%22User%20Busy%22>;index=1.1

URI SIP в заголовке History-Info отформатирован в соответствии с разделом 25 RFC 3261 (см. определение addr-spec). В предыдущем примере исходный текст заголовка Reason URI — SIP;cause=496;text="User Busy", который получает символы ;, "и = , экранированные в шестнадцатеричные значения %3BASCII , %22и 3Dсоответственно.

History-Info защищен обязательным механизмом TLS.

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

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

Retry-After

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

Обработка повторных попыток (ответ 603)

Если пользователь наблюдает несколько пропущенных вызовов для одного вызова после отклонения входящего вызова, это означает, что механизм повторных попыток поставщика магистрали SBC или ТСОП настроен неправильно. Необходимо перенастроить SBC, чтобы остановить повторные попытки в ответе 603.

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

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

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

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

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

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

Поделиться через