WebRTC-видеозвонки: настройка ICE, TURN и SFU для сайта

# /etc/turnserver.conf
listening-port=3478
tls-listening-port=5349
realm=yourdomain.com
server-name=yourdomain.com
lt-cred-mech
use-auth-secret
static-auth-secret=YOUR_SECRET
total-quota=100
bps-capacity=0
stale-nonce=600
cert=/etc/letsencrypt/live/yourdomain.com/fullchain.pem
pkey=/etc/letsencrypt/live/yourdomain.com/privkey.pem

Для высоких нагрузок (100+ одновременных звонков) мы используем кластеризацию coturn с DNS round-robin. Каждый экземпляр держит до 100 сессий.

Что такое SFU и когда он нужен?

SFU (Selective Forwarding Unit) — это медиасервер, который пересылает потоки без микширования. В отличие от mesh-топологии (P2P), где при 5 участниках создаётся 10 соединений на клиенте, SFU принимает один поток и ретранслирует получателям. Нагрузка на клиент снижается в 9 раз при 10 участниках. Мы используем mediasoup или LiveKit в зависимости от требований к производительности и гибкости.

SFU позволяет обслуживать в 10 раз больше участников с той же пропускной способностью.

Сигнальный сервер: реализация на Node.js + Socket.IO

Сигнальный сервер транслирует SDP-офферы, ответы и ICE-кандидаты между участниками. Пример серверной части:

// server.js
io.on('connection', (socket) => {
  socket.on('join-room', (roomId, userId) => {
    socket.join(roomId);
    socket.to(roomId).emit('user-connected', userId);
    socket.on('offer', (offer, targetId) => {
      io.to(targetId).emit('offer', offer, socket.id);
    });
    socket.on('answer', (answer, targetId) => {
      io.to(targetId).emit('answer', answer, socket.id);
    });
    socket.on('ice-candidate', (candidate, targetId) => {
      io.to(targetId).emit('ice-candidate', candidate, socket.id);
    });
    socket.on('disconnect', () => {
      socket.to(roomId).emit('user-disconnected', userId);
    });
  });
});

Этот код — основа для P2P и SFU-звонков. TURN-сервер обходится примерно в $10–20 в месяц на небольшой проект, а экономия на трафике благодаря Simulcast достигает 50%.

Клиентская часть: RTCPeerConnection и управление медиа

На клиенте создаём RTCPeerConnection с серверами ICE/TURN и получаем медиапоток:

const pc = new RTCPeerConnection({
  iceServers: [
    {
      urls: 'stun:stun.yourdomain.com:3478'
    },
    {
      urls: 'turn:turn.yourdomain.com:3478',
      username: generateTurnUsername(ttl),
      credential: generateTurnCredential(username, secret),
    },
  ],
  iceTransportPolicy: 'all',
});

const stream = await navigator.mediaDevices.getUserMedia({
  video: {
    width: { ideal: 1280 },
    height: { ideal: 720 },
    frameRate: { ideal: 30 }
  },
  audio: {
    echoCancellation: true,
    noiseSuppression: true,
    sampleRate: 48000
  },
});

stream.getTracks().forEach(track => pc.addTrack(track, stream));

Для улучшения качества используем Simulcast с SFU — клиент отправляет три потока разного разрешения:

pc.addTransceiver(videoTrack, {
  direction: 'sendonly',
  sendEncodings: [
    { rid: 'low', maxBitrate: 150000, scaleResolutionDownBy: 4 },
    { rid: 'mid', maxBitrate: 500000, scaleResolutionDownBy: 2 },
    { rid: 'high', maxBitrate: 1500000 },
  ],
});

SFU выбирает подходящий слой для каждого получателя, что даёт лучшее качество при ограниченной пропускной способности. Дополнительно контролируем состояние соединения через обработчики oniceconnectionstatechange и onconnectionstatechange, реализуя автоматическое переподключение при временных сбоях.

Мониторинг и оптимизация

После запуска важно отслеживать реальные метрики звонков. Используем getStats() для сбора ключевых показателей:

• packetsLost — процент потерь пакетов; при превышении 5% запускаем адаптивное снижение битрейта.
• jitter — джиттер; если >30ms, переключаем аудиокодек на Opus с более низкой задержкой.
• roundTripTime — RTT; высокий RTT сигнализирует о необходимости сменить TURN-сервер или маршрут.

Отметим: как указано в документации WebRTC API, эти данные помогают оперативно выявлять проблемные сессии и корректировать конфигурацию.

Что входит в работу: состав deliverables

После внедрения вы получаете:

• архитектурную документацию с описанием топологии, серверов и потоков;
• исходный код сигнального сервера и клиентской интеграции (Git-репозиторий);
• доступы к TURN-серверу (учётные записи с ограничением по времени);
• обучение команды (2-часовая сессия по эксплуатации);
• месяц пост-релизной поддержки (мониторинг через getStats(), исправление инцидентов).

Процесс внедрения и сроки

Внедрение WebRTC проходит в пять этапов:

1. Аналитика — аудит текущей инфраструктуры, сценариев использования, ожидаемой нагрузки.
2. Проектирование — выбор топологии (P2P или SFU), серверов, кодеков.
3. Реализация — настройка TURN/STUN, сигнального сервера, клиентской интеграции.
4. Тестирование — проверка под нагрузкой, в разных сетях, на мобильных устройствах.
5. Деплой — запуск в продакшен, мониторинг через getStats().

Сроки:

• P2P видеозвонок с сигнальным сервером — от 3 до 5 дней.
• Групповые звонки через SFU — от 2 до 3 недель.
• Запись и постобработка — плюс 1 неделя.
• Полноценная конференц-платформа — от 6 до 10 недель.

Стоимость рассчитывается после аудита. Свяжитесь с нами — обсудим задачу, оценим ваш проект и предложим оптимальную архитектуру. Закажите внедрение WebRTC и получите стабильные видеозвонки в любых сетях.