Outbound Dialling - Telephony Disconnection Reason Matrix for Failed AI Predictive and Agent Handled Preview calls
Semantic fallacy of SIP call rejection codes mean that any given SIP call rejection response may not be appropriate to the real cause of the call failure. This shall be termed as a “miscoded call rejection”. These miscoding's are usually location or provider dependent. In many cases miscoded rejections are constantly repeated across many calls to different destinations. In many cases, the given rejection cause supplied after the miscode is (almost always) only ever a result of a miscode. In this case the presence of this rejection code can reliably indicate the real reason, though it does not semantically match. One common example is when a ‘congestion’ type cause is supplied for a bad address, and investigations show that all verified congestions relate to bad addresses.
Mechanism:
Such an issue as above could be remedied with a translation of a given SIP response to a ISDN Disconnect Reason.
However, while SIP codes are available to the dialler, there are two distinct cases where a SIP response -> ISDN Disconnect Reason translation may be inappropriate:
Where the “Response” clause is used in the SIP message to indicate a Q931/ISDN type rejection cause.
Where E1s are still in use.
In this case a ISDN Rejection cause code translation is required instead and can be provided by the INVADE Telephony Disconnection Reason Matrix.
Implementation:
Asterisk supplies the dialler with rejection codes from within the standard enumerated set of ISDN causes. When the trunk is SIP, Asterisk performs a translation of the SIP code to the ISDN code. This translation is hard coded within the Asterisk process.
The dialler performs its determination of a Disconnect Reason for a call solely on the basis of the ISDN cause code provided by Asterisk. The SIP cause code is also supplied but is not currently used by the dialler process. Where a SIP code needs translation, it will be implemented as a SIP cause -> ISDN cause override and will be performed in the dialler. This will be done within the message processor of the AI dialler.
Where ISDN cause translation is required, it can be done as a ISDN code -> Disconnect Reason override.
Configuration
Translation are defined by INVADE Engineers via a CSD ticket, in most cases this will be achieved during the initial configuration & bedding in of the Dialler and / or when the provider / route is changed . A translation will be process wide and not (initially) be port or route specific. The translations defined in the configuration need only be those that override the default.