Hangup анализ и логика событий

hangup с Bridged=no

hangup-ы от IVR или Очереди интерпретируются как пропущенные вызовы только в случае
наличия в событии [Bridged] => no.
Это происходит в 100% случаев, не смотря на то, что в рамках глобального [CallID] может быть ситуация, когда первым событием такого вызова был dial-out с последующим answer-ом

(пример - ситуация, когда скрипт веб звонка с сайта генерирует вызовы от имени добавочного, который указан в настройках интеграции и связан с одним из пользователей CRM)

В этом случае всегда:
CallerIDNum - Внешний номер(АОН/номер звонящего) по которому вызов регистрируем в CRM
CalledExtension - номер добавочного, на уровне которого вызов был пропущен, IVR или Очередь.

hangup от очереди приоритетнее (hangup от ИВР-а с таким же [CallID] в этом случае игнорируется)

В событии:

453*099@доменАТС, берем из него только то, что до собаки(@).
CalledDID - источник вызова(вызываемый извне номер, посредством которого вызов попал в АТС)
Статус вызова в CRM указываем как пропущенный.
Все события с указанием [Bridged] => yes - всегда игнорируем!
Эта логика уже успешно работает сейчас в нескольких интеграциях

Примечание:

• при hangup от ИВР-а с глобальным [CallID], уникальным в рамках всего вызова в АТС, отслеживание вызова заканчивается целиком. НО, учитывая то, что hangup от Очереди(а он для нас приоритетнее) может прилететь на доли секунды позже hangup-а ИВР-а, то будет не лишней задержка в пару секунд, с тем, чтобы в CRM отдать(!в случае если ответа на вызов не было!) добавочный очереди, а не ИВР-а.

• если вызов проходил через несколько очередей и по всем ним прилетел Хэнгап+хэнгап от ИВР-а, то берем для статистики хэнгап от последней очереди!