hbruser

WebRTC построен на основе нескольких протоколов:
STUN, ICE, DTLS, SDP, SRTP, RTCP

Все эти протоколы используются, в передаче потока от одного пира к другому.

Лучше поздно, чем никогда :)

Как осмысленно перевести на русский определение RTCIceCandidate?

Кандидат (пара ip:port) для установки соединения.

internet connectivity establishment.

Протокол установки соединения.

В iOS с этим совсем плохо для браузеров.
Если камеру еще как-то можно забрать, то микрофон никак.
Лучше дождаться поддержки getUserMedia от Apple или пилить нативное приложение, без использования браузера.

Вот здесь показаны примеры, как собирать WebRTC статистику в Chrome и Firefox.

Если сделать несколько замеров статистики, можно определить, приходит ли видеотрафик, какой битрейт, есть ли потери, и т.д. Но даже если трафик приходит и нормально декодируется, юзер может видеть черный экран. Это уже нужно отдельно распознавать.

MediaRecorder

mediaRecorder.ondataavailable = function(e) {
      chunks.push(e.data);
 }

А потом можно отправлять через socket.io.

Да, так сделать можно.
В скрипте https://simplewebrtc.com/audio.js у вас используется такая штука как

navigator.mediaDevices.getUserMedia({video:{width: 320, height:240}})

При вызове getUserMedia() браузер запрашивает доступ к микрофону.
Поэтому чтобы не запрашивать доступ к микрофону просто не нужно это вызывать.
Другое дело, не сломает ли это данный конкретный скрипт и логику его работы.

Web Call Server

Идея вполне рабочая. На Asterisk можно настроить как видеозвонки, так и передачу сообщений.
Но на убийцу скайпа не тянет. На первой сотне юзеров баги sipml5 и Asterisk станут вашими багами.
Для небольшого видеочата вполне может оказаться рабочим решением.

снимите два дампа с помощью Wireshark

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

в них посмотрите как ходят STUN и ICE пакеты

скорее всего что-то куда-то не доходит

Лучший способ записать видеочат, это иметь MCU на стороне сервера, котроая микширует видеопотоки в одну картинку. Остальное костыли.

Шаринг экрана можно сделать с быстрой установкой расширений (inline).
В этом случае пользователю не нужно переходить на store и что-то качать, и он ставит расширение, клиакая на ссылку в раузере.

Расширения придестя делать и выкладывать в store и для Chrome и для FF.
Без них никакая запись работать не будет в силу политик безопасности браузера.

Браузеры поддерживают всего два "протокола" по которым можно транслировать видео с локальной web-камеры (если мы говорим про камеру, которую использует браузер):
- WebRTC
- RTMP и ему подобные

1. Показывать видео с камеры компьютера в окне браузера практически чистым HTML5

Чистый HTML5 - это:
- Canvas + Websockets.
- WebRTC video element
- HLS тоже можно назвать самым чистым

2. Проигрывать видеопоток в браузере через WebRTC и видеть его с другого IP адреса через VLC player

VLC умеет играть RTSP.

Сервер, который умеет все что вы описали одновременно, это Web Call Server 4.
- принять поток по WebRTC
- раздать по HTML5 Websockets
- раздать по WebRTC
- раздать по RTSP

Вообще говоря если задержка не критична, лучше использовать HLS (Apple HTTP Streaming).
Все остальные протоколы доставки не являются кроссбраузерными или имеют другие ограничения.

Chrome, WebRTC (.webm)
Так выглядит запись WebRTC-потока из Chrome браузера при использовании Flashphoner сервера.
Справа воспроизведение записанного webm файла в VLC.
IE, Flash (mp4)
А это пример с Flash, когда поток отдает IE


На браузере простой JavaScript + Jquery и API.

C iOS нужно будет специальное приложение для записи.
iOS браузеры не поддерживают WebRTC. Разве что Ericsson какой-нибудь, но им никто не пользуется.

Здесь поможет WebRTC сервер, который проксирует трафик, например этот. Работает, насколько мне известно даже под VPN. Правда не будет p2p.

TURN сервер поможет скорее всего, только его нужно хитро сконфигурировать.

P.P.S. И вообще, возможно ли полностью обойтись без сервера или все-таки мне придется использовать хоть какой-то бэкенд?

Нельзя.
Серверная часть нужна:
- для сигналинга
- для преодоления NAT (нужен STUN сервер)
- для проксирования трафика если потребуется (нужен TURN)

Т.е. нужно три логических сервера. Поэтому без бэкенда не обойтись.

Есть ли опесурсные реализации для фолбэка webrtc?

фоллбэки - это либо плагины, либо Flash

Из опенсорсных реализаций плагинов знаю webrtc4all

Опенсорсные Flash-WebRTC реализации мне не известны.
Из платных WCS4 может раздавать Flash поток по WebRTC и обратно, но стоит денег.

Если объяснять на пальцах как работают 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

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

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