В этой статье я расскажу о том, какие существуют методы реализации голосовой связи для web-проектов.
Статья носит обзорный характер и ориентирована на самый широкий круг читателей. Однако, любой желающий найдет все необходимые ссылки для углубления в суть вопроса.
Будут рассмотрены следующие задачи:
Для начала стоит понять, какие технологии имеются в нашем распоряжении. Если быть реалистами, то по сути единственным вариантом является использование Flash. Да, есть другие технологии, но, к сожалению, все они значительно менее распространены. В то время как Flash установлен почти у всех.
Чем хорош Flash, так это удобной работой с потоковым аудио-видео. Есть два главных метода работы с аудиопотоком во Flash-приложениях:
Есть также надежда, что в ближайшее время Flash-серверы позволят использовать протокол UDP для связи с клиентскими приложениями. В этом случае исчезнут многие недостатки первого решения. Напомню, что протокол TCP гарантирует доставку данных, а UDP — нет. Для передачи голосового трафика в реальном времени не требуется точность данных, требуется гарантированное время доставки и устойчивость к периодическим сбоям канала передачи. Вот почему протокол UDP в данном случае предпочтителен.
Перейдем к более конкретным вещам.
С точки зрения разработчика, два варианта реализации передачи аудио (с ретрансляцией через сервер и без) не сильно отличаются. В обоих случаях требуется внешний сервер. Однако, в случае с P2P сервер выполняет лишь вспомогательную роль при установлении соединения. Весь голосовой трафик идет напрямую от клиента к клиенту. Сервер для установления P2P-соединения называется Stratus. В скором времени его функциональность будет встроена в Flash Media Server (и, видимо, Red5). Сейчас единственный вариант — воспользоваться общедоступным beta-сервисом от Adobe.
Отличная статья по использованию нового P2P-протокола — здесь.
Пример реализации — тут.
При использовании ретранслирующего сервера задача является стандартной для Flash-среды. Что в этом случае, что в случае P2P основная идея заключается в том, что каждый из собеседников публикует выходящий аудиопоток и подписывается на входящий. Данные передаются с использованием протокола RTMP (RTMFP, в случае P2P).
Одна из ключевых проблем при реализации голосовой связи один на один — сигнализация пользователей о поступающих звонках. Если пользователь является инициатором звонка, он знает, в какой момент ему инициировать передачу и прием голосового трафика. Что касается пользователя, которому звонят, требуется какой-то способ известить его об этом. Как решать эту задачу — вопрос конкретного приложения.
В случае с голосовой связью один на один достаточно просто реализовать схему, которая выше называлась оптимальной. То есть использовать P2P, когда это возможно, иначе — медиа-сервер.
При организации конференций практически ничего не меняется. Только теперь на аудиопоток любого пользователя подписываются сразу все участники конференции.
Опять же, возможна реализация как через сервер, так и используя P2P. Но в данном случае вероятность, что P2P не будет функционировать, выше по простой причине, что участников обмена здесь уже не два, а больше: у кого-нибудь да не заработает.
Пожалуй, самая интересная тема из рассматриваемых. Для решения задачи используется SIP-шлюз любого оператора IP-телефонии. Схема работы здесь следующая:
Голосовая связь пользователей один на один с использованием P2P-протокола реализована в приложении для социальной сети ВКонтакте.Онлайн, автором которого являюсь я.
Также была реализована техническая платформа для совершения из приложения звонков на стационарные и мобильные телефоны через SIP-шлюз. Однако, в публичный доступ технология не была запущена.
Пример реализации связки Flash <-> SIP: проект flaphone.
У описанных технологий есть целый ряд применений. Например, использование в рамках движка CMS-системы или организация службы телефонной поддержки на сайте компании, интернет-магазина.
Статья носит обзорный характер и ориентирована на самый широкий круг читателей. Однако, любой желающий найдет все необходимые ссылки для углубления в суть вопроса.
Будут рассмотрены следующие задачи:
- Голосовая связь один на один между пользователями сайта.
- Голосовая конференция, то есть разговор более чем 2 собеседников.
- Звонки на стационарные и мобильные телефоны из браузера.
Введение
Для начала стоит понять, какие технологии имеются в нашем распоряжении. Если быть реалистами, то по сути единственным вариантом является использование 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 версии.
Есть также надежда, что в ближайшее время Flash-серверы позволят использовать протокол UDP для связи с клиентскими приложениями. В этом случае исчезнут многие недостатки первого решения. Напомню, что протокол TCP гарантирует доставку данных, а UDP — нет. Для передачи голосового трафика в реальном времени не требуется точность данных, требуется гарантированное время доставки и устойчивость к периодическим сбоям канала передачи. Вот почему протокол UDP в данном случае предпочтителен.
Перейдем к более конкретным вещам.
Голосовая связь один на один
С точки зрения разработчика, два варианта реализации передачи аудио (с ретрансляцией через сервер и без) не сильно отличаются. В обоих случаях требуется внешний сервер. Однако, в случае с P2P сервер выполняет лишь вспомогательную роль при установлении соединения. Весь голосовой трафик идет напрямую от клиента к клиенту. Сервер для установления P2P-соединения называется Stratus. В скором времени его функциональность будет встроена в Flash Media Server (и, видимо, Red5). Сейчас единственный вариант — воспользоваться общедоступным beta-сервисом от Adobe.
Отличная статья по использованию нового P2P-протокола — здесь.
Пример реализации — тут.
При использовании ретранслирующего сервера задача является стандартной для Flash-среды. Что в этом случае, что в случае P2P основная идея заключается в том, что каждый из собеседников публикует выходящий аудиопоток и подписывается на входящий. Данные передаются с использованием протокола RTMP (RTMFP, в случае P2P).
Одна из ключевых проблем при реализации голосовой связи один на один — сигнализация пользователей о поступающих звонках. Если пользователь является инициатором звонка, он знает, в какой момент ему инициировать передачу и прием голосового трафика. Что касается пользователя, которому звонят, требуется какой-то способ известить его об этом. Как решать эту задачу — вопрос конкретного приложения.
- Вариант 1. Использовать асинхронные запросы, выполняемые периодически. Например, 1 раз в секунду. В ответе на запрос должен содержаться признак, что имеется входящий звонок и надо принять решение, отвечать ли на него. Затем, настроить входящий и выходящий аудиопотоки.
- Вариант 2. Comet-архитектура, когда клиент держит постоянное подключение к серверу и получает ответ только тогда, когда произошло некоторое событие. В данном случае, входящий звонок.
В случае с голосовой связью один на один достаточно просто реализовать схему, которая выше называлась оптимальной. То есть использовать P2P, когда это возможно, иначе — медиа-сервер.
Организация конференций
При организации конференций практически ничего не меняется. Только теперь на аудиопоток любого пользователя подписываются сразу все участники конференции.
Опять же, возможна реализация как через сервер, так и используя P2P. Но в данном случае вероятность, что P2P не будет функционировать, выше по простой причине, что участников обмена здесь уже не два, а больше: у кого-нибудь да не заработает.
Звонки на стационарные и мобильные телефоны
Пожалуй, самая интересная тема из рассматриваемых. Для решения задачи используется SIP-шлюз любого оператора IP-телефонии. Схема работы здесь следующая:
- Организуется двусторонняя передача аудиоданных между клиентским Flash-приложением и медиа-сервером по протоколу RTMP.
- На стороне медиа-сервера происходит транскодирование голосового трафика. То есть перекодирование аудио из одного кодека в другой. Flash поддерживает два кодека для работы с голосом: Nellymoser и SPEEX (начиная с 10 версии).
Также медиа-сервер должен уметь работать со стеком SIP-протокола. - Таким образом, на стороне медиа-сервера строится мост: Flash Player <-> SIP.
Рабочие примеры
Голосовая связь пользователей один на один с использованием P2P-протокола реализована в приложении для социальной сети ВКонтакте.Онлайн, автором которого являюсь я.
Также была реализована техническая платформа для совершения из приложения звонков на стационарные и мобильные телефоны через SIP-шлюз. Однако, в публичный доступ технология не была запущена.
Пример реализации связки Flash <-> SIP: проект flaphone.
Применения
У описанных технологий есть целый ряд применений. Например, использование в рамках движка CMS-системы или организация службы телефонной поддержки на сайте компании, интернет-магазина.