Топологии потоков вызовов

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

Предыстория

Основные понятия сети

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

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

Сеть клиента обычно имеет несколько периметров сети с брандмауэрами и /или прокси-серверами, которые применяют политики безопасности вашей организации. Мы рекомендуем выполнить комплексную оценку сети , чтобы обеспечить оптимальную производительность и качество решения для коммуникации.

Сеть служб коммуникации — это сеть, которая поддерживает Службы коммуникации Azure. Корпорация Майкрософт управляет этой сетью и распределяет ее по всему миру с центрами обработки данных Майкрософт, ближайшими к конечным клиентам. Эта сеть отвечает за транспортную ретрансляцию, обработку мультимедиа для групповых вызовов и других компонентов, поддерживающих широкие возможности обмена данными мультимедиа в режиме реального времени.

Типы трафика

Службы коммуникации основаны главным образом на двух типах трафика: мультимедиа в режиме реального времени и сигналов.

Мультимедийные данные в реальном времени передаются с использованием протокола передачи в реальном времени (RTP). Этот протокол поддерживает передачу данных в формате аудио, видео и обмена экранами. Эти данные чувствительны к проблемам с задержкой сети. Хотя можно передавать мультимедийные данные в режиме реального времени с помощью TCP или HTTP, рекомендуется использовать протокол UDP в качестве протокола транспортного уровня для поддержки высокопроизводительного взаимодействия с пользователем. Полезные данные мультимедиа, передаваемые по RTP, защищены с помощью безопасного RTP (SRTP).

Пользователи решения служб коммуникации подключаются к службам с клиентских устройств. Обмен данными между этими устройствами и вашими серверами осуществляется при помощи сигнализации. Например: запуск звонков и чат в режиме реального времени поддерживаются сигналами между устройствами и службой. Большинство сигнального трафика использует HTTPS REST. В некоторых сценариях можно использовать SIP в качестве протокола передачи сигнала. Хотя этот тип трафика менее чувствителен к задержкам, низкая задержка обеспечивает приятный опыт взаимодействия для пользователей вашего решения.

Шифрование мультимедиа

Потоки вызовов в SDK для звонков в Azure Communication Services и клиентах Teams основаны на модели предложений и ответов Session Description Protocol (SDP) RFC 8866 через HTTPS. После того как вызываемый абонент принимает входящий вызов, вызывающий и вызываемый абоненты согласны с параметрами сеанса.

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

Пакет SDK для вызовов Служб коммуникации Azure использует DTLS для получения ключа шифрования. После завершения рукопожатия DTLS, носитель начинает передаваться с помощью ключа шифрования, согласованного в ходе DTLS, через SRTP.

Службы коммуникации Azure, SDK для звонков и клиенты Teams используют токен на основе учетных данных для безопасного доступа к ретрансляторам мультимедиа через TURN. Ретрансляторы мультимедиа обмениваются маркером через защищенный TLS-канал.

Трафик медиа Служб коммуникации Azure между двумя конечными точками, участвующими в аудио, видео и видеотрансляциях Azure, использует SRTP для шифрования медиа потока. Криптографические ключи согласовываются между двумя конечными точками через протокол передачи сигналов, использующий TLS 1.2 и AES-256 (в режиме GCM) зашифрованный UDP/TCP-канал.

Принципы потока вызовов

Существует четыре общих принципа, которые лежат в основе потоков вызовов Служб коммуникации Azure:

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

• Конечная точка мультимедиа, используемая для поддержки вызова служб коммуникации, выбирается в зависимости от потребностей обработки мультимедиа и не влияет на количество участников звонка.

  Например, вызов типа "точка — точка" может использовать конечную точку мультимедиа в облаке для обработки мультимедиа для транскрибирования или записи, а вызов с двумя участниками может не использовать никакие конечные точки мультимедиа. Групповые вызовы используют конечную точку мультимедиа для задач смешивания и маршрутизации.

  Эта конечная точка выбирается в зависимости от региона, в котором размещен вызов. Трафик мультимедиа, отправляемый клиентом в конечную точку мультимедиа, может быть перенаправлен напрямую. Или он может использовать транспортный ретранслятор в Azure, если этого требуют ограничения сетевого брандмауэра клиента.

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

  Предпочтительный маршрут идёт напрямую к удалённому узлу-партнёру (клиенту). Если прямой маршрут недоступен, один или несколько транспортных ретрансляторов перенаправляют трафик. Трафик мультимедиа не должен проходить через серверы, которые действуют как формирователи пакетов, серверы виртуальной частной сети (VPN) или другие функции, которые могут задерживать обработку и ухудшать пользовательский опыт.

• Сигнальный трафик всегда передается на любой сервер, ближайший к пользователю.

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

Потоки вызовов в различных топологиях

Службы коммуникации (Интернет)

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

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

Описания потока:

• Поток 2. Представляет поток, инициированный пользователем в клиентской сети в Интернете в рамках взаимодействия с службами коммуникации пользователя. Примеры таких потоков включают передачу DNS и одноранговую трансляцию мультимедиа.
• Поток 2' — представляет поток, инициированный пользователем удаленных мобильных служб коммуникации, с VPN в клиентскую сеть.
• Поток 3. Представляет поток, инициированный удаленным пользователем служб мобильной связи в конечные точки служб коммуникации.
• Поток 4. Представляет поток, инициированный пользователем в клиентской сети для служб коммуникации.
• Поток 5. Представляет одноранговый поток мультимедиа между одним пользователем Служб коммуникации и другим в клиентской сети.
• Поток 6. Представляет одноранговый поток мультимедиа между удаленным пользователем служб мобильной связи и другим пользователем удаленных мобильных служб коммуникации через Интернет.

Вариант использования: один на один вызов

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

В системе используются сообщения проверки подключения STUN, чтобы определить, какие медиапути инициатора/адресата работают, после чего выбирается наилучший из них. После того как система установит путь подключения, он выполняет подтверждение безопасности транспортного уровня данных (DTLS) для обеспечения безопасности подключения. После рукопожатия DTLS система получает ключи SRTP на основе процесса рукопожатия DTLS. Затем мультимедиа (то есть пакеты RTP/RTCP, защищенные с помощью SRTP) отправляются с помощью выбранной пары кандидатов. Ретранслятор транспорта доступен в составе Служб коммуникации Azure.

Если кандидаты с локальным IP-адресом и портом или кандидаты рефлексивного типа имеют подключение, то для медиа выбирается прямой путь между клиентами (или через использование NAT). Если оба клиента находятся в клиентской сети, следует выбрать прямой путь. Для этого требуется прямое подключение UDP в клиентской сети. Если клиенты являются пользователями кочевого облака, то в зависимости от NAT или брандмауэра носитель может использовать прямое подключение.

Если один клиент является внутренним в сети клиента, а один клиент является внешним (например, мобильным пользователем облака), то маловероятно, что прямое подключение между локальными или рефлекторными кандидатами будет включено. В этом случае можно использовать один из кандидатов ретранслятора транспорта от любого клиента (например, внутренний клиент получил кандидата ретранслятора из ретранслятора транспорта в Azure; внешний клиент должен иметь возможность отправлять пакеты STUN/RTP/RTCP в ретранслятор транспорта). Другой вариант — внутренний клиент отправляет кандидат ретранслятора, полученный мобильным облачным клиентом. Хотя настоятельно рекомендуется использовать UDP-подключение для мультимедиа, поддерживается протокол TCP.

Высокоуровневые шаги:

1. Пользователь служб коммуникации A разрешает доменное имя URL-адреса (DNS) с помощью потока 2.
2. Пользователь A выделяет порт ретрансляции мультимедиа на транспортном ретрансляторе Teams с помощью потока 4.
3. Пользователь служб коммуникации A отправляет "приглашение" с кандидатами ICE с помощью flow 4 в службы коммуникации.
4. Службы коммуникации уведомляют пользователя B с помощью потока 4.
5. Пользователь B выделяет порт ретрансляции мультимедиа на транспортном ретрансляторе Teams, используя поток 4.
6. Пользователь B отправляет "answer" с кандидатами ICE с помощью потока 4, который перенаправлен обратно пользователю A с помощью потока 4.
7. Пользователь A и Пользователь B запускают тесты подключения ICE, и после этого выбирается лучший доступный путь передачи мультимедиа. См. на следующих схемах для различных вариантов использования.
8. Оба пользователя отправляют данные телеметрии в Службы связи, используя Поток 4.

Клиентская сеть (интрасеть)

На шаге 7 выбран одноранговый поток мультимедиа 5.

Эта передача данных двунаправленная. Направление потока 5 указывает, что одна сторона инициирует связь с точки зрения подключения. В этом случае не имеет значения, какое направление используется, так как обе конечные точки находятся в сети клиента.

Сеть клиента к внешнему пользователю (мультимедиа ретранслируются через транспортный ретранслятор Teams)

На шаге 7 выбран поток 4 (от клиентской сети к службам коммуникации) и Поток 3 (от удаленного пользователя мобильных служб коммуникации до служб коммуникации Azure).

В Azure транспортная ретрансляция Microsoft Teams обрабатывает эти потоки.

Эта передача медиа двунаправленная. Направление указывает, какая сторона инициирует связь с точки зрения подключения. В этом случае эти потоки используются для передачи сигналов и мультимедиа, используя различные транспортные протоколы и адреса.

Клиентская сеть к внешнему пользователю (прямое медиа)

На шаге 7 выбран поток 2 (от сетей клиентов к одноранговому узлу клиента через Интернет).

Прямой медиа-поток с удалённым мобильным пользователем (не передаётся через Azure) является необязательным. Другими словами, этот путь можно заблокировать для принудительного направления мультимедиа через транспортный ретранслятор в Azure.

Эта передача медиа двунаправленная. Направление Flow 2 для удаленного мобильного пользователя указывает, что одна сторона инициирует связь с точки зрения связи.

VPN-пользователь к внутреннему пользователю (мультимедиа через реле транспортировки Teams)

Сигнализация между VPN и клиентской сетью использует Flow 2*. Сигнал между сетью клиента и Azure использует Flow 4. Однако мультимедиа обходит VPN и направляется с использованием потоков 3 и 4 через Azure Media Relay.

VPN-пользователь к внутреннему пользователю (прямое медиа)

Сигнализация между VPN и клиентской сетью использует Поток 2'. Сигнал между сетью клиента и Azure использует поток 4. Однако носитель обходит VPN и маршрутизируется с помощью потока 2 из клиентской сети в Интернет.

Эта передача данных двунаправленная. Направление Flow 2 для удаленного мобильного пользователя указывает, что одна сторона инициирует связь с точки зрения подключения.

VPN-пользователь к внешнему пользователю (прямые медиа)

Прямой медиапоток для вызова VPN-пользователя внешним пользователем в формате один на один.

Сигнализация между VPN-пользователем и клиентской сетью осуществляется посредством Flow 2* и Flow 4 в Azure. Однако медиа-трафик обходит VPN и маршрутизируется с помощью потока 6.

Эта передача медиа двунаправленная. Направление потока 6 к удаленному мобильному пользователю указывает, где одна из сторон инициирует связь в контексте подключения.

Вариант использования: клиент служб коммуникации в ТСОП через магистраль служб коммуникации

Службы связи позволяют осуществлять и получать звонки из общедоступной телефонной сети (ТСОП). Если магистраль ТСОП подключена с использованием телефонных номеров, предоставленных Коммуникационными службами, для этого варианта использования отсутствуют специальные требования к подключению. Если вы хотите подключить собственный локальный PSTN транк к Службам связи Azure, вы можете использовать прямую маршрутизацию Azure (доступно в 2021 календарном году).

В этом случае сигнал и носители из клиентской сети в Azure используют Flow 4.

Вариант использования: вызовы групп служб коммуникации

Служба общего доступа к аудио-видео/экранам (VBSS) является частью Служб коммуникации Azure. Он имеет общедоступный IP-адрес, который должен быть доступен из клиентской сети и должен быть доступен из клиента Nomadic Cloud. Каждый клиент или конечная точка должны иметь возможность подключаться к службе.

Внутренние клиенты получают локальные, рефлексивные и ретрансляционные кандидаты таким же образом, как описано для вызовов "один к одному". Клиенты отправляют этих кандидатов в службу в приглашении. Служба не использует ретранслятор, потому что она имеет общедоступный IP-адрес, поэтому она отвечает, предоставляя свой локальный IP-адрес. Клиент и служба проверяют подключение таким же образом, как описано для один-к-одному вызовов.

Ограничения взаимодействия

Мультимедиа, передаваемые через Службы коммуникации Azure, ограничены следующим образом:

Сторонний пограничный контроллер сеанса (SBC) на границе с ТСОП должен завершить поток RTP/RTCP, защищенный с помощью SRTP, а не передавать его в следующий прыжок. Если вы передаете поток в следующий прыжок, это может быть не понятно.

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

Сторонний B2BUA (или SBC). Сторонний SBC завершает мультимедийные потоки служб коммуникации в ОТС и из нее. Взаимодействие со сторонним SBC в сети служб коммуникации (в котором сторонний поставщик SBC медиатирует две конечные точки служб коммуникации) не поддерживается.

Неподдерживаемые технологии

VPN-сеть. Службы коммуникации не поддерживают передачу мультимедиа через виртуальные сети. Если пользователи используют VPN-клиенты, клиент должен разделить и перенаправить трафик мультимедиа через не VPN-подключение, как указано в разделе "Включение мультимедиа Lync для обхода VPN-туннеля".

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

Дальнейшие шаги

Связанные статьи

• Дополнительные сведения о типах вызовов.
• Узнайте об архитектуре клиента-сервера.