Conversation Quality Assessment in 3CX

After the complete end of the call (when the external subscriber hangs up), a recording of the conversation appears in 3CX, or several recordings of conversations that correspond to the entire chain of transfers, if any. Recordings of conversations appear with a slight delay: from a few milliseconds to 1-2 seconds after hanging up. As soon as this happens, the “webhooks” module converts the wav-file (s) with the recording (recordings) into mp3-format and places them in a separate folder, from which it is possible to download recordings via an https-link. The link to download the files is sent via the corresponding POST request. Thus, a webhook with information about the end of the call and a webhook with a link to the conversation file are different, separate webhooks.

In a POST request, in the general case, several links can be sent to download a conversation recording. The fact is that in 3CX one conversation can correspond to several sound files. This happens if they spoke through a mobile application, and during the conversation, the connection was lost for a short time. In this case, each short-term disconnection is the beginning of a new record file.

In addition to the link to the conversation record, the POST request contains a call id, by which it can be identified with the call start / end events. Optionally (via an ini file) in the POST request, you can enable the transfer of complete information about the ended call. In this case, the POST request will contain the same information (besides the link to download the record) as the call termination event.

Records of conversations in mp3 format are stored in a separate package for the required number of days (the corresponding parameter is set in the ini-file of the service). At night, records that have expired are automatically deleted by the service.

Example:

{"FILES":["https://3CXFQDN:5001/webapi/recording/211230102738_669-1-1.mp3"]}

1. Create a separate database on the same 3CX instance (dbname with dbpassword)

2. Create table

— Table: public.operator_state_history

— DROP TABLE IF EXISTS public.operator_state_history;

CREATE TABLE IF NOT EXISTS public.operator_state_history
(
date timestamp with time zone,
old_values text COLLATE pg_catalog.”default”,
new_values text COLLATE pg_catalog.”default”,
ext text COLLATE pg_catalog.”default”
)
WITH (
OIDS = FALSE
)
TABLESPACE pg_default;

ALTER TABLE IF EXISTS public.operator_state_history
OWNER to phonesystem;

3. Specify the following in the TCXWebAPI.ini

DBS_NAME = dbname
DBS_PORT = 5480
DBS_LOGIN = phonesystem
DBS_PASSWORD =dbpassword
DBS_TABLE = public.operator_state_history

4. Select user history

SELECT date, old_values, new_values, ext
FROM public.operator_state_history

"2022-12-30 18:00:00+00" "Available" "Out of office" "540"
"2022-12-30 18:00:00+00" "Available" "Out of office" "519"
"2022-12-30 06:00:00+00" "Out of office" "Available" "540"
"2022-12-30 06:00:00+00" "Out of office" "Available" "519"
"2022-12-29 18:00:00+00" "Available" "Out of office" "540"
"2022-12-29 18:00:00+00" "Available" "Out of office" "519"

1. Create custom table

CREATE TABLE IF NOT EXISTS public.webhook_history
(
date timestamp with time zone,
event text COLLATE pg_catalog."default",
callerid text COLLATE pg_catalog."default",
id text COLLATE pg_catalog."default",
cl_participants_id integer,
content_str text COLLATE pg_catalog."default",
userid text COLLATE pg_catalog."default"
)
WITH (
OIDS = FALSE
)
TABLESPACE pg_default;

ALTER TABLE IF EXISTS public.webhook_history
OWNER to phonesystem;


3.Selecting data
SELECT date, event, callerid, id, cl_participants_id, content_str, userid
FROM public.webhook_history;