At the same time, our requirements for setting up Asterisk have increased. To find out the result of the call, we need the "extra" field in the CEL table. If you haven't added it yet, call statuses will work in the old way with only two basic values.
Despite the temporary support for CEL without
extra, it's better not to leave the settings that don't meet system requirements. We already rely on the content of
extrafor handling call interception and transfers, and will rely on it when developing new features.
If the new call statuses do not meet your expectations yet, you can temporarily disable them by making the
To do this, you need to set the value "id" instead of "extra" in the config field
database.column_name_aliases.cel_extra. After that, the module will look in the
idfield instead of
extra, won't see the expected data, and will work in the old way.
Don't forget to restart the service for the changes to take effect, and let us know what needs to be changed in the call statuses so that they work more correctly.
Call statuses are based on a call property that is new to us - the result. This is the result of peer A's attempt to call peer B, expressed with a code from the SIP protocol. The codes are similar in appearance and meaning to the status codes of the HTTP protocol, for example,
404means "not found", but in a telephony sense.
The call result is not a literal SIP status code, but the set of situations described by these codes is very fitting.
To determine the result of the call, we rely on the contents of the
extrafield. It contains
dial_statusvalues set by Asterisk.
hangup_causehas values from 0 to 127, and some of them correspond to one or more SIP status codes.
dial_statuscan be either empty or one of 9 values, such as "ANSWERED" or "CANCEL". Both of these fields together allow us to determine the result of the call:
Obviously, not all 1280 possible combinations are considered here. Some
hangup_causevalues are not used by Asterisk, some combinations don't make sense or aren't possible, but most importantly, our preliminary research has shown that this set of combinations covers all common cases. As new cases are discovered, we will add them to the list, but for now, they will be handled in the old way with two options.
Each CRM has its own idea of what statuses a call can have. They depend on the point of view of a specific CRM on the role of calls in a business process and the model of employee interaction with a call. It is important that in CRM, users can both set and read the call status along with automation, and therefore, the list of options should be intuitive and not too large. We map our set of call results to this reduced set of statuses.
The final call status is determined by the call result and additional conditions:
Kommo call statuses are not based on SIP status codes. Instead, they are intended to be filled in by the user:
- 1.Left a voice message
- 2.Call back later
- 3.Out of the office
- 4.Conversation commenced
- 5.Wrong number
- 6.Didn't get through
- 7.Number busy
In addition to the status, Kommo has a "Call Result" field that contains arbitrary text. We tried to use this text to make the status more intuitive.
Call data in Kommo is determined by call result as follows: