Как использовать SIP-параметр “Diversion” для перенаправления звонков в колл-центр без потери контекста

Как использовать SIP-параметр “Diversion” для перенаправления звонков в колл-центр без потери контекста

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

Если вы управляете колл-центром на базе SIP-инфраструктуры (Asterisk, FreeSWITCH, Cisco CUCM, 3CX и т.п.) — и хотите, чтобы звонки перенаправлялись так, чтобы агенты видели всю историю, а не только номер звонящего — читайте дальше. Я покажу, как это работает на практике, где ошибаются чаще всего, и как настроить это правильно, чтобы снизить время обработки звонков на 20–40%.

Что такое Diversion и зачем он нужен

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

• Кто перенаправил звонок?
• Когда и почему?
• Какой номер был первоначально набран?

Это не просто лог. Это данные, которые CRM-система может использовать, чтобы показать агенту: «Этот клиент уже звонил 3 минуты назад, его вопрос передали от оператора по продажам, потому что он уточнил условия возврата товара».

Без Diversion вы получаете только From — номер звонящего. С Diversion — вы получаете путь звонка. И это кардинально меняет подход к обслуживанию.

Как это работает на практике — пример

Представьте сценарий:

1. Клиент звонит на общий номер: +7 (495) 123-45-67.
2. Автоматический ответчик предлагает выбор: «1 — продажи, 2 — поддержка».
3. Клиент выбирает «2» — звонок перенаправляется на группу поддержки.
4. Но поддержка не может решить вопрос — передаёт на инженера.
5. Инженер видит: «Звонок от +7 (495) 123-45-67, перенаправлен от группы поддержки (ID: support-03), причина: требует технического вмешательства».

Всё это — благодаря заголовку Diversion. Он выглядит примерно так:

Diversion: <sip:support-03@pbx.company.local>;reason=unconditional;screen=no;counter=1
Diversion: <sip:+74951234567@pbx.company.local>;reason=unconditional;screen=no;counter=2

Здесь:

• reason=unconditional — означает, что перенаправление произошло без условия (например, не было ответа).
• screen=no — система не проверяла, кто звонит (это важно для приватности).
• counter — сколько раз звонок уже перенаправлялся.

CRM-система (например, Bitrix24, Salesforce, или кастомная на базе OpenCTI) читает этот заголовок, и на экране агента появляется не просто «Поступил звонок от +7 (495) 123-45-67», а:

Звонок перенаправлен:
От: +7 (495) 123-45-67 → Поддержка (support-03) → Инженер
Причина: запрос на техническую поддержку
Время первого входа: 14:03
Длительность предыдущего разговора: 2 мин 18 сек

Агент не спрашивает: «Что случилось?» — он уже знает. И это экономит 1–3 минуты на каждом звонке.

Когда Diversion работает, а когда — нет

Не все системы поддерживают Diversion. И не все перенаправления его передают. Вот что важно понимать:

Ситуация	Diversion передаётся?	Почему
Перенаправление между агентами в одном PBX (Asterisk → FreeSWITCH)	Да, если настроено	Оба PBX понимают SIP-стандарт и корректно генерируют заголовок
Перенаправление через облачный сервис (например, Twilio → ваш PBX)	Редко	Облако часто обрезает заголовки для «безопасности» или из-за упрощённой логики
Перенаправление через мобильную сеть (VoLTE → SIP)	Нет	Мобильные операторы не передают SIP-заголовки между сетями
Перенаправление по расписанию (например, после 18:00 — на внешнюю службу)	Да, если настроено в PBX	Технически возможно, но часто игнорируется при настройке
Перенаправление через IVR (автоответчик)	Да, если IVR поддерживает SIP-расширения	Некоторые дешёвые IVR просто «переключают» номер, не генерируя Diversion

Если вы используете облачный колл-центр (например, Callbell, CloudTalk, Zadarma) — проверьте документацию. Многие из них не передают Diversion, потому что их логика построена на «номер звонящего — это всё, что нужно». Это удобно для простых сценариев, но не для сложных.

Как настроить Diversion в популярных системах

Вот как это делается на практике — без теории, только рабочие шаги.

1. Asterisk

В файле /etc/asterisk/sip.conf или в диалплане (extensions.conf) добавьте:

exten => _X.,1,NoOp(Перенаправление звонка)
 same => n,Set(DIVERSION_REASON=unconditional)
 same => n,Set(DIVERSION_SCREEN=no)
 same => n,Set(DIVERSION_COUNTER=IF([LEN({DIVERSION_COUNTER})}>0]?${DIVERSION_COUNTER}+1:1)})
 same => n,Set(DIVERSION=${DIVERSION_COUNTER})
 same => n,Dial(SIP/support-team/${EXTEN},30)
 same => n,Hangup()

Или, если перенаправляете через Queue:

exten => 123,1,Queue(support-team,tT)
 same => n,Set(DIVERSION_REASON=busy)
 same => n,Set(DIVERSION=${SIP_HEADER(Diversion)})
 same => n,Dial(SIP/engineer/${EXTEN})

Важно: Set(DIVERSION=...) — это не стандартная переменная. Вам нужно добавить в func_odbc.conf или использовать func_sipdiversion.so — модуль, который позволяет работать с этим заголовком. Без него — Diversion не будет генерироваться.

2. FreeSWITCH

В диалплане (default.xml):

<extension name="transfer_to_support">
  <condition field="destination_number" expression="^123$">
    <action application="set" data="diversion_reason=unconditional"/>
    <action application="set" data="diversion_screen=no"/>
    <action application="set" data="diversion_counter=count({diversion_counter})}"/>
    <action application="bridge" data="sofia/internal/support-team@yourdomain.com"/>
  </condition>
</extension>

FreeSWITCH поддерживает Diversion по умолчанию, но только если вы не используете transfer без параметров. Всегда используйте bridge с явными настройками.

3. Cisco CUCM

В интерфейсе: Call Routing → Route Plan Report → найдите нужный маршрут → нажмите «Edit» → в разделе Forward and Transfer Options включите:

• Enable Diversion Header — да
• Diversion Reason — Unconditional
• Diversion Screening — No

И обязательно проверьте, что в Device Pool для всех устройств включена опция Allow Diversion Header.

4. 3CX

3CX — сложный случай. Он не позволяет напрямую настраивать Diversion через GUI. Но можно обойти это через:

1. Создать Custom SIP Header в правилах маршрутизации (в разделе «Advanced»).
2. Использовать Custom IVR с HTTP-запросом к внешнему скрипту, который добавляет Diversion в SIP-пакет.
3. Или — если вы используете 3CX в режиме «SIP trunk» — настроить Diversion на стороне шлюза (например, на Cisco или Grandstream).

Если вы используете 3CX — будьте готовы к костылям. Это не встроенный функционал, а обходной путь.

Частые ошибки — и как их избежать

Вот что ломает Diversion чаще всего:

• Не проверяете, передаётся ли Diversion. Просто включили — и думаете, что всё работает. Проверьте через Wireshark или tcpdump — ищите заголовок Diversion в SIP-пакете.
• Используете перенаправление через «перевод звонка». В Asterisk это Dial(...,T) — он не генерирует Diversion. Нужно Bridge или Queue.
• Перенаправляете на внешний номер (например, на мобильный). Diversion не передаётся в мобильные сети. Это нормально — но если вы ожидаете, что агент на телефоне увидит историю — не ждите этого.
• Игнорируете порядок заголовков. Diversion должен быть в SIP-запросе до From. Если система его перезаписывает — вы теряете контекст.
• Считаете, что Diversion — это «дополнительная фича». Нет. Это ключевой элемент для сложных сценариев. Без него вы работаете как в 2005 году.

Что выбрать в зависимости от ситуации

Вот как принимать решение:

• Если у вас простой колл-центр (10–20 линий, один уровень поддержки) — Diversion не нужен. Достаточно номера звонящего. Не тратите время на настройку.
• Если у вас 3+ уровня поддержки, или звонки перекидываются между отделами (продажи → поддержка → бухгалтерия) — Diversion обязателен. Без него вы теряете 15–30% эффективности.
• Если вы используете облачный сервис (Twilio, Vonage, CloudTalk) — проверьте документацию. Если Diversion не поддерживается — думайте о переходе на собственный PBX или о кастомной интеграции через API.
• Если клиенты звонят с мобильных — Diversion не будет работать при перенаправлении через сотовую сеть. Но он будет работать между вашими серверами. Это уже лучше, чем ничего.
• Если вы интегрируете с CRM — убедитесь, что CRM умеет читать Diversion. Некоторые системы (например, Bitrix24) требуют плагина или кастомного скрипта.

Как лучше сделать — практические рекомендации

Вот что реально работает:

1. Начните с логирования. Включите SIP-логи на вашем PBX и найдите пример звонка, который перенаправляется. Проверьте, есть ли в нём Diversion. Если нет — ищите причину.
2. Используйте только Bridge, а не Transfer. Transfer — это «бросить звонок», а Bridge — «передать с контекстом».
3. Сделайте единый шаблон для всех перенаправлений. Например: reason=unconditional — для всех автоматических перенаправлений, reason=busy — если агент занят, reason=unavailable — если не отвечает.
4. Интегрируйте Diversion с CRM. Если CRM не читает его — напишите простой скрипт на Python или Node.js, который ловит SIP-заголовок и записывает его в поле «История перенаправлений».
5. Тестируйте с реальными звонками. Не на тестовом номере — на настоящем. Звоните с телефона, перенаправляйте, смотрите, что видит агент.
6. Обучите агентов. Они должны понимать, что Diversion — это не «техническая магия», а инструмент, который показывает им, что уже сделали до них. Это снижает стресс и повышает доверие к системе.

Итог: что делать прямо сейчас

Если вы управляете колл-центром с 3+ уровнями поддержки — и звонки перекидываются между отделами — Diversion — это не опция. Это необходимость.

Вот что вам нужно сделать в ближайшие 48 часов:

1. Проверьте, передаётся ли Diversion в вашей системе — с помощью Wireshark или логов PBX.
2. Если нет — найдите, почему: неправильный тип перенаправления, отключённая опция в PBX, или ограничение облачного провайдера.
3. Настройте Diversion в одном маршруте (например, «звонок с IVR → поддержка»).
4. Подключите этот заголовок к CRM — даже если через простой скрипт.
5. Проведите тест: звоните сами, перенаправляйте, смотрите, что видит агент. Если он видит контекст — вы победили.

Это не займёт больше 2–3 часов. Но сэкономит вам 10–20 часов в неделю на повторных вопросах, недопонимании и раздражённых клиентах.

Diversion — это не про технологии. Это про то, чтобы клиенту не приходилось рассказывать одну и ту же историю три раза. И вы — тот, кто может это исправить.

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