Введение
Доброго времени суток, Хабровчане.
Хочу поделится с сообществом своим опытом по реализации аудио-звонков c web и мобильных клиентов в Cisco UCCX. Возможно, он кому-нибудь поможет в будущем или в настоящем.
Итак, однажды, передо мной была поставлена задача организовать аудио-звонки с web и мобильных клиентов на в Cisco UCCX. Все знают прекрасные сервисы по типу zingaya, но заказчик четко ограничивал использование сторонних сервисов.
Задача свелась к написанию клиента, выбора SBC и пробрасыванием сигнализации от клиента на Cisco Call Manager.
Проведенный мною анализ остановил меня на трех способах реализации требований:
- RTMP клиенты, написанные под Adobe AIR и Flash + mod_rtmp к freeswitch в качестве SBC
- RTMFP клиенты, написанные под Adobe AIR и Flash + RTMFP2SIP gateway от компании Flashphoner
- WebRTC клиенты, написанные на js + Mobicents SIP Servlets
RTMP клиент для Freeswitch
Достоинства
- Скорость развертывания
- Скорость разработки клиента
- Легкая интеграция с другими IP PBX
- MPL лицензия
Я поставил описание этого варианта на первое место, как самый переспективный, который и был реализован.
Для остальных вариантов были написаны демо версии, но в продакш пошел первый.
Скорость развертывания
Она феноменальна, особенно у компаний, которые уже используют Freeswitch в своей работе. Достаточно раскомментировать строчку endpoints/mod_rtmp в modules.conf, скомпилировать модуль (make mod_rtmp-install в src),
поправить конфигурационный файл в $FSPATH/conf/autoload_config/rtmp.conf.xml (а именно выставить ip, порт, диалплан),
подгрузить установленный модуль (load mod_rtmp в fs_cli) и открыть порт в iptables.
Все — можно приступать к разработке клиента.
Скорость разработки клиента
Freeswitch содержит в себе демо-клиента, написанного на ActionScript3 с JS CallBacks (clients/flex).
Для данной задачи был написан Adobe AIR клиент, реализующий логику управления NetStream и callbacks от Freeswitch, таких как login, logout, call, notify и прочее.
Вкратце, работа происходит следующим образом:
Freeswitch на каждый NetStream назначает uuid канала, и дальше все звонки бриджует через себя. Единственная проблема, которую я словил, это невозможность использовать TTS и ASR (подключенными через unimrcp) MRCPv2 протоколу, при звонке с RTMP клиента.
Затраченное время на разработку — неделя, в две руки (то есть один человек или два одноруких кодера).
Благодаря Adobe AIR в полку клиентов было: desktop-client, tablet-client для iOS и Android, mobile-client для iOS и Android и Flash-client.
Код был один, различие только в layout и иконках, что очень порадовало как меня, так и заказчика.
Недостатки
- Использование TCP и нестабильность работы по 3G каналам
- Отсутствие шумоподавления
- Поддержка только Speex
- Связь между двумя RTMP клиентами — SIG и RTP идет через Freeswitch
Использование TCP и нестабильность работы по 3G каналам
Как показала практика, данный клиент стабилен на adsl, lan каналах и wifi. На 3G он вел себя непредсказуемо (впрочем как и покрытие МТС 3G). В любом случае, коннекты он держал, и максимум что было — corrupted audio.
Отсутствие шумоподавления
Всем известная проблема, спасибо
Пока не решили для десктопных клиентов, мобильные клиенты используют наушники.
Поддержка только Speex
Если удаленная сторона это IP PBX, то Freeswitch возмет транскодинг на себя.
Но между RTMP клиентом и Freeswitch пока ходит Speex.
Нужна доработка mod_rtmp для поддержки G.711.
Связь между двумя RTMP клиентами — SIG и RTP идет через Freeswitch.
Для связи 2-х RTMP клиентов всегда нужен сервер.
RTMFP клиент для RTMFP2SIP
Достоинства
- Продукт с поддержкой
- Есть бесплатная версия на 10 аудио- соединений
- UDP
Недостатки
- Денег неправославных стоит
- API реализован в виде swc, проблемы с подгрузкой в мобильные клиенты
Данный продукт также рассматривался как переспективный, пока я не потерпел неудачу с
добавлением функционала в Adobe AIR Mobile.
Для Desktop и Web клиентов, у данного продукта есть серьезные преимущества над первым в списке:
1) UDP-based протокол
2) Поддержка H.264 и G.711.
Поведение SIG и RTP абсолюно идентично первому варианту (только UDP вместо TCP).
В общем в связи с его неполной пригодностью для задачи, меня хватило только на его установку,
настройку и тестовый звонок. Она достаточно тривиальна и неплохо описана разработчиком.
Был сделан демо-клиент на Flash — срок разработки 3 дня.
WebRTC клиенты, написанные на js + Mobicents SIP Servlets
Если признаться, на эту я возлагал наибольшие надежды.
У меня был достаточный опыт работы с Mobicents, поэтому поддержка WebRTC в версии 2.0.0 FINAL стала для меня приятной новостью.
Я всерьез грезил о видео- и аудио-звонках без плагинов и веб-браузеров, но судьба оказалась жестокой.
Я не буду описывать технологию WebRTC, ее без труда можно найти в поиске Хабра.
Отмечу только одно, что мне надо сделать татуировку: «Не используй драфты».
Желательно на лбу, желательно в зеркальном отражении, чтобы при утреннем бритье, я каждый раз вспоминал эту гениальную мысль, пришедшую когда реализация siprec draft для Broadworks не работала с реализацией siprec draft для Cisco (потому что Broadworks использовал siprec 04, а Cisco siprec 11).
Если интересно, то более-менее стабильно работал только Chrome билд 24, ночной Firefox отказывался, а экспериментальный Ericsson Bowser завесил мне и iPad, и мой Nexus S.
Поэтому я напишу гипотетические достоинства, и недостатки.
Достоинства
- При звонке между двумя WebRTC клиентами (при условии использвания одинаковых кодеков) SIG — идет через SIP proxy, а вот RTP напрямую.
- Никаких плагинов (в идеале)
- Элегантность интерграции в порталы
- Использование JBOSS в качестве AS для Mobicents
Недостатки
- Драфт
- Половина браузеров не поддерживает
- Та половина которая поддерживает, реализовала пару кодеков
Был сделан демо-клиент который зависал в Ericsson Bowser и работал только в Chrome build 24 — срок разработки — 3 дня.
Источники
RTMP
wiki.freeswitch.org/wiki/Mod_rtmp
RTMFP
flashphoner.com/flash-rtmfp-sip-gateway
WebRTC
code.google.com/p/sipservlets
code.google.com/p/sipservlets/wiki/HTML5WebRTCVideoApplication
Заключение
Надеюсь эта статья была вам полезна и съэкономила вам время при выборе одной из этих технологий.