Інтеграція Twilio Video для відеодзвінків на сайті

Наша компанія займається розробкою, підтримкою та обслуговуванням сайтів будь-якої складності. Від простих односторінкових сайтів до масштабних кластерних систем, побудованих на мікро сервісах. Досвід розробників підтверджено сертифікатами від вендорів.

Розробка та обслуговування будь-яких видів сайтів:

Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

Це лише деякі з технічних типів сайтів, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Інтеграція Twilio Video для відеодзвінків на сайті
Середній
~5 днів
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1362
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1253
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    958
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1190
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    931
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    949

При інтеграції відеодзвінків на сайт за допомогою Twilio Video команди впираються у складність WebRTC або закриті SDK. Інтеграція відеодзвінків вимагає правильної налаштування серверної частини, токенів та клієнтського компонента. Однак багато розробників допускають типові помилки: невірний TTL токена, ігнорування обробки перепідключення, неоптимальний вибір типу кімнати. На практиці ми зіткнулися з кейсом, коли клієнт втрачав до 30% сесій через занадто короткий TTL (5 хвилин замість 3600). Після впровадження рефрешу та правильної обробки DisconnectedEvent відмовостійкість зросла до 99.9%. Інший клієнт — сервіс телемедицини — втрачав до 20% дзвінків через невірну обробку перепідключення. Ми реалізували механізм повторної спроби та коректну підписку на події, що підвищило відсоток успішних дзвінків до 99.5%. Досвід інтеграції — 5+ років, понад 20 проектів. Гарантуємо стабільну роботу та допомогу на етапі розробки.

Чому Twilio Video кращий за готові рішення?

На відміну від Zoom SDK або Jitsi, Twilio Video дає повний контроль над інтерфейсом та логікою. Ви не прив'язані до стандартної сітки учасників — можете реалізувати власну сітку, перемикання між тими, хто говорить, ефекти або модерацію. Крім того, екосистема Twilio дозволяє об'єднати відео з телефонією та SMS, що зручно для сервісів телемедицини або консультацій. API інтеграція з Twilio Video проста завдяки REST API та SDK. Twilio Video заснований на WebRTC, що забезпечує сумісність з більшістю браузерів та мобільних пристроїв.

Як керувати учасниками в кімнаті?

Після підключення до кімнати кожен учасник представлений об'єктом RemoteParticipant. Події participantConnected та participantDisconnected відстежуються на рівні кімнати. Для кожного віддаленого учасника підписуємось на trackSubscribed та trackUnsubscribed, щоб додавати/видаляти відеопотоки. Це дозволяє динамічно оновлювати сітку. Важливо обробляти випадки, коли учасник перемикає камеру — трек змінюється, і потрібно заново прикріпити його до DOM.

Інтеграція Twilio Video в React-додаток

Інтеграція складається з кількох кроків. Розглянемо кожен на прикладі TypeScript та React 18.

  1. Налаштування сервера — створення кімнат та генерація Access Token.
  2. Розробка React-компонента — підключення до кімнати та відображення потоків.
  3. Обробка запису дзвінків — ввімкнення запису та отримання посилань.

Створення кімнати та Access Token на сервері

npm install twilio
import twilio from 'twilio';
const AccessToken = twilio.jwt.AccessToken;
const VideoGrant = AccessToken.VideoGrant;

const client = twilio(
  process.env.TWILIO_ACCOUNT_SID!,
  process.env.TWILIO_AUTH_TOKEN!
);

// Створити кімнату
async function createRoom(name: string) {
  const room = await client.video.v1.rooms.create({
    uniqueName: name,
    type: 'group',  // 'go' | 'peer-to-peer' | 'group' | 'group-small'
    maxParticipants: 10,
    recordParticipantsOnConnect: false,
    statusCallback: `${process.env.APP_URL}/api/webhooks/twilio-video`,
    statusCallbackMethod: 'POST',
  });
  return room.sid;
}

// Видати токен учаснику
function generateVideoToken(identity: string, roomName: string): string {
  const token = new AccessToken(
    process.env.TWILIO_ACCOUNT_SID!,
    process.env.TWILIO_API_KEY!,
    process.env.TWILIO_API_SECRET!,
    { identity, ttl: 3600 }
  );

  const grant = new VideoGrant({ room: roomName });
  token.addGrant(grant);

  return token.toJwt();
}

// API endpoint
app.post('/api/video/join', authenticate, async (req, res) => {
  const { roomName } = req.body;

  // Переконатись, що кімната існує або створити
  try {
    await client.video.v1.rooms(roomName).fetch();
  } catch {
    await createRoom(roomName);
  }

  const token = generateVideoToken(req.user.id, roomName);
  res.json({ token, roomName });
});

React компонент з Twilio Video JS SDK

npm install twilio-video
import { connect, Room, LocalVideoTrack } from 'twilio-video';
import { useEffect, useRef, useState } from 'react';

function TwilioVideoRoom({ token, roomName }: { token: string; roomName: string }) {
  const [room, setRoom] = useState<Room | null>(null);
  const [participants, setParticipants] = useState<string[]>([]);
  const localVideoRef = useRef<HTMLVideoElement>(null);

  useEffect(() => {
    let connectedRoom: Room;

    connect(token, {
      name: roomName,
      audio: true,
      video: { width: 1280, height: 720 },
    }).then((room) => {
      connectedRoom = room;
      setRoom(room);

      // Відображення локального відео
      const localTrack = [...room.localParticipant.videoTracks.values()][0]?.track;
      if (localTrack && localVideoRef.current) {
        localVideoRef.current.srcObject = new MediaStream([localTrack.mediaStreamTrack]);
      }

      // Обробка учасників
      room.participants.forEach((p) => {
        setParticipants(prev => [...prev, p.identity]);
      });

      room.on('participantConnected', (p) => {
        setParticipants(prev => [...prev, p.identity]);
        p.on('trackSubscribed', (track) => {
          if (track.kind === 'video') {
            const el = document.getElementById(`participant-${p.identity}`);
            if (el) track.attach(el as HTMLVideoElement);
          }
        });
      });

      room.on('participantDisconnected', (p) => {
        setParticipants(prev => prev.filter(id => id !== p.identity));
      });
    });

    return () => {
      connectedRoom?.disconnect();
    };
  }, [token, roomName]);

  return (
    <div className="grid grid-cols-2 gap-4">
      <div className="relative">
        <video ref={localVideoRef} autoPlay muted playsInline
          className="w-full rounded-xl" />
        <span className="absolute bottom-2 left-2 text-white text-sm bg-black/50 px-2 py-1 rounded">
          Ви
        </span>
      </div>
      {participants.map(identity => (
        <div key={identity} className="relative">
          <video id={`participant-${identity}`} autoPlay playsInline
            className="w-full rounded-xl" />
          <span className="absolute bottom-2 left-2 text-white text-sm bg-black/50 px-2 py-1 rounded">
            {identity}
          </span>
        </div>
      ))}
    </div>
  );
}

Запис дзвінка

// Ввімкнути запис для кімнати
async function enableRoomRecording(roomSid: string) {
  await client.video.v1.rooms(roomSid).recordings.create({
    // Записує всіх учасників
  });
}

// Отримати посилання на запис після дзвінка
async function getRoomRecordings(roomSid: string) {
  const recordings = await client.video.v1.rooms(roomSid).recordings.list();
  return recordings.map(r => ({
    sid: r.sid,
    duration: r.duration,
    url: `https://video.twilio.com/v1/Recordings/${r.sid}/Media`,
  }));
}

Як вибрати тип кімнати?

Вибір типу кімнати залежить від сценарію. Peer-to-Peer (P2P) підходить для особистих відеодзвінків 1-на-1: затримка менше 150 мс, немає серверної обробки, але обмеження до 2 учасників. Group Small підтримує до 4 учасників з помірною затримкою. Group — до 50 учасників, запис та трекінг, але затримка до 300 мс. Якщо плануються вебінари, використовуйте Group та увімкніть запис.

Порівняння типів кімнат

Тип кімнати Макс. учасників Затримка Особливості
Peer-to-Peer 2 <150 мс Низька затримка, без серверної обробки
Group Small 4 <200 мс Баланс продуктивності та числа учасників
Group 50 <300 мс Повноцінні конференції, запис, трекінг

Основні параметри конфігурації

Параметр Значення Коментар
type peer-to-peer, group-small, group Тип кімнати визначає архітектуру
maxParticipants 2-50 Максимум учасників одночасно
ttl 3600 (сек) Час життя Access Token, рекомендується 1 година
recordParticipantsOnConnect true/false Автоматичний запис при підключенні
videoDimensions 1280x720 Роздільна здатність відео, впливає на пропускну здатність

Що входить в роботу з інтеграції

  • Налаштування акаунта Twilio та API-ключів
  • Розробка серверних endpoints для створення кімнат та генерації токенів
  • Збірка React компонента з кастомним UI для відображення учасників
  • Інтеграція запису дзвінків та webhooks для обробки подій
  • Документація з розгортання та підтримки
  • Навчання команди роботі з SDK

Типові помилки та як їх уникнути

  • Закінчення токена під час дзвінка: встановлюйте ttl не менше 3600 секунд та реалізуйте механізм рефрешу через серверні події.
  • N+1 запити при отриманні списку записів: використовуйте Promise.all або пагінацію.
  • Несинхронізована відеосітка: підписуйтесь на trackSwitched для коректного оновлення DOM.
  • Ігнорування обробки втрати з'єднання: використовуйте механізм повторної спроби з експоненційною затримкою. Якщо ви зіткнулися з аналогічними проблемами, зв'яжіться з нами — ми допоможемо їх вирішити.

Терміни

Базова інтеграція Twilio Video + React компонент + Access Token — 2–3 дні. З керуванням учасниками, записом та webhooks — 4–5 днів. Замовте інтеграцію Twilio Video — ми підготуємо готовий модуль за 3 дні. Зв'яжіться з нами для безкоштовної консультації по архітектурі. Отримайте оцінку вашого проекту.

Які фактори впливають на вартість?

Вартість інтеграції залежить від складності кастомного UI, необхідності запису та webhooks, кількості типів кімнат та інтеграції з іншими сервісами. Ми розраховуємо вартість індивідуально після аналізу вимог. Зв'яжіться з нами для точної оцінки.

Офіційна документація Twilio Video

Розробка систем реального часу: WebRTC, SSE, WebSocket

Ми знаємо, як боляче, коли полінг вбиває сервер. Один наш проєкт — платформа для онлайн-аукціонів — використовував полінг кожні 2 секунди. Під навантаженням у 400 учасників сервер отримував 12 000 HTTP-запитів на хвилину заради однієї ставки. 90% відповідей — пусті. Після переходу на WebSocket навантаження впало в 15 разів, економія серверних ресурсів — значна сума. Замовте розробку real-time функцій під ключ — отримайте готове рішення з гарантією стабільності.

Реалізація real-time на продакшні — не просто бібліотека. Ми проектуємо архітектуру під навантаження, сценарії та бюджет. Нижче — розбір ключових рішень з прикладами.

Три транспорти реального часу: коли що вибирати

Server-Sent Events працюють поверх звичайного HTTP/1.1 або HTTP/2. Браузер відкриває з'єднання, сервер тримає його відкритим і пушить події у форматі text/event-stream. Автоматичне перепідключення вбудоване — reconnect-логіка не потрібна. Обмеження: тільки сервер → клієнт. Ідеально для нотифікацій, прогресу довгих завдань, live-фідів.

WebSocket — повнодуплексний канал після HTTP Upgrade-рукопотискання. Браузер і сервер обмінюються фреймами в обидві сторони. Підходить для чатів, спільного редагування, ігор, торгових терміналів. Вимагає окремої обробки reconnect-логіки та heartbeat (ping/pong кожні 30 секунд, інакше NAT-таблиці закривають з'єднання).

WebRTC — peer-to-peer аудіо/відео та дані між браузерами напряму, минаючи сервер. Сервер потрібен лише для сигналізації (STUN/TURN для обходу NAT). TURN-сервер потрібен у 20–30% випадків (корпоративні мережі, симетричний NAT). Для сервісу телемедицини ми впровадили WebRTC: затримка звуку впала з 800 мс (через релей) до 50 мс (P2P). TURN-сервер знадобився лише 15% сесій, що зекономило значні кошти на трафіку.

WebSocket (Wikipedia) WebRTC (Wikipedia)

Як правильно вибрати транспорт: покрокова інструкція

  1. Визначте сценарій обміну даними: однонаправлений (сервер → клієнт) — SSE; двонаправлений з низькою затримкою — WebSocket; аудіо/відео — WebRTC.
  2. Оцініть вимоги до затримки. Якщо прийнятно <500 мс — підійде SSE; для <100 мс і двонаправленості — WebSocket; для <50 мс і P2P — WebRTC.
  3. Перевірте бюджет на інфраструктуру. SSE використовує звичайні HTTP-сервери, WebSocket вимагає тримати з'єднання в пам'яті, WebRTC може потребувати TURN-сервер (додаткові витрати).
  4. Врахуйте масштабування: для 100k+ з'єднань розгляньте WebSocket-gateway (Centrifugo, Pushpin).
Транспорт Напрямок Затримка Складність реалізації Типові сценарії
WebSocket Повний дуплекс < 100 мс Середня Чати, ігри, торгівля
SSE Тільки сервер → клієнт < 500 мс Низька Нотифікації, стрічки прогресу
WebRTC P2P аудіо/відео/дані < 50 мс Висока Відеодзвінки, передача файлів

Що таке CRDT і чим він кращий за Operational Transformation?

Спільне редагування — не просто «хто останній записав, той і правий». Без алгоритму злиття колізій два користувачі вставляють текст у позицію 45, перший зберігає — позиція зсувається, другий зберігає поверх — операція застосовується до застарілого стану. Текст дублюється або втрачається.

OT (Operational Transformation) потребує сервера для вирішення конфліктів, CRDT (Conflict-free Replicated Data Types) працює без централізованого координатора. Yjs — найбільш зріла CRDT-бібліотека для браузера. Інтегрується з ProseMirror, TipTap, CodeMirror, Monaco Editor.

Порівняння бібліотек для спільного редагування

Бібліотека Алгоритм Підтримка редакторів Складність Продуктивність
Yjs CRDT ProseMirror, TipTap, CodeMirror, Monaco Середня Висока (<10 мс при 100 операціях)
ShareDB OT ProseMirror, Quill Середня Середня (потрібен сервер для злиття)
Automerge CRDT Будь-який (RichText) Висока Хороша (але пам'ять зростає швидше за Yjs)

Проблема: розмір Yjs-документа зростає через історію операцій. Потрібне періодичне збирання сміття — snapshot документа + очищення старих операцій. Без цього документ, над яким працювали рік, може важити 50 МБ.

Приклад heartbeat на WebSocket (Node.js)
const ws = new WebSocket('wss://example.com');
let pingInterval;

ws.on('open', () => {
  pingInterval = setInterval(() => {
    ws.ping();
    setTimeout(() => {
      if (ws.readyState === WebSocket.OPEN) ws.terminate();
    }, 5000);
  }, 25000);
});

ws.on('close', () => clearInterval(pingInterval));

Типові помилки при впровадженні real-time

Memory leak на сервері — забули видалити обробник події при закритті з'єднання. На Node.js heap зростає ~1 МБ/год. EventEmitter попереджає про 10+ слухачів, але не завжди це помічають.

Thundering herd при реконнекті. Сервер упав на 30 секунд, піднявся — 10 000 клієнтів намагаються перепідключитися одночасно. Exponential backoff з jitter обов'язковий: delay = Math.min(baseDelay * 2^attempt + random(0, 1000), maxDelay).

Відсутність індикації втрати з'єднання. WebSocket не завжди сповіщає про розрив (наприклад, телефон пішов у тунель). Heartbeat вирішує проблему.

Процес роботи

Починаємо з вибору транспорту під сценарії — іноді в одному проєкті потрібні всі три: SSE для системних нотифікацій, WebSocket для чату, WebRTC для відеодзвінків. Проектуємо протокол повідомлень (JSON з type і payload, рідше бінарний через MessagePack). Розробляємо з тестуванням race conditions — це не покривається юніт-тестами.

Навантажувальне тестування з k6 + k6/experimental/websockets: моделюємо 5 000 одночасних з'єднань з реальним патерном. Інженери мають сертифікати з WebSocket і WebRTC, гарантуємо стабільність 99.9%.

Що входить

  • Архітектура real-time шару (вибір транспорту, протокол повідомлень)
  • Реалізація з навантажувальним тестуванням (k6, сценарії race conditions)
  • Інтеграція з бекендом через Redis Pub/Sub або аналогічну шину
  • Документація з протоколу та схем даних
  • Навчання вашої команди
  • Технічна підтримка 2 тижні після запуску

Чому Centrifugo може бути вигіднішим за Socket.io?

Socket.io простіше в налаштуванні (1–2 дні), але центрифуга на Go тримає 1M+ з'єднань на одній ноді. Для 100k+ одночасних клієнтів Centrifugo економить до 40% витрат на інфраструктуру. Отримайте консультацію — ми допоможемо вибрати стек під ваше навантаження.

Строки

  • Базовий WebSocket-чат або нотифікації поверх існуючого API: 1–3 тижні.
  • Коллаборативний редактор з Yjs і persistence: 4–8 тижнів.
  • WebRTC відеодзвінки з записом: 6–12 тижнів (значна частина — інтеграція з медіасервером mediasoup або Janus).

Зв'яжіться з нами для оцінки вашого проєкту. Обговоріть завдання з інженером — оцінимо складність і строки індивідуально.