При тестовом звонке по дефолтным параметрам, я так понял, подразумевается, что голос запишется и потом воспроизведется (как в скайпе тестовый звонок).
Так вот, несколько попыток, ни одна не завершилась успехом, я все слышу, после сигнала проговариваю, после следующего сигнала, в ответ тишина. проверил в 3-х браузерах — Opera,FF,Chrome — результат идентичный.
Что я делаю ни так?
В момент начала звонка в «контейнере» появляется диалог «разрешить использование микрофона». Вы там отметили «разрешить»? Иначе записать ничего не получится.
>Во-первых, перспектива его поддержки в Internet Explorer весьма туманна
Я так понял, что тут решается конкретная задача запустить звонилку на всех браузерах в Windows.
Клиентская часть разрабатывалась в основном на Mac OS X, так что все должно работать.
По поводу Linux: я только что загрузил в Parallels Desktop Ubuntu 10.4, поставил на нее Flash Player 11.0.1.152 и потестировал — заработало, но только после того, как я в системных настройках звука выкрутил уровень микрофона почти на максимум.
К сожалению, на единственной досупной нам десктопной линуксовой машине (виртуальной) все работает. Но судя по количеству коментариев на эту тему, проблема с Линуксом действительно есть. Мы постараемся разобраться.
Да, весь трафик идет через наши сервера, иначе на сегодняшний день невозможно.
Мы проводили нагрузочное тестирование, держим где-то 400-500 одновременных звонков на сервер. И серверов у нас несколько. Архитектура такая, что параллелить можно бесконечно, так что будем доставлять по мере необходимости. Причем ставить сервера будем именно там, где сервис используют, чтобы минимизировать сетевые задержки.
Совсем не поэтому, просто на текущий момент по-другому нельзя. Но если например убрать требование, чтобы все работало без установки дополнительных плагинов, то вполне возможно посылать SIP-траффик напрямую из браузера в ваш сервис.
Такие технологии у нас тоже есть. Вы можете зайти на talkpad.ru, установить нативный плагин, и затем позвонить на свой SIP-сервер. Вы сможете увидеть, что RTP траффик идет напрямую. Просто такое решение явно не подходит для открытого веба. Для внутрикорпоративного сервиса — вполне можно.
Это из за проблем с безопасностью?
Ну а если Stip TLS + Zrtp?
Просто дополнительные сервера, как то печально, просто провайдеры корпят над системами с высокой доступностью а тут выходит ещё надо добавить серверов.
Поясню еще раз. В требованиях есть такая строчка: «поддержка браузерами минимум у 95% пользователей без инсталляции чего-либо». Это означает что мы можем использовать только стандартные методы HTML5 + Javascript, либо очень популярные плагины, которым является Flash.
HTML5 + Javascript на сегодняшний день не могут даже банально снимать звук с микрофона, поэтому отпадают. Flash может, но Flash-приложениям не дают прямого доступа к Socket API, поэтому нельзя просто открыть сокет и посылать туда данные. Таким образом протоколы SIP и RTP отпадают (а также их секъюрные варианты). Приходится использовать то, что доступно Flash, а именно абстракцию над протоколом UDP, которая называется RTMFP. Ну и на серверной стороне уже конвертируем в стандартные протоколы.
transcoding — это преобразование из одного кодека в другой. Имеется ввиду что теперь Flash поддерживает G.711 и H.264 и не надо Speex и Sorenson Spark в них преобразовывать, что значительно экономит CPU сервера.
Однако трафик через сервер пропускать все равно надо. И этот проект это тоже делает, отсюда «Best Flash-to-SIP Gateway for Flash-VoIP communications».
Flashphoner.com (как и другие похожие проекты) использует протокол RTMP (смотрите title их главной страницы), который реализован поверх TCP и больше подходит для потокового вещания чем для разговоров в реальном времени.
Мы, с другой стороны, используем RTMFP, который работает поверх UDP и позволяет добиться нормального качества связи.
Есть такая вещь как WebRTC, которая позволит все что надо снимать без Flash, кстати, вполне работает уже в специализированных браузерах, еще чуть-чуть и будет доступно простым смертным вместе с Хромом
Да только там написано неправильно, WebRTC позволяет использовать любой протокол сигнализации, в том числе и SIP. Не знаете — не пишите, чтоб не вводить людей в заблуждение.
Давайте тогда будем совсем честными с людьми. WebRTC вообще не определяет сигнальный протокол, и предполагается, что сигнализация будет делаться Javascript-средствами WebSocket или AJAX long-polling (или того хуже). Это означает, что напрямую, без серверной прослойки, подключиться к обычному SIP-серверу на сигнальном уровне не получится.
В то же время RTP поддерживается из коробки. Однако смотрим на кодеки: iLBC, iSAC и VP8. Это означает, что для взаимодействия с обычной IP телефонией голосовые и видео данные также придется прогонять через сервер и транскодить в более общепринятые.
Все это в совокупности означает, что WebRTC поддерживает SIP ничуть не лучше, чем Flash. Разве что, это вещь сильно более открытая и серверную часть сильно легче написать.
Пробовали. Долгое время на talkpad.ru висела именно связка siprtmp + VideoIO. Все работает, пока есть идеальное сетевое соединение между пользователем и сервером с siprtmp. Но как только есть хоть малейшие проблемы с сетью, проявляется сущность протокола RTMP — он начинает «захлебываться», постоянно запрашивая ретрансмиты потерянных пакетов.
Это и побудило задуматься над поиском альтернативы. Реализаций более подходящего для VoIP протокола RTMFP, которую просто можно взять и использовать, сейчас нет, поэтому написали свою. Результат понравился, и поэтому решили предложить это решение всем желающим через облачное API.
Как я уже написал, адобовскими продуктами сделать подобный функционал вообще нельзя. Последний Flash Media Server Enterprice Edition конечно поддерживает RTMFP, но только для нужд P2P. Направить такой поток в какой-нибудь Flash Media Gateway для конвертации в SIP не представляется возможным.
Если вам удалось заставить связку FMS+FMG работать, то молодцы. Хотя тогда непонятно, зачем вы писали свою реализацию RTMFP.
То, что у Zingaya есть RTMFP, мы знаем. В конце статьи я как раз рассмотрел пример как сделать базовый функционал Zingaya-подобного click2call сервиса на базе нашего API.
Ухх, вспомнил, как-то надо было поднять RTMP сервак и из всех возможных вариантов выбор пал на red5, т.к. он бесплатный. И так как я не сисадмин и даже не программист по образованию, то пришлось мне с ним помучаться, стоооооолько настроек было связано с этим расширением у скрипта для которого оно требовалось.
Ну и ресурсов кушало не хило, полуторагигагерцовый проц, гиг оперативы и 10Мб/с канал. Скрипт держал не больше 10 пользователей одновременно, если подключалось больше, то кто-то отваливался, кого-то начинало сильно лагать, кто-то вообще не мог подключиться.
Смотрели по логам. При вашем звонке уходит SIP INVITE (инициирование нового вызова) на 188.94.208.62:5060, а в ответ тишина. Поэтому звонок и не проходит.
Если объемы большие, то конечно возможно, пишите в личку, договоримся.
RTCKit: API голосового и видео общения в браузере