Equivalence between SIP/ISDN response codes and CCA's telephony result code

Equivalence between SIP/ISDN response codes and CCA's telephony result code

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 : ). 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.

Equivalence sheet

Call Result in CCA ISDN SIP Comment
Busy 17 486  
No answer 19 204  
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


Custom behavior

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:

Computer\HKEY_CURRENT_USER\Software|MI4C\CTArchitect\Dial Settings.

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"

Have more questions? Submit a request


  • Avatar
    Marijn Vanhee

    from 5.4.6 onwards, the custom behavior is no longer configured in registry but can be viewed and changed via CTArchitect Settings