В этом руководстве представлены схемы потоков данных для Службы коммуникации Azure. Используйте эти схемы, чтобы понять, как клиенты и службы взаимодействуют с Azure для предоставления взаимодействия.
Службы коммуникации — это облачная служба с интерфейсами REST API и пакетами SDK клиентской библиотеки, которые помогают интегрировать взаимодействие с приложениями. Службы коммуникации поддерживают несколько форматов связи: голосовой и видеозвонок, текстовый чат, SMS и пользовательские двоичные данные.
Вы можете добавить связь в веб-приложения и мобильные приложения, интегрировать пользовательские службы и боты, а также программно получить доступ к общедоступной сети телефонной связи (ТСОП). Вы можете получить номера телефонов непосредственно из API-интерфейсов Службы коммуникации Azure или портал Azure и использовать эти номера для приложений SMS или голосовых звонков. Используя прямую маршрутизацию служб коммуникации, вы можете принести собственный поставщик телефонии через протокол SIP и пограничные контроллеры сеансов.
В этих схемах потоков данных используются следующие компоненты:
- Клиентское приложение. Веб-сайт или собственное приложение, используемое конечными пользователями для обмена данными. Службы коммуникации предоставляют клиентские библиотеки SDK для браузеров и собственных приложений. Библиотека пользовательского интерфейса с открытым исходным кодом, основанная на этих пакетах SDK, предоставляет программируемые веб-компоненты (React), iOS и Android UI.
- Служба управления удостоверениями. Служба, которая создается для сопоставления пользователей и служб с удостоверениями служб коммуникации. Эта служба также создает маркеры для пользователей, когда им нужно получить доступ к плоскости данных.
- Служба контроллера связи. Служба, которая создается для управления потоками чата и голосовой связью и видеозвонками.
- Служба данных связи. Возможность службы, которая создается для прямого взаимодействия с контентом связи, например отправкой сообщений чата и SMS-сообщений или воспроизведением звука в голосовом вызове.
Отраслевые стандарты для связи, такие как WebRTC, отделяют обмен данными в плоскость управления и сигнального уровня и плоскости данных. Используя службы коммуникации, вы можете создать взаимодействие без необходимости понимать внутреннюю реализацию WebRTC службы. Однако эти понятия помогут вам разработать приложение:
| Система | Функция | Протоколы | Модель доступа |
|---|---|---|---|
| Плоскость управления | Управляет тем, кто взаимодействует, когда и как | REST | Учетные данные службы Microsoft Entra |
| Плоскость данных | Содержит содержимое связи, голос, видео, текст и данные, которые взаимодействуют с людьми и приложениями | UDP, RTMP, WebSockets, REST | Маркеры доступа пользователей и учетные данные службы Microsoft Entra |
Распространенный поток данных возникает, когда клиентские приложения инициируют обмен данными, запрашивая сведения об управлении с контроллера службы:
- Какие собрания у меня есть сегодня?
- Какой номер телефона я использую для звонка моего друга Джозефа?
- Каковы имена моих товарищей по команде? Какие текущие потоки чата у нас есть?
Служба управления выполняет эти запросы, предоставляя клиентам маркеры и идентификаторы служб коммуникации для пользователей, потоков, номеров телефонов и звонков. Затем клиенты используют эти маркеры и идентификаторы для взаимодействия с плоскостем данных Azure. API служб коммуникации не ограничивают структуру пользовательского интерфейса или процессов, управляющих взаимодействием.
В стандарте WebRTC клиенты запрашивают сведения об управлении службами, отправляя сообщения управления в процессе, известном как сигнал. Идентификаторы служб коммуникации, такие как идентификатор вызова, сопоставимы с описаниями сеансов WebRTC.
Пользователи, прошедшие проверку подлинности с помощью маркеров доступа пользователей
Клиенты служб коммуникации представляют маркеры доступа пользователей для доступа с улучшенной безопасностью, уровнем вызовов и чата Azure. Вы должны создавать маркеры доступа пользователей и управлять ими с помощью доверенной службы. Маркер и строка подключения или секреты Microsoft Entra, необходимые для их создания, должны быть защищены. Неправильное управление маркерами доступа может привести к дополнительным расходам из-за неправильного использования ресурсов.
Скачайте файл Visio для этой архитектуры.
Поток данных
- Пользователь запускает клиентское приложение.
- Клиентское приложение обращается к службе управления удостоверениями. Служба управления удостоверениями поддерживает сопоставление удостоверений приложений и удостоверений служб коммуникации. (Удостоверения приложений включают пользователей и другие адресные объекты, такие как службы или боты.)
- Служба управления удостоверениями использует сопоставление для выдачи маркера доступа пользователя для соответствующего удостоверения.
приложение Azure служба или Функции Azure являются двумя альтернативами для работы службы управления удостоверениями. Эти службы легко масштабируется и имеют встроенные функции для проверки подлинности пользователей. Они интегрированы с OpenID и сторонними поставщиками удостоверений, такими как Facebook.
Ресурсы
- Концепция:удостоверение пользователя
- Краткое руководство.Создание маркеров доступа и управление ими
- Руководство. Создание службы управления удостоверениями с помощью Функции Azure
- Пример:Создание службы управления удостоверениями с помощью Функции Azure
Пользователь вызывает приложение или номер телефона
Самый простой сценарий голосового и видеозвонка включает в себя вызов другого пользователя на переднем плане без push-уведомлений. Вы можете интегрировать голосовые и видеозвонки служб коммуникации в веб-приложения, собственные мобильные и классические приложения Windows. Библиотека пользовательского интерфейса с открытым исходным кодом помогает ускорить разработку.
Скачайте файл Visio для этой архитектуры.
Поток данных
- Инициирующий пользователь получает удостоверение Служб коммуникации для человека, которого они хотят вызвать. В типичном сценарии пользователь получает удостоверение из списка друзей, который поддерживается службой управления удостоверениями. Список сопоставляет друзей пользователя и связанные удостоверения служб коммуникации.
- Инициирующий пользователь запускает клиент вызова и вызывает удаленного пользователя.
- Принимающее пользователь уведомляется о входящем вызове с помощью пакета SDK для вызовов. Чтобы получать входящие вызовы, приемчик должен уже инициализировать клиент вызова.
- Пользователи взаимодействуют друг с другом с помощью голосового и видео в вызове.
Поток данных почти идентичен, когда пользователь вызывает внешний номер телефона. Ключевое отличие заключается в том, что для доступа к традиционной телефонии инициирующий пользователь должен запрашивать исходные и конечные номера телефонов из службы контроллера, а не запрашивать удостоверения пользователей.
В некоторых ситуациях приложения могут принимать звонки в фоновом режиме с помощью служб платформы, таких как Apple Push Notification. Эту функцию можно включить, интегрируя службы коммуникации с Центрами уведомлений Azure.
Ресурсы
- Общие сведения о концепции:вызове
- Концепция:библиотека пользовательского интерфейса
- Краткое руководство. Добавление голосового вызова в приложение
- Краткое руководство.Добавление видеозвонка в приложение
- Пример:Группирование звонков для интернета, iOS и Android
Пользователь присоединяется к групповому вызову без приглашения
Возможно, пользователи смогут присоединиться к групповому вызову без явного приглашения. Ваше приложение может предоставить постоянное социальное пространство или клуб , который включает канал видеозвонка, который пользователи могут присоединиться, когда они хотят. Этот поток данных показывает вызов, который изначально создается клиентом и позволяет удаленному клиенту присоединяться без явного приглашения:
Скачайте файл Visio для этой архитектуры.
Поток данных
- Инициирующий пользователь инициализирует клиент вызова и выполняет групповой вызов.
- Инициирующий пользователь предоставляет общий доступ к идентификатору группового вызова со службой контроллера связи.
- Служба контроллера коммуникации предоставляет идентификатор вызова другим пользователям. Например, если приложение предоставляет пользовательские клубы, идентификатор группового вызова является атрибутом модели данных клуба, хранящейся в Azure Cosmos DB.
- Другие пользователи присоединяются к вызову с помощью идентификатора группового вызова.
- Пользователи взаимодействуют друг с другом с помощью голосового и видео в вызове.
Microsoft 365 и Teams
Многие организации используют Microsoft 365 и Teams для обмена данными. Службы коммуникации и Teams взаимодействуют, что позволяет выполнять следующие сценарии:
- Создайте пользовательское приложение, чтобы разрешить внешнему пользователю присоединиться к собранию Teams. Этот сценарий идеально подходит для сценариев виртуального посещения, где бизнес, использующий Teams, размещает собрание для внешних потребителей, использующих пользовательское приложение и пользовательское удостоверение. Дополнительные сведения об этом сценарии см . в руководстве по виртуальным посещениям и образце построителя.
- Создайте пользовательское приложение для внутреннего пользователя с учетными данными Teams или Microsoft Entra. Этот сценарий предназначен для создания пользовательских клиентов Teams для сотрудников.
В этих сценариях пользовательских приложений используются API Microsoft Graph и службы коммуникации. При создании внешних приложений и служб, подключающихся к Teams, обычно в качестве уровня управления Teams используется Microsoft Graph. Этот уровень управления используется для настройки того, кто взаимодействует и как и когда они взаимодействуют с помощью API:
Сведения из этих API элементов управления, такие как URL-адрес собрания и идентификатор потока, используются для подключения клиентов служб коммуникации и чата к плоскости данных Teams.
В Teams также есть пакеты SDK для добавления пользовательских функций в teams и через магазин Teams, например вкладки, боты и автоматизацию. Эти сценарии выходят за рамки область этой статьи.
Службы коммуникации не поддерживают непосредственное взаимодействие с каналами Teams. Для пользовательских приложений можно использовать API чата Microsoft Graph и канала для создания пользовательских клиентов для сотрудников, обращающихся к каналам.
Приложение присоединяется к запланированному вызову Teams
Приложения Служб коммуникации могут присоединяться к вызовам Teams. Для внешних пользователей приложению требуется ссылка на собрание Teams. Извлечение ссылок осуществляется через API Microsoft Graph. Вот поток данных:
Скачайте файл Visio для этой архитектуры.
Поток данных
- (1A) Служба контроллера коммуникации планирует групповой вызов с помощью API Microsoft Graph. В другом случае использования (1B) пользователи планируют групповой вызов с помощью Outlook или Teams.
- Служба контроллера коммуникации делится сведениями о вызове Teams с клиентами Служб коммуникации.
- Как правило, пользователь Teams должен присоединиться к вызову через пользовательский интерфейс Teams и разрешить внешним пользователям проходить через лобби предварительного вызова Teams. Однако это требование зависит от конфигурации клиента Teams и определенных параметров собрания.
- Пользователи служб коммуникации инициализируют клиент вызова и присоединяются к собранию Teams с помощью сведений, полученных на шаге 2.
- Пользователи взаимодействуют друг с другом с помощью голосовой связи и видео.
Ресурсы
- Руководство и пример построителя:Виртуальные посещения
- Концепция:взаимодействие Teams
- Краткое руководство. Присоединение к собранию Teams
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.
Автор субъекта:
- Крис Палмер | Диспетчер продуктов основной группы
Другие участник:
- Мик Альбертс | Технический писатель
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.
Следующие шаги
- Что такое службы коммуникации?
- Создание ресурса Служб коммуникации
- Справочная документация по службам коммуникации
- Модуль Learn: введение в Службы коммуникации Azure
- Модуль Learn: создание веб-приложения для голосового вызова с помощью Службы коммуникации Azure