Как использовать SIP-параметр Diversion для умного перенаправления звонков

Представьте ситуацию: клиент звонит вам, а ваш менеджер в этот момент занят или находится вне офиса. Система перенаправляет звонок на голосовую почту или, что хуже, на другого специалиста, который понятия не имеет, что у этого клиента за проблема. Клиент раздражен, вы теряете время, а качество сервиса падает.

В мире телефонии есть мощный инструмент, который решает эту проблему на уровне самого протокола передачи сигнала. Это SIP-параметр Diversion. Если говорить простым языком, это «невидимая записка», которую телефонная система оставляет в пакете звонка, чтобы везде, где бы он ни прошел, система знала: «Этот звонок изначально звонил сюда, а потом был перенаправлен». Многие инженеры игнорируют этот параметр, считая его техническим шумом, но на практике именно он позволяет настроить связку колл-центра и офисной АТС так, чтобы звонки не терялись и обрабатывались правильно.

В этой статье мы разберем, как именно использовать Diversion, чтобы перенаправление звонков работало прозрачно, комфортно для оператора и эффективно для бизнеса. Без лишней теории про RFC-документы — только практика.

Почему обычного перенаправления часто недостаточно

Когда вы настраиваете переадресацию (например, «если менеджер не ответил, переведи на старшего»), вы, вероятно, используете стандартные механизмы SIP-перенаправления. Чаще всего это происходит через заголовок History-Info или просто через изменение поля Request-URI. Но есть нюанс.

Без параметра Diversion (или его аналога X-Diversion в некоторых провайдерах) принимающая сторона видит звонок как новый входящий вызов. Система колл-центра думает: «О, новый звонок от абонента 8-900…». Она не знает, что этот звонок уже был, что он уже направлялся на голосовую почту, что он был перенаправлен с другого номера.

Именно здесь кроется главная боль. Если вы не передаете эту историю, вы не сможете:

• Показать оператору историю перенаправления (откуда пришел звонок).
• Настроить правильную маршрутизацию (например, не перенаправлять звонок на голосовую почту дважды).
• Правильно вести статистику (определить, кто именно инициировал перенаправление).

Параметр Diversion решает эту задачу. Он содержит информацию о том, на какой номер изначально был предназначен звонок, и кто его перенаправил. Это позволяет колл-центру видеть полную картину до того, как оператор поднимет трубку.

Как работает механизм Diversion на практике

Давайте разберем механику процесса. Когда вы звоните, ваш телефон отправляет пакет SIP INVITE. В нем есть заголовок From (кто звонит) и To (кому звоним). Если звонящий не дозвонился и звонок перенаправляется на колл-центр, сервер-посредник (прокси) может добавить в этот пакет специальный заголовок.

Вот пример того, как это выглядит «под капотом» (в коде SIP-пакета):

Diversion: ;reason=no-answer;counter=1

Разберем это поле по частям, чтобы понимать, что вы настраиваете:

• URI (sip:+7999…) — это номер, на который изначально звонили. Именно этот номер должен быть виден оператору, чтобы он понимал контекст.
• reason (причина) — почему звонок перенаправляется. Это может быть no-answer (нет ответа), busy (занят), unconditional (всегда) или out-of-service (недоступен).
• counter (счетчик) — сколько раз звонок уже перенаправлялся. Это критически важно, чтобы избежать бесконечных петель.

Когда звонок доходит до вашего колл-центра, программное обеспечение (например, Asterisk, FreeSWITCH или облачная АТС) считывает этот заголовок. Если оно настроено правильно, оно не просто показывает номер клиента, но и всплывает подсказка: «Клиент звонил на прямой номер менеджера, он не ответил, звонок перенаправлен сюда».

Сценарии использования: когда Diversion реально нужен

Не во всех случаях этот параметр критичен. В малом бизнесе, где звонок идет напрямую на мобильный, он часто не заметен. Но в задачах колл-центра, где звонки проходят сложную цепочку маршрутизации, Diversion становится ключевым.

Сценарий 1: «Бесшовная» переадресация на горячую линию

Менеджер уходит в отпуск или болеет. Администратор ставит переадресацию на общих операторов. Клиент звонит менеджеру, слышит «недоступен», и звонок идет в общую очередь. Без Diversion оператор видит звонок как «Входящий на общий номер». С Diversion оператор видит: «Исходящий звонок на менеджера Петрова, перенаправлен в очередь». Это меняет скрипт общения. Оператор сразу говорит: «Здравствуйте, я вижу, вы пытались связаться с Петровым, как я могу помочь?» — это намного прохладнее, чем обычное «Алло, слушаю вас».

Сценарий 2: Предотвращение петель (Loop Prevention)

Это классическая проблема. Представьте: вы звоните на номер А. Номер А не отвечает, перенаправляет на номер Б. Но номер Б тоже не отвечает и перенаправляет обратно на номер А. Если система не видит, что звонок уже был на номере А, она снова перенаправит его на Б. И так далее, пока не закончится время тик-аута или не исчерпается лимит попыток. Параметр counter в заголовке Diversion растет с каждым витком. Как только он достигает значения 5 или 6, любая грамотная телефонная система должна сбросить звонок, чтобы не грузить сеть.

Сценарий 3: Умная статистика

Вам нужно знать, какой процент звонков на прямые линии менеджеров не доходит до них и уходит в колл-центр. Обычные логи показывают, сколько звонков пришло на общий номер. А вот с Diversion вы можете сделать точную выгрузку: «Всего звонков на Петрова — 100, перенаправлено в колл-центр — 30». Это позволяет понять, к чему готовиться менеджеру, если его вернут на линию.

Технические нюансы настройки

Внедрение Diversion требует внимания к конфигурации вашей SIP-телефонии. Здесь нет кнопки «Включить Diversion», нужно понимать, как взаимодействуют компоненты.

Основная сложность заключается в том, что разные производители оборудования интерпретируют этот параметр по-разному. В стандарте SIP (RFC 5806) описан заголовок History-Info, который считается более современным, но многие старые и простые системы до сих пор используют Diversion (из RFC 4458) или проприетарные заголовки (например, X-Diversion).

Если вы настраиваете это самостоятельно, вам нужно проверить три точки:

1. Исходная АТС (отправитель). Она должна уметь формировать заголовок Diversion при активации переадресации. В конфиге (например, в Asterisk это context или extensions.conf) нужно убедиться, что при переходе на другой номер (GoSub или Goto) параметр не удаляется.
2. Транзитный провайдер (SIP Trunk). Часто провайдеры «чистят» заголовки, которые считают лишними или потенциально опасными (например, чтобы не подменить номер). Вам нужно проверить, проходит ли заголовок через шлюз провайдера. Иногда требуется добавить правило в SIP-фильтре провайдера: «Разрешить заголовок Diversion».
3. Приемная АТС (колл-центр). Программа должна уметь читать этот заголовок и отображать его в интерфейсе оператора. Обычно для этого используется модуль CRM или виджет, который парсит SIP-пакет.

Сравнение подходов: Diversion против History-Info

Часто возникает вопрос: использовать классический Diversion или переходить на новый стандарт History-Info? Давайте сравним, чтобы вы могли принять решение.

Критерий	Diversion (RFC 4458)	History-Info (RFC 4244)
Совместимость	Высокая. Поддерживается большинством старых и новых систем (Cisco, Avaya, Asterisk).	Средняя. Лучше поддерживается современными сетями, но требует поддержки обеими сторонами.
Информативность	Ограниченная. Показывает только конечный пункт перенаправления и причину.	Высокая. Позволяет видеть полную цепочку всех перенаправлений (историю).
Сложность настройки	Низкая. Простой заголовок, легко настраивается в простых скриптах.	Высокая. Требует правильной работы с индексами и вложенностью.
Идеальный сценарий	Простая переадресация «здесь и сейчас» (на голосовую почту или на департамент).	Сложные маршруты в крупных корпорациях, где важно видеть весь путь звонка.

Если вы строите небольшую систему или используете оборудование, которое не обновлялось 3–5 лет, лучше сосредоточиться на Diversion. Если у вас современная IP-телефония с поддержкой сквозной аналитики — пробуйте внедрять History-Info, но имейте запасной вариант на случай, если провайдер его обрезает.

Частые ошибки при настройке

В реальной практике настройки колл-центров я сталкивался с ошибками, которые превращают полезный инструмент в проблему. Вот на что стоит обратить внимание, чтобы не наломать дров:

1. Удаление заголовков провайдером.
Это самая частая причина «не работает». Провайдеры часто фильтруют входящие заголовки, если они не входят в белый список. Если вы видите, что звонок перенаправляется, но на стороне колл-центра нет информации о предыдущем номере, проверьте логи на шлюзе. Скорее всего, заголовок Diversion удаляется на входе в сеть оператора связи. Решение: написать в техподдержку провайдера с требованием не удалять заголовок Diversion (и P-Asserted-Identity).

2. Конфликт с номером отображения (Caller ID).
Иногда система пытается подменить номер звонящего на номер того, с кого идет перенаправление. В результате оператор видит не номер клиента, а номер менеджера, с которого перенаправили звонок. Это ошибка. Параметр Diversion должен содержать номер клиента в поле From и номер перенаправляемого в поле Diversion. Всегда проверяйте, кто именно показывается в окне звонка.

3. Бесконечный цикл.
Если настройка перенаправления сделана жестко (например, «всегда перенаправлять на номер Х»), а на номере Х тоже стоит перенаправление обратно, включите счетчик. Если ваша АТС не умеет проверять counter в заголовке Diversion, лучше ограничить количество попыток перенаправления на уровне логики (например, «максимум 2 перенаправления»). Иначе звонок будет бегать по кругу, «съедая» ресурсы системы.

4. Игнорирование причины.
Некоторые системы просто передают звонок, не записывая причину перенаправления. В результате оператор не понимает, почему клиент попал к нему. Если звонок перенаправлен из-за «занято», скрипт должен быть одним, если из-за «недоступен» — другим. Убедитесь, что параметр reason передается корректно.

Как выбрать решение для вашей ситуации

Чтобы не запутаться в технических деталях, используйте этот простой алгоритм выбора стратегии:

• Если у вас малый бизнес (до 10 сотрудников) и вы используете облачную АТС.
  Вам, скорее всего, не нужно копаться в SIP-пакетах. Современные облачные АТС (например, Мегафон, МТС, RingCentral) уже имеют встроенную логику «История звонка». Настройте переадресацию в интерфейсе «Настройки -> Переадресация», и система сама передаст нужные данные. Ищите в меню «Показать историю перенаправления» или «Источник звонка».
• Если у вас своя АТС (Asterisk, FreeSWITCH, 3CX) и свой SIP-транк.
  Здесь вам придется вступать в мир конфигурационных файлов. Вам нужно найти место в коде (обычно это контекст переадресации), где формируется ответ на звонок. Добавьте туда команду сохранения заголовка Diversion. Для Asterisk это часто делается через переменные DB или напрямую через сокет SIP. Пример: SIPAddHeader(Diversion: ;reason=no-answer).
• Если вы интегрируете колл-центр с CRM.
  Это самый ответственный момент. Ваша CRM должна уметь читать SIP-заголовки или получать их через CTI-мост. Если CRM не видит Diversion, она не сможет подгрузить карточку клиента. В этом случае обязательно проверьте документацию вашего CTI-моста: поддерживает ли он передачу заголовков Diversion в карточку клиента. Если нет, возможно, потребуется доработка на стороне разработчика CRM.

Практические рекомендации: как сделать лучше

Чтобы система работала стабильно и не вызывала головной боли, следуйте этим советам:

1. Тестируйте «вслепую». Не настраивайте перенаправление сразу на живых менеджеров. Заведите тестовый номер, который всегда идет на голосовую почту или в очередь. Позвоните с него, посмотрите, что приходит на принимающую сторону.

2. Используйте логи. Включите детальное логирование SIP-пакетов на промежуточных узлах. В Asterisk это core set verbose 10 или включение логгера sip. Вы увидите реальный заголовок, который проходит по сети. Это единственный способ понять, где именно он теряется.

3. Договоритесь с провайдером. Перед запуском обязательно уточните у провайдера, поддерживает ли он передачу заголовков Diversion и History-Info. Многие провайдеры по умолчанию их «режут» в целях безопасности, и без их воли вы не передадите данные.

4. Визуализируйте. Самое важное — это то, что видит оператор. Если в заголовке Diversion есть данные, но оператор их не видит — это провал. Настройте интерфейс так, чтобы информация из заголовка выводилась крупным шрифтом или подсвечивалась цветом. Например, «Перенаправлено с номера +7900…».

5. Не доверяйте слепо. Всегда проверяйте, что перенаправление не создает конфликтов с другими правилами маршрутизации. Иногда правило «если занят, на почту» конфликтует с правилом «если звонит VIP, всегда соединять». Убедитесь, что приоритеты расставлены верно.

Итог

Параметр Diversion — это не просто техническая деталь протокола SIP, это инструмент, который делает звонки «умными». Он позволяет колл-центру видеть не только число, которое звонит, но и историю этого вызова. Это экономит время оператора, улучшает сервис для клиента и помогает избежать хаоса в маршрутизации.

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

Информация в статье носит ознакомительный характер и основана на общих принципах работы SIP-протокола. При настройке реальных телефонных систем учитывайте специфику вашего оборудования и требования провайдера связи. Неправильная конфигурация может привести к сбоям в работе телефонии.