Как устроены звонки из amoCRM: браузер и софтфон

WebRTC не гарантирует звонок быстрее софтфона: задержку определяют сеть, маршрут RTP, кодеки и настройка АТС. Я разделяю сигнализацию и аудио, объясняю, как проверить связку браузера с Asterisk, и показываю, когда удобнее браузер, а когда отдельный SIP-клиент.

Чем WebRTC в amoCRM отличается от софтфона

WebRTC — набор браузерных механизмов для передачи аудио и видео в реальном времени. Софтфон — приложение, которое обычно регистрируется на АТС как SIP-устройство. В amoCRM оба варианта могут запускать звонок из карточки контакта, но сама CRM не превращает браузер в телефон и не задаёт автоматически весь путь аудио: его определяют телефония, интеграционный коннектор и настройки АТС. Если разбираем такую связку, сначала проверяем, что умеет именно установленный коннектор и как он связывает событие в CRM с вызовом. Для настройки всей цепочки можно подключить ИТ-аутсорсинг, если внутри компании некому отвечать за телефонию и сеть.

У WebRTC есть как минимум два разных потока. Сигнализация сообщает участникам, что звонок начинается, согласует параметры и передаёт сетевые кандидаты; в Asterisk браузер часто подключается к PJSIP через защищённый WebSocket (WSS). Сам голос идёт по медиаканалу WebRTC: ICE подбирает маршрут, а аудио передаётся в защищённом RTP. Поэтому формула «WebRTC гонит звук по WebSocket» неверна. WebSocket здесь обычно перевозит сигнализацию, а не разговор. Перепутать эти слои — хороший способ открыть не тот порт и получить очень уверенный, но бесполезный отчёт о проделанной работе.

Софтфон обычно использует SIP для сигнализации и RTP для медиа, однако конкретный транспорт зависит от клиента и конфигурации: SIP бывает поверх UDP, TCP или TLS. Нельзя объявить, что у всех софтфонов есть лишний этап handshake или что каждый из них работает через TCP. У обоих вариантов есть регистрация, согласование кодеков и прохождение медиа через сеть; отличаются клиент и способы их настройки. Я выбираю браузерный вариант, когда важен запуск из рабочего места без установки отдельного приложения и интеграция поддерживает WebRTC. Софтфон оставляю, когда он нужен для аппаратных гарнитур, мобильной работы или существующего процесса регистрации.

• WebRTC: браузер, сигнализация часто через WSS, защищённое RTP-аудио
• Софтфон: отдельный SIP-клиент; транспорт задаёт конфигурация
• amoCRM запускает сценарий, но маршрут звука определяет телефония

Как проверять задержку, а не объявлять победителя

В исходном варианте текст называл сравнение WebRTC и софтфона «тестом», но не приводил ни единого замера, ни точки измерения, ни одинаковых условий. Такой вывод нельзя публиковать как факт. Пинг до АТС показывает сетевой RTT до узла, а не задержку голоса от микрофона до динамика. Логи SIP показывают ход сигнализации и временные метки событий; сами по себе они не измеряют путь аудиопакета. Чтобы сравнить два клиента, нужны один и тот же интернет-канал, АТС, маршрут до оператора, гарнитура, кодек и сопоставимые звонки. Затем фиксируют задержку медиа, потери пакетов, джиттер и жалобы на качество. Без этого победитель выбирается по настроению, а не по данным.

В условной студии «Лагуна-Сервис» я бы начал с двух одинаковых тестовых звонков: один из браузера, второй из SIP-клиента на том же рабочем месте и в той же сети. Записал бы время установки вызова отдельно от времени прохождения аудио: пользователи часто называют «задержкой» и долгий дозвон, и паузу между репликами, хотя это разные неисправности. Дальше сопоставил бы SIP/PJSIP-журнал, статистику WebRTC в браузере и сетевые показатели медиа. Не приписываю этой студии вымышленные миллисекунды и «выигрыш по всем параметрам»: в исходных данных замеров не было. Когда цифр нет, честный результат — перечень проверок и локализованная причина.

Для диагностики я разделяю цепочку на этапы: клик в CRM, сигнализация от клиента к АТС, набор номера, ответ удалённой стороны, установление медиапути и двусторонний звук. Если карточка открывается медленно, ищу задержку в CRM или коннекторе. Если долго устанавливается вызов — изучаю SIP-сценарий и ответы узлов. Если разговор уже идёт, но собеседники слышат друг друга с паузой или перебивают, проверяю медиамаршрут, потери, джиттер и буферизацию. Иначе можно месяц «ускорять WebRTC», пока проблема остаётся в перегруженном канале или на удалённом участке сети.

• Разделяйте время дозвона и задержку аудио
• Сравнивайте клиенты при одинаковых условиях
• Фиксируйте потери, джиттер и маршрут RTP

Настройки Asterisk: WSS, медиа и RTP-порты

Для браузерного клиента Asterisk должна иметь соответствующие модули и конфигурацию: документация Asterisk перечисляет res_http_websocket и res_pjsip_transport_websocket, а для WebRTC-подключения описывает TLS, WSS-транспорт PJSIP и параметры защищённого медиа. В этом сценарии важны ICE и DTLS-SRTP; актуальный сертификат и доступный по защищённому соединению WebSocket нужны в типовой браузерной схеме. Это не сводится к «откройте порт для WebSocket»: отдельно проверьте HTTPS-страницу приложения, адрес WSS, сертификат, сетевые правила для сигнализации и медиапотока. Для браузерной страницы безопасный контекст обычно обязателен. Конкретные адреса и порты зависят от схемы размещения, поэтому я сверяю их с действующей конфигурацией, а не копирую чужой список.

Диапазон RTP не является универсальной константой 10000–20000. Его задают в конфигурации конкретной установки Asterisk, а внешние межсетевые экраны и NAT должны пропускать фактически выбранные медиапорты. Проверяю rtp.conf, правила периметра и сопоставление внешнего и внутреннего адресов; затем делаю тест звонка с обеих сторон. Если закрыта сигнализация, звонок может не установиться. Если не проходит медиатрафик, вызов может соединиться без звука или с односторонним звуком. Проверять RTP обычным ping бессмысленно: ICMP-пакет не подтверждает доставку голосового потока. В базе знаний есть типовые примеры диапазона, но они не заменяют настройки вашего сервера.

При проблемах за NAT я смотрю на адреса и порты, которые Asterisk и клиент объявляют друг другу, и на реальные направления медиапакетов. В PJSIP есть параметры для работы с RTP и NAT, но включать их «на всякий случай» без проверки не нужно: сначала установите, где заканчивается маршрут и что видит каждая сторона. При одностороннем звуке сравните адрес назначения в SDP, сетевые правила и приходящие RTP-пакеты. При полном отсутствии звука проверьте, установился ли ICE и завершилось ли согласование DTLS-SRTP. Это более полезный порядок, чем обвинять провайдера по привычке. Если ошибка воспроизводится только на Wi-Fi, сравните её с проводным подключением — иногда ответ лежит на столе, буквально рядом с ноутбуком.

• Уточните версию Asterisk и доступность модулей WebRTC
• Сверьте WSS, сертификат и PJSIP endpoint
• Откройте фактический RTP-диапазон из конфигурации

Кодеки и качество голоса: Opus не волшебная кнопка

Asterisk рекомендует Opus для качественного аудио в WebRTC, но доступность кодека зависит от сборки и модуля codec_opus. Наличие Opus в браузере не означает, что он автоматически доступен на сервере или разрешён в endpoint. Сначала проверяю согласованный кодек в SDP и конфигурации обеих сторон. Если кодеки различаются, Asterisk может потребовать транскодирование — это дополнительная обработка, которая использует ресурсы и способна влиять на задержку и качество. Но нельзя говорить, что любое несовпадение непременно «добавляет секунды»: итог зависит от нагрузки, кодеков и реализации. Проверка списка разрешённых форматов и фактически выбранного кодека обычно полезнее, чем массово менять настройки наугад.

G.711, G.722 и Opus отличаются требованиями и характеристиками; утверждать, что любой софтфон «зациклен» на первых двух, нельзя. G.711 часто проще в совместимости, но для передачи несжатого аудио ему нужна большая полоса, чем некоторым современным кодекам. Opus умеет адаптироваться к условиям сети, однако он не исправит потери, нестабильный Wi-Fi, неверный маршрут RTP или перегрузку АТС. Если звук «роботизируется», я проверяю сетевые потери и джиттер прежде, чем менять кодек. Если пропадает одна сторона речи, кодек редко бывает первым подозреваемым: сначала медиамаршрут и NAT.

Начинаю сравнение со списка допустимых кодеков на клиенте и endpoint Asterisk, затем смотрю, что действительно согласовано для вызова. Проверяю, не включено ли ненужное транскодирование между ногами вызова и не упирается ли сервер в CPU при одновременных звонках. После изменения делаю повторный вызов в тех же условиях и фиксирую, что именно стало лучше: разборчивость, потери или нагрузка. «Стало чище» — полезное наблюдение, но не измерение задержки. Запись разговора может помочь разобрать дефект, однако она не заменяет статистику канала и не всегда отражает, что пользователь слышал в реальном времени.

• Проверьте фактический, а не предполагаемый кодек
• Убедитесь, что сборка Asterisk поддерживает Opus
• Сначала ищите потери и джиттер, потом меняйте кодек

Отказ связи, регистрация и запись звонков

После обрыва сети браузер или софтфон может потерять соединение или SIP-регистрацию. Нельзя обещать, что WebRTC восстановится мгновенно после перезагрузки вкладки: повторное подключение зависит от приложения, состояния АТС, маршрута и логики интеграции. И обратное тоже верно: многие SIP-клиенты автоматически повторяют регистрацию. Поэтому я проверяю не тип клиента в вакууме, а поведение при конкретном сбое: что видит оператор, как быстро приложение регистрируется снова и где отображается пропущенный вызов. Keep-alive и таймауты имеют смысл лишь в контексте конкретного SIP-стека; это не универсальные выключатели стабильности. Автоперезапуск процесса не возвращает автоматически разговор, который уже оборвался.

Запись не зависит от того, нажал ли менеджер кнопку в произвольном софтфоне. В Asterisk можно организовать запись на стороне АТС, в частности приложением MixMonitor() для текущего канала. Но это надо настроить в диалплане и проверить хранение файлов, права доступа, передачу записи в CRM и политику хранения. Интеграция может прикреплять файл к карточке, а может только передавать событие о звонке — возможности зависят от коннектора. Поэтому обещание «запись всегда централизована и уже лежит в amoCRM» без проверки конкретной связки было бы таким же мифом, как кнопка «решить все проблемы». В базе подтверждено назначение MixMonitor, но не утверждения о поведении отдельного продукта Softphone.Pro; это сравнение из текста удалено.

Для условной «Лагуна-Сервис» я бы оформил проверку отказа отдельным сценарием: отключить сеть на тестовом рабочем месте, восстановить её, проверить повторную регистрацию и сделать входящий вызов. Затем проверить, что запись началась, сохранилась на АТС и появилась в нужной карточке, если такая функция предусмотрена коннектором. Ни реальные результаты, ни сроки восстановления здесь не выдумываю: их можно назвать после теста. Такой чек-лист быстро показывает, кто отвечает за каждый участок — браузер, приложение, АТС или интеграция. А если запись теряется только на входящих, расследование надо вести по маршруту именно входящего вызова, не переписывая весь диалплан.

• Проверьте повторное подключение после реального сбоя
• Настройте запись на АТС и проверьте путь файла
• Уточните, что именно коннектор передаёт в amoCRM

Что выбрать компании: короткий порядок решения

Если сотрудники работают за компьютером в поддерживаемых браузерах, а коннектор умеет WebRTC, браузерный клиент сокращает число устанавливаемых программ и упрощает выдачу рабочего места. Это аргумент про удобство сопровождения, не обещание меньшей задержки и не гарантия нулевой стоимости: настройка WSS, сертификатов, телефонии и диагностики всё равно нужна. Софтфон разумен, если организация уже использует управляемые SIP-клиенты, аппаратные телефоны, специфические гарнитуры либо функции, которых нет в браузерной интеграции. Важно сравнивать общую схему: стоимость лицензии, работы администратора и поддержки, совместимость, восстановление после сбоев и доступность отчётов. Нельзя заранее записывать все софтфоны в платные: есть разные продукты и модели лицензирования.

Мой порядок такой: выяснить поддержку WebRTC у интеграции; проверить браузеры и рабочие места; собрать текущую схему сигнализации и медиа; убедиться, что Asterisk настроен на нужный транспорт, кодеки и сетевой маршрут; сделать пробные вызовы; проверить входящие, исходящие, запись и работу после краткого сетевого обрыва. После этого сравнить с SIP-клиентом на тех же рабочих местах. Если WebRTC удобнее и проходит проверку, оставляем его. Если в конкретной сети он нестабилен или нужной функции нет, не превращаем выбор технологии в религию: оставляем софтфон или используем оба варианта по ролям. У телефона нет моральных предпочтений.

В диагностике я опираюсь на наблюдаемое: приложение запускает вызов, Asterisk видит сигнализацию, медиапоток проходит в обе стороны, согласуется ожидаемый кодек, запись попадает туда, где её ищет сотрудник. Любой сбой привязываю к одному шагу и воспроизвожу повторно. Для сравнения телефонии полезно сначала понять как связаны Asterisk и CRM, а при проблеме с маршрутизацией посмотреть ошибки в PJSIP. Так можно принять решение по своей инфраструктуре, а не по лозунгу «браузер всегда быстрее».

• WebRTC — когда поддерживается интеграцией и удобен браузерный сценарий
• Софтфон — когда важны SIP-клиент или функции вне браузера
• Выбор — после одинакового теста вызова, аудио и записи

Частые вопросы