Event Logic on Extension Numbers
This subsection specifies the order to analyze extension number events. Failure to follow the sequence of this order may lead to incorrect integration behavior.
A successful call has status CallStatus = ANSWER, unsuccessful calls have statuses CallStatus=CANCEL (the call was canceled by the caller), CallStatus = BUSY (the called number is busy). Other options are possible too. Such calls should not go to the CRM system as successful ones.
Incoming Calls
(the "dial-in" event on an extension number within its SubCallID)
CalledNumber is the extension number that has received this incoming call. When a "dial-in" event is received, you should display for its user in the CRM system a notification indicating the entity that is associated with it in the CRM system and that was determined by the CRM system in response to a request with a number from CallerIDNum.
Further registration of the call in the CRM system is carried out with indication of the user matched to the extension number from CalledNumber, but only if this call was accepted by the extension number (within the scope of this SubCallID there was an “answer” event).
By the "answer" event following the "dial-in" event, we understand what extension number received this call. If the extension numbers were called in parallel, then the PBX will issue for the rest of the call subCallID within the global CallID the "hangup" events that should be used to hide notifications on this incoming call for other users of the CRM system (because it is no longer relevant for them) or to display a new notification indicating that the call was accepted by another extension number (if it is not possible to hide the previous one).
When the "answer" event occurs, the connection is established. After the "hangup" event with the same SubCallID, the following data about this incoming call is transmitted to the CRM system:
Duration ‒ duration,
RecID ‒ call recording ID,
CalledDID ‒ the call source (the number used to direct the call to the PBX).
You can display a notification to the CRM system user associated with CalledNumber about the dialogue end with CallerIDNum.
All calls that the "answer" event after the "dial-in" event was received for and that are not local PBX calls, despite presence of "[Bridged] => no" in the "hangup" event from the voice menu or queues within global CallID, are recorded in the CRM system by SubCallID.
If the CallerIDNum of the "dial-in" event is equal to the extension number of this PBX then such calls are ignored as local calls, unless otherwise is specified by the additional parameter below.
If the CallerIDNum of the "dial-in" event is equal to the extension number of this PBX, but the RemoteNumber parameter is present, then such a call is accepted for processing by the integration, and the RemoteNumber value is used as the caller number (instead of CallerIDNum) when recording the call in the CRM system.
If the CallerIDNum of the "dial-in" event is not equal to the extension number of this PBX, then such calls are always accepted for processing by the integration.
Outgoing Calls
(the "dial-out" event on an extension number within its SubCallID)
CallerExtension ‒ extension number that is the originator of the outgoing call. It has the following format: client_prefix*internal_name @PBX_domain_name, specify only the client_prefix*internal_name.
Upon receiving a "dial-out" event, you should display for the user of this extension number in the CRM system a notification about the outgoing call with indication of the entity that is associated with it in the CRM system and that was specified in the CalledNumber. The further call registration in the CRM system is carried out with indication of the user whom the extension number from the CallerExtension corresponds to.
Event Logic
If the "dial-out" event CalledNumber is equal to the extension number of this PBX, then we by default ignore such calls as local calls.
If the "dial-out" event CalledNumber is not equal to the extension number of this PBX, then such calls are always accepted for processing by the integration and their data is recorded in the CRM system.
All calls that the "answer" event after the "dial-out" event was received for and that are not local PBX calls, despite presence of "[Bridged] => no" in the "hangup" event from the IVR/queues within global CallID, are recorded in the CRM system by SubCallID.
The "answer" event receiption means that the connection was established (may be you should to send an additional notification to the CRM system to display the required additional information to the callee associated with CallerExtension). After the "hangup" event with the same SubCallID, the following data about this outgoing call is transmitted to the CRM system:
Duration — duration,
RecID — call recording ID,
CalledDID — the call source (the number called from outside and used to direct the call to the PBX).
You can display a notification to the CRM system user associated with CallerExtension about the dialogue end with CallerIDNum.
Call Termination
("hangup" event with Bridged = no)
Events of type "hangup"” from the IVR or queue are interpreted as missed calls only if Bridged=> no is present in the event.
This happens in all cases, despite the fact that there may be a situation within a global CallID when the first event of such a call was a "dial-out" event followed by an "answer" event (for example, when a script for a web call from a website generates calls on behalf of an extension number that is specified in the integration settings and associated with one of the CRM system users).
In this case, the following settings are always used:
CallerIDNum — external number (ANI ID / caller number) used to register the call in the CRM system.
CalledExtension — extension number, which level the call was missed at: IVR or Queue. The "hangup" event from the queue has a higher priority, in this case the "hangup" event from the IVR with the same CallID is ignored.
CalledDID — the call source (the number called from outside and used to direct the call to the PBX).
The call status in the CRM system must be indicated as missed.
All events with indication of "Bridged => yes" are always ignored.
Note
for the "hangup" event from an IVR with a global CallID that is unique for the entire call in the PBX, the call tracking ends entirely. But since the Queue "hangup" event (and it has a higher priority) can occur a fraction of a second later than the IVR "hangup" event, then a delay of a couple of seconds may be useful for the CRM system gets (if the call is answered was not) the Queue extension number, not the IVR one.
if the call passed through several queues and the "hangup" event occurred for all of them, and the IVR "hangup" event occurred too, then the "hangup" event from the last queue is taken for statistics.