Direct Routing-протокол SIPDirect Routing - SIP protocol

В этой статье описано, как прямая маршрутизация реализует протокол SIP.This article describes how Direct Routing implements the Session Initiation Protocol (SIP). Чтобы правильно маршрутизировать трафик между контроллером границ сеанса (SBC) и прокси SIP, некоторые параметры SIP должны иметь определенные значения.To properly route traffic between a Session Border Controller (SBC) and the SIP proxy, some SIP parameters must have specific values. Эта статья предназначена для администраторов голосовой связи, которые отвечают за настройку соединения между локальным SBC и прокси-службой SIP.This article is intended for voice administrators who are responsible for configuring the connection between the on-premises SBC and the SIP proxy service.

Обработка входящего запроса: Поиск клиента и пользователяProcessing the incoming request: finding the tenant and user

Во входящем звонке прокси-сервер SIP должен найти клиента, которому адресован звонок, и найти определенного пользователя в этом клиенте.On an incoming call, the SIP proxy needs to find the tenant to which the call is destined and find the specific user within this tenant. Администратор клиента может настроить невыполненные номера, например + 1001, в нескольких клиентах.The tenant administrator might configure non-DID numbers, for example +1001, in multiple tenants. Таким образом, важно найти определенного клиента, для которого нужно выполнить поиск по номеру, так как невыполненные номера могут быть одинаковыми в нескольких организациях Microsoft 365 или Office 365.Therefore, it is important to find the specific tenant on which to perform the number lookup because the non-DID numbers might be the same in multiple Microsoft 365 or Office 365 organizations.

В этом разделе показано, как прокси-сервер SIP находит клиент и пользователя, а также выполняет проверку подлинности SBC для входящего подключения.This section describes how the SIP proxy finds the tenant and the user, and performs authentication of the SBC on the incoming connection.

Ниже приведен пример сообщения INVITE протокола SIP на входящем звонке.The following is an example of the SIP Invite message on an incoming call:

Имя параметраParameter name Пример значенияExample of the value
URI запросаRequest-URI ПРИГЛАСИТЬ sip:+18338006777@sip.pstnhub.microsoft.com SIP/2,0INVITE sip:+18338006777@sip.pstnhub.microsoft.com SIP /2.0
С помощью заголовкаVia Header Via: SIP/2.0/TLS sbc1. adatum. раздел: 5058; Alias; Branch = z9hG4bKac2121518978Via: SIP/2.0/TLS sbc1.adatum.biz:5058;alias;branch=z9hG4bKac2121518978
Верхний колонтитул Max-ForwardsMax-Forwards header Макс. Пересылка: 68Max-Forwards:68
От верхнего колонтитулаFrom Header Из заголовка из: <SIP: 7168712781@sbc1. adatum. раздел; Transport = UDP; Tag = 1c747237679From Header From: sip:7168712781@sbc1.adatum.biz;transport=udp;tag=1c747237679</span
В верхний колонтитулTo Header Кому: sip:+183338006777@sbc1.adatum.bizTo: sip:+183338006777@sbc1.adatum.biz
Заголовок CSeqCSeq header CSeq: 1 пригласитьCSeq: 1 INVITE
Заголовок контактаContact Header Контакт: <SIP: 68712781@sbc1. adatum. раздел: 5058; Transport = TLS>Contact: <sip: 68712781@sbc1.adatum.biz:5058;transport=tls>

Получив приглашение, прокси-сервер SIP выполняет следующие действия:On receiving the invite, the SIP proxy performs the following steps:

  1. Проверьте сертификат.Check the certificate. При первоначальном подключении служба прямой маршрутизации получает полное доменное имя, представленное в заголовке контакта, и сопоставляет его с общим именем или альтернативным именем предоставленного сертификата.On the initial connection, the Direct Routing service takes the FQDN name presented in the Contact header and matches it to the Common Name or Subject Alternative name of the presented certificate. Имя SBC должно совпадать с одним из следующих вариантов:The SBC name must match one of the following options:

    • Вариант 1.Option 1. Полное ДОМЕНное имя, представленное в заголовке контакта, должно совпадать со стандартным именем или названием субъекта предоставленного сертификата.The full FQDN name presented in the Contact header must match the Common Name/Subject Alternative name of the presented certificate.

    • Вариант 2.Option 2. Доменное имя FQDN, представленное в заголовке контакта (например, adatum.biz полного доменного имени sbc1.adatum.biz), должно соответствовать подстановочному значению в общем имени или альтернативном имени для темы (например, *. adatum.biz).The domain portion of the FQDN name presented in the Contact header (for example adatum.biz of the FQDN name sbc1.adatum.biz) must match the wildcard value in Common Name/Subject Alternative Name (for example *.adatum.biz).

  2. Попробуйте найти клиента, используя полное ДОМЕНное имя, представленное в заголовке контакта.Try to find a tenant using the full FQDN name presented in the Contact header.

    Убедитесь в том, что полное доменное имя из заголовка контакта (sbc1.adatum.biz) зарегистрировано как DNS-имя в любой организации Microsoft 365 или Office 365.Check if the FQDN name from the Contact header (sbc1.adatum.biz) is registered as a DNS name in any Microsoft 365 or Office 365 organization. Если найден, Поиск пользователя выполняется в клиенте с полным доменным именем SBC, зарегистрированным в качестве доменного имени.If found, the lookup of the user is performed in the tenant that has the SBC FQDN registered as a Domain name. Если не найдено, применяется шаг 3.If not found, Step 3 applies.

  3. Действие 3 применимо только в том случае, если шаг 2 не удался.Step 3 only applies if Step 2 failed.

    Удалите часть узла из полного доменного имени, представленной в заголовке контакта (FQDN: sbc12.adatum.biz, после удаления узла: adatum.biz), и убедитесь, что это имя зарегистрировано как DNS-имя в любой организации Microsoft 365 или Office 365.Remove the host portion from the FQDN, presented in the Contact header (FQDN: sbc12.adatum.biz, after removing the host portion: adatum.biz), and check if this name is registered as a DNS name in any Microsoft 365 or Office 365 organization. Если найден, Поиск пользователя выполняется в этом клиенте.If found, the user lookup is performed in this tenant. Если он не найден, вызов завершается сбоем.If not found, the call fails.

  4. Используя номер телефона, представленный в URI запроса, выполните обратный просмотр номера в клиенте, найденном на этапе 2 или 3.Using the phone number presented in the Request-URI, perform the reverse number lookup within the tenant found in Step 2 or 3. Сопоставить предоставленный телефонный номер URI-адресу SIP пользователя в клиенте, найденном на предыдущем этапе.Match the presented phone number to a user SIP URI within the tenant found on the previous step.

  5. Примените параметры магистрали.Apply trunk settings. Найдите параметры, заданные администратором клиента для этого SBC.Find the parameters set by the tenant admin for this SBC.

    Корпорация Майкрософт не поддерживает для прокси-сервера SIP или сервер агента пользователя, не поддерживающие прокси-серверы, а также один и тот же объект, который может изменить URI запроса, созданный с помощью парного SBC.Microsoft does not support having a third-party SIP proxy or User Agent Server between the Microsoft SIP proxy and the paired SBC, which might modify the Request URI created by the paired SBC.

    Требования для двух подстановок (шаги 2 и 3), необходимые для сценария, где один SBC связан с многочисленными клиентами (сценарий с несущей), рассматриваются ниже в этой статье.The requirements for the two lookups (steps 2 and 3) needed for the scenario where one SBC is interconnected to many tenants (carrier scenario) are covered later in this article.

Подробные требования для заголовка и запроса URI для контактаDetailed requirements for Contact header and Request-URI

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

Для всех входящих звонков на прокси-сервер Microsoft SIP в заголовке контакта должно быть указано полное доменное имя одноименного SBC в имени узла URI.For all incoming calls to the Microsoft SIP proxy, the Contact header must have the paired SBC FQDN in the URI hostname as follows:

Синтаксис: Contact: <SIP: Phone или SIP address@FQDN SBC; Transport = TLS>Syntax: Contact: <sip:phone or sip address@FQDN of the SBC;transport=tls>

Это имя должно быть также представлено в поле "замещающий имя" или "в списке субъектов" для предоставленного сертификата.This name must also be in the Common Name or Subject Alternative name field(s) of the presented certificate. Корпорация Майкрософт поддерживает использование подстановочных знаков в полях "Общее имя" или "дополнительное имя субъекта" сертификата.Microsoft supports using wildcard values of the name(s) in the Common Name or Subject Alternative Name fields of the certificate.

Поддержка подстановочных знаков описана в документе RFC 2818, который можно получить в разделе 3,1.The support for wildcards is described in RFC 2818, section 3.1. ПредназначеныSpecifically:

Имя может содержать подстановочный знак * , который рассматривается как один компонент доменного имени или фрагмент компонента. Например, * . a.com соответствует foo.a.com, но не Bar.foo.a.com. f * . com соответствует foo.com, а не Bar.com "."Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com."

Если несколько значений в заголовке контакта, представленном в сообщении SIP, отправляется с помощью SBC, используется только часть полного имени из первого значения заголовка Contact.If more than one value in the Contact header presented in a SIP message is sent by the SBC, only the FQDN portion of the first value of the Contact header is used.

URI запросаRequest-URI

Для всех входящих вызовов URI запроса — используется для сопоставления номера телефона с пользователем.For all incoming calls, the Request-URI is used to match the phone number to a user.

В настоящее время номер телефона должен содержать знак "плюс" (+), как показано в следующем примере.Currently The phone number must contain a plus sign (+) as shown in the following example.

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

Контакты и записи: рекомендации для заголовков маршрутовContact and Record-Route headers considerations

Прокси-серверу SIP требуется вычислить полное доменное имя следующего прыжка для новых клиентских транзакций в диалоговом окне (например, пока или повторное приглашение), а также при ответе на параметры SIP.The SIP proxy needs to calculate the next hop FQDN for new in-dialog client transactions (for example Bye or Re-Invite), and when replying to SIP Options. Используется либо контакт, либо маршрут записи.Either Contact or Record-Route are used.

Согласно стандарту RFC 3261, в любом запросе, который может привести к новому диалоговому окну, требуется заголовок Contact.According to RFC 3261, Contact header is required in any request that can result in a new dialog. Маршрут записи требуется только в том случае, если прокси-сервер хочет сохранить путь для будущих запросов в диалоговом окне.The Record-Route is only required if a proxy wants to stay on the path of future requests in a dialog. Если используется межпрокси-объект SBC с оптимизацией локальных файлов для прямой маршрутизации, необходимо настроить маршрут записи, так как прокси-сервер SBC должен оставаться на маршруте.If a proxy SBC is in use with Local Media Optimization for Direct Routing, a record route will need to be configured as the proxy SBC needs to stay in the route.

Корпорация Майкрософт рекомендует использовать заголовок контакта только в том случае, если не используется объект SBC для прокси-сервера:Microsoft recommends using only Contact header if a proxy SBC is not used:

  • В соответствии с RFC 3261, маршрут записи используется, если прокси-сервер хочет сохранить путь для будущих запросов в диалоговом окне, что не является обязательным, если не настроен ни один прокси-сервер, так как весь трафик проходит между прокси-сервером SIP и парным однобайтовым массивом Microsoft.Per RFC 3261, Record-Route is used if a proxy wants to stay on the path of future requests in a dialog, which is not essential if no proxy SBC is configured as all traffic goes between the Microsoft SIP proxy and the paired SBC.

  • Прокси-сервер Microsoft SIP использует только заголовок контакта (но не маршрут записи) для определения следующего прыжка при отправке исходящих параметров ping.The Microsoft SIP proxy uses only Contact header (not Record-Route) to determine the next hop when sending outbound ping Options. Настройка только одного параметра (контакта) вместо двух (контактных данных и маршрутов) упрощает администрирование, если не используется одноименной SBC-объект.Configuring only one parameter (Contact) instead of two (Contact and Record-Route) simplifies the administration if a proxy SBC is not in use.

Для вычисления следующего прыжка прокси-сервер SIP использует:To calculate the next hop, the SIP proxy uses:

  • Приоритет 1.Priority 1. Маршрут записи верхнего уровня.Top-level Record-Route. Если маршрут записи верхнего уровня содержит полное доменное имя или IP-адрес, используется полное доменное имя или IP-адрес, чтобы сделать исходящее подключение в диалоговом окне.If the top-level Record-Route contains the FQDN name or IP, the FQDN name or IP is used to make the outbound in-dialog connection.

  • Приоритет 2.Priority 2. Заголовок контакта.Contact header. Если маршрут записи не существует, прокси-сервер SIP выполнит поиск значения заголовка Contact, чтобы сделать исходящее подключение.If Record-Route does not exist, the SIP proxy will look up the value of the Contact header to make the outbound connection. (Это рекомендуемая конфигурация.)(This is the recommended configuration.)

Если используются как контакт, так и маршрут записи, администратор SBC должен сохранить значения одинаково, что приводит к дополнительным затратам на администрирование.If both Contact and Record-Route are used, the SBC administrator must keep their values identical, which causes administrative overhead.

Использование полного доменного имени в контакте или записи в маршрутеUse of FQDN name in Contact or Record-Route

Использование IP-адреса не поддерживается ни в одной записи, ни на маршруте, ни в контакте.Use of an IP address is not supported in either Record-Route or Contact. Единственным поддерживаемым вариантом является полное доменное имя, которое должно совпадать либо с общим именем, либо с другим именем темы сертификата SBC (значения подстановочных знаков в сертификате поддерживаются).The only supported option is an FQDN, which must match either the Common Name or Subject Alternative Name of the SBC certificate (wildcard values in the certificate are supported).

  • Если IP-адрес указан в разделе запись (маршрут или контакт), проверка сертификата завершается сбоем, и вызов завершается сбоем.If an IP address is presented in Record-route or Contact, the certificate check fails and the call fails.

  • Если полное доменное имя не совпадает со значением общего или альтернативного имени субъекта в представленном сертификате, вызов завершается сбоем.If the FQDN does not match the value of the Common or Subject Alternative Name in the presented certificate, the call fails.

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

В таблице ниже приведено краткое описание различий в потоке звонков и других параметров, не являющихся режимами обхода:The following table below summarizes the call flow differences and similarities between non-bypass and bypass modes:

Имя параметраParameter name Режим без обходаNon-bypass mode Режим пропускаBypass mode
Потенциальные мультимедийные сообщения в 183 и 200, поступающие изMedia candidates in 183 and 200 messages coming from Процессоры мультимедиаMedia processors КлиентыClients
Количество сообщений 183, которые может принимать SBCNumber of 183 messages SBC can receive По одному на сеансOne per session СерверMultiple
Ответ на звонок можно получить с помощью предварительной подконтрольной подготовки (183)Call can be with provisional answer (183) ДаYes ДаYes
Звонок может быть недоступен для предварительного ответа (183)Call can be without provisional answer (183) ДаYes ДаYes

Поток обхода файлов без мультимедиаNon-media bypass flow

У пользователя Teams может быть несколько конечных точек одновременно.A Teams user might have multiple endpoints at the same time. Например, Teams для клиента Windows, Teams для iPhone и Team Phone (клиентская группа Android).For example, Teams for Windows client, Teams for iPhone client, and Teams Phone (Teams Android client). Каждая конечная точка может сообщить о себе HTTP-части следующим образом:Each endpoint might signal an HTTP rest as follows:

  • Ход вызова, преобразованный прокси SIP в сообщение SIP 180.Call progress – converted by the SIP proxy to the SIP message 180. При получении сообщения 180, SBC должен создать локальный звонок.On receiving message 180, the SBC must generate local ringing.

  • Ответ на мультимедиа, преобразованный прокси SIP на сообщение 183 с кандидатами мультимедиа в протоколе описания сеансов (SDP).Media answer – converted by the SIP proxy to message 183 with media candidates in Session Description Protocol (SDP). При получении сообщения 183 в коде SBC ожидается соединение с кандидатами мультимедиа, полученными в сообщении SDP.On receiving message 183, the SBC expects to connect to the media candidates received in the SDP message. Обратите внимание, что в некоторых случаях ответ на мультимедиа может не генерироваться, и конечная точка может ответить на сообщение "звонок принят".Note that in some cases the Media answer might not be generated, and the end point might answer with “Call Accepted” message.

  • Звонки принимаются через прокси-сервер SIP в сообщение SIP 200 с помощью SDP.Call accepted – converted by the SIP proxy to SIP message 200 with SDP. При получении сообщения 200 ожидается, что SBC будет отправлять и получать носители от предоставленных кандидатов SDP.On receiving message 200, the SBC is expected to send and receive media to and from the provided SDP candidates.

Несколько конечных точек с ответом на предварительный ЗвонокMultiple endpoints ringing with provisional answer

  1. При получении первого приглашения из SBC прокси-сервер SIP отправляет сообщение "SIP SIP/2.0 100 пытается" и оповещает все конечные точки конечных пользователей о входящем звонке.On receiving the first Invite from the SBC, the SIP proxy sends the message "SIP SIP/2.0 100 Trying" and notifies all end user endpoints about the incoming call.

  2. После уведомления каждая конечная точка начнет звонить и отправлять сообщения "ход выполнения звонка" на прокси-сервер SIP.Upon notification, each endpoint will start ringing and sending "Call progress” messages to the SIP proxy. Так как пользователь Teams может иметь несколько конечных точек, прокси-сервер SIP может получать сообщения о ходе выполнения звонка.Because a Teams user can have multiple end points, the SIP proxy might receive multiple Call Progress messages.

  3. Для каждого сообщения о ходе выполнения звонка, полученного от клиентов, прокси-сервер SIP преобразует сообщение о ходе выполнения звонка в сообщение SIP "SIP SIP/2.0 180 пытается".For every Call Progress message received from the clients, the SIP proxy converts the Call Progress message to the SIP message "SIP SIP/2.0 180 Trying". Интервал отправки таких сообщений определяется интервалом приема сообщений от контроллера звонков.The interval for sending such messages is defined by the interval of the receiving messages from the Call Controller. На приведенной ниже схеме есть сообщения 2 180, созданные прокси-сервером SIP.In the following diagram, there are two 180 messages generated by the SIP proxy. Эти сообщения поступают из двух конечных точек пользователя Teams.These messages come from the two Teams endpoints of the user. У каждого клиента есть уникальный идентификатор тега.The clients each have a unique Tag ID. Каждое сообщение, поступающие из другой конечной точки, будет отдельным сеансом (параметр "тег" в поле "Кому" будет отличаться).Every message coming from a different endpoint will be a separate session (the parameter “tag” in the “To” field will be different). Но конечная точка может не создать сообщение 180 и отправить сообщение 183 прямо дальше, как показано на следующей схеме.But an endpoint might not generate message 180 and send message 183 right away as shown in the following diagram.

  4. После того как конечная точка создаст сообщение ответа на мультимедиа с IP-адресом кандидатов конечной точки, прокси-сервер SIP преобразует сообщение, полученное в сообщении о ходе сеанса SIP 183, с помощью SDP, заменяя SDP из обработчика мультимедиа.Once an endpoint generates a Media Answer message with the IP addresses of endpoint’s media candidates, the SIP proxy converts the message received to a "SIP 183 Session Progress" message with the SDP from the client replaced by the SDP from the Media Processor. На приведенной ниже схеме конечная точка из вилки 2 ответила на звонок.In the following diagram, the endpoint from Fork 2 answered the call. Если магистраль не пропускается, сообщение SIP 183 генерируется только один раз (Bot или конечная точка клиента).If the trunk is non-bypassed, the 183 SIP message is generated only once (either Ring Bot or Client End Point). 183 может находиться на существующей вилке или начать новую.The 183 might come on an existing fork or start a new one.

  5. Сообщение о принятии вызова отправляется с конечными кандидатами конечной точки, принимающей звонок.A Call Acceptance message is sent with the final candidates of the endpoint that accepted the call. Сообщение о принятии звонка будет преобразовано в сообщение SIP 200.The Call Acceptance message is converted to SIP message 200.

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

Несколько конечных точек звонить без предварительного ответаMultiple endpoints ringing without provisional answer

  1. При получении первого приглашения из SBC прокси-сервер SIP отправляет сообщение "SIP SIP/2.0 100 пытается" и оповещает все конечные точки конечных пользователей о входящем звонке.On receiving the first Invite from the SBC, the SIP proxy sends the message "SIP SIP/2.0 100 Trying" and notifies all end user endpoints about the incoming call.

  2. После уведомления каждая конечная точка начнет звонить и отправлять сообщение "ход звонка" на прокси-сервер SIP.Upon notification, each endpoint will start ringing and sending the message "Call progress” to the SIP proxy. Так как пользователь Teams может иметь несколько конечных точек, прокси-сервер SIP может получать сообщения о ходе выполнения звонка.Because a Teams user can have multiple end points, the SIP proxy might receive multiple Call Progress messages.

  3. Для каждого сообщения о ходе выполнения звонка, полученного от клиентов, прокси-сервер SIP преобразует сообщение о ходе выполнения звонка в сообщение SIP "SIP SIP/2.0 180 пытается".For every Call Progress message received from the clients, the SIP proxy converts the Call Progress message to the SIP message "SIP SIP/2.0 180 Trying". Интервал отправки сообщений определяется интервалом получения сообщений от контроллера звонков.The interval for sending the messages is defined by the interval of receiving the messages from the Call Controller. На рисунке ниже есть сообщения 2 180, созданные прокси SIP, то есть пользователь вошел в три клиента Teams и каждый клиент отправляет ход вызова.On the picture below there are two 180 messages generated by the SIP proxy, meaning that user logged into three Teams clients and each client send the call progress. Каждое сообщение будет отдельным сеансом (тег "" to ") в поле" Кому "(другое)Every message will be a separate session (parameter “tag” in “To” field is different)

  4. Сообщение о принятии вызова отправляется с конечными кандидатами конечной точки, принимающей звонок.A Call Acceptance message is sent with the final candidates of the endpoint that accepted the call. Сообщение о принятии звонка будет преобразовано в сообщение SIP 200.The Call Acceptance message is converted to SIP message 200.

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

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

Такие же сообщения (100 пытается, 180, 183) используются в сценарии обхода мультимедиа.The same messages (100 Trying, 180, 183) are used in the media bypass scenario.

В приведенной ниже схеме показан пример пропуска потока вызова.The schema below shows an example of the bypass call flow. Обратите внимание, что кандидаты мультимедиа могут поступать из разных конечных точек.Note that the media candidates can come from different endpoints.

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

Параметр "замена"Replaces option

SBC должен поддерживать приглашение с замещением.The SBC must support Invite with Replaces.

Сведения о размере SDPSize of SDP considerations

Интерфейс Direct Routing может отправлять сообщение SIP, превышающее 1 500 байт.The Direct Routing interface might send a SIP message exceeding 1,500 bytes. Размер SDP в основном вызывает это.The size of SDP primarily causes this. Тем не менее, если в SBC есть магистральная линия UDP, она может отклонить сообщение, если оно переадресовано с прокси-сервера SIP Microsoft на магистраль в неизменном виде.However, if there is a UDP trunk behind the SBC, it might reject the message if it is forwarded from the Microsoft SIP proxy to the trunk unmodified. Корпорация Майкрософт рекомендует при отправке сообщения в магистральные UDP-магистрали отменять некоторые значения в SDP на SBC.Microsoft recommends stripping some values in SDP on the SBC when sending the message to the UDP trunks. Например, можно удалить кандидатов на ICE или неиспользуемые кодеки.For example, the ICE candidates or unused codecs can be removed.

Передача вызоваCall transfer

Прямая маршрутизация поддерживает два способа передачи звонков.Direct Routing supports two methods for call transfer:

  • Вариант 1.Option 1. Прокси-серверы SIP ссылаются с клиента на локальный и действуют как REFEREE, как описано в разделе 7,1 из RFC 3892.SIP proxy processes Refer from the client locally and acts as a Referee as described in section 7.1 of RFC 3892.

    С помощью этого параметра прокси-сервер SIP завершает передачу и добавляет новое приглашение.With this option, the SIP proxy terminates the transfer and adds a new Invite.

  • Вариант 2.Option 2. Прокси-сервер SIP отправляет ссылку на SBC и действует в качестве средства пересылки, как описано в разделе 6 документа RFC 5589.SIP proxy sends the Refer to the SBC and acts as a Transferor as describing in Section 6 of RFC 5589.

    С помощью этого параметра прокси-сервер SIP отправляет ссылку на SBC и ожидает, что объект SBC полностью обрабатывает передачу.With this option, the SIP proxy sends a Refer to the SBC and expects the SBC to handle the Transfer fully.

Прокси-сервер SIP выбирает метод на основе возможностей, предоставленных SBC.The SIP proxy selects the method based on the capabilities reported by the SBC. Если SBC указывает на то, что он поддерживает метод "ссылка", прокси-сервер SIP будет использовать вариант 2 для передачи звонков.If the SBC indicates that it supports the method “Refer”, the SIP proxy will use Option 2 for call transfers.

Ниже приведен пример SBC, отправляющего сообщение о том, что метод ссылки поддерживается.The following is an example of an SBC sending the message that the Refer method is supported:

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

Если SBC не показывает, что он поддерживает поддерживаемый метод, прямая маршрутизация будет использовать вариант 1 (прокси-сервер SIP выступает в качестве REFEREE).If the SBC doesn’t indicate that Refer as a supported method, Direct Routing will use Option 1 (SIP proxy acts as a Referee) . SBC также должен сообщить, что он поддерживает метод notify:The SBC must also signal that it supports the Notify method:

Пример SBC, указывающий на то, что метод ссылки не поддерживается:Example of SBC indicating that Refer method is not supported:

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

Прокси-серверы SIP ссылаются с клиента на локальный и функционируют как REFEREESIP proxy processes Refer from the client locally and acts as a Referee

Если в SBC указано, что метод ссылки не поддерживается, прокси-сервер SIP действует как REFEREE.If the SBC indicated that the Refer method is not supported, the SIP proxy acts as a Referee.

Запрос ссылки, поступающий из клиента, будет прекращен на прокси-сервере SIP.The Refer request that comes from the client will be terminated on the SIP proxy. (Запрос на получение ссылки от клиента показан в виде "позвонить на Дэйв" на следующей схеме.(The Refer request from the client is shown as “Call transfer to Dave” in the following diagram. Дополнительные сведения можно найти в разделе 7,1 из RFC 3892.For more information, see section 7.1 of RFC 3892.

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

Прокси-сервер SIP отправляет ссылку на SBC и действует как переправитель.SIP proxy send the Refer to the SBC and acts as a Transferor

Этот способ является предпочтительным для передачи звонков и является обязательным для устройств, исключающих сертификацию мультимедиа.This is the preferred method for call transfers, and it is mandatory for devices seeking media bypass certification. Передача вызова без SBC, которая может обрабатывать ссылку, не поддерживается в режиме обхода мультимедиа.Call Transfer without the SBC being able to handle Refer is not supported in media bypass mode.

Эти стандарты описаны в разделе 6 документа RFC 5589.The standard is explained in Section 6 of RFC 5589. Ниже приведены соответствующие документы RFC.The related RFCs are:

Этот параметр предполагает, что прокси-сервер SIP выступает в качестве перенаправляющего и отправляет сообщение о ссылке на SBC.This option assumes that the SIP proxy acts as a Transferor and sends a Refer message to the SBC. SBC действует как получатель и обрабатывает ссылку для создания нового предложения для передачи.The SBC acts as a Transferee and handles the Refer to generate a new offer for transfer. Возможны два варианта:There are two possible cases:

  • Звонок будет передан внешнему абоненту PSTN.The call is transferred to an external PSTN participant.
  • Вызов передается от одного пользователя Teams другому пользователю Teams в том же клиенте через SBC.The call is transferred from one Teams user to another Teams user in the same tenant via the SBC.

Если звонок передается из одного пользователя группы на другой через SBC, предполагается, что SBC выдаст новое приглашение (начать новое диалоговое окно) для целевого объекта передачи (пользователя Teams) с использованием сведений, полученных в сообщении об ошибке.If the call is transferred from one Teams user to another via the SBC, the SBC is expected to issue a new invite (start a new dialog) for the transfer target (the Teams user) using the information received in the Refer message.

Для внутреннего заполнения полей "Кому" и "Пересылка" для транзакции запроса прокси-сервер SIP должен передать эти данные внутри заголовков "ссылка на/ссылка".To populate the To/Transferor fields for the transaction of the request internally, the SIP proxy needs to convey this information inside the REFER-TO/REFERRED-BY headers.

Прокси-сервер SIP будет ссылаться на ссылку в качестве URI SIP, состоящего из полного доменного имени прокси-сервера SIP, и одного из указанных ниже вариантов.The SIP proxy will form the REFER-TO as a SIP URI comprised of a SIP proxy FQDN in the hostname and either one of the following:

  • Номер телефона E. 164 в части имени пользователя URI в случае, если цель передачи — номер телефона, илиAn E.164 phone number in the username part of the URI in case the transfer target is a phone number, or

  • параметры x-m и x-t заключают полную пересылку MRI и идентификатор клиента соответственно.x-m and x-t parameters encoding the full transfer target MRI and tenant ID respectively

УПОМЯНУТый заголовок — это URI SIP с MRI, который закодирован в нем, а также ИДЕНТИФИКАТОРом клиента пересылки и другими параметрами контекста передачи, как показано в следующей таблице:The REFERRED-BY header is a SIP URI with transferor MRI encoded in it as well as transferor tenant ID and other transfer context parameters as shown in the following table:

ПараметрParameter ЗначениеValue ОписаниеDescription
x-mx-m MRIMRI Полный MRI объекта пересылки/передачи, заполненный CCFull MRI of transferor/transfer target as populated by CC
x-tx-t Идентификатор клиентаTenant ID Идентификатор клиента x-t — необязательный идентификатор клиента, заполненный CCx-t Tenant ID Optional Tenant Id as populated by CC
x-Tix-ti Идентификатор корреляции для пересылкиTransferor Correlation Id Идентификатор корреляции вызова для пересылкиCorrelation Id of the call to the transferor
x-TTx-tt Универсальный код ресурса (URI) для целевого вызова передачиTransfer target call URI URI замены закодированного вызоваEncoded call replacement URI

В этом случае размер заголовка ссылки может доставлять до 400 символов.The size of the Refer Header can be up to 400 symbols in this case. SBC должен поддерживать обработку сообщений с размером до 400 символов.The SBC must support handling Refer messages with size up to 400 symbols.

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

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

Прокси-сервер SIP поддерживает (всегда предлагает) таймер сеанса для вызовов, не исключаясь, но не предлагает его в обходных вызовов.The SIP proxy supports (always offers) the Session Timer on non-bypass calls but does not offer it on bypass calls. Использование таймера сеанса с помощью SBC не является обязательным.Use of the Session Timer by the SBC is not mandatory.

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

Прокси-сервер SIP проанализирует URI запроса и, если параметр User = Phone, служба будет обрабатывать запрос URI как номер телефона, который соответствует номеру пользователя.The SIP proxy analyses the Request-URI and if the parameter user=phone is present, the service will handle the Request-URI as a phone number, matching the number to a user. Если параметр не указан, прокси-сервер SIP применяет эвристику для определения типа пользователя Request-URI (номер телефона или адрес SIP).If parameter is not present the SIP proxy applies heuristics to determine the Request-URI user type (phone number or a SIP address).

Microsof рекомендует всегда применять параметр User = Phone для упрощения процесса настройки звонка.Microsof recommends always applying the user=phone parameter to simplify the call setup process.

История — заголовок infoHistory-Info header

Заголовок History-info используется для перенаправления запросов SIP и "предоставить (s) Стандартный механизм для захвата данных журнала запросов, чтобы включить широкий спектр служб для сетей и конечных пользователей".The History-Info header is used for retargeting SIP requests and “provide(s) a standard mechanism for capturing the request history information to enable a wide variety of services for networks and end-users.” Дополнительные сведения можно найти в статье RFC 4244 – раздел 1,1.For more information, see RFC 4244 – Section 1.1. Для телефонной системы Microsoft этот заголовок используется в сценариях Simulring и переадресации звонков.For Microsoft Phone System, this header is used in Simulring and Call Forwarding scenarios.

При отправке данные о журнале будут включены следующим образом:If sending, the History-Info is enabled as follows:

  • Прокси-сервер SIP вставит параметр, содержащий связанный номер телефона, в отдельные записи журнала — сведения, которые составляют заголовок History – info, отправленный контроллеру КТСОП.The SIP proxy will insert a parameter containing the associated phone number in individual History-Info entries that comprise the History-Info header sent to the PSTN Controller. Используя только записи с параметром "телефонный номер", контроллер PSTN перестраивает новый заголовок History-info и передает его в поставщик магистральной службы SIP через прокси-сервер SIP.Using only entries that have the phone number parameter, the PSTN Controller will rebuild a new History-Info header, and pass it on to the SIP trunk provider via SIP proxy.

  • В заголовке история — данные будут добавлены для одновременных звонков и переадресации звонков.History-Info header will be added for simultaneous ring and call forwarding cases.

  • Закрывающий заголовок "История — данные" не будет добавлен для вариантов передачи звонков.History-Info header will not be added for call transfer cases.

  • Отдельная запись журнала в заголовке реконструированный заголовок info содержит параметр номера телефона в сочетании с полным доменным именем маршрутизации (sip.pstnhub.microsoft.com), установленным в качестве хост-части универсального кода ресурса (URI). параметр "User = Phone" будет добавлен как часть URI SIP.An individual history entry in the reconstructed History-Info header will have the phone number parameter provided combined with the Direct Routing FQDN (sip.pstnhub.microsoft.com) set as the host part of the URI; a parameter of ‘user=phone’ will be added as part of the SIP URI. Любые другие параметры, связанные с исходным заголовком History — info (за исключением параметров контекста телефона), будут переданы в повторно созданном заголовке журнала — info.Any other parameters associated with the original History-Info header, except for phone context parameters, will be passed through in the re-constructed History-Info header. Обратите внимание на то, что закрытые записи (в соответствии с механизмами, определенными в разделе 3,3 из RFC 4244) будут переадресованы как есть, так как поставщик магистральной магистрали SIP является надежным одноранговым элементом.Note that entries that are private (as determined by the mechanisms defined in Section 3.3 of RFC 4244) will be forwarded as is because the SIP trunk provider is a trusted peer.

  • Журнал входящих сообщений — данные игнорируются.Inbound History-Info is ignored.

Ниже приведен формат заголовка History-info, отправляемого прокси SIP:Following is the format of the History-info header sent by the SIP proxy:

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

Если звонок был перенаправлен несколько раз, сведения о каждом перенаправлении будут включены по соответствующей причине в хронологическом порядке.If the call was redirected several times, information about every redirect is included with the appropriate reason in chronological order.

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

History-info: 
<sip:+14257123456@sip.pstnhub.microsoft.com;user=phone?Reason=SIP;cause=302;text=”Move Temporarily”>;index=1
<sip:+14257123457@sip.pstnhub.microsoft.com;user=phone?Reason=SIP;cause=496;text=”User Busy”>;index=1.1

История — данные защищены обязательным механизмом TLS.The History-Info is protected by a mandatory TLS mechanism.

Соединение между собой SBC и механизмом перемещения по прямой маршрутизацииSBC connection to Direct Routing and failover mechanism

Ознакомьтесь с разделом отказоустойчивый механизм сигнализации SIP в разделе планирование прямой маршрутизации.See the section Failover mechanism for SIP signaling in Plan for Direct Routing.

Повтор — послеRetry-After

Если центр обработки данных, на который осуществляется прямая маршрутизация, занят, служба может отправить односекундное сообщение с помощью одинарного интервала в SBC.If a Direct Routing datacenter is busy, the service can send a Retry-After message with a one-second interval to the SBC. Когда SBC получает сообщение 503 с заголовком Retry-After в ответе на приглашение, этот объект должен завершить это подключение и попробовать следующий доступный центр обработки данных Майкрософт.When the SBC receives a 503 message with a Retry-After header in response to an INVITE, the SBC must terminate that connection and try the next available Microsoft datacenter.

Перезагрузка ICE: вызов обхода мультимедиа, передаваемый в конечную точку, не поддерживающую обход мультимедиаICE Restart: Media bypass call transferred to an endpoint that does not support media bypass

SBC должен поддерживать перезапуски ICE, как описано в RFC 5245, раздел 9.1.1.1.The SBC must support ICE restarts as described in RFC 5245, section 9.1.1.1.

Перезагрузка в прямом маршруте реализована в соответствии со следующими абзацами RFC:The restart in Direct Routing is implemented according to the following paragraphs of the RFC:

Чтобы перезапустить ICE, агент должен изменить оба типа ICE-PWD и Ice-ufrag для потока мультимедиа в предложении. Обратите внимание, что в одном предложении можно использовать атрибут уровня сеанса, но для того, чтобы предоставить один и тот же объект Ice-PWD или Ice-ufrag как атрибут уровня мультимедиа в последующих предложениях. Это не является изменением пароля, изменением его представления и не приводит к перезапуску ICE.To restart ICE, an agent MUST change both the ice-pwd and the ice-ufrag for the media stream in an offer. Note that it is permissible to use a session-level attribute in one offer, but to provide the same ice-pwd or ice-ufrag as a media-level attribute in a subsequent offer. This is not a change in password, just a change in its representation, and does not cause an ICE restart.

Агент задает остальные поля в SDP для этого потока мультимедиа так же, как и в первоначальном предложении этого потока мультимедиа (см. раздел 4,3). Следовательно, набор кандидатов может включать в себя не более одного или всех предыдущих кандидатов для этого потока и может включать совершенно новый набор кандидатов, собранных в соответствии с описанием, описанным в разделе 4.1.1.An agent sets the rest of the fields in the SDP for this media stream as it would in an initial offer of this media stream (see Section 4.3). Consequently, the set of candidates MAY include some, none, or all of the previous candidates for that stream and MAY include a totally new set of candidates gathered as described in Section 4.1.1.

Если звонок первоначально был установлен с пропуском мультимедиа и этот звонок передается клиенту Skype для бизнеса, прямая маршрутизация должна вставить процессор мультимедиа – это связано с тем, что прямая маршрутизация не может использоваться для клиента Skype для бизнеса с пропуском мультимедиа.If the call was initially established with media bypass, and the call is transferred to a Skype for Business client, Direct Routing needs to insert a Media Processor--this is because Direct Routing cannot be used with a Skype for Business client with media bypass. Прямая маршрутизация запускает процедуру перезапуска ICE, изменяя Ice и ufrag и предлагая новые кандидаты мультимедиа в повторном приглашении.Direct Routing starts the ICE restart process by changing the ice-pwd and ice-ufrag and offering new media candidates in a reinvite.