Основы потока вызовов
В следующем разделе содержатся общие сведения о потоках вызовов в Службах коммуникации Azure. Потоки сигнализации и мультимедиа могут быть разными в зависимости от типов вызовов, которые совершают ваши пользователи. Например, это могут быть голосовые вызовы через IP (VoIP) "один к одному", ТСОП "один к одному" или групповые вызовы с разными сочетаниями подключений по VoIP и ТСОП. Изучите раздел Типы вызовов.
О протоколах сигнализации и передачи мультимедиа
При установке однорангового вызова или группового вызова два протокола используются за кулисами — HTTPS (REST) для сигнализации и SRTP для мультимедиа.
Сигнал между пакетами SDK или между пакетами SDK и контроллерами сигналов служб коммуникации обрабатывается с помощью HTTPS REST (TLS). Службы коммуникации Azure использует TLS 1.2. Мультимедийный трафик в реальном времени (RTP) передается преимущественно по протоколу UDP. Если использование UDP запрещено брандмауэром, пакет SDK будет использовать протокол TCP для передачи мультимедиа.
Давайте рассмотрим протоколы сигнализации и передачи мультимедиа в разных сценариях.
Примеры потока вызовов
Случай 1. VoIP, где возможно прямое подключение между двумя устройствами
При вызове VoIP или видеовызове "один к одному" трафик передается по самому прямому пути. Прямой путь здесь означает, что если два пакета SDK могут обращаться друг к другу напрямую, они всегда будут устанавливать прямое соединение. Обычно это возможно, если два пакета SDK находятся в одной подсети (например, в подсети 192.168.1.0/24), или если устройства находятся в подсетях, которые могут видеть друг друга (в нашем примере это пакеты SDK в подсетях 10.10.0.0/16 и 192.168.1.0/24).
Случай 2. VoIP, где прямое подключение между устройствами невозможно, но где подключение между устройствами NAT возможно
Если два устройства находятся в подсетях, которые не видят друг друга (например, если Анна работает в кафе, а Олег дома), но возможно подключение между соответствующими устройствами NAT, пакеты SDK на стороне клиента будут использовать подключение через устройства NAT.
Для Анны это устройство NAT в кафе, а для Олега — устройство NAT дома. Устройства Анны и Олега обменяются внешними адресами своих устройств NAT. Пакеты SDK узнают свои внешние адреса из службы STUN, которую Службы коммуникации Azure предоставляют бесплатно. Логика обработки подтверждения между устройствами Анны и Олега внедрена в пакеты SDK, предоставляемые Службой коммуникации Azure. (Дополнительная настройка не требуется.)
Случай 3. VoIP, где ни прямое, ни NAT-подключение невозможно
Если одно из клиентских устройств или оба они размещены за симметричным NAT, требуется отдельная облачная служба для ретрансляции мультимедиа между двумя пакетами SDK. Для этого Службы коммуникации также предоставляют службу TURN. В пакете SDK для вызовов в Службах коммуникации служба TURN применяется автоматически с учетом обнаруженных сетевых требований. Плата TURN включается в цену звонка.
Случай 4. Групповые вызовы с ТСОП
Как сигнализация, так и передача мультимедиа для вызовов ТСОП передаются через ресурс телефонии Служб коммуникации Azure. Этот ресурс взаимосвязан с другими операторами.
Поток мультимедийного трафика ТСОП проходит через специальный компонент — обработчик мультимедиа.
Примечание.
Для тех, кто знаком с обработкой мультимедиа, наш обработчик мультимедиа также является обратным агентом пользователя, как определено в ПРОТОКОЛе SIP RFC 3261: сеансов, то есть он может переводить кодеки при обработке вызовов между сетями Майкрософт и операторами. Контроллер сигнализации Служб коммуникации Azure — это реализация прокси-сервера SIP согласно тому же стандарту RFC от Майкрософт.
Для групповых вызовов потоки мультимедиа и сигнализация всегда проходят через серверную часть Служб коммуникации Azure. Аудио и (или) видео от всех участников объединяются в обработчике мультимедиа. Все участники группового вызова отправляют аудио- и (или) видеопотоки в обработчик мультимедиа, а он возвращает им объединенные потоки мультимедиа.
По умолчанию в качестве протокола реального времени (RTP) для групповых вызовов используется UDP.
Примечание.
Обработчик мультимедиа может выполнять роль MCU или SFU.
Если пакет SDK не может использовать UDP для передачи мультимедиа из-за ограничений брандмауэра, будет предпринята попытка использовать протокол TCP. Обратите внимание, что обработчик мультимедиа работает с UDP, поэтому в описанном выше случае с групповым вызовом включается служба TURN из Служб коммуникации, которая будет выполнять преобразование из TCP в UDP. Плата TURN включается в цену звонка.
Случай 5. Использование пакета SDK Служб коммуникации и Microsoft Teams на запланированной конференции Teams
Передача сигналов через сигнальный контроллер. Передача мультимедиа через обработчик мультимедиа. Контроллер сигнализации и обработчик мультимедиа совместно используются Службами коммуникации и Microsoft Teams.
Случай 6. Ранний носитель
Ссылается на носитель (например, аудио и видео), обменяемый перед принятием определенного сеанса вызываемым пользователем. Если существует ранний поток мультимедиа, SBC должен защелковаться на первую конечную точку, которая запускает потоковую передачу мультимедиа; Поток мультимедиа может начинаться до назначения кандидатов. SBC должен иметь поддержку отправки DTMF на этом этапе, чтобы включить сценарии IVR/voicemail. SBC должен использовать наиболее приоритетный путь, по которому он получил проверка, если номинации не завершены.
Следующие шаги
Вас могут заинтересовать следующие документы:
- Дополнительные сведения о типах вызовов.
- Сведения об архитектуре "клиент — сервер"
- См. дополнительные сведения о топологиях потока вызовов.