hbruser

В общем в live режиме hls не получиться, смотрите пост.

Этот пост про задержку, а не про производительность.
В случае ТС требуются минимальные затраты на перепакетизацию потока.

Минимальные затраты может дать использование Flash, т.к. Flash поддерживает H.264 и потребуется только ре-пакетизация потока в тот же кодек. Если использовать HTML5(WebM) затраты будут выше, так как потребуется транскодинг в VP8 или VP9 видео кодек, а это как раз сильно затратная операция.

>По ссылке есть решение, но оно без звука и с помощью javasript - я не пробовал.
Тоже самое, но со звуком
По ссылке совсем другая технология, там видео перекодируется на лету в MPEG1. Не очень затратный кодек, т.к. сжимает плохо. Поэтому производительность будет лучше чем в WebM и хуже чем в Flash.

1. Mona Server
Бывший Cumulus.

2. Web Call Server 4

Поддерживает RTMFP-потоки и конвертацию в RTSP, Websocket, WebRTC
Т.е. можно организовать обмен видеопотоками между:

IE - IE
IE - Chrome/Firefox
IE - VLC/RTSP player
IE - iOS Safari

Здесь IE работает с Flash Player и сервером через RTMFP-протокол.

Также, судя по forums.adobe.com/thread/636094 и forums.adobe.com/message/2809280 реализация данного протокола не сильно выгодна, поскольку RTMFP не обходит NAT.

NAT не страшен если есть сервер, который может проксировать потоки.

Также, учитывая распространенность флеш на мобильных устройствах, направленность на HTML5 и разработки, связанные с WebRTC навряд ли кто-то будет сильно этим заниматься.

Многие легаси системы продолжают работать на флэшовом Adobe FMS и Wowza. Зачастую для них очень дорого переходить на WebRTC и другие технологии. Так что по крайней мере на десктопе Flash себя пока хорошо чувствует.

Если объяснять на пальцах как работают WebRTC-звонки, то выглядит это так:

1. Саша и Кузя открыли страницу в браузере. На странице JavaScript.
Находятся они естественно не за одним компьютером, а скорее всего в разных городах.
2. Далее они должны обменяться кодеками и дать друг другу свои WebRTC-координаты (IP адреса и порты). Например, если у Саши Google Chrome, то у него приоритетным будет видеокодек VP8, а если Firefox, то H.264 насколько я помню.
3. После того, как они обменялись этой информацией, трафик начинает идти от одного к другому(возможно через TURN сервер) и имеем установленный звонок.

Обмен нужной информацией называется "сигналинг" и требует стороннего сервера. Без него никак. Участникам звонка не узнать IP адрес друг друга если не будет центрального сервера, который им в этом поможет.

Ну и далее много вариантов.
Подбираете нужный сервер или cloud-сервис и созваниваете через него.

Вот два примера установки соединения через сервер Flashphoner:

1. Сигналинг идет через SIP.
www.youtube.com/watch?v=BG7CZSsR8WA

2. Простой стриминг. Один дает поток, другой играет и обратно.
www.youtube.com/watch?v=0eBm5rL6nSs

Если IP камера поддерживает RTSP и H.264, можно смотреть на Android планшете в Chrome или Firefox браузере без установки дополнительного ПО. Здесь пример настройки.

WebRTC Media & Broadcasting Server - работает по UDP, поэтому задержка будет минимальной до 500 миллисекунд если без потерь.

Про сеть VGA не понял. Как транслировать с IP-камеры без задержки, можно прочитать здесь.

Вот подробный обзорчик на хабре как запустить на своем сервере.

WebRTC Broadcasting Server - можно сделать много слушателей и много вещателей.

На ноут надо Asterisk поставить, завести пару SIP аккаунтов и готово. Потом на каждый из андроидов установить SIP клиент и они смогут звониться между собой, если с Asterisk в одной сети конечно.

Если с WebRTC и в разумное время, то будет тяжеловато. Знаю админа одного - третью неделю уже Asterisk мучает чтобы sipml5 с ним корректно поднять:) Хотя может быть руки не оттуда.

без напильника - kayako

использую manycam - это splitter для веб камеры.
Хотя вру. В последнее время купил пару вебкамер и использую их. Так надежнее :)

Отправлять видео по вебсокету... Сэр знает толк в извращениях.
По вебсокету создается соединение с сервером, дальше обмен SDP и SRTP потоки. Это и есть WebRTC. Ну и сервер нужно подыскать, который работает по Websockets/WebRTC и способен принимать поток и отдавать его подписчикам.

Задержка вообще зависит много от чего
1) Jitter buffer имеет свой размер и свои алгоритмы сброса пакетов
2) Сервер, через который идет трафик(TURN или другой сервер) может иметь свои буферы

Задержка кодирования и декодирования потока невидима глазом.
Ну и от RTT конечно зависит.
У вас сколько задержка от RTT и насколько вы хотите ее улучшить?

У Chrome и FF немного разные методы установки защищенного соединения: DTLS и SDES. Попробуйте покопать в этом направлении.

Все заканчивается на коннекте Websocket. Сервер вас срубает с какой-то ошибкой.
sipml5 если и юзать, то со своим сервером, а не с тем общественным, на котором не известно что происходит.

Чтобы принимать звонки вам потребуется либо внешний телеком провайдер, который предоставляет внешний номер телефона, либо GSM/PSTN шлюз, в который можно воткнуть SIM карты для приема вызовов. Если это CRM, то скорее всего нужно масштабируемое решение и потребуется арендовать пул номеров у провайдера. На эти номера будут поступать звонки и ваш Asterisk сервер будет распределять их по операторам.

webrtc действительно подойдет если операторы CRM будут использовать Chrome или FF.
В IE оно пока не работает.

jssip или sipml5 надо внимательно тестировать, т.к. могут вылезти такие баги, которые не удастся исправить в разумное время. Кстати удержание вызова в WebRTC работает через воркэраунды в силу некоторых причин. Знаю что у Flashphoner удержание и трансферы для WebRTC работают. В sipml5 не тестировал.

автоматическое определение номера

это скорее дело Asterisk-а прислать эти данные Web-телефону

открытие карточки клиента

Это есть в каждом API. Раз вызов входящий видно, значит есть соответствующее событие.

Возможно есть какие-то готовые решения такой интеграции веб-телефона на страницу сайта.

Более готовых софтверных решений чем Flashphoner не видел. Есть куча SAAS. Может их?