Звонки в случае обоих протоколов идут через сервер, к сожалению это необходимо, так как даже Flash не умеет отсылать и принимать прозвольные UDP пакеты.
К сожалению Richard_Ferlow отчасти прав: звонки из браузера действительно сейчас у многих людей вызывают непонимание. Но надежда есть: google уже давно сделал звонки из браузера в GMail, Facebook сделала видео-чат прямо в веб-интерфейсе. ВКонтакте сейчас активно тестирует аналогичный видео-чат. Возможно все это сделает среднего пользователя более привычным к таким вещам.
Скажу так: в случае идеального сетевого соединения разница между двумя протоколами не так существенна. Но на практике такого почти не бывает. Решение на основе RTMFP переживет гораздо больший процент потерянных пакетов в сети без существенной потери качества.
Этот сервис использует протокол RTMP, а не RTMFP. Разница существенная, подробности тут. Ну и принимать звонки по SIP понравится далеко не всем, хотя такая возможность у нашей платформы тоже есть.
Технологии примерно одинаковые, и мы и Зингайа используем протокол RTMFP. Разница в том, что мы делаем платформу, и для нас click-to-call виджет — это просто демонстрация возможностей, в то время как для них это основной бизнес. Ну и бесплатных 150 минут у них (на данный момент) нет.
Как я уже упоминул, Гугл обещает нам поддержку WebRTC в Google Chrome «in early 2012». С помощью этой технологии можно будет обойтись и без Flash. Остальные браузеры (IE конечно под вопросом) тоже скорее всего подтянутся со временем.
Попробовал позвонить. К сожалению качество связи оставляет желать лучшего, причем дело не во временных недоработках. При звонках из браузера на стационарные и сотовые они используют протокол RTMP, который работает поверх TCP, со всеми вытекающими последствиями (подробнее тут).
Есть российский аналог — talkpad.ru, все то же самое, только с использованием более нового протокола RTMFP на UDP, ну и качество соответствующее.
Смотрели по логам. При вашем звонке уходит SIP INVITE (инициирование нового вызова) на 188.94.208.62:5060, а в ответ тишина. Поэтому звонок и не проходит.
Если объемы большие, то конечно возможно, пишите в личку, договоримся.
Давайте тогда будем совсем честными с людьми. WebRTC вообще не определяет сигнальный протокол, и предполагается, что сигнализация будет делаться Javascript-средствами WebSocket или AJAX long-polling (или того хуже). Это означает, что напрямую, без серверной прослойки, подключиться к обычному SIP-серверу на сигнальном уровне не получится.
В то же время RTP поддерживается из коробки. Однако смотрим на кодеки: iLBC, iSAC и VP8. Это означает, что для взаимодействия с обычной IP телефонией голосовые и видео данные также придется прогонять через сервер и транскодить в более общепринятые.
Все это в совокупности означает, что WebRTC поддерживает SIP ничуть не лучше, чем Flash. Разве что, это вещь сильно более открытая и серверную часть сильно легче написать.
Если вам удалось заставить связку FMS+FMG работать, то молодцы. Хотя тогда непонятно, зачем вы писали свою реализацию RTMFP.
То, что у Zingaya есть RTMFP, мы знаем. В конце статьи я как раз рассмотрел пример как сделать базовый функционал Zingaya-подобного click2call сервиса на базе нашего API.
Как я уже написал, адобовскими продуктами сделать подобный функционал вообще нельзя. Последний Flash Media Server Enterprice Edition конечно поддерживает RTMFP, но только для нужд P2P. Направить такой поток в какой-нибудь Flash Media Gateway для конвертации в SIP не представляется возможным.
К сожалению, на единственной досупной нам десктопной линуксовой машине (виртуальной) все работает. Но судя по количеству коментариев на эту тему, проблема с Линуксом действительно есть. Мы постараемся разобраться.
Пробовали. Долгое время на talkpad.ru висела именно связка siprtmp + VideoIO. Все работает, пока есть идеальное сетевое соединение между пользователем и сервером с siprtmp. Но как только есть хоть малейшие проблемы с сетью, проявляется сущность протокола RTMP — он начинает «захлебываться», постоянно запрашивая ретрансмиты потерянных пакетов.
Это и побудило задуматься над поиском альтернативы. Реализаций более подходящего для VoIP протокола RTMFP, которую просто можно взять и использовать, сейчас нет, поэтому написали свою. Результат понравился, и поэтому решили предложить это решение всем желающим через облачное API.
Есть российский аналог — talkpad.ru, все то же самое, только с использованием более нового протокола RTMFP на UDP, ну и качество соответствующее.
Если объемы большие, то конечно возможно, пишите в личку, договоримся.
В то же время RTP поддерживается из коробки. Однако смотрим на кодеки: iLBC, iSAC и VP8. Это означает, что для взаимодействия с обычной IP телефонией голосовые и видео данные также придется прогонять через сервер и транскодить в более общепринятые.
Все это в совокупности означает, что WebRTC поддерживает SIP ничуть не лучше, чем Flash. Разве что, это вещь сильно более открытая и серверную часть сильно легче написать.
То, что у Zingaya есть RTMFP, мы знаем. В конце статьи я как раз рассмотрел пример как сделать базовый функционал Zingaya-подобного click2call сервиса на базе нашего API.
Это и побудило задуматься над поиском альтернативы. Реализаций более подходящего для VoIP протокола RTMFP, которую просто можно взять и использовать, сейчас нет, поэтому написали свою. Результат понравился, и поэтому решили предложить это решение всем желающим через облачное API.