Integration Operation

Transferring Call to Responsible Manager

At the very beginning, a call goes to the voice menu: to the IVR type extension number where the rule "Call Interactive" is added. This rule is most often used in integrations for the SetVar action to set a variable, which value will contain the extension number to transfer the call. This function is most often called "call transfer to the responsible employee".

For an IVR type extension number, the first action is to send a "Call interactive" request to search by the caller number for the corresponding entity in the CRM system and for the related responsible manager to return to the PBX the responsible manager extension number in the action variable Setvar. The PBX, bypassing the voice greeting, sends the call to this responsible manager (using the IVR rule "Transfer to number in variable"). If the extension number cannot receive the call, and there are no forwarding rules for the extension number, it is recommended not to make the "Transfer to number in variable" rule the last one.

Example

https://myintegration:8080/cid/807/getmanager/TLP55522
where https://myintegration:8080 — is the integration server address,
807 — is the serial number of the application for this integration,
TLP55522 — is the PBX user login been used to create the application for this integration.

It allows you to conveniently catch only the specified user integration events in the integration server using ngrep or in the logs. We propose to ask the user whether it is necessary to transfer the incoming call to the responsible manager and, if the user agrees, automatically add it to the IVR in the Main context by the first rules:

Call interactive + Transfer from variable, where "Variable name" must be equal to the name of the variable returned by the integration.

If you disable the option of transferring an incoming call to the responsible manager in the settings of the integration application/widget, you must delete these rules from the IVR Main context (it is recommended to perform this action carefully not to delete the necessary rules, since their sequence number may be changed during the PBX configuration).

Logging Call Data

All events of ordinary extension numbers (type = phone) for dial-in and dial-out events are analyzed and, in the answer event presence, are logged by the hangup event and SubCallID as separate calls, instead of CallID. Thus, it is possible to divide the call within the PBX into separate call legs (before the transfer and after it) and log them as separate calls.
Unanswered incoming calls are logged by presence of the option Bridged=no in the "hangup-ах" events from the IVR and queues. You should remember that Bridged=yes always indicates a successful incoming call. Its data should be recorded when analyzing "dial-in" events within their own SubCallID values.

Call Initiation (ClickToCall/callback)

The system first calls the call source number (src_num) and then, if the answer is successful, calls the call destination number (dst_num).

If the call source number is an extension number, it is recommended to transfer not only the src_num and dst_num options, but also both the caller_id_name and caller_id_number, specifying in them the value equal to the dst_num. Thus, when a call comes to the user SIP phone, not the user own extension number would appear (the value from src_num transmitted by the system by default, if caller_id_name and caller_id_number are not specified), but the number, which the user will call to. It will give the user the opportunity at least to call back to the same number without the integration usage by pressing RD (redial).

Sending Link to Conversation Record to Integration

The system logs incoming, outgoing and missed calls, keeps track of their statistics for each extension number. The "Conversation Records (/record/)" resource allows you to get a list of available records of a client or certain extension number for the specified period, to get the record files directly, and also to delete records in a range or per item. An application using a REST API (for example, the CRM system) gets a link to a file in the storage using the appropriate API resources:

GET /extension/{extension_id}/record/{record_uuid}/storage_url/

This resource returns responses in the form:
{ "record_url": "http://storage.hostname/bd7zzrXD5395gn7FMgzKtB8zhZnNoYx8BdkX_HgNdeE2lnJjPMLcOR_1hQprGf-dW94wuTCNRAY6MDjMZ0zWIg==" }

Clicking on the link from the API response, you can directly download the conversation record file. The resulting link to the conversation record file can be used in the integration with the CRM system. To use this method, additional configuration of an outside web server is required.

Example

Request:
GET https://hostname/api/ver1.0/client/@me/record/30-624835FEEE0E11E6A19D331E4D6A0606/storage_url/

System response:
{ "record_url": "http://storage.hostname/bd7zzrXD5395gn7FMgzKtB8zhZnNoYx8BdkX_HgNdeE2lnJjPMLcOR_1hQprGf-dW94wuTCNRAY6MDjMZ0zWIg==" }

 

← Event Logic on Extension Numbers