Видеоконференции в Asterisk

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

Существуют и opensource серверы видеоконференций (MCU), такие как openmcu и mcumediaserver. Первый поддердживает только протокол h323 и разрабатывается довольно давно, однако проект до сих пор сырой и имеет много проблем, второй пока в начальной стадии разработки. Оба этих проекта умеют микшировать видеопотоки в один (2х2, 3х3 и т.д.), что требует серьезных процессорных затрат на декодирование, микширование звука и видео и затем снова сжатие. Однако есть альтернатива в виде универсального приложения для аудио- видеоконференций app_conference для asterisk, которое мы и решили протестировать.

В качестве сервера для тестирования была применена платформа Trixbox 300 в конфигурации P4 1.6 ГГц 256 RAM c установленым Trixbox 2.6 (Asterisk 1.4.18.1-2). В качестве видеотелефонов использовались три компьютера с Windows XP, с установлеными софтфонами Kapanga и USB веб камерами D-Link DSB-C320 и Logitech. Разрешенные кодеки: G711MuLaw (audio), G711ALaw (audio), H.261 (video).

На сервере app_conference собрать не удалось, разбираться не стали и применили готовый откомпилированный app_conference.so из RPM asterisk-conference-1.4.21-1.fc7.i386.rpm. Астериск подхватил модуль и в дальнейшем работал без каких-либо нареканий. Модуль не требует какого-либо оборудования для работы. Настройки sip.conf одного из экстеншенов для передачи видео:

sip.conf
[general]
videosupport=yes 
 
[100]
type=friend
secret=100
record_out=On-Demand
record_in=On-Demand
qualify=yes
port=5060
pickupgroup=
nat=yes
mailbox=100@device
host=dynamic
dtmfmode=rfc2833
dial=SIP/100
context=from-internal
canreinvite=no
callgroup=
callerid=x100 <100>
accountcode=
call-limit=50
disallow=all 
allow=ulaw 
allow=alaw 
allow=speex 
allow=gsm 
allow=h261 
allow=h263 
allow=h263p

Диалплан для тестирования:

from-internal-custom.conf
[from-internal-custom]
;первый режим: управление dtmf 
exten => 200,1,conference(temp,XR,1) 
;второй режим: управление vad 
exten => 201,1,conference(temp,SVDA,VADSTART,VADCONTINUE) 

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

У app_conference, по сути, есть два режима работы по переключению видеопотоков: по dtmf и по vad (голосовой активности).

Управление по dtmf

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

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

Такое управление неудобно по следующим причинам: каждый смотрит куда хочет, а не на говорящего (руководителя); изначально неизвестно, кто под каким номером зашел (зато если в Asterisk завести sip камеры, то таким способом можно организовать что-то вроде видеонаблюдения, и по словам авторов можно записывать видеопоток). Однако из командной строки можно принудительно назначить источник видеосигнала для всех участников конференции, что дает широкие возможности манипуляции с помощью AMI и PHP приложений.

Управление по VAD

Нам удалось заставить работать app_conference в этом режиме только при включении подавления тишины в софтофоне, что может вызвать проблемы при обычных звонках. Выяснилось, что VAD детектор переключает видеопотоки на говорившего если он говорит более 10 секунд. Срабатывание этого механизма было нечетким, да и вообще не очень понятным. В общем, идея хорошая, но малоработоспособная.

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

  1. для тех, кто не любит GUI в любых его проявлениях:
    В режиме работы по dtmf при создании конференции (по первому вошедшему) запускается скрипт или программа, которая, подключившись у Asterisk по AMI, начинает мониторить поток событий на наличие нажатых кнопок со стороны модератора конференции, затем выполняет команду, которая принудительно раздает видео с выбранного источника. Например, руководитель, всех отчитав произносит: «Выслушаем начальника транспортного цеха» и нажимает кнопку 7 (номер начальника транспортного цеха). Все участники конференции видят этого начальника, слышат что он говорит и могут задать ему вопросы. Выбор видео можно совместить с отключением аудио для всех остальных.
  2. Использование GUI
    Целесообразно разработать несложный GUI на PHP, который по AMI ищет конференции, показывает список участников, а для модератора - предоставляет органы управления, кому и когда говорить и кого показывать (т.е. сделать аналог web-meetme).

Замечания по производительности

App_conference позиционируется как hight perfomance замена meetme, однако при трех участниках LA была 0,44, а при широковещательном видео - 1,55..1,99. При более поздних замерах - такой загрузки замечено не было, так как был отключен режим отладки (который записывает в full очень много информации). В интернете встречаются упоминания о конференциях (видимо только голос) в 250 человек.

  1. конференция с произвольным выбором:
    2 абонента - LA 0,23 91.4%id
    3 абонента - LA 0.37 76.8%id
  2. конференция с широковещательным видео:
    2 абонента - LA 0.19 83.7%id
    3 абонента - LA 0.37 88.0%id

Послесловие

Совместно с камерами D-link использовалась и Logitech, но последняя имела очень плохое качество изображения, сильные шумы в условиях, при которых D-link показывали четкую и чистую картинку.

videokonferencii_v_asterisk.txt · Последние изменения: 2013/11/20 12:35 (внешнее изменение)
GNU Free Documentation License 1.3
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0 Яндекс.Метрика