Службы коммуникации Azure прямая маршрутизация: сведения о протоколе SIP

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

Обработка входящего запроса: поиск ресурса Служб коммуникации

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

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

Пример сообщения "Приглашение SIP" для входящего вызова:

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

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

   • Вариант 1. Полное полное доменное имя, представленное в заголовке контакта, должно соответствовать общему имени или альтернативному имени субъекта представленному сертификату.

   • Вариант 2. Часть доменного имени полного доменного имени, представленная в заголовке контакта (например, contoso.com имени полного доменного имени sbc1.contoso.com) должна соответствовать значению wild карта в common Name/Subject Alternative Name (например, *.contoso.com).

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

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

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

   Проверьте, зарегистрировано ли полное доменное имя из заголовка контакта (sbc1.contoso.com) в качестве полного доменного имени SBC в любом ресурсе связи Azure. При обнаружении вызов отправляется в этот ресурс. Если не найдено, применяется шаг 4.

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

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

5. Шаг 5 применяется только в том случае, если не удалось выполнить шаги 2, 3 и 4.

   Удалите часть узла из полного доменного имени, представленную в заголовке контакта (FQDN: sbc1.contoso.com, после удаления части узла: contoso.com) и проверка, если это имя зарегистрировано в качестве полного доменного имени SBC в любом ресурсе коммуникации Azure. При обнаружении вызов отправляется в этот ресурс. Если не найдено, вызов завершается ошибкой.

6. Если ресурс связан с развертыванием Dynamics Omnichannel, выполните поиск номера телефона, представленного в URI запроса. Сопоставляйте указанный номер телефона с пользователем Omnichannel (очередью), найденным на предыдущем шаге.

7. Шаг 7 применяется только в том случае, если не удалось выполнить шаги 6.

   Если для ресурса коммуникации нет развертывания Omnichannel, либо номер в URI запроса не соответствует заданному номеру Omnichannel, отправьте вызов в сетку событий.

8. Шаг 8 применяется только в том случае, если не удалось выполнить шаги 7.

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

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

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

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

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

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

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

Это имя (полное доменное имя) также должно находиться в поле общего имени или альтернативного имени субъекта в представленном сертификате. Корпорация Майкрософт поддерживает использование wild карта значений имен в полях общего имени или альтернативного имени субъекта сертификата. Поддержка диких карта описана в разделе RFC 2818, раздел 3.1. В частности:

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

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

URI запроса

Для всех входящих вызовов используется универсальный код ресурса (URI) запроса для идентификации вызываемого пользователя. В настоящее время номер телефона должен содержать знак плюса (+), как показано в следующем примере.

INVITE sip:[email protected] SIP /2.0

Из заголовка

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

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

From: <sip:[email protected];transport=udp;tag=1c68821811

Рекомендации по заголовкам contact и Record-Route

Прокси-сервер SIP должен вычислить полное доменное имя следующего прыжка для новых транзакций клиента в диалоговом окне (например, Bye или Re-Invite), а также при ответе на параметры SIP. Это можно сделать с помощью contact или Record-Route. Согласно RFC 3261, раздел 8.1.1.8, в любом запросе требуется заголовок контакта, который может привести к новому диалогу. Запись-маршрут требуется только в том случае, если прокси-сервер хочет оставаться на пути будущих запросов в диалоговом окне.

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

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

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

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

Использование полного доменного имени в контакте или записи маршрута

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

• Если IP-адрес представлен в маршруте записи или контакте, сертификат проверка завершается ошибкой, и вызов завершается ошибкой.

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

Заголовки контекста вызова

Заголовки контекста вызова в настоящее время доступны только для пакета SDK службы автоматизации вызовов. Пакет SDK службы автоматизации вызовов поддерживает заголовок user-to-User и до пяти настраиваемых заголовков SIP. Эти заголовки поддерживаются в методах INVITE и REFER.

Заголовок user-to-User

Заголовок SIP User-To-User (UUI) является отраслевым стандартом для передачи контекстной информации во время процесса настройки вызова. Максимальная длина ключа заголовка UUI составляет 64 символов. Максимальная длина значения заголовка UUI составляет 256 символов. Значение заголовка UUI может состоять из буквенно-цифровых символов и нескольких выбранных символов, включая =, , %. ~-;.!*_+

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

Службы коммуникации Azure также поддерживает до пяти пользовательских заголовков SIP. Пользовательский ключ заголовка SIP должен начинаться с обязательного X-MS-Custom- префикса. Максимальная длина ключа заголовка SIP составляет 64 символов, включая X-MS-Custom- префикс. Ключ заголовка SIP может состоять из буквенно-цифровых символов и нескольких выбранных символов, включая ., *~!%_+. - Максимальная длина значения заголовка SIP составляет 256 символов. Значение заголовка SIP может состоять из буквенно-цифровых символов и нескольких выбранных символов, включая =, !+. -~;.%*_

Сведения о реализации см. в разделе " Передача контекстных данных между вызовами".

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

Ниже приведены сведения о том, как sip Proxy обрабатывает входящий вызов.

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

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

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

  Примечание.

  В некоторых случаях ответ мультимедиа может не быть создан, а конечная точка может ответить с сообщением "Принять вызов".

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

  Примечание.

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

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

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

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

3. Для каждого сообщения о ходе вызова, полученного от конечных точек, прокси-сервер SIP преобразует сообщение о ходе вызова в сообщение SIP SIP SIP/2.0 180 Ringing. Интервал отправки таких сообщений коррелирует с интервалом получения сообщений от контроллера вызовов. На следующей схеме есть два 180 сообщений, созданных прокси-сервером SIP. Эти сообщения приходят из двух конечных точек пакета SDK. Конечные точки имеют уникальный идентификатор тега. Каждое сообщение, поступающее из другой конечной точки, является отдельным сеансом (параметр "tag" в поле "To" отличается). Но конечная точка может не создавать сообщение 180 и отправлять сообщение 183 сразу, как показано на следующей схеме.

4. Когда конечная точка создает сообщение "Ответ на носитель" с IP-адресами кандидатов мультимедиа конечной точки, прокси-сервер SIP преобразует сообщение, полученное в сообщение "Ход выполнения сеанса SIP 183" с SDP из конечной точки, замененной SDP из обработчика мультимедиа. На следующей схеме конечная точка из Fork 2 ответила на вызов. Сообщение SIP 183 создается только один раз. 183 может прийти на существующую вилку или начать новую.

5. Сообщение о принятии звонков отправляется в прокси-сервер SIP с окончательными кандидатами конечной точки, которая приняла вызов. Сообщение о принятии звонков преобразуется в СООБЩЕНИЕ SIP 200.

   

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

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

2. По уведомлению каждая конечная точка начинает звонить и отправляет сообщение "Ход вызова" в прокси-сервер SIP. Так как одно и то же Службы коммуникации Azure удостоверение может использоваться в нескольких приложениях, прокси-сервер SIP может получать несколько сообщений о ходе вызова.

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

4. Сообщение о принятии звонков отправляется в прокси-сервер SIP с окончательными кандидатами конечной точки, которая приняла вызов. Сообщение о принятии звонков преобразуется в СООБЩЕНИЕ SIP 200.

   

Вариант замены

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

Размер рекомендаций ПО SDP

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

Передача звонков

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

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

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

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

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

Прокси-сервер SIP выбирает метод на основе возможностей, сообщаемых SBC. Если SBC указывает, что он поддерживает метод "Ссылаться", прокси-сервер 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. Запрос на ссылку от клиента отображается как "Вызов передачи в Dave" на следующей схеме. Дополнительные сведения см. в разделе 7.1 RFC 3892.

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

Прокси-сервер SIP в качестве метода передачи вызовов является предпочтительным методом.

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

• Управление вызовами протокола запуска сеанса (SIP) — передача

• Заголовок протокола запуска сеанса (SIP) "Заменяет"

• Механизм протокола запуска сеанса (SIP) "Ссылаемый по"

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

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

Если вызов передается из одной конечной точки пакета SDK в другую конечную точку пакета SDK через SBC, SBC, как ожидается, выдает новое приглашение (запуск нового диалогового окна) для целевого объекта передачи с помощью информации, полученной в сообщении "Ссылка". Чтобы заполнить поля to/Transferor для транзакции запроса внутренне, прокси-сервер SIP должен передать эти сведения внутри заголовков REFER-TO/REFERRED-BY. Прокси-сервер SIP формирует URL-адрес в виде URI SIP, состоящий из полного доменного имени прокси-сервера SIP в имени узла и либо:

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

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

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

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

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

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

• Универсальный код ресурса (URI) запроса request in INVITE from SIP proxy to User C содержит параметр причины .

• Заголовок History-Info заполняется.

• Когда пользователь A является другим пользователем ТСОП, прокси-сервер SIP создает временный ответ "SIP SIP/2.0 181 Call is forwarded" (Вызов SIP SIP/2.0 181).

• Если пользователь A и пользователь C являются пользователями ТСОП, прокси-сервер SIP сохраняет предварительный ответ "SIP SIP/2.0 181 Звонок перенаправляются".

• Заголовок History-Info должен использоваться для предотвращения циклов.

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

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

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

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

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

Заголовок History-Info

Заголовок History-Info используется для перенацеливание запросов SIP и "предоставьте стандартный механизм для записи сведений журнала запросов, чтобы обеспечить широкий спектр служб для сетей и конечных пользователей". Дополнительные сведения см. в разделе RFC 4244 — раздел 1.1. Для прямой маршрутизации этот заголовок используется в сценариях одновременного вызова и переадресации звонков.

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

• Прокси-сервер SIP вставляет параметр, содержащий связанный номер телефона в отдельных записях журнала и сведений, составляющих заголовок History-Info, отправляемый контроллеру ТСОП. Используя только записи, имеющие параметр номера телефона, контроллер ТСОП перестроит новый заголовок History-Info и передает его поставщику магистрали SIP через прокси-сервер SIP.

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

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

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

  Примечание.

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

• Журнал входящих данных сохраняется для предотвращения циклов.

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

<sip:[email protected]?Privacy=history&Reason=SIP%3Bcause%3D486>;index=1.2

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

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

History-Info:
  <sip:[email protected]:5061;user=phone?Reason=SIP%3Bcause%3D302%3Btext%3D%22Moved%20temporarily%22>;index=1,
  <sip:[email protected]: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 SIP;cause=496;text="User Busy"универсального кода ресурса (URI), который получает его ;"и = символы, экранированные в шестнадцатеричные значения %3BASCII, %22и 3Dсоответственно.

Журнал-информация защищена обязательным механизмом TLS.

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

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

Retry-After

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

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

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