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+ проектов. Закажите бесплатный аудит текущей интеграции — получите отчёт с рекомендациями.