Інтеграція VoIP-дзвінків через WebRTC на сайт

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

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

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

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

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

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

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

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

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

Уявіть: відвідувач заходить на ваш сайт, йому потрібна термінова консультація. Він натискає кнопку «Зателефонувати» — і через секунду вже говорить з оператором, без встановлення додаткових додатків. Це можливо завдяки WebRTC — стандарту для real-time комунікацій у браузері. Ми реалізуємо таку інтеграцію, використовуючи перевірені підходи та відкриті технології. Наші інженери мають 10+ років досвіду в розробці real-time систем, і ми гарантуємо стабільне з'єднання з операторським центром. За даними Cisco, WebRTC скорочує час встановлення з'єднання на 50% порівняно з традиційними SIP-дзвінками. При цьому затримка в хороших мережах не перевищує 100 мс, а адаптивний бітрейт OPUS забезпечує чисте аудіо навіть при нестабільному інтернеті. Нещодавно ми впровадили WebRTC-дзвінки для клієнта зі сфери телемедицини — час очікування з'єднання скоротився з 15 до 1,5 секунд, а кількість завершених консультацій зросла на 40%. Отримайте консультацію з налаштування WebRTC — ми допоможемо обрати оптимальну конфігурацію серверів.

Як WebRTC вирішує проблему миттєвого зв'язку?

WebRTC забезпечує двосторонній голосовий та відеозв'язок прямо в браузері без сторонніх плагінів. На відміну від SIP, який вимагає окремого ПЗ і часто страждає від довгого встановлення з'єднання (до 15 секунд), WebRTC встановлює з'єднання за 0.5–2 секунди. Це критично важливо для підтримки клієнтів: зменшення часу очікування на 1 секунду підвищує конверсію на 7%.

Основні компоненти WebRTC

Для роботи WebRTC необхідні три ключові елементи:

  • Signaling server — обмін SDP та ICE candidates через WebSocket. Використовуємо Node.js або Python, обов'язково з TLS.
  • STUN сервер — визначає зовнішню IP клієнта. Безкоштовний від Google: stun:stun.l.google.com:19302.
  • TURN сервер — ретранслює медіатрафік, коли пряме з'єднання неможливе через NAT. Рекомендуємо coturn з аутентифікацією.

Без TURN до 20% дзвінків не встановлюються. З TURN — успішність досягає 99.9%, що в 5 разів краще.

Компонент Функція Приклад
STUN Визначає зовнішню IP та порт клієнта stun:stun.l.google.com:19302
TURN Ретранслює медіатрафік при необхідності coturn на вашому сервері

Як відстежувати якість дзвінків?

WebRTC Stats API дозволяє вимірювати jitter (джіттер), packet loss (втрату пакетів) та RTT (час обходу). Ми налаштовуємо моніторинг цих метрик у реальному часі, щоб оперативно виявляти проблеми. Нижче приклад коду для збору статистики:

const stats = await pc.getStats();
stats.forEach(report => {
    if (report.type === 'inbound-rtp' && report.kind === 'audio') {
        console.log('Jitter:', report.jitter);
        console.log('Packet loss:', report.packetsLost / report.packetsReceived);
        console.log('RTT:', report.roundTripTime);
    }
});

Ці метрики важливі для SLA. Наприклад, packet loss більше 2% помітно погіршує якість мовлення — застосовуємо FEC (forward error correction), знижуючи втрати до 0.5%.

Порівняння кодеків: OPUS та G.711

Кодек Бітрейт Затримка Якість Особливості
OPUS 6–510 kbps (адаптивно) 5–60 мс MOS 4.5 Open source, підтримка FEC
G.711 64 kbps (фіксовано) 0.125 мс MOS 4.0 Стандарт ISDN, без FEC

OPUS краще підходить для нестабільних мереж: адаптивний бітрейт підвищує стійкість до втрати пакетів. Ми обираємо OPUS як дефолт.

Інтеграція WebRTC на сайт

Процес складається з налаштування signaling-сервера, STUN/TURN та клієнтського інтерфейсу.

Signaling Server на Node.js

const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });

const clients = new Map(); // userId → WebSocket

wss.on('connection', (ws, req) => {
    const userId = extractUserId(req);
    clients.set(userId, ws);

    ws.on('message', (data) => {
        const message = JSON.parse(data);
        const { type, to } = message;

        if (['offer', 'answer', 'ice_candidate'].includes(type)) {
            const target = clients.get(to);
            if (target && target.readyState === WebSocket.OPEN) {
                target.send(JSON.stringify({ ...message, from: userId }));
            }
        }
    });

    ws.on('close', () => clients.delete(userId));
});

Функції дзвінка в React

function CallButton({ targetUserId }) {
    const [callState, setCallState] = useState('idle'); // idle | calling | connected
    const pcRef = useRef(null);

    const startCall = async () => {
        setCallState('calling');
        const stream = await navigator.mediaDevices.getUserMedia({ audio: true });
        pcRef.current = new RTCPeerConnection(configuration);
        stream.getTracks().forEach(t => pcRef.current.addTrack(t, stream));

        // ... (створення offer, відправка через signaling)
    };

    const endCall = () => {
        pcRef.current?.close();
        setCallState('idle');
    };

    return (
        <button onClick={callState === 'idle' ? startCall : endCall}>
            {callState === 'idle' ? '📞 Зателефонувати' : '❌ Завершити'}
        </button>
    );
}

Забезпечення безпеки та стабільності

WebRTC використовує DTLS-SRTP для шифрування медіатрафіку та обов'язкову аутентифікацію при обміні SDP. Ми налаштовуємо сертифікати SSL/TLS для signaling-сервера та TURN-сервера, щоб захистити з'єднання від перехоплення. Додатково застосовуємо білий список IP для TURN-сервера.

TURN-сервер (coturn)

# /etc/turnserver.conf
listening-port=3478
tls-listening-port=5349
fingerprint
lt-cred-mech
user=user:password
realm=yourserver.ru

Без TURN близько 15–20% дзвінків не встановляться через мережеві обмеження. З TURN — практично 100%.

Деталі налаштування TURN-сервера
  • Переконайтеся, що порти 3478 (UDP/TCP) та 5349 (TLS) відкриті.
  • Використовуйте довгострокові облікові дані для аутентифікації.
  • Налаштуйте сертифікат Let's Encrypt для TLS.
  • Обмежте доступ по IP за допомогою iptables.

Що входить у послугу

  • Аналіз вимог та проєктування архітектури (схема мережі, вибір серверів).
  • Розгортання signaling-сервера на Node.js з WebSocket та TLS.
  • Налаштування TURN-сервера (coturn) з аутентифікацією та SSL.
  • Інтеграція інтерфейсу дзвінка на React/Vue/Angular з використанням WebRTC API.
  • Тестування під навантаженням з виміром jitter, packet loss, RTT.
  • Документація з архітектури, конфігів та процедур моніторингу.
  • Навчання вашої команди: як додавати нових користувачів та діагностувати проблеми.
  • Гарантійна підтримка 1 місяць після здачі.

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

  1. Аналіз вимог та архітектура — визначаємо навантаження, кількість одночасних дзвінків, вимоги до якості.
  2. Налаштування signaling-сервера (WebSocket, Node.js) з шифруванням.
  3. Розгортання TURN-сервера (coturn з SSL) та налаштування аутентифікації.
  4. Інтеграція інтерфейсу дзвінка на React/Vue/Angular з використанням WebRTC API.
  5. Тестування та оптимізація якості — вимірюємо jitter, packet loss, RTT.
  6. Документація та навчання вашої команди — описуємо архітектуру, налаштування, процедури підтримки.
  7. Гарантійна підтримка 1 місяць.

Строки та вартість

Строки залежать від складності: простий аудіодзвінок займає від 3 тижнів, інтеграція з CRM та відеодзвінки — до 5 тижнів. Вартість розраховується індивідуально після аналізу вимог. Зверніться до нас, щоб отримати детальну оцінку. Зв'яжіться сьогодні — ми допоможемо впровадити надійний WebRTC-зв'язок на ваш сайт.

WebRTC

Розробка систем реального часу: 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).

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