Web-телефония. Обзор технологий
Продолжаем публикацию интересных заметок с хабрхабры...
статья от хurl=http://alexeyb.habrahabr.ru/ъalexeyb
В этой статье я расскажу о том, какие существуют методы реализации голосовой связи для web-проектов.
Статья носит обзорный характер и ориентирована на самый широкий круг читателей. Однако, любой желающий найдет все необходимые ссылки для углубления в суть вопроса.
Будут рассмотрены следующие задачи:
1. Голосовая связь один на один между пользователями сайта.
2. Голосовая конференция, то есть разговор более чем 2 собеседников.
3. Звонки на стационарные и мобильные телефоны из браузера.
Повторюсь и скажу, что все задачи решаются в рамках web-среды. Основное условие: пользователям не требуется установка дополнительного ПО, только браузер и Flash Player.
Введение
Для начала стоит понять, какие технологии имеются в нашем распоряжении. Если быть реалистами, то по сути единственным вариантом является использование Flash. Да, есть другие технологии, но, к сожалению, все они значительно менее распространены. В то время как Flash установлен почти у всех.
Чем хорош Flash, так это удобной работой с потоковым аудио-видео. Есть два главных метода работы с аудиопотоком во Flash-приложениях:
Использование медиа-сервера (media streaming server). В данном случае весь голосовой трафик проходит через сервер. В качестве сервера может выступать Flash Media Server или Red5 (open source).
Преимущества: хорошая проходимость трафика (firewall и NAT не помеха).
Недостатки: нагрузка на сервер, большее время отклика, возможность использовать только протокол TCP.
Новый P2P-протокол RTMFP, реализованный в Flash Player 10.
Преимущества: построен на базе протокола UDP, хорошее качество связи, нет нагрузки на сервер.
Недостатки: плохая проходимость через firewall и NAT (около 60% пользователей), требуется Flash Player 10 версии.
Оптимальное решение на сегодняшний день: динамически определять возможность использования P2P-протокола; использовать его, если есть возможность, иначе — использовать первый вариант.
Есть также надежда, что в ближайшее время Flash-серверы позволят использовать протокол UDP для связи с клиентскими приложениями. В этом случае исчезнут многие недостатки первого решения. Напомню, что протокол TCP гарантирует доставку данных, а UDP — нет. Для передачи голосового трафика в реальном времени не требуется точность данных, требуется гарантированное время доставки и устойчивость к периодическим сбоям канала передачи. Вот почему протокол UDP в данном случае предпочтителен.
Перейдем к более конкретным вещам.
Голосовая связь один на один
С точки зрения разработчика, два варианта реализации передачи аудио (с ретрансляцией через сервер и без) не сильно отличаются. В обоих случаях требуется внешний сервер. Однако, в случае с P2P сервер выполняет лишь вспомогательную роль при установлении соединения. Весь голосовой трафик идет напрямую от клиента к клиенту. Сервер для установления P2P-соединения называется Stratus. В скором времени его функциональность будет встроена в Flash Media Server (и, видимо, Red5). Сейчас единственный вариант — воспользоваться общедоступным beta-сервисом от Adobe.
Отличная статья по использованию нового P2P-протокола — здесь.
Пример реализации — тут.
При использовании ретранслирующего сервера задача является стандартной для Flash-среды. Что в этом случае, что в случае P2P основная идея заключается в том, что каждый из собеседников публикует выходящий аудиопоток и подписывается на входящий. Данные передаются с использованием протокола RTMP (RTMFP, в случае P2P).
Одна из ключевых проблем при реализации голосовой связи один на один — сигнализация пользователей о поступающих звонках. Если пользователь является инициатором звонка, он знает, в какой момент ему инициировать передачу и прием голосового трафика. Что касается пользователя, которому звонят, требуется какой-то способ известить его об этом. Как решать эту задачу — вопрос конкретного приложения.
Вариант 1. Использовать асинхронные запросы, выполняемые периодически. Например, 1 раз в секунду. В ответе на запрос должен содержаться признак, что имеется входящий звонок и надо принять решение, отвечать ли на него. Затем, настроить входящий и выходящий аудиопотоки.
Вариант 2. Comet-архитектура, когда клиент держит постоянное подключение к серверу и получает ответ только тогда, когда произошло некоторое событие. В данном случае, входящий звонок.
Оба варианта подразумевают использование основных средств web-разработки на стороне сервера (например, php). Хотя, в принципе, для этой задачи можно приспособить и медиа-сервер. На стороне клиента может использоваться javascript или Flash.
В случае с голосовой связью один на один достаточно просто реализовать схему, которая выше называлась оптимальной. То есть использовать P2P, когда это возможно, иначе — медиа-сервер.
Организация конференций
При организации конференций практически ничего не меняется. Только теперь на аудиопоток любого пользователя подписываются сразу все участники конференции.
Опять же, возможна реализация как через сервер, так и используя P2P. Но в данном случае вероятность, что P2P не будет функционировать, выше по простой причине, что участников обмена здесь уже не два, а больше: у кого-нибудь да не заработает.
Звонки на стационарные и мобильные телефоны
Пожалуй, самая интересная тема из рассматриваемых. Для решения задачи используется SIP-шлюз любого оператора IP-телефонии. Схема работы здесь следующая:
Организуется двусторонняя передача аудиоданных между клиентским Flash-приложением и медиа-сервером по протоколу RTMP.
На стороне медиа-сервера происходит транскодирование голосового трафика. То есть перекодирование аудио из одного кодека в другой. Flash поддерживает два кодека для работы с голосом: Nellymoser и SPEEX (начиная с 10 версии).
Также медиа-сервер должен уметь работать со стеком SIP-протокола.
Таким образом, на стороне медиа-сервера строится мост: Flash Player SIP.
Red5phone — проект с открытым исходным кодом, который реализует описанную схему. Проект достаточно сырой, но является хорошей отправной точкой.
Рабочие примеры
Голосовая связь пользователей один на один с использованием P2P-протокола реализована в приложении для социальной сети ВКонтакте.Онлайн, автором которого являюсь я.
Также была реализована техническая платформа для совершения из приложения звонков на стационарные и мобильные телефоны через SIP-шлюз. Однако, в публичный доступ технология не была запущена.
Пример реализации связки Flash SIP: проект flaphone
Применения
У описанных технологий есть целый ряд применений. Например, использование в рамках движка CMS-системы или организация службы телефонной поддержки на сайте компании, интернет-магазина.
(C) ХабраХабр.ру
КОмментарии по теме:
Flaphone — Он работает уже очень давно и хорошо, при этом позволяет позвонить еще и на Skype. Для организации службы поддержки есть CallMe-виджет, который можно размещать на своем сайте — он будет звонить куда вы ему скажите на SIP URI, Телефонный номер через SIP-оператора или на пользователя Skype. Используя Gtalk2voip гейтвей, можно звонить еще и на gtalk/yahoo/msn. Как-то так.
CallMe — это фича сервиса flaphone, вы можете получить embed-html код, как у плеера youtube, который покажет кнопку, при нажатии на которую произойдет вызов на указанный номер,SIP URI или SkypeID. Подробнее можно почитать в разделе help flaphone.
flaphone.com/help.php#callme_widget
А действии можно посмотреть здесь: innosystems.ru/index.php?id=15
CallMe — это фича сервиса flaphone, вы можете получить embed-html код, как у плеера youtube, который покажет кнопку, при нажатии на которую произойдет вызов на указанный номер,SIP URI или SkypeID. Подробнее можно почитать в разделе help flaphone.
flaphone.com/help.php#callme_widget
А действии можно посмотреть здесь: innosystems.ru/index.php?id=15
Раз такая пляска, позволю себе немного порекламировать нашу разработку: www.flash2voip.com — простой flash-based SIP телефон (с книгой контактов на сервере). Работает с SIPNET, Gizmo5 и прочими бетамаксами. Регистрации не требует, однако обязательно наличие рабочего SIP аккаунта.
В основе лежит наш GTalk2VoIP Gateway к которому мы уже год назад имплементировали модуль поддержки протокола RTMP и возможность шлюзовать в SIP и H.323, но вот приложение сделали совсем недавно.
В основе лежит наш GTalk2VoIP Gateway к которому мы уже год назад имплементировали модуль поддержки протокола RTMP и возможность шлюзовать в SIP и H.323, но вот приложение сделали совсем недавно.
0 Комментарии