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

Чому голосовий дзвінок із сайту зривається на поганій мережі

Голосовий дзвінок із сайту ламається не в момент розмови, а раніше — коли мережа починає втрачати пакети.

Абонент на мобільному в ліфті, в метро або на перевантаженому Wi-Fi губить 3-5% трафіку, і класична телефония на TCP чесно перепитує втрачене: кожен зниклий пакет повертається повторно, черга зростає, затримка звуку йде за 400-500 мс.

Розмова перетворюється на рацію — люди починають перебивати одне одного, а через хвилину просто кладуть слухавку.

WebRTC вирішує це інакше на рівні транспорту: голос іде по UDP через SRTP, а не по надійному каналу. Втрачений пакет не перепитується — замість нього підставляється попередній кадр, і вухо чує легке «згладжування», а не провал у тишу.

За якість зв'язку відповідає не один механізм, а зв'язка: ехоподавлення, автоматичне регулювання підсилення та шумоподавлення знімають акустику приміщення, а адаптивний джиттер-буфер підлаштовує глибину під реальний розкид доставки.

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

Далі вступає керування маршрутом. WebRTC збирає ICE-кандидатів — локальні адреси, рефлексивні через STUN, ретрансляцію через TURN — і вибирає пару з найменшою затримкою та втратами, а при погіршенні каналу перемикається на резервну без перез'єднання.

Клієнт не чує «алло, ви мене чуєте?» і не чекає повторного додзвону: сесія живе, поки є хоч один робочий шлях.

Ціна помилки тут вимірюється не якістю звуку, а заявкою, що пішла. Людина, яка додзвонилася з другої спроби, вже не повертається на сторінку — вона телефонує конкуренту.

Тому розбираємо, як це закривається у вебі: від сигналінгу та медіасервера до метрик, за якими видно деградацію раніше, ніж її помітить клієнт.

Що дає вбудований голосовий зв'язок на сайті

Голосовий канал прямо в браузері усуває головний розрив у воронці: відвідувач не йде набирати номер, а з'єднується з оператором з тієї ж вкладки, де переглядає товар або заявку.

За нашою практикою частка успішних додзвонів зростає в 1,5–2 рази проти сценарію «зателефонуйте нам» — просто тому, що зникає етап перемикання пристрою та повторного пошуку.

З'єднання встановлюється за 1–3 секунди: браузер одразу піднімає медіапотік, без додзону через проміжні вузли та очікування в черзі. Для клієнта це різниця між «передзвоню потім» і розмовою тут і зараз.

Що змінюється в цифрах

• Частка додзвонів — зростає завдяки тому, що дзвінок доступний в один клік з тієї ж сторінки, де виникло питання.
• Час з'єднання — секунди замість хвилин, оператор відповідає, поки інтерес ще гарячий.
• Стійкість зв'язку — при перемиканні між мережами розмова не переривається: потік переналаштовується на новий канал, абонент цього не помічає.
• Навантаження на підтримку — частина типових питань закривається голосом за одну хвилину, а не листуванням на кілька повідомлень.

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

Ми піднімаємо медіасервер, налаштовуємо маршрутизацію викликів і підключаємо запис розмов, щоб у вас залишалася історія звернень і матеріал для розбору якості.

Окремо закриваємо те, що найчастіше ламає голос на сайті: права доступу до мікрофона, шифрування потоку та поведінку при слабкій мережі. Оператор бачить, з якої сторінки телефонує людина, — розмова починається не з «вітаю, чим допомогти», а одразу по суті.

Способи підключення дзвінків: порівняння варіантів

Є три принципово різні шляхи, і вибір між ними визначається не «модністю» технології, а тим, хто відповідає за якість зв'язку і що відбувається із записом розмов. Нижче — порівняння за реальними обмеженнями, з якими стикаються під час експлуатації.

Що визначає вибір на практиці

Перше питання — куди потрапляє запис розмови і хто його зберігає. Якщо за вимогами до персональних даних запис не повинен залишати ваш контур, зовнішній сервіс відпадає незалежно від зручності.

Друге — наскільки нестандартна логіка. Типова схема «клієнт натиснув кнопку — з'єднався з вільним оператором» закривається будь-яким варіантом.

Розподіл за навичками, пріоритети, повторні дзвінки та передача контексту в CRM — тільки власною інфраструктурою або зовнішнім сервісом із відкритим програмним інтерфейсом.

Третє — готовність адмініструвати. Власний контур дає повний контроль, але потребує стежити за сертифікатами, пропускною здатністю каналу та відмовостійкістю медіасервера. Зовнішній сервіс знімає цю роботу, але переносить точку відмови назовні.

Розберімо, як це виглядає в працюючій системі.

Як ми впроваджуємо голосовий зв'язок: етапи робіт

Впровадження голосового зв'язку починається не з коду, а з аудиту поточної телефонії: з'ясовуємо, який оператор і АТС вже використовуються, як маршрутизуються виклики, де зберігаються записи розмов і які вимоги у служби підтримки.

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

Від схеми до робочого дзвінка

1. Аудит телефонії та вимог. Фіксуємо сценарії: вхідні в браузер, вихідні з інтерфейсу оператора, переведення між співробітниками, запис і оцінка якості. Перевіряємо, які кодеки підтримує оператор і чи є обмеження за кількістю одночасних ліній.
2. Схема з'єднань. Малюємо шлях виклику: браузер клієнта, сигнальний сервер, медіа-шлюз, АТС і оператор. Узгоджуємо, де terminates шифрування і як трафік проходить через наявний контур безпеки.
3. Налаштування медіа. Підбираємо кодеки під реальні канали клієнтів, налаштовуємо обхід NAT і роботу через мобільні мережі, де з'єднання нестабільне. Окремо перевіряємо, що при падінні одного вузла виклик не рветься, а перемикається на резервний.
4. Інтеграція з інтерфейсом. Вбудовуємо панель дзвінка в наявні картки клієнтів і заявок, синхронізуємо події з CRM: початок розмови, завершення, запис, пропущений виклик.
5. Перевірка якості на реальних мережах. Проганяємо сценарії з офісу, домашнього Wi-Fi і мобільного інтернету, заміряємо затримку, втрати пакетів і частку викликів, які встановлюються з першої спроби. Окремо дивимося поведінку при слабкому сигналі.
6. Передача в експлуатацію. Віддаємо налаштовану схему, інструкції для підтримки, порядок діагностики типових збоїв і доступи до моніторингу. Супроводжуємо перші дзвінки, поки команда не переконається, що система поводиться передбачувано.

Кожен етап закінчується артефактом: схемою, конфігурацією або звітом про заміри. Це дозволяє повернутися на крок назад без переробки всього проєкту і точно розуміти, де саме виникла проблема, якщо вона з'явиться після запуску.

Політики доступу та керування учасниками дзвінка

Права в дзвінку — це не бінарне «може телефонувати / не може», а набір незалежних дозволів: ініціювати виклик, приймати вхідний, запрошувати третього учасника, вмикати запис, вивантажувати запис, бачити історію по всіх операторах або лише по своїх.

Ролі операторів описуємо декларативно, у конфігурації, а не в коді: зміна повноважень у співробітника — це правка одного запису, а не реліз. Нижче — чек-ліст того, що налаштовуємо та перевіряємо до запуску.

• Ролі операторів — матриця «роль → дозволені дії»: хто телефонує, хто лише приймає, хто може ставити виклик на утримання та переводити на іншого. Права успадковуються від групи, щоб новий співробітник отримував коректний набір з першого дня.
• Правила запису — що пишемо: лише вхідні, лише вихідні або всі розмови; з якого моменту починається запис і що відбувається при відключенні згоди другої сторони. Окремо — термін зберігання та порядок видалення за запитом.
• Обмеження за регіонами — білий список напрямків і заборона на виклики в недозволені зони. Правило спрацьовує до встановлення з'єднання, тому небажаний виклик просто не йде в мережу.
• Журналювання подій — фіксуємо початок і кінець виклику, учасників, зміну статусу, факт запису та завантаження. Запис незмінний: правку та видалення видно окремим рядком.
• Розмежування доступу до записів — прослуховування та вивантаження лише для ролей з відповідним дозволом; рядовий оператор бачить свої розмови, керівник — по своїй групі.
• Сесії та відкликання доступу — при блокуванні співробітника активні з'єднання закриваються, а видані посилання на записи перестають відкриватися.
• Перевірка перед запуском — проганяємо сценарії: спроба виклику в закритий регіон, запис без згоди, доступ до чужого запису. Кожен має завершитися відмовою та рядком у журналі.

Такий контур дає передбачуваний порядок: повноваження змінюються без викату нової версії, інцидент розбирається за журналом, а не за спогадами, а вимоги щодо регіонів і запису виконуються на рівні системи, а не на дисципліні операторів. Опишіть ваші ролі та обмеження — повернемося з оцінкою та планом налаштування.

Що замовник отримує після впровадження

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

• Конфігурації сигналінгу та медіа: параметри TURN/STUN, ліміти смуги на сесію, таймаути переговорів, правила вибору кодека — з коментарями, чому виставлено саме таке значення.
• Схеми з'єднань: шлях сигналу від браузера до АТС, точки відмови, поведінка при недоступності TURN — у вигляді діаграм, а не текстового опису.
• Регламент обслуговування: що моніториться (частка невдалих сесій, затримка встановлення зв'язку, якість каналу), які пороги вважаються аварійними і хто реагує.
• Інструкції для операторів: як прийняти виклик у браузері, що робити при «немає звуку» та «не додзвонилися», як передати звернення на другий рівень — мовою користувача, без технічних термінів.
• План відновлення: порядок дій при падінні TURN, при деградації каналу та при відмові АТС, включно з переведенням дзвінків на резервний маршрут.
• Правила оновлення: як викочувати зміни сигналінгу без обриву активних розмов і як відкочуватися на попередню конфігурацію.
• Доступи та ролі: хто і що може змінювати в конфігурації, де зберігаються секрети, як вони ротуються.

Кожен пункт перевіряється на прийманні: якщо за документом інженер, який не брав участі у впровадженні, піднімає стенд і відтворює дзвінок — артефакт готовий. Опишіть задачу — повернемося з оцінкою та планом.

Чим WebRTC відрізняється від звичної телефонії

Класична телефонія будується навколо АТС: виклик іде через комутатор, який тримає стан лінії, маршрутизацію та запис розмови.

WebRTC прибирає комутатор зі схеми — медіапотік іде напряму між браузером клієнта та вашим сервером або оператором, а сигналінг лише домовляється про параметри сесії.

Для відвідувача сайту це означає дзвінок в один клік прямо зі сторінки, без застосунку, додаткового номера та очікування гудків.

Де WebRTC виграє: підключення займає секунди, контекст дзвінка зберігається — оператор бачить, з якої сторінки та щодо якого товару звернулася людина, а сама сесія живе всередині вашої системи, а не в окремій телефонній книзі.

Де поступається: якість і стійкість залежать від каналу зв'язку клієнта, а не від оператора, тому на слабкому мобільному інтернеті можливі просідання, які класична лінія згладжує на своїй стороні.

Плюс запис, чергу та розподіл викликів потрібно будувати на своїй стороні, а не отримувати «з коробки» від телефонного провайдера.

Якщо у вас уже розгорнуто АТС, ламати її не потрібно.

Робоча схема — залишити АТС ядром для внутрішніх ліній і вхідних на міські номери, а WebRTC підключити до неї як ще один канал: браузерний виклик приходить на ту саму чергу, оператори працюють у звичному інтерфейсі, запис і звіти залишаються в одному місці. Так ви отримуєте дзвінки з сайту без другої інфраструктури та без розриву історії звернень.

Розвилка проста: якщо дзвінок з сайту — основний канал продажів, WebRTC варто робити повноцінним, із власною чергою та аналітикою. Якщо це доповнення до телефону, достатньо моста до наявної АТС.

На практиці вибір упирається в те, скільки викликів піде через браузер і наскільки глибоко їх потрібно пов'язувати з даними про клієнта.

Кейс: стабільні дзвінки в інтернет-магазині

Клієнт — інтернет-магазин із власною службою підтримки та відділом продажів — прийшов із конкретним болем: дзвінки із сайту працювали через сторонній сервіс-надбудову, і в години пік половина викликів не доходила до оператора. Клієнт скаржився, що «кнопка зателефонувати є, а додзвонитися неможливо».

Ми розібрали воронку дзвінка за логами і побачили три вузькі місця. Перше — з'єднання встановлювалося через проміжний сервер, який не тримав навантаження при одночасних викликах. Друге — при перемиканні мережі у клієнта (мобільний інтернет → Wi-Fi) сесія рвалася без відновлення.

Третє — звук ішов без адаптації до каналу: при слабкому інтернеті якість падала до нерозбірливої, але система не знижувала навантаження і не перемикала кодеки.

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

Для слабких каналів увімкнули адаптивне керування бітрейтом і перемикання кодеків на льоту — звук залишається розбірливим навіть на нестабільному з'єднанні.

WebRTC у цій архітектурі — не надбудова, а транспорт: з'єднання йде напряму, проміжний сервер лише допомагає сторонам знайти одна одну і більше не бере участі в передачі звуку.

Метрики до і після

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

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

Часті технічні сумніви перед стартом

Перед стартом майже кожна команда ставить один і той самий набір запитань: чи витримає інфраструктура навантаження, чи не обірветься дзвінок у частини клієнтів, як бути із записом розмов і що робити з мобільними мережами. Нижче — розбір за кожним пунктом, без маркетингу.

А якщо у клієнта старий браузер або нестандартне середовище?

Підтримка голосового зв'язку є в усіх актуальних гілках основних браузерів, включно з мобільними. Реальні складнощі виникають не із самим з'єднанням, а з доступом до мікрофона: політики безпеки вимагають захищеного з'єднання та явного дозволу користувача.

Ми закладаємо перевірку підтримки на вході та зрозумілий сценарій деградації — якщо дзвінок неможливий, клієнт бачить альтернативу, а не порожній екран.

Як організувати запис розмов і не порушити закон?

Запис вмикається на стороні сервера й не залежить від пристрою клієнта, тому працює однаково на всіх платформах. Ключовий момент — згода: перед початком запису обидві сторони отримують повідомлення, факт підтвердження фіксується.

Самі файли складаються в захищене сховище з розмежуванням доступу та строком зберігання за вашою політикою.

Мобільні мережі — дзвінок не буде рватися при перемиканні?

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

Для критичних сценаріїв додаємо резервний шлях через проміжний сервер — він вмикається, коли пряме з'єднання встановити не вдається.

Опишіть ваш сценарій — повернемося з оцінкою та планом, які з цих пунктів потребують окремого опрацювання.

Обговоримо ваше завдання і повернемося з планом

Щоб повернутися з оцінкою термінів і планом впровадження, нам потрібен від вас мінімум — сценарій дзвінків. Опишіть його у вільній формі: хто телефонує, кому і в який момент.

Далі ми самі розкладемо це на архітектуру: де ініціюється сесія, чи потрібен запис, як обробляються пропущені виклики, куди потрапляють логи. Чим конкретніші вхідні дані, тим точніша оцінка — без «уточнимо по ходу».

Далі робота йде за зрозумілими етапами, і на кожному ви бачите результат, а не звіт про зайнятість.

• Розбираємо сценарій дзвінків: вхідні, вихідні, переведення між операторами, робота з чергою, поведінка при обриві зв'язку.
• Перевіряємо сумісність з вашою телефонією — офісною АТС, хмарним провайдером або номером напряму.
• Збираємо прототип на тестовому контурі: реальний дзвінок із браузера, без встановлення софту на стороні клієнта.
• Узгоджуємо план впровадження: що робимо на вашій стороні, що на нашій, у якому порядку і з якими контрольними точками.
• Виводимо в продуктив, налаштовуємо запис, шифрування і права доступу за ролями.
• Передаємо документацію і залишаємося на підтримці — правки в сценарії та моніторинг якості зв'язку.

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

Опишіть ваш сценарій дзвінків — повернемося з оцінкою термінів і планом впровадження.