|Summary||This article is a cheat sheet to understand the default treatment of SIP codes by CCA|
|Applies to||askiafield ; askiavoice|
|Written for||fieldwork managers ; system administrators|
|Keywords||SIP ; codes ; voice ; askiavoice ; CATI ; telephony ; VOIP|
Pre-requisites : This article only applies to integrated telephony systems.
When monitoring fieldwork or trying to setup a new VOIP environment, it is useful to understand how telephony codes are handled by CTArchitect & CCA.
CTArchitect acts as a telephony node. It will initiate calls according to the SIP protocol (documentation here : https://en.wikipedia.org/wiki/List_of_SIP_response_codes ). Therefore, it will receive SIP or ISDN result codes at the end of each call. Depending on these result codes, calls will be classified (Wrong address, No answer, Successful call...etc). Field supervisors will be able to read this information.
General rules about call results
- The CTArchitect application will not change the SIP or ISDN code it receives from the voice-carrying network equipment. Therefore, the equipment should be configured according to the Call center needs.
- This cheat sheet lists the default SIP/ISDN response codes and their meaning. By default, CTArchitect will work optimally if the gateway is following this protocol (RFC 3261)
Here is the environment in which the telephony result code is propagated : Respondent -> Public telephony equipment (ISDN) / internet (SIP) -> CTArchitect -> CCA (Call result)
- The callback behavior (number of attempts and time between attempts) is defined per survey, or per sample list, depending on the Callback rules.
Callback rules are based on the Call Result, not on the SIP code directly.
|Call Result in CCA||ISDN||SIP||Comment|
|Hung up before connection||8,9||199|
|Answering machine||Detected by CTArchitect|
|Fax||Detected by CTArchitect|
|Network unavailable||18,27,38||500||Behavior can be changed via dialler parameters|
|Number changed||22||410||Behavior can be changed via dialler parameters|
|Rejected||21||603||Behavior can be changed via dialler parameters|
|Temporary failure||34,41,42,44||503||Behavior can be changed via dialler parameters|
|Wrong address||1,28||404,484||Behavior can be changed via dialler parameters|
|Unknown error||All other codes|
In the table above, where it states that the behavior can be changed via dialler parameters, 2 options are available in the registry of the dialler host.
It consists of a mapping between SIP/ISDN error codes and dialler behavior, which is available at:
When modifying this mapping, ISDN codes shall be added in the "Data" value of these 5 possible registry keys. SIP codes too, but they need to be prefixed with "5".
1) Mark as temporary failure (TemporaryFailureIsdnDisconnectCauses):
The phone number will be called again, and will be seen as "not called" in CCA. It counts for 0 call attempts in the call history
2) Mark as unsuccessful attempt
(CallRejectedIsdnDisconnectCause, NetworkOutOfOrderIsdnDisconnectCause, NumberChangedIsdnDisconnectCause and WrongAddressIsdnDisconnectCause) :
The call will be counted in the total number of call attempts, in one of the 4 possible CCA categories : "Phone network out of order", "Phone number changed", "Call Rejected" or "Wrong address".
Then, the callback rules for these 4 categories can be handled per survey or per sample list, according to the fieldwork managers needs.
In the example above, SIP code 404 (5404) is associated to "WrongAddressIsdnDisconnectCause" and will therefore count as one unsuccessful attempt, in the CCA category "Wrong address"