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

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

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

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

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

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

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

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

Стандарты RFC

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

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

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

  • ПРОТОКОЛ SIP RFC 3261: протокол инициации сеанса
  • RFC 3325 Частное расширение протокола инициации сеанса для утверждения удостоверения в доверенных сетях — разделы об обработке заголовка P-Asserted-Identity. Прямая маршрутизация отправляет P-Asserted-Identity с заголовками идентификатора конфиденциальности.
  • RFC 4244 Расширение протокола SIP для необходимых сведений журнала. Дополнительные сведения см. в статье Описание протокола SIP маршрутизации.
  • RFC 3892 Механизм Referred-By протокола инициации сеанса
  • RFC 3891 Заголовок "Replaces" для протокола sip (SIP)
  • RFC 6337 Использование модели предложения и ответа по протоколу SIP. См. раздел "Отклонения от RFC".
  • RFC 3711 и RFC 4771. Защита трафика RTP с помощью SRTP. SBC должен иметь возможность устанавливать ключи с помощью SDES.
  • RFC 8035 Уточнение предложений и ответов по протоколу описания сеанса (SDP) для мультиплексирования RTP/RTCP

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

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

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

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

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

RFC и разделы Описание Отклонение
RFC 6337, раздел 5.3 Удержание и возобновление мультимедиа RFC позволяет использовать "a=inactive", "a=sendonly", a=recvonly" для размещения вызова на удержание. Прокси-сервер SIP поддерживает только "a=inactive" и не понимает, отправляет ли SBC "a=sendonly" или "a=recvonly".
RFC 6337, раздел 5.4 Поведение при получении SDP с c=0.0.0.0 RFC3264 требуется, чтобы агент получал SDP с адресом подключения 0.0.0.0.0, что указывает, что не следует отправлять RTP или RTCP в одноранговый узел. Прокси-сервер SIP не поддерживает этот параметр.
RFC 3261, раздел 25 Дополненная BNF для протокола SIP Символ "#" должен быть отправлен как "%23" Прокси-сервер SIP отправляет символ "#" в неэкранированном запросе URI.
RFC 3264, раздел 8.3.1 Модель предложения и ответа с SDP В RFC 3264 подробно описан механизм перенацеливания мультимедиа MAY (необязательно), позволяющий изменять порт мультимедиа, IP-адрес или транспорт после установки сеанса. Необязательная перенацелительная настройка носителя не поддерживается. Во время вызова sip-запросы на обновление порта мультимедиа, IP-адреса или транспорта не поддерживаются. Мультимедиа не будут отправляться в обновленный целевой объект сеанса; носитель из прямой маршрутизации продолжает поступать в исходный целевой объект.

Примечание из RFC, поддерживающее выбор; Оферфер должен быть готов к получению мультимедиа как на старом, так и на новом портах сразу после отправки предложения. Оференду не следует прекращать прослушивание мультимедиа на старом порту, пока не будет получен ответ и носитель не поступит в новый порт.|

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Прокси-сервер SIP отправляет приложение CRLF в соответствии с RFC 5626: управление Client-Initiated Connections в протоколе SIP.

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

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

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

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

Notes

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

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

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

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

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

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

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

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

Трафик SIP всегда проходит через прокси-сервер SIP.

DTMF

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

  • Last updated on