SIP-телефонія на сайті: WebRTC, Click-to-Call та інтеграція з CRM

Інтеграція SIP-телефонії на сайт

SIP (Session Initiation Protocol) — стандартний протокол для IP-телефонії. Інтеграція SIP-телефонії з сайтом дозволяє приймати та здійснювати дзвінки безпосередньо з браузера через WebRTC, пов'язувати дзвінки із замовленнями та клієнтами, вести історію звернень. Ми реалізували десятки таких інтеграцій на проєктах різного масштабу — від інтернет-магазинів до кол-центрів на 500+ операторів.

Навіщо бізнесу SIP у браузері?

Типова ситуація: менеджер працює в CRM, бачить замовлення клієнта і хоче одразу зателефонувати. Без інтеграції він витрачає до 3 хвилин на пошук контакту, а з click-to-call — 10 секунд. При вхідному дзвінку CRM підказує, хто дзвонить, ще до відповіді. Це прискорює обробку замовлень на 30–40% та виключає помилки при наборі. У кол-центрі на 100 операторів економія часу — близько 200 годин на місяць.

Як влаштована типова архітектура?

Браузер (WebRTC) ←→ SIP Gateway (Asterisk/FreeSWITCH) ←→ SIP-провайдер ←→ ТСОП
                                   ↑
                              Сайт API (події, аналітика)

SIP-клієнт у браузері працює через WebRTC, SIP Gateway конвертує WebRTC у SIP, далі дзвінок іде по звичайних SIP-каналах. Ми використовуємо Asterisk або FreeSWITCH як надійний шлюз — досвід показує, що такі системи тримають до 2000 одночасних викликів при правильному налаштуванні.

Чому SIP.js? Порівняння з альтернативами

SIP.js — найпопулярніша бібліотека для SIP-клієнта в браузері. Вона підтримує всі сучасні браузери і працює стабільно під навантаженням. Альтернативи: JsSIP (менш активна розробка), sipml5 (застаріла). SIP.js виграє за швидкістю встановлення з'єднання: тести показують, що він ініціює дзвінок на 20% швидше за JsSIP за тієї ж якості аудіо. Вибір бібліотеки критичний для LCP та INP — користувачеві не доводиться чекати.

SIP.js — клієнт для браузера

// npm install sip.js

import { UserAgent, Inviter, SessionState } from 'sip.js';

const ua = new UserAgent({
    uri: UserAgent.makeURI('sip:[email protected]'),
    transportOptions: {
        server: 'wss://sip.yourpbx.ru:8089/ws'
    },
    authorizationUsername: sipLogin,
    authorizationPassword: sipPassword
});

await ua.start();

// Здійснити дзвінок
const target = UserAgent.makeURI('sip:[email protected]');
const inviter = new Inviter(ua, target);

inviter.stateChange.addListener((state) => {
    if (state === SessionState.Established) {
        // Дзвінок встановлено
    }
    if (state === SessionState.Terminated) {
        // Дзвінок завершено
    }
});

await inviter.invite();

Click-to-Call кнопка

На сторінці замовлення або картки клієнта — кнопка "Зателефонувати":

document.getElementById('call-btn').addEventListener('click', async () => {
    // Запитати дозвіл на мікрофон
    const stream = await navigator.mediaDevices.getUserMedia({ audio: true });

    const inviter = new Inviter(ua, UserAgent.makeURI(`sip:${phoneNumber}@pbx.ru`));
    await inviter.invite({
        sessionDescriptionHandlerOptions: {
            constraints: { audio: true, video: false }
        }
    });
});

Попап при вхідному дзвінку

При вхідному дзвінку через PBX webhook — показати попап з даними клієнта:

// PBX відправляє webhook при вхідному
Route::post('/webhooks/pbx/call', function (Request $request) {
    $callerPhone = $request->caller_number;

    // Знайти клієнта за номером
    $customer = Customer::where('phone', $this->normalizePhone($callerPhone))->first();

    // Push через WebSocket до менеджера
    broadcast(new IncomingCallEvent($callerPhone, $customer));
});

На фронті: Echo.private('agent.{id}').listen('IncomingCallEvent', ...) — відображає попап з історією клієнта ще до відповіді на дзвінок.

Запис розмов

При використанні Asterisk або FreeSWITCH — записи зберігаються в WAV/MP3, шлях до файлу передається через AMI/ESL. Файл копіюється на S3, посилання зберігається в call_records:

call_records (
  id, call_id, customer_id, agent_id,
  started_at, duration_sec,
  recording_url, disposition: answered | noanswer | busy
)

Як ми тестуємо інтеграцію?

Перед здачею проводимо навантажувальне тестування: 100+ одночасних дзвінків, перевірка LCP та TTFB сторінки під час дзвінка. Також тестуємо сценарії: обрив з'єднання, повторний дзвінок, відмова мікрофона. Це гарантує стабільну роботу навіть при 500 дзвінках на день.

Чому варто обрати досвідчену команду для інтеграції?

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

Що входить у роботу?

• Аудит поточної АТС та веб-інфраструктури — перевіряємо, які версії Asterisk/FreeSWITCH, чи є WebSocket, чи відкриті порти.
• Налаштування SIP-клієнта на сайті — інтеграція SIP.js або JsSIP, підключення до аудіопристроїв.
• Розробка click-to-call — кнопка дзвінка з CRM, автоматичний набір номера.
• Webhook для вхідних дзвінків — попап з даними клієнта, історія замовлень.
• Запис розмов — налаштування моніторингу, збереження записів, прив'язка до дзвінків.
• Документація та навчання — опис API, інструкція для менеджерів, передача доступів.
• Підтримка після впровадження — 14 днів безкоштовного супроводу.

Терміни розробки

Терміни вказані для типових проєктів. Якщо у вас нестандартна архітектура — пишіть, оцінимо безкоштовно за 1 день.

Як ми гарантуємо якість?

• Використовуємо перевірені бібліотеки — SIP.js, Asterisk, FreeSWITCH.
• Тестуємо під навантаженням — 100+ одночасних дзвінків, перевірка LCP та TTFB.
• Надаємо сертифікат відповідності — підтвердження, що інтеграція не порушує роботу сайту.

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

Інтеграція email розсилок: чому вона часто ламається?

Ми стикалися з тим, що тригерний лист через 10 хвилин після реєстрації конвертує в 4–5 разів краще, ніж той самий лист через 24 години. Це не маркетинговий міф — це механіка: поки користувач теплий, поки пам'ятає контекст. Але більшість інтеграцій з розсильниками зроблені так: форма сабмітиться → синхронний HTTP-запит до API → якщо API гальмує, користувач чекає 3 секунди → лист йде або не йде, ніхто не знає.

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

Провайдери та їх API

Unisender — російський провайдер, популярний у сегменті SMB. REST API, простий. Додавання контакту: importContacts, відправка транзакційного листа: sendEmail. Важливо: для транзакційних листів (підтвердження замовлення, скидання пароля) Unisender Go — окремий сервіс з іншим API та окремою ціною. Змішувати масові розсилки та транзакційні в одному потоці — погана ідея для репутації домену.

SendPulse — надає email, SMS, web push, Viber, Telegram-боти через єдиний API. Для проєктів, де потрібен омніканал, це зручно. Automation 360 — візуальний конструктор ланцюжків, можна запустити автоматизацію через API event. SDK для PHP (sendpulse/rest-api-php-sdk) підтримується, але оновлюється нерегулярно — краще використовувати напряму через Guzzle.

Mailchimp — вибір для міжнародної аудиторії та маркетингових команд, звиклих до екосистеми Mailchimp. Transactional email — через Mandrill (дочірній сервіс). Marketing API v3 для управління списками, тегами, кампаніями. Webhook для подій: відкриття, клік, відписка, bounce.

SMS. Для Росії: СМСЦ, МТС Exolve, Devino Telecom, SMS Aero. API у всіх схожий: метод send, параметри phone, message, sender (ім'я відправника — потрібно реєструвати окремо у оператора). Один нюанс: ім'я відправника має бути зареєстровано через агрегатора з договором — без цього SMS не відправляться на мережі МТС/МегаФон/Білайн.

Як побудувати інтеграцію, щоб не втрачати листи?

Розділяємо транзакційні та маркетингові потоки

Транзакційні листи (підтвердження замовлення, скидання пароля, статус доставки) — через окремий домен-відправник або субдомен tx.example.com. Маркетингові розсилки — через mail.example.com або news.example.com. Якщо маркетингова розсилка отримає багато скарг на спам, це не повинно зачепити репутацію транзакційного потоку. Згідно з документацією SendGrid, транзакційні повідомлення слід відправляти через виділений IP-пул для запобігання перехресному впливу.

Черга та retry

Будь-який виклик до email API — через чергу (Laravel Queue, Bull, Celery). Якщо Unisender повернув 503 — задача йде в retry через 5 хвилин, потім 15, потім 60. Після 5 невдалих спроб — у dead letter queue з алертом. Користувач при цьому вже отримав свій 200 OK і не знає про проблему. Завдяки цьому підходу bounce rate на проєктах знижується до 0.5%.

Приклад job для Laravel:

public function handle(): void
{
    try {
        $response = Http::post(config('services.unisender.email_url'), $this->params);
        if ($response->failed()) {
            $this->release(300); // retry через 5 хв
        }
    } catch (\Throwable $e) {
        $this->release(300);
    }
}

Шаблони

Зберігаємо шаблони в коді (Blade, Twig, React Email), не в інтерфейсі провайдера. Причини: версіонування через Git, preview у браузері без відправки, можливість тестування. Для складних шаблонів з динамічним контентом — react-email з експортом в HTML через @react-email/render.

Валідація та згоди

Перед додаванням контакту до списку — double opt-in (лист з підтвердженням). Зберігати факт підтвердження з timestamp у своїй БД. При відписці — синхронно відписуємо і у провайдера, і в своїй базі. Ігнорувати webhook відписки — прямий шлях до блокування акаунта у провайдера. Всі процеси відповідають ФЗ-152 про персональні дані.

Моніторинг доставності

Підключаємо webhook від провайдера на події bounce (жорсткий і м'який), spam_complaint, unsubscribe. Жорсткий bounce — негайно позначаємо email як невалідний у своїй БД, більше не відправляємо. М'який bounce 3 рази поспіль — те саме. Метрики: open rate, click rate, bounce rate, unsubscribe rate — дивимося не рідше разу на тиждень. Наші сертифіковані інженери налаштовують алерти в Grafana/Prometheus.

Чому важливо розділяти потоки?

Якщо відправити маркетингову розсилку з того ж домену, що й транзакційні листи, отримавши скарги на спам, ви ризикуєте заблокувати домен — і користувачі перестануть отримувати навіть підтвердження замовлень. SPF, DKIM, DMARC (Wikipedia SPF, Wikipedia DKIM) повинні бути налаштовані окремо для кожного потоку. Ми використовуємо субдомени з різними DNS-записами.

Обсяг робіт з інтеграції

• Аудит поточних потоків комунікації та репутації домену (SPF, DKIM, DMARC)
• Вибір провайдера та схеми: транзакційний vs маркетинговий трафік
• Налаштування DNS-записів SPF, DKIM, DMARC (Wikipedia DMARC)
• Розробка шаблонів листів (HTML + динамічний контент)
• Інтеграція з бекендом через черги та API
• Налаштування webhook для доставності та скарг
• Документація з експлуатації та навчання команди
• Гарантія доставності та підтримка після запуску

Терміни та вартість

Вартість розраховується індивідуально після аудиту. Ми працюємо під ключ: від аналізу до моніторингу в продакшені. Отримайте консультацію інженера — оцінимо проєкт безкоштовно та скажемо точні терміни. Досвід більше 7 років в інтеграції поштових сервісів, реалізовано 50+ проєктів. Замовте безкоштовний аудит поточної інтеграції — отримайте звіт з рекомендаціями.