Логика событий на внутренних номерах
В этом подразделе указан порядок анализа событий на внутренних номерах, несоблюдение последовательности которого может привести к некорректному поведению интеграции.
Успешный вызов имеет CallStatus=ANSWER, неуспешные вызовы: CallStatus=CANCEL (вызов отменен звонящим), CallStatus=BUSY (вызываемый номер занят). Возможны иные варианты. Такие вызовы не должны попадать в CRM-систему как успешные.
Входящие вызовы
(событие “dial-in” на внутреннем номере в рамках его SubCallID)
CalledNumber ‒ внутренний номер, на который поступил данный входящий вызов. Его пользователю в CRM-системе при получении события “dial-in” нужно вывести уведомление с указанием связанной с ним в CRM-системе сущности, которая была определена CRM-системой в ответ на запрос с номером из CallerIDNum.
Дальнейшая регистрация вызова в CRM-системе осуществляется с указанием того пользователя, которому соответствует внутренний номер из CalledNumber, но только если данный вызов был принят внутренним номером (в рамках данного SubCallID было событие “answer”).
По событию “answer”, следующему за “dial-in”, мы понимаем, какой именно внутренний номер принял этот вызов. Если обзвон внутренних номеров происходил параллельно, то по остальным SubCallID данного вызова в рамках глобального CallID АТС отдаст события “hangup”, по которым нужно скрывать уведомления об этом входящем вызове у остальных пользователей CRM-системы (т.к. для них он уже будет не актуален), или вывести новое уведомление с указанием того, что данный вызов был принят другим внутренним номером (в случае, если скрыть предыдущее не представляется возможным).
При наступлении события “answer” соединение установлено. После события “hangup” с таким же SubCallID данные об этом входящем вызове передаются в CRM-систему:
Duration ‒ длительность,
RecID ‒ ID записи разговора,
CalledDID ‒ источник вызова (номер, посредством которого вызов попал в АТС).
Можно вывести пользователю CRM-системы, связанному с CalledNumber, уведомление об окончании его диалога с CallerIDNum.
Все вызовы, по которым после события “dial-in” было получено событие “answer” и которые не относятся к локальным вызовам АТС, несмотря на наличие "[Bridged] => no" в событии “hangup” от голосового меню или очередей в рамках глобального CallID, фиксируются в CRM-системе с регистрацией по SubCallID.
Если CallerIDNum события “dial-in” равен внутреннему номеру данной АТС, то такие вызовы игнорируются как локальные звонки, если не указано иного по дополнительному параметру ниже.
Если CallerIDNum события “dial-in” равен внутреннему номеру данной АТС, но присутствует параметр RemoteNumber, то такой вызов принимается в обработку интеграцией, а значение из RemoteNumber используется в качестве номера звонящего (вместо CallerIDNum) при регистрации вызова в CRM-системе.
Если CallerIDNum события dial-in не равен внутреннему номеру данной АТС, то такие вызовы всегда принимаются к обработке интеграцией.
Исходящие вызовы
(событие “dial-out” на внутреннем номере в рамках его SubCallID)
CallerExtension — внутренний номер ‒ инициатор исходящего вызова. Имеет формат вида: префикс_клиента*имя_внутреннего@имя_домена_АТС, указываем только префикс_клиента*имя_внутреннего.
Пользователю данного внутреннего номера в CRM-системе при получении события “dial-out” нужно вывести уведомление об исходящем вызове с указанием связанной с ним в CRM-системе сущности, которая была указана в CalledNumber. Дальнейшая регистрация вызова в CRM-системе осуществляется с указанием того пользователя, которому соответствует внутренний номер из CallerExtension.
Логика событий
Если CalledNumber события “dial-out” равен внутреннему номеру данной АТС, то такие вызовы мы по умолчанию игнорируем как локальные звонки.
Если CalledNumber события “dial-out” не равен внутреннему номеру данной АТС, то такие вызовы всегда принимаются к обработке интеграцией и данные о них регистрируются в CRM-системе.
Все вызовы, по которым после события “dial-out” был получен answer, и которые не относятся к локальным вызовам АТС, несмотря на наличие "Bridged => no" в hangup от IVR/Очередей в рамках глобального CallID, заносятся в CRM-систему с регистрацией по SubCallID.
Получение события “answer” означает, что соединение установлено (возможно, нужно передать дополнительное уведомление в CRM-систему для вывода звонящему пользователю, связанному с CallerExtension, требующейся дополнительной информации). При наступлении события “hangup” с таким же SubCallID данные об этом исходящем вызове передаются в CRM-систему:
Duration — длительность,
RecID — ID записи разговора,
CalledDID — источник вызова (вызываемый извне номер, посредством которого вызов попал в АТС).
Можно вывести пользователю CRM-системы, связанному с CallerExtension, уведомление об окончании его диалога с CalledNumber.
Прекращение вызова
Анализ пропущенных вызовов
(событие “hangup” с Bridged=no)
События типа “hangup” от IVR или Очереди интерпретируются как пропущенные вызовы только в случае наличия в событии Bridged => no.
Это происходит во всех случаях, несмотря на то, что в рамках глобального CallID может быть ситуация, когда первым событием такого вызова было событие “dial-out” с последующим событием типа “answer” (например, когда скрипт веб-звонка с сайта генерирует вызовы от имени внутреннего номера, который указан в настройках интеграции и связан с одним из пользователей CRM-системы).
В этом случае всегда:
CallerIDNum — внешний номер (АОН/номер звонящего), по которому вызов регистрируется в CRM-системе,
CalledExtension — внутренний номер, на уровне которого вызов был пропущен, IVR или Очередь. Событие “hangup” от очереди приоритетнее, в этом случае событие “hangup” от IVR с таким же CallID игнорируется.
CalledDID — источник вызова (вызываемый извне номер, посредством которого вызов попал в АТС).
Статус вызова в CRM-системе нужно указать как пропущенный.
Все события с указанием Bridged => yes — всегда игнорируются.
Примечание:
при “hangup” от IVR с глобальным CallID, уникальным в рамках всего вызова в АТС, отслеживание вызова заканчивается целиком. Но т.к. событие “hangup” от Очереди (а оно является более приоритетным) может произойти на доли секунды позже события “hangup” от IVR, то будет не лишней задержка в пару секунд для того, чтобы CRM-системе отдать (в случае, если ответа на вызов не было) внутренний номер Очереди, а не IVR.
если вызов проходил через несколько очередей и по всем ним произошло событие “hangup”, а также произошло событие “hangup” от IVR, то для статистики берется “hangup” от последней очереди.
Фиксация статистики по hangup
По hangup можно фиксировать статистику в CRM. Например, соотнеся hangup по SubCallID с соответствующим dial-in
При входящем звонке последний hangup на ivr и на добавочном может быть сгенерирован в один и тот же eventTime
← События на внутренних номерах Функционирование интеграции →