Hangup analysis and logic of events

Hangups with Bridged=no Hangups from IVR or Queue are interpreted as missed calls only if the event contains [Bridged] => no. This occurs in 100% of cases, despite situations where within the global [CallID], the first event of such a call was a dial-out followed by an answer.

(example - a scenario where a website call script generates calls on behalf of an extension specified in the integration settings and associated with one of the CRM users)

In this case, always:

• CallerIDNum - The external number (CLI/caller's number) by which the call is logged in the CRM

• CalledExtension - The extension number at which the call was missed, IVR, or Queue.

A hangup from the queue takes precedence (a hangup from IVR with the same [CallID] is ignored in this case)

In the event:

• From "453*099@PBXdomain", only the part before the "@" is considered.

• CalledDID - Call source (the number called from outside, through which the call entered the PBX)

• The call status in CRM is marked as missed.

• All events with [Bridged] => yes are always ignored!

• This logic is already successfully implemented in several integrations.

Note:

• When there's a hangup from IVR with a global [CallID], unique within the entire call in the PBX, call tracking ends entirely. However, given that a hangup from the Queue (which is a priority for us) might arrive fractions of a second after the IVR's hangup, a delay of a few seconds wouldn't be amiss to ensure that, in the CRM (if there was no answer to the call), the extension from the queue is logged, not from the IVR.

• If the call went through several queues and hangups came from all of them plus a hangup from IVR, the hangup from the last queue is used for statistics!