Эта статья написана членами сообщества разработчиков RTC, которые поделились своим опытом разработки шлюза WebRTC2SIP на основе Agora SDK и FreeSWITCH и использовали это решение для улучшения системы аудио- и видеоплатформы, изначально разработанной на основе протокола SIP. Если вы заинтересованы, вы можетекликните сюда, общайтесь с автором.
Программа и идеи
Зачем это делать?
В начале этого года я получил проектное задание, и заказчик обратился с просьбой интегрировать функцию webrtc в собственную систему аудио- и видеоплатформы (исходная система была разработана на основе протокола SIP и стабильно работает уже много лет, с определенным количеством существующих клиентов). После сравнения эффектов нескольких продуктов RTC заказчик был очень доволен демонстрационными аудио- и видеоэффектами звуковой сети и указал, что сеть передачи SD-RTN звуковой сети должна использоваться для всесторонней трансформации клиентского программного обеспечения и улучшения. качество звука звонка. Согласно измерениям клиентов, в некоторых странах и регионах качество аудиозвонков намного лучше, чем у WeChat в том же сетевом окружении.Например, голосовые вызовы между Восточной Африкой и Китаем имеют небольшую задержку и более четкие голоса.
В настоящее время система подключена к сети и работает уже несколько месяцев без каких-либо проблем, качество связи также очень хорошее, что соответствует ожиданиям клиентов. Компании требуется краткое изложение проблем, возникших на этапе разработки, и мы также надеемся отплатить сообществу, сформировать позитивное взаимодействие и постоянно укреплять сильную атмосферу обучения и общения в сообществе. Чувствуя работу по разработке в течение этого периода времени, я написал эту статью, Мы будем регулярно обновлять этот пост, чтобы делиться идеями разработки, решениями, возникающими проблемами и решениями, надеясь быть полезными для всех. Я могу набирать код, но я не очень хорош в выражении.Если вы столкнетесь с подобными проблемами в процессе реализации этого модуля и хотите узнать некоторые подробности, пожалуйста, свяжитесь с нами для вопросов или обмена электронной почтой (адрес электронной почты обмена: bd@qzlink .com), мы постараемся вам ответить.
Попутно несколько коллег часто анализируют код до полуночи. Наконец стабилизировался после 4 месяцев испытаний. На самом деле, оглядываясь назад, я понимаю, что не понимал документацию по API Shengwang и не использовал функции сообщества должным образом. Если яма, с которой вы столкнулись, похожа на нашу, то найдите время, чтобы несколько раз внимательно прочитать документацию по API, и вы сможете это исправить.
Без лишних слов, вот требования заказчика:
1. Полностью трансформировать клиентское ПО 5 платформ Android, iOS, Windows, MacOS и Web, оригинальные клиенты были разработаны на базе Pjsip, Linphone и Sipjs;
2, требуется локальная плохая сетевая среда, четкие голосовые вызовы, но также для удовлетворения требований (поддержка голосовой сети сети передачи аудио и видео в реальном времени);
3, минимально инвазивные, старайтесь не изменять функции системного сервера, клиент не имеет смысла для достижения обновлений;
4. Решить проблемы потери пакетов, фильтрации UDP, невозможности вызова и неслышных вызовов, часто встречающихся в протоколе SIP;
5. Решите проблемы поведения, такие как SIP-серверы, которые часто пытаются атаковать вызовы, злонамеренные атаки регистрации сканирования и т. д., и улучшите стабильность системы;
6. Реализовать двустороннюю связь между протоколом WebRTC и протоколом SIP.Он не только совместим с вызовами SIP, но также поддерживает клиент RTC для отправки вызовов на сервер SIP, а также поддерживает сервер SIP для вызова клиентское программное обеспечение (в сети передачи аудио и видео в реальном времени звуковой сети). передача). .
На самом деле, когда мы впервые получили запрос, мы вместе обсудили и проанализировали: похоже, у такого проекта большой бюджет, но для полноплатформенного клиента задача разработки тяжелая, и нужно учитывать много деталей. ● Удовлетворение ожиданий клиентов — вопросительный знак, поэтому большинство коллег не советуют этого делать. Затем, после того как руководитель и клиент пошли веселиться, работа не знала, как продолжать.
Причина босса очень проста, не делай ни того, ни этого, так что же нам делать? Если кто-то может это сделать, клиенты все равно будут приходить к нам? Затем сделайте это, действуйте немедленно, проверьте различные материалы, прочитайте документы по техническому развитию Shengwang, проконсультируйтесь со студентами-технарями Shengwang и придумайте предварительный план за 2 дня.
Существует 6 шагов к решению:
1. Напишите сигнальный модуль самостоятельно, сохраняйте гибкость и просто реализуйте его. Разработать TCP-сервер для работы с сигнальным сервером;
2. Суть заключается в разработке шлюза преобразования протоколов SIP2WebRTC/WebRTC2SIP и обслуживании конечного автомата;
3. Разработать процессоры аудио- и видеокодеков для обеспечения взаимодействия между голосом в голосовой сети и голосовым кодеком SIP;
4, разработка модуля управления состоянием, SessionManger, для того, чтобы поддерживать статус IP и порт клиента;
5, в сочетании с аудио и видео звуковой сетью SDK, интегрируют свой собственный модуль сигнализации и модуль связи WEBRTC2SIP;
6. Настройте общую сигнализацию вызовов SIP для всех клиентов платформы.
Обычно используемые SIP-сигналы: 1 регистрация, 2 вызова, 3 ответа, 4 отбоя, 5 отклонений, 6 отмен, 7 удержание, 8 DTMF, 9 пользователь не отражен, 10 пользователь в автономном режиме, 11 передача, 12 конференция (я кратко представлю предыдущий из 6 ).
PS: Давайте пока назовем эту систему WebRTC2SIP Connector или SIP2WebRTC Connector. Что касается того, почему это называется так, я не знаю. Может быть, слишком много людей называют XX Gateway. Если вы не называете это так, это не показывает, насколько мощным является SD-RTN. Я его отец. Можешь называть это как хочешь, ха-ха.
После прояснения наших идей нам необходимо подтвердить несколько основных вопросов:
SDK какой платформы используется для разработки базового модуля WebRTC2SIP Connector?
Поддерживает ли Agora SDK несколько одновременных вызовов?
Какой формат кодирования голоса и форматов кодирования видео? Оценка отбора проб, сколько?
Сторона клиента SIP Нет конкретных требований кодирования? Исправлен клиент приемлемый речевой кодирование, я выбрал PCMA
Здесь я хотел бы поблагодарить Shengwang за его быструю реакцию на наши нишевые потребности.Я также благодарю Shengwang за техническую поддержку.Я пришел в компанию, чтобы пообщаться в течение нескольких часов, и поделился некоторой технической информацией.Поставьте большой лайк.
SoundNet рекомендует:
Разрабатывайте модули преобразования протоколов с помощью Agora Windows SDK или Linux SDK;
Оба SDK поддерживают несколько одновременных вызовов;
Голос в формате PCM, видео находится в формате YUV, а частота дискретизации составляет 48 кГц;
Вот цифры.
Краткое описание общего процесса выглядит следующим образом:
1. Когда запускается каждый клиентский SDK, инициируйте TCP-соединение и войдите на сервер сигнализации TCP Server.Инициализация модуля передачи WebRTC2SIP также инициирует TCP-соединение для входа в TCP-сервер, и TCP-сервер записывает такую информацию, как UID, IP и порт.
2. Конкретный процесс звонка примерно таков:
(1) При звонке подать заявку на номер комнаты и инициировать сообщение о вызове в соответствии с настраиваемым форматом сигнализации.После его получения TCP-сервер перенаправляет его на модуль передачи WebRTC2SIP;
(2) После того, как WebRTC2SIP его получит, он создает поток, анализирует сообщение, запускает SDK SoundNet и добавляет указанный номер комнаты;
(3) Начать чтение аудиопроцесса, одновременно запустить поток, инкапсулировать стандартное сообщение SIP и инициировать запрос приглашения sip на SIP-сервер телефонного сервера;
(4) SIP-сервер звонит по вызываемому номеру телефона после получения запроса на вызов и возвращает сигнал вызова.
(5) WebRTC2SIP получает сигнал вызова и инкапсулирует настроенную информацию о звонке в клиентский SDK;
(6) После вызванного ответа WebRTC2SIP запустить Media Coder, чтобы начать парсинг медиапотока, и после ресемплинга записать его в комнату звуковой сети. Реализовать голосовые вызовы.
3. Вызов из SIP в SDK SoundNet аналогичен другому, и наоборот.
Обратите внимание:
1. Каждый терминал должен иметь индивидуальный номер;
2, каждый вызов должен присоединиться к звуковому каналу в номере аудио и видео, для достижения взаимодействия;
3.Поскольку кодировка другая,требуется ресемпл.Это очень важно.Иначе при подключении не будет звука,и две стороны не совпадут.
4. Модуль WebRTC2SIP должен обрабатываться в многопоточном режиме для реализации одновременных вызовов;
5. Модуль WebRTC2SIP должен поддерживать полный конечный автомат и добавлять уникальный номер к каждому вызову, чтобы избежать ошибок.
До сих пор мы объясняли общие решения и технические идеи, увидев это, вы должны понять, что сделать это несложно, по крайней мере, сейчас так кажется.
дизайн сообщения
Как упоминалось выше, обычно используемые сигналы SIP: 1 регистрация, 2 звонок, 3 вызов, 4 ответ, 5 отбой, 6 отмена.
С помощью этих пакетов входящие и исходящие звонки могут быть в основном реализованы, другие отклонения, DTMF и т. Д. Похоже.
как показано на рисунке:
Соглашение:
1. Взаимодействие на стороне клиента и на стороне сервера в формате JSON;
Обязательные параметры: msgtag — уникальный идентификатор сообщения, userid — кто его инициировал, а appid — тег приложения. шифрование подписи подписи (в зависимости от ситуации)
2. Сообщение, возвращаемое сервером, должно включать msgtag \appid\errcode.
errcode=1 означает, что произошла ошибка, errmsg будет иметь значение, если errcode=0 означает, что возвращаемый результат правильный, обычно возвращаемый msgtag является запрошенным msgtag+"_res" в качестве отличия
3. roomID – это номер комнаты, который соответствует идентификатору канала звуковой сети.Каждое сообщение о вызове должно содержать назначение roomID.
4.callType — это видео\аудио, первое представляет собой видеозвонок, второе — голосовой вызов
5.direction направление вызова во входящем (SIP-сервер отправляет вызов на SDK звуковой сети) и исходящем (SDK звуковой сети отправляет вызов на SIP-сервер)
6.isSIP YES / NO указывает, является ли вызов внутренним вызовом (реализованным сетевым клиентом) или SIP-вызовом (посадка).
В этой статье я просто перечислю базовый DEMO-формат сообщения.
Сигнализация 1: Регистрационное сообщение
Ответное сообщение:
Сигнализация 2: Сообщение о вызове
Ответное сообщение:
Сигнализация 3: Звонок
Ответное сообщение:
Сигнализация 4: Получение сообщения
Ответное сообщение:
Сигнализация 5: повесить пакеты
Ответное сообщение:
Сигнал 6: Отменить сообщение
Ответное сообщение:
Сообщение, разработанное, как показано на рисунке выше, очень простое и не требует слишком много словесных пояснений для справки.
Следовать за
Независимо от того, является ли клиент или коннектор WebRTC2SIP по сути аудио- и видео-клиентом SDK звуковой сети, а затем интегрирует пользовательские сигнальные пакеты, поэтому во время инициализации вам необходимо вызвать специальный интерфейс (временно называемый initSIP), вызовите его. Параметр типа передается при использовании интерфейса.
(1) Если он вызывается с мобильного телефона, компьютера или веб-страницы, он возвращает адрес и порт TCP-сервера для установления TCP-соединения.
(2) Если это запрос сервера передачи соединителя, в дополнение к возврату адреса и порта TCP-сервера он также возвращает адрес и порт SIP-сервера и префикс вызова. В противном случае, когда SDK инициирует телефонный звонок, соединитель не знает, куда переадресовать звонок. Это может быть достигнуто путем разработки http-интерфейса.
APP инициализируется, вызывает интерфейс initSIP, устанавливает TCP-соединение или устанавливает TCP-соединение при вызове;
TCP-сервер поддерживает статус всех терминалов и сетевое расположение в роли диспетчера сеансов;
Номер, введенный вызывающим абонентом, редактируется и инкапсулируется, а вызывающее сообщение отправляется на сервер через сокет tcp, а пользовательский интерфейс отображает страницу ожидания коммутируемого доступа;
Когда вызываемая сторона получает сообщение о вызове, она инкапсулирует сообщение о вызове и отправляет его на сервер через сокет tcp.Сервер запрашивает диспетчер сеансов для запроса IP-адреса и порта вызывающей стороны и вызываемой стороны, чтобы реализовать маршрутизацию и пересылку сообщения, а вызывающая страница отображает страницу вызова после ее получения. В то же время коннектор WebRTC2SIP запускает поток медиакодера для разбора и передискретизации прочитанного аудиопотока. Таким образом, обмен сообщениями объединяется, и может быть реализована вся логика SIP-вызова.
Заинтересованные студенты, идите и попробуйте.