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

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

Общие сведения

Основные понятия сети в Службе Azure Kubernetes (AKS)

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

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

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

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

Типы трафика

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

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

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

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

Потоки звонков в Службы коммуникации Azure вызовы пакета SDK и клиентов Teams основаны на предложении RFC 8866 RFC 8866 по протоколу HTTPS. После того как вызывающий объект принимает входящий вызов, вызывающий и вызывающий абонент согласны с параметрами сеанса.

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

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

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

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

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

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

• Первый участник группового вызова Службы коммуникации определяет регион, в котором будет размещен вызов. В некоторых топологиях, описанных ниже, существуют исключения из этого правила.
• Конечная точка мультимедиа, используемая для поддержки вызова служб коммуникации, выбирается в зависимости от потребностей обработки мультимедиа и не влияет на количество участников звонка. Например, вызов типа "точка — точка" может использовать конечную точку данных в облаке, чтобы обрабатывать данные для записи или транскрибирования, в то время как при вызове с двумя участниками конечные точки данных могут не использоваться. Групповые вызовы используют конечную точку мультимедиа для смешивания и маршрутизации. Эта конечная точка выбирается в зависимости от региона, в котором размещается вызов. Трафик данных, отправленный с клиента на конечную точку данных, может маршрутизироваться напрямую или использовать транспортный ретранслятор в Azure, если это предусмотрено клиентскими ограничениями сетевого брандмауэра.
• Трафик данных для одноранговых звонков принимает самую прямую доступную маршрутизацию, предполагая, что для вызова не требуется конечная точка данных в облаке. Предпочтительным будет маршрут непосредственно к удаленному одноранговому узлу (клиенту). Если прямой маршрут недоступен, один или несколько ретрансляторов транспорта перенаправляют трафик. Трафик данных не следует передавать через серверы, которые действуют как формирователи пакетов, VPN-серверы или другие функции, которые могут привести к задержке обработки и снизить эффективность взаимодействия с пользователями.
• Трафик сигнализации всегда поступает на сервер, расположенный к пользователю ближе всего.

Подробные сведения о выбранном пути передачи данных см. в основной документации по потокам вызовов.

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

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

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

Рис. 1. Топология Служб коммуникации Azure

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

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

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

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

Один к одному вызову означает, что один пользователь напрямую вызывает другого пользователя. Чтобы инициализировать вызов вызывающего пакета SDK, получите набор кандидатов, состоящих из IP-адресов и портов, включая локальный, ретранслятор и рефлекторный (общедоступный IP-адрес клиента, как показано ретранслятором). Пакет SDK вызывающего абонента отправляет этих кандидатов в вызываемую сторону; Вызываемая партия также получает аналогичный набор кандидатов и отправляет их вызывающему объекту. Сообщения для проверки подключения STUN используются для определения работоспособности путей передачи данных вызывающей/вызываемой стороны и последующего выбора наиболее работоспособного пути. После установки пути подключения подтверждение DTLS выполняется по этому подключению, чтобы обеспечить безопасность. После подтверждения DTLS ключи SRTP извлекаются из процесса подтверждения DTLS. Данные (т. е. пакеты TP/RTCP, защищенные с помощью SRTP) затем отправляются с использованием выбранной пары кандидатов. Ретранслятор транспорта доступен в рамках Службы коммуникации Azure.

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

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

Важные действия:

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

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

Рис. 2. Поток трафика в клиентской сети

На шаге 7 для передачи выбран одноранговый поток данных 5.

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

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

Рис. 3. От клиентской сети к внешнему пользователю (данные передаются через транспортный ретранслятор Azure)

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

Эти потоки ретранслируются транспортным ретранслятором Teams в Azure.

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

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

Рис. 4. От клиентской сети к внешнему пользователю (прямая передача данных)

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

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

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

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

Рис. 5. От VPN-пользователя к внутреннему пользователю (данные передаются через Azure Relay)

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

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

Рис. 6. От VPN-пользователя к внутреннему пользователю (прямая передача данных)

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

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

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

Рис. 7. От VPN-пользователя к внутреннему пользователю (прямая передача данных)

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

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

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

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

Рис. 8. Подключение пользователя Служб коммуникации к ТСОП через канал связи Azure

В этом случае сигнализация и передача данных из клиентской сети в Azure используют поток 4.

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

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

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

Рис. 9. Групповые вызовы Служб коммуникации

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

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

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

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

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

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

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

Примечание.

Хотя заголовок указывает Lync, он применим к Службы коммуникации Azure и Teams*.

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

Следующие шаги

Начало работы с вызовами

Вас могут заинтересовать следующие документы:

• Дополнительные сведения о типах вызовов.
• Сведения об архитектуре "клиент — сервер"