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

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

Предыстория

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

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

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

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

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

Типы трафика

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

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

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

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

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

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

Экземпляры службы Azure Communication Services, которые вызывают клиентов SDK, используют протокол DTLS (Datagram Transport Layer Security) для получения ключа шифрования. После завершения процедуры рукопожатия DTLS, носитель начинает передаваться с использованием этого ключа шифрования, согласованного с помощью DTLS, через SRTP.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Пользователь Служб связи Azure A разрешает доменное имя URL-адреса (DNS) с помощью Flow 2.

2. Пользователь A выделяет порт медиа-ретрансляции в транспортном ретрансляторе Teams с помощью "Flow 4".

3. Пользователь A отправляет приглашение с кандидатами интерактивного создания подключений (ICE) с помощью Flow 4 в Службы коммуникации Azure.

4. Службы коммуникации Azure уведомляют пользователя B с помощью потока 4.

5. С помощью потока 4 пользователь B выделяет порт ретрансляции мультимедиа на транспортном ретрансляторе Teams.

6. Пользователь B отправляет ответ с кандидатами ICE с помощью потока 4, который пересылается обратно пользователю А с помощью потока 4.

7. Пользователь A и Пользователь B запускают тесты соединения ICE, и выбран лучший доступный медиапуть. Просмотрите следующие схемы, чтобы просмотреть различные варианты использования.

8. Оба пользователя отправляют данные телеметрии в Службы коммуникации Azure с помощью потока 4.

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

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

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

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

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

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

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

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

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

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

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

VPN-пользователь для внутреннего пользователя (медиа, передаваемые ретрансляцией транспорта Teams)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Замечание

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

• Средства управления трафиком: устройства обрезки пакетов, инспекции пакетов или формирования пакетов не поддерживаются и могут значительно снизить качество.

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

Как начать совершать звонки

Связанный контент

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