WebRTC, Flash RTMFP и Java Applets - инструменты для создания платформы web VoIP звонков
VoIP




Если в каком-нибудь коммюнити спрашивают про аудио- или видеозвонки из браузера, как правило, получают ответ: "Попробуйте WebRTC". WebRTC, действительно, подходящая для этого технология и имеет ряд преимуществ над другими способами передачи аудио и видео в браузере.

Адепты WebRTC уже давно похоронили Flash, несмотря на то, что WebRTC местами имеет сырые реализации и доступна далеко не повсеместно. В настоящей статье представлены TOP 3 технологий звонков из браузера с описанием их преимуществ и недостатков.

Как известно, сам браузер "звонить" до последнего времени не умел. Не умел  обрабатывать звук с микрофона, посылать, принимать и воспроизводить. Относительно недавно в некоторых браузерах появилась возможность захвата с микрофона и вебкамеры и дальнейшей отправки этих данных по защищенному SRTP протоколу, а так же  воспроизведение потока с использованием адаптивного jitter buffer. Все эти новые  возможности  и есть не что иное, как WebRTC. Здесь стоит заметить, что браузерные звонки существовали за много лет до появления WebRTC, поэтому начнём с наиболее древних.

TOP3 – Java


Временем появления браузерных звонков можно считать момент, когда Java апплеты стали поддерживать захват аудио с микрофона. Java Runtime Environment (JRE), как правило, уже установлена в системе, будь-то Linux или Windows. JRE так же присутствует в виде плагина в большинстве известных браузеров. Например, если заглянуть во вкладку chrome://plugins браузера Google Chrome, можно найти там NPAPI Java плагин. Этот плагин и будет средой для выполнения Java апплета. Второй, более продвинутый способ запуска, это JNLP (Java Network Launch Protocol), который позволяет, к примеру, кустомизировать окно "Загрузка апплета...".

В итоге Java код выполняется десктопом или браузерным плагином, захватывает аудио с микрофона и отправляет его на сервер по стандартному RTP протоколу (для Java можно с легкостью отыскать несколько готовых RTP реализаций). С безопасностью здесь так же все в порядке. Понятно, что апплет должен быть подписан, и при запуске пользователя спросят, желает ли он запустить подписанный апплет от данного производителя, который может получить доступ к тем или иным функциям.

Плюсы решения на Java:
  • простое;
  • нет лишних звеньев, возможность прямого взаимодействия с сервером по RTP;
  • широкая распространенность и доступность JRE для конечного пользователя.

Кажется, что все идеально? К сожалению, в Java есть проблемы с DSP для VoIP. А это весь "must have" набор:
  • AEC (Acoustic Echo Cancellation);
  • AGC (Automatic Gain Control);
  • Adaptive Jitter Buffer;
  • Noise suppression.

Теперь представим звонок с Java апплета без гарнитуры (наушников с микрофоном). Если провести этот эксперимент ночью, поставив колонки на полную громкость, можно напугать соседей до заикания. Всё из-за эхоподавления. Его нет. Отсутствие AGC заставит ваших пользователей крутить уровень громкости (нормальный AGC должен делать это за пользователя, чтобы не было слишком тихо или слишком громко). А отсутствие Adaptive Jitter Buffer выльется либо в большую задержку либо в "choppy audio" – прерывистый неразборчивый звук. В результате качество коммуникации будет далеким от оптимального.

Все недостающие алгоритмы можно теоретически реализовать на Java, но есть пара проблем. Во-первых, реализовать универсальные и производительные алгоритмы (например AEC) достаточно сложно: такая реализация потребует высоких трудозатрат и расходов на R&D. Во-вторых, реализация таких алгоритмов на Java может работать в несколько раз медленнее, чем на C/C++, что может повлечь серьезные проблемы с производительностью и перерасход ресурсов клиентского CPU.

Производители Java апплетов с функцией звонков реализуют собственные DSP процессоры или используют уже существующие решения на C/C++. Как правило, они подкладывают к апплету DLL библиотеки, которые берут на себя обработку вышеописанных DSP алгоритмов. В результате Java апплет имеет стандартные VoIP функции для обеспечения качественного звонка со всеми "must have" VoIP алгоритмами.

В конечном итоге остается два минуса Java:
  • кроссплатформенность - придется снабжать апплеты DLL библиотеками под Win и SO библиотеками под Linux;
  • сложность реализации этих DSP библиотек.

Довести DSP до отличного качества или купить соответствующие разработки может позволить себе не каждый вендор. То же касается поддержки различных аудио- и видеокодеков.

В итоге, Java можно назвать незаслуженно покинутой разработчиками платформой для браузерных звонков.

Незаслуженно покинута она по двум причинам:
  • недостаток встроенных возможностей по работе с DSP;
  • более распространенные для Web конкурирующие платформы, которые лишены такого недостатка.

О них далее.


TOP 2 – Flash


До некоторого времени Flash был технологией для красивых интерактивных баннеров.

В 2002 году появилась в релизе версия Flash Communication Server MX 1.0 - прародитель сегодняшнего Adobe Media Server. Flash Player 6, являясь тогда продуктом компании Macromedia, умел взаимодействовать с FCS MX 1.0 и обмениваться с сервером аудиопотоками. Это еще раз указывает на то, что WebRTC припозднился на 10 лет, а также то, что рынок начинает закрывать свои потребности за 10 лет до появления вменяемой технологии браузерного интерактива.

В это время Flash Player 6 уже умел захватывать аудио и жать его в NellyMoser и видео - в Sorenson Spark. Java в это время была слабо представлена в веб и Flash Player 6 в связке с сервером претендовали на мировое господство в области web-стриминга. Позже появились Red5, Wowza, но это немного другая история.

В качестве транспорта для аудио и видео в Flash Player 6 использовался протокол RTMP, который сегодня имеет открытую спецификацию, опубликованную Adobe.

Flash Player 6 в связке с сервером стал платформой для браузерных звонков, обладающей следующими функциями:
  • NellyMoser, Sorenson spark;
  • RTMP.

До полноценного браузерного VoIP тогда было еще очень далеко. AEC (Acoustic Echo Cancellation) в тот период, наверное, даже не было в планах. Но платформа делала свое дело и передавала звук и видео от одного плеера к другому через сервер.

Все, кто работают с VoIP, рано или поздно сталкиваются с задержкой. Когда разработчик впервые тестирует написанное им VoIP приложение, он не обращает внимания на задержку: звук есть, картинка есть - и хорошо. Первыми задержку замечают пользователи и пишут репорты типа: «I say "one" then Bob says "two" and it seems it takes about 5 seconds. Why?» Потом уже два разработчика начинают тестировать звук и не понимают, куда пропали эти 5 секунд, ведь у них сервер Xeon на 100500 ядер и он не может тормозить.

Задержка была в связке Flash Player 6 + Flash Communication Server MX 1.0, а также осталась  в  следующих версиях сервера, включая последнюю Adobe Media Server, с ней безуспешно боролись на Wowza и Red5. Причина, конечно, проста и известна каждому VoIP разработчику: RTMP протокол работает поверх TCP, а потому не приспособлен для полноценного VoIP. Сохранить пакеты любой ценой – это не тот случай, когда дело касается передачи звука либо видео. Но это главная задача TCP протокола: сохраняем пакеты и получаем задержку. Все просто.

Отсутствие полноценного UDP транспорта сделало невозможным развитие интерактивных сервисов. Например, если участник вебинара хочет пообщаться face-to-face с ведущим, у него не всегда получится это сделать нормально. Все в значительной степени зависит от качества сети и потерь. В результате на базе RTMP развивались, в основном, video on demand сервисы, или live video, или вебинары с одним ведущим, где задержка не так важна.

Кстати, здесь вопрос к Macromedia: почему они не сделали audio и video стриминг по UDP. Это бы значительно упростило жизнь всем разработчикам и конечным пользователям. Очевидно, что VoIP функция браузера была на переферии и над ней никто особо не задумывался, а для интерактива с данными (sharedobjects, callbacks итд) TCP подходит оптимально.

Ситуацию с UDP в Flash Player сдвинула компания Adobe, когда в версии плеера 10 ввели поддержку нового протокола RTMFP и эхоподавление. В 11 версии Flash Player добавили поддержку кодеков G.711 и H.264. В AS3 API так же имеются упоминания про Adaptive Jitter Buffer для G.711 и Speex.

VoIP возможности Flash Player 11:
  • Nelly Moser, Speex, G.711, Sorenson Spark, H.264;
  • RTMP, RTMFP;
  • AEC;
  • Adaptive Jitter Buffer;
  • AES шифрование.

Благодаря этим нововведениям, Flash Player имеет практически все необходимое, чтобы стать VoIP платформой №1 для браузера: шифрование AES защищает трафик между браузером и сервером от посторонних;  AEC и Jitter Buffer обеспечивают качество воспроизведения звука; новые кодеки совместимы с традиционным VoIP, а RTMFP протокол работает по UDP. Не хватает AGC (Automatic Gain Control). Его отсутствие не смертельно, но неприятно для тех, кто понимает пользу этой функции для VoIP и не понимает, почему её до сих пор нет. Помогает перенос AGC-фильтра на сторону сервера.

Еще одна маленькая неприятность от Adobe - невозможность во Flash Player нормально проиграть H.264 поток, закодированный для передачи по RTP. В багтрекере Adobe cуществует "by design" баг, который накладывает ограничение 1 NALU per video frame. Это ограничение отрубает все H.264 кодеры, которые дают поток, совместимый с RTP. В результате приходится применять транскодинг, что в свою очередь вызывает избыточное потребление ресурсов CPU, которого в принципе хотелось бы избежать.

Flash RTMFP основан на UDP и довольно прилично передает звук. Но и здесь не обошлось без сюрпризов. В доках Adobe AS3 сказано, что RTMFP для аудио и видео поддерживает три режима: надежная доставка (reliable), частично-надежная доставка (partially reliable), ненадежная доставка (unreliable). В этих же доках есть только два флага для audioReliable и videoReliable: true, false. False описывается как режим частичной доставки (partially reliable). В итоге, получается, что ненадежная доставка (unreliable) пропала, а для передачи звука она наиболее важна.

Частичная доставка – это TCP подобные ретрансмиты, которые  происходят очень ограниченное время, но и этого хватает, чтобы испортить звук на нестабильной сети. Такие ретрансмиты вызывают джиттер, который портит поток. Jitter buffer на принимающей стороне в данном случае не помогает, т.к. идет очень большой разброс. Решением является переход к ненадежной доставке (unreliable) звука. В Flash Player API нет возможностей её включить, и приходится добавлять её на уровне протокола на серверной стороне.

Например, в WebRTC - Flash RTMFP SIP Gateway Flashphoner Web Call Server реализован хак на уровне протокола, который позволяет полностью исключить ретрансмиты в RTMFP и обеспечить unreliable доставку. Это в разы повышает устойчивость потока к потерям и лагам сети.  Можно получить разборчивый Speex поток до 12% потерь в сети. Тот же поток заметно рвется в случае частичной доставки(partially reliable) причем  рвется на тестах с Adobe Flash Media Gateway, несмотря на то что эта часть Adobe Media Server должна по задумке являться эталонной реализацией RTMFP протокола.

Плюсы Flash:
  • самый широкий охват браузеров;
  • привычная технология для разработчиков - Flex/AS3;
  • качественная VoIP передача аудио и видео.


Минусы Flash:
  • требует промежуточного сервера (не поддерживает открытые UDP протоколы, такие как RTP/SRTP);
  • относительно медленное улучшение VoIP части разработчиком (Adobe): отсутствие AGC, H.264 1 NALU per frame problem.

Кстати, что мешает разработчикам Flash Player внедрить WebRTC стек?



TOP 1 – WebRTC


И наконец, любимец публики, зомбирующая разработчиков, кошмарящая телекомов и  активно обсуждаемая технология WebRTC. Рынок живет ожиданиями, а в ожиданиях сегодня доминирует WebRTC.

На текущий момент WebRTC присутствует в трех распространенных браузерах в состоянии production:
  • Google Chrome;
  • Mozilla Firefox;
  • Mozilla Firefox mobile.

А также  в двух браузерах в состоянии beta:
  • Google Chrome Beta Mobile;
  • Яндекс Браузер.

Яндекс Браузер не проверяли, но по информации в сети, он не всегда корректно работает с WebRTC, поэтому мы поставили его в beta в нашем списке.

Даже в Chrome браузере WebRTC продолжает оставаться недоработанной, хотя уже прошло немало времени после релиза. Простые вещи работают, но когда дело доходит до смены состояния сессии по SDP (аналог re-INVITE в SIP) или при других нетривиальных действиях, появляются разные сюрпризы, которые сильно огорчают.

Однако это не мешает WebRTC завоевывать все новые умы и определять вектор развития VoIP и вообще интерактивных технологий в Web. И это не удивительно по двум причинам:
  • WebRTC поддерживается гигантами индустрии;
  • WebRTC имеет действительно удачную и продуманную архитектуру, избавленную от ошибок и недостатков, выявленных в браузерных плагинах, которые существовали до неё.

На технологической начинке WebRTC хотелось бы остановиться отдельно, это:

SRTP, DTLS, ICE, STUN, AEC, AGC, Adaptive Jitter Buffer, Opus, VP8

Выглядит так, как будто в браузер встроили софтфон. Не хватает только поддержки SIP.

Действительно, набор используемых в WebRTC технологий  больше похож на VoIP SDK. SRTP и DTLS обеспечивает защиту трафика между WebRTC узлами. ICE и STUN помогают преодолеть NAT, выставив с обеих сторон кандидатов для созвона в виде простых пар host:port. AEC, AGC и Jitter Buffer работают для того чтобы сделать аудио и видео качественным – без лагов и задержек. Кодеки Opus и VP8 хорошо подходят для глобального Интернета, где битрейт до конечного пользователя может легко падать до очень низких значений вопреки обещаниям провайдеров про каналы в 100Mbps.

Несколько омрачает картину отсутствие поддержки WebRTC в других браузерах, таких как IE, Safari, Opera и т.д. К недостаткам еще можно отнести несовместимость с традиционным VoIP оборудованием. Например, производители SIP/VoIP продуктов, коих великое множество, были бы очень признательны поддержке обычных SIP/RTP протоколов и кодеков для совместимости с миллионами устройств.

Здесь стоит упомянуть, что WebRTC изначально задумана как peer-to-peer между браузерами и ориентирована на шифрованный SRTP трафик. Скорее всего, именно поэтому VoIP вендорам, которые обмениваются стандартными RTP потоками, придётся внедрять у себя WebRTC совместимый транспорт и кодеки.

Хотя и здесь не все так плохо. Существуют шлюзы для обеспечения такого рода совместимости. Например   WebRTC SIP Gateway Flashphoner Web Call Server 3 является шлюзом, который может соединить WebRTC клиента и стандартное SIP/RTP устройство будь то VoIP свитч или GSM шлюз, работающий по SIP. Таким образом,  данная проблема вполне решаема путем ввода промежуточного ПО.

Преимущества и недостатки WebRTC достаточно прозрачны:

Плюсы WebRTC:
  • полноценное VoIP в браузере

Минусы WebRTC:
  • недостаточно поддерживающих браузеров
  • отсутствие RFC (Cпецификации находятся в draft-ах и меняются, хотя нужно признать, что по сравнению с тем, что было год назад,  сейчас все более-менее стабильно).
  • отсутствие совместимости с традиционным VoIP (by design).

Ожидания и ресурсы, стоящие за WebRTC, с лихвой перекрывают текущие минусы, поэтому смело отдаем ей законное первое место TOP1 в списке браузерных технологий для VoIP.

Если же вспомнить, что остальные описанные здесь браузерные технологии Java и Flash – это  плагины (хоть и предустановленные в большинстве браузеров), то выходит, что WebRTC – это  единственная чисто-браузерная технология, которой в этом отношении нет аналогов.

Итак, мы закончили разбор трех технологий для web звонков, обобщим все описанное выше в виде следующих таблиц:

VoIP фильтры




Сетевые протоколы и спецификации




Аудио кодеки




Видео кодеки




Поддерживаемые браузеры




Некоторые пояснения:
  1. Все возможности Java клиента отмечены символом \\*. Это означает, что все вышеописанное может быть теоретически реализовано на Java. Вопрос в том сколько времени это займет, как хорошо это будет работать и сколько будет весить исполняемый файл со всеми библиотеками.
  2. С символами "плюс", "минус" и "вопрос" все должно быть понятно.
  3. В последний столбец таблицы было решено добавить для сравнения один из продвинутых VoIP софтфонов "традиционной" VoIP телефонии - Bria.

Ну вот и пришло время заняться подсчетом.

Некоторые функции, конечно, могут быть даже близко не равны по весу, но если считать в попугаях получается следующая картина:

Первое место в этой гонке VoIP технологий и коммуникационных протоколов занимает VoIP софтфон - 54% (21 попугай из 39). На втором месте WebRTC - 44% (17 попугаев из 39) и Flash, который идет за WebRTC с 41% (16 попугаев из 39).

В окончании, хотелось бы поставить вопрос: если мы строим облако для web-звонков с выходом на SIP/VoIP/PSTN, на чем мы будем это облако строить, какие материалы использовать?

Отвечая на этот вопрос, придется затронуть еще пару моментов. Первый из них связан с мобильными устройствами, второй - с проходимостью через брандмауэры.

Не секрет, что сейчас важна поддержка Android, iOS SDK и кроссплатформенность. С мобильными устройствами все более или менее понятно. Есть несколько вариантов:
  1. Adobe Air – тот же Flash с поддержкой тех же RTMP/RTMFP протоколов. Серьезный недостаток – нет эхоподавления. Преимущество – кроссплатформенность. Разворачиваем один и тот же код на Android и IOS.
  2. Браузер с поддержкой WebRTC. Недостаток – не очень удобно. Нативное мобильное приложение будет лучше в look and feel терминах.
  3. Портировать WebRTC код под IOS и Android. Недостаток – не кроссплатформенно и нетривиально.
  4. Использовать стандартный VoIP SDK с поддержкой SIP/RTP и портировать на IOS и Android. Недостаток – не  кроссплатформенно, несовместимо с WebRTC. Преимущества – совместимо  с традиционным VoIP оборудованием.

Теперь про брандмауэры(firewalls). Как звук пройдет через брандмауэр, если UDP на нем отключен? Ответ: для этого потребуется переключение на TCP транспорт. Подойдет например Flash RTMP.

А если весь трафик организации идет через proxy, и админ закрыл весь не HTTP трафик? Тогда придется использовать HTTP туннелированные, например RTMPT, что, кстати, не лучшим образом скажется на задержке.

В итоге получаем супероблако для VoIP звонков такого вида: для передачи аудио и видео используем WebRTC, RTMFP, RTMP, RTMPT, Java Applet. Для интеграции со стандартным VoIP используем SIP, RTP. Для мобильных устройств: Adobe Air, WebRTC, SIP/RTP клиентов.

Перечисленные технологии покроют большинство браузеров и мобильных устройств, хотя схема определенно избыточна.

Что из нее убрать, чтобы облегчить – решать вам.

Материал подготовлен при участии специалистов компании Flashphoner

Звонок с сайта на платформе Flashphoner Web Call Server 3.0
VoIP


В чем особенность виджета «Звонок с сайта», представленного в базовой комплектации профессиональной платформы Flashphoner Web Call Server? Как протестировать качество связи? Какие этапы интеграции с сайтом программного обеспечения? Ответы на эти вопросы представлены в кратком обзоре одного из виджетов программного обеспечения Flashphoner.

Виджет «Звонок с сайта» компании Flashphoner


В последние несколько лет виджет «Звонок с сайта» уже успел стать неотъемлемой частью сайтов и электронной коммерции. Бесплатный звонок с сайта для клиентов в отдел продаж, сервис, службу доставки из любой точки мира позволяет сократить время на принятие решения в 1,5 раза и увеличить объем продаж практически в 2 раза.
Компания Flashphoner уже более 4 лет работает над созданием профессионального программного обеспечения для создания возможности браузерных медиа коммуникаций в режиме реального времени. Виджет «Звонок с сайта» или «Clik to call» входит в базовый пакет программной платформы Web Call Server и имеет открытый код со стороны клиентской части, что позволяет использовать как базовый внешний вид виджета, так и применять корпоративные стандарты. Особенности платформы Flashphoner WCS позволяют также настраивать видео-звонки на SIP-устройства, встраивать в сайт «web-phone», общаться с посетителями через текстовый онлайн-чат и многое другое.
К особенностям можно отнести также то, что виджет можно легко встроить в корпоративную IVR, что достаточно удобно для компаний с разветвленной структурой продаж, предоставления консультаций и сервисных услуг, или имеющих географически распределенную структуру организаций. Настроить переадресацию звонков с сайта можно на любой тип аудио-, видео- телекоммуникационных устройств, к которым относятся PSTN и GSM телефоны, SIP-устройства и софтфоны, в том числе прямо в браузере. Таким образом, нажав кнопку «Звонок с сайта» на вашем сайте, клиент сможет бесплатно связаться с нужным отделом или даже сотрудником компании. При этом базовая безлимитная лицензия не имеет ограничений на количество линий. Web Call Server устанавливается с резервом до 300 коннектов. При большем объеме одновременных звонков через сервер специалисты Flashphoner рекомендуют устанавливать дополнительный сервер для распределения нагрузки.

Тестовая площадка Flashphoner Web Call Server


Для того, что попробовать качество аудио- и видеосвязи, есть несколько возможностей:
1. Первоначально можно воспользоваться тестовой онлайн-площадкой. В тестовом варианте уже введены все базовые настройки виджета, которые выводят звонок на служебное голосовое приветствие, настроенное по внутреннему номеру АТС разработчика.

medium.gif
Рис. 1 – базовая кнопка «Call me» платформы Flashphoner Web Call Server

Для того чтобы звонок прошел успешно после нажатия кнопки «Call me», откройте доступ Flash к вашему микрофону и видеокамере, выбрав кнопку «Разрешить», как показано на рис. 2.
medium.gif
Рис. 2 Доступ к камере и микрофону при использовании виджета «Звонок с сайта»

Протестировать качество связи, предоставляемое продуктами стандартного пакета Flashphoner Web Call Server можно на тестовой площадке с браузерным веб-телефоном. После введения SIP-настроек имеющегося аккаунта, зарегистрированного у VoIP провайдера, можно совершить 3 основных типа звонков (Browser↔Browser, Browser↔SIP, Browser↔GSM/PSTN).
2. Для более детального ознакомления с возможностями платформы можно скачать и установить Flashphoner WCS в полнофункциональной конфигурации продукта по ознакомительной лицензии на 30 дней.
3. Хорошим базовым вариантом для тестирования разработчиками комплексных решений контакт-центров и VoIP-провайдеров станет версия Developer, которая является бесплатной полнофункциональной версией продукта с ограничением по количеству коннектов.
Итак, чтобы воспользоваться наиболее простым вариантом тестирования, просто перейдите по адресу тестовой онлайн-площадки и введите настройки имеющегося SIP-аккаунта так, как показано на рис. 3.
medium.gif
Рис. 3 – демо-софтфон Flashphoner

Login: имя зарегистрированного SIP аккаунта
Password: ****** (пароль аккаунта, зарегистрированного у VoIP-провайдера)
Domain: sipnet.ru (вариант взят для примера. Изначально предоставляется VoIP-провайдером)
Port: 5060
Остальные поля заполняются автоматически.


После введения настроек можно совершать тестовые звонки типа Flash↔GSM/PSTN, для тестирования звонков по типам Flash↔Flash и Flash↔SIP понадобится второй зарегистрированный аккаунт у VoIP-провайдера, настройки которого вводятся аналогичным образом в веб-телефон или софтфон, установленный на компьютерном устройстве. Звонки между аккаунтами VoIP-провайдера совершаются по имеющемуся логину или внутреннему номеру.
Также при звонках для возможности соединения не забудьте дать разрешение на использование микрофона и веб-камеры.

Внедрение «Clik-to-call» в корпоративный сайт


Чтобы приступить к внедрению виджета «Clik2call» в выбранный сайт, необходимо совершить несколько подготовительных действий, которые представлены в виде 3-х этапов:
1. Скачивание и установка JDK.
2. Скачивание, установка серверной части платформы.
3. Скачивание, установка и настройка клиентской части ПО.
Развернутую пошаговую инструкцию платформы можно посмотреть на сайте разработчика.

Для того, чтобы внедрить виджет «Звонок с сайта» на сайт, введем настройки на стороне сервера Flashphoner WCS.
Путь к файлам на сервере Flashphoner следующий: /usr/local/FlashphonerWebCallServer/conf/

Шаг 1. Введите логин, пароль и SIP proxy, настройки полученные от VoIP-провайдера при регистрации аккаунта – account.xml.

< root registered="true" login="1000" authenticationName="1000" password="1000" outboundProxy="10.10.10.10" domain="10.10.10.10" port="5060" visibleName="1000"/ >
Для соединения, как правило, используется 5060 порт.

Шаг 2. Укажите внутренний номер корпоративной АТС – callee.xml.
< callee account="5002"/ >

В примере используется платформа для АТС – Asterisk, на которой уже сконфигурированы несколько внутренних номеров, из них: 5002 – голосовое меню, 5001 – музыкальная заставка, 5003 – echo и т.д. Изменить систему внутренних номеров согласно корпоративным требованиям можно самостоятельно.

Шаг 3. Настройте автологин виджета «Звонок с сайта»
Для того, чтобы виджет связать с сервером, необходимо ввести настройки в файл click2call-test-1.htm
< input id="auto_login_token" type="hidden" value="abcd"/ >

Элементы id=token и value=abcd, в соответствии с которыми сервер определяет, какой SIP-аккаунт следует автологинить при запуске виджета «Звонок с сайта».
После этого перезапустите Flashphoner WCS для сохранения изменений с помощью команд ./shutdown.sh и ./startup.sh.

Шаг 4. Введите дополнительные настройки в файл flashLoader.js (папка /var/www/html/WCS-2.1/286/js). Раскомментируйте следующие строки скрипта:
$(function() {
flashvars.token = $("#auto_login_token").val();
});


Шаг 5. Встройте виджет «Звонок с сайта» в ваш сайт
Теперь можно добавить кнопку виджета «Звонок с сайта» , имеющего базовый дизайн, представленный в комплектации Flashphoner WCS или измененный по корпоративным стандартам. Для этого вставьте в страницу сайта следующий код виджета:

< div style="background: -webkit-gradient(linear, left top, left bottom, from(#3b3), to(#0a0)); box-shadow: 0px 1px 0px #666, inset 0px 1px 0px #0f0; color: #004400;
text-shadow: 0px 1px 0px #0d0; border-radius: 12px; position: absolute; height: 24px; font: 13px Lucida Grande, Lucida Sans Unicode; border: 1px solid #111;
text-align: center; cursor: pointer; line-height: 24px; display: block; padding: 0 20px;"
onclick='window.open("click2call-test-1.html","_blank","width=340,height=260,resizable=no,toolbar=no,menubar=no,location=no,status=no,scrollbar=no")'>
CALL ME


Первый раз на сайте?

askdev.ru — это социальный сайт вопросов и ответов для IT-специалистов: программистов, веб-дизайнеров, системных администраторов.
о сайте » регистрация »

1

VoIP

SIP, OpenSer, Sems, RtpProxy, Asterisk и т.д.

Присоединяйтесь!

Популярные Теги

voip