Post-answer In-band Call ID Data Collection

Introduction

Dialogic Media gateways allow a user to collect in-band DTMF caller id data from a PBX to integrate calls. This integration data typically carries a mixture of called party, calling party, call origin (internal or external), and call reason (direct, busy, ring no answer, do not disturb) data for the gateway to consume and use in its IP signaling. 

The focus of this technical note will be to explain some basics of this technology and give some details on the configuration parameters that affect how it is collected and used. 

There are several types of caller ID signaling that you may encounter in the field when doing installations. This technical note will deal specifically with what is often referred to as post-answer, or Type II, DTMF call ID. 

Protocol Details

The image below shows in a graphical manner how Type II DTMF Caller ID functions.

The blue square at the far left indicates the burst of ring signal on the analog line. This is the trigger to tell the gateway that a call is present on the line.

The black band next in line indicates the gateway taking the line off hook to answer the call. This is the trigger to the call source to start sending the in-band DTMF call ID data to the gateway.

The next few purple blocks are indicating each of the individual DTMF digits that make up the stream of digits to use as integration data.

Open

Call Processing

The significance of this sequence is that it impacts the integration of calls that flow through the gateway. As calls arrive at the gateway, they are first signaled via the SIP protocol to the application, and then, once the application responds correctly, the circuit call is answered. 

Normally, this sequence works okay because on the digital set and ISDN-based integrations the call integrated data is available right as the call initially arrives, thus allowing the initial SIP invite containing this data to be sent. This normal sequence is shown in the diagram below: 

Open

However, in the case of these post answer type calls, the integration data is not yet present so the call flow typically is slightly different, as shown in the diagram below:

This flow means two things. First, the application will need to be able to handle receiving an invite that is delivered with no integration data (anon) by delaying when it decides what prompts to play. Second, the application will need to process the SIP INFO message that will be generated after the call has been answered and use the data present in that message to properly integrate the call.

Also note that because the integration data is delivered via in-band DTMF digits, the total time between when the call arrives and when the application is free to use the voice path to the caller is determined by how quickly these digits are delivered and processed. Because these digits are passed between the source and the gateway in the voice path, the voice path is not fully established between the caller and the gateway through the circuit network until these integration digits are completely sent to the gateway. 

This is necessary so that the digits do not compete with other inbound audio from the caller. The calling party experience may vary depending on the specific situation, as some PBXs continue to provide ring-back to the caller until after all the digits have been sent (even though the call has actually been answered), whereas others do not. The gateway does not influence this calling party experience, so you need to be aware of the impact it may have in your site specific implementation.

If your application is not architected to use the SIP INFO message then there is an alternate method of gateway configuration that can be used that will allow you to have the call integration data present in the initial invite message. The call flow resulting form this configuration is shown in the diagram below:

To set this configuration, you will need to instruct the gateway to auto-answer every call that arrives to it before signaling to the IP side application. This will cause the call source to send the integration data to the gateway so it can be used to send out the initial invite message containing the data instead of it going out anonymously. 

Note here that because the call is actually answered before it is signaled, if the IP side does not respond, or takes a longer than normal time to respond, the caller is going to hear a slightly longer period of silence before any opening greetings will be played. 

Parameters

The following section will list the configuration parameters that affect the collection and processing of this in-band call ID data. This will help you better understand what significance they have, when they need to be adjusted, and how to gauge the proper values.

The diagram below shows you where several of these parameters take effect within the context of a call.

Analog Interface Type (Dialogic 1008LS or 1004LS Media Gateways only)

This setting specifies how the gateway will be expecting to collect the call ID data. In the case of these kinds of calls (post answer DTMF) this should be set to PBX.

If this value is set incorrectly the gateway will not be able to properly process the in-band call ID digits.

This setting can be found in the config.ini file labeled as telAlgIfType.

CPID Type (Dialogic 2000 Media Gateway Series only)

This setting specifies how the gateway will be expecting to collect the call ID data. In the case of these kinds of calls (post answer DTMF) this should be set to TypeII_CPID. 

If this value is set incorrectly the gateway will not be able to properly process the in-band call ID digits. 

This setting can be found in the config.ini file labeled as t1e1CASCpidType. 

Auto-Answer Inbound TDM Calls

This setting allows the gateway to auto-answer the inbound calls before sending out the initial invite message. To use the feature this should be set to yes.

Note that to use this feature, you must have the gateway set to use post-answer DTMF type signaling as shown in the parameter above. Other settings will cause this parameter not to be used regardless of how it is set. Also note that to activate this feature, you must export the config.ini file, alter it in that file, and then re-import the file back into the gateway as this parameter is not exposed in the web interface.

If this setting is set incorrectly the gateway will not auto-answer the inbound calls as requested and this will have a negative effect on call integration.

This setting can be found in the config.ini file labeled as telAutoAnswer.

Incoming Rings Before Answer

This setting tells the gateway how many rings to wait for before processing the inbound call. Its intent is to allow for the requisite 2 rings cycles needed to collect FSK type caller ID data and thus is set by default to a value of 2. In these post answer DTMF cases, this value should be set to 1 to process the alerting call as soon as possible and because there is not a need to wait for 2 complete rings.
If this setting is set incorrectly the call processing will be delayed by as many rings as specified.

This setting can be found in the config.ini file labeled as telIncomRing.

Initial Wait for In-band CPID

This setting allows you to control how long the gateway will wait after answering a call to start processing any DTMF digits that it hears in-band as call ID digits. 

If this setting is set to too short a value, then the gateway will timeout and stop waiting for in-band call ID digits before they are presented. If this value is set too long, then DTMF digits pressed by users can be falsely seen as in-band call ID data and not processed as RFC2833 digits. 

Note that the default setting of 2000 msecs is typically adequate, but your site may require this setting to be adjusted upwards. 

This setting can be found in the config.ini file labeled as telInbCpidStartMs.

In-band CPID Complete Timeout

This setting is used to adjust the time between the in-band DTMF digits that come from the call source. This timer sets the maximum inter-digit time allowed between each in-band DTMF digit for the gateway to continue seeing the stream as in-band DTMF integration data. If this timer expires the digit collection stops and the collected string is sent to the parser to be processed for integration.

If this setting is set too low you can miss digits required for integration.

This setting can be found in the config.ini file labeled as telInbCpidEndMs.

Maximum Call Party Delay

This setting adjusts the maximum length of time that the gateway will accept in-band DTMF digits as integration digits. This is used to make sure that DTMF digits pressed by calling parties are not accidentally taken as in-band integration digits by the gateway. 

This setting should be adjusted to be just long enough to allow the gateway to collect all the digits form the call source, but not longer. If this setting is set too short, then the gateway will stop seeing in-band DTMF digits as in-band integration data and move on to parsing the data and processing the call prematurely. If it set to too long of a value, then in-band digits that are the result of callers pressing keys may not be processed as RFC2833 digits. 

This setting can be found in the config.ini file labeled as telCallInfoTout.

Reading traces to get values

Knowing what values you need to change gets you only half way. Knowing where to find out what values you need to use for these settings comprises the other half of the equation. The data you need to determine these values can be collected from the gateway trace debug stream. To properly look at this data, the minimum traces you’ll need to enable are:

tel event
tel code
voip prot

It's acceptable to have more degug enabled than this;owever, what is listed here is the minimum needed to configure this setup. Also note that in this example the gateway has been setup to properly parse the collected data, and that process is not detailed in this technical note.

Lets look at the example of an in-bound call as it gets processed: 

001 001:28.078 [Tel-1 ] Code eALGFXO_EVENT_RING in eALGFXO_STATE_IDLE
002 001:28.078 [Tel-1 ] Code _condAutoAnswerType2Cpid: YES
003 001:28.078 [Tel-1 ] Code algFxoAllocateCallObject 7dd618
004 001:28.078 [Tel-1 ] Code algFxoChangeCallState() 7dd618 INCOMING
005 001:28.080 [Tel-1 ] Code _algFxoFsmGetPreCallCpid()
006 001:28.080 [Tel-1 ] Code _actSetCallIncoming
007 001:28.080 [Tel-1 ] Code _actSetCallConnected
008 001:28.082 [Tel-1 ] Code algFxoSetCallConnected 7dd618 (7)Answered
009 001:28.082 [Tel-1 ] Code algFxoChangeCallState() 7dd618 CONNECTED
010 001:28.082 [Tel-1 ] Event Tone Detect Enabled (0xFF)
011 001:28.084 [Tel-1 ] Code _actOffHook
012 001:28.124 [Tel-1 ] Event Offhook
013 001:28.124 [Tel-1 ] Code New Tout -1
014 001:28.124 [Tel-1 ] Code _entryWaitT2CpidState
015 001:28.124 [Tel-1 ] Code New Tout 2000
016 001:28.124 [Tel-1 ] Code eALGFXO_STATE_WAIT_T2CPID <- eALGFXO_STATE_IDLE
017 001:28.126 [Tel-1 ] Code ANALOG_CSM_CARRIER --> ANALOG_CSM_LOC_DEBOUNCE
018 001:28.166 [Tel-1 ] Code ANALOG_CSM_LOC_DEBOUNCE --> ANALOG_CSM_CARRIER
019 001:28.754 [Tel-1 ] Code _algProcessDspEvent 0x3 0x23 0x0
020 001:28.754 [Tel-1 ] Event Dtmf (#) On
021 001:28.844 [Tel-1 ] Code _algProcessDspEvent 0x4 0x23 0x0
022 001:28.844 [Tel-1 ] Event Dtmf (#) Off
023 001:28.846 [Tel-1 ] Code eALGFXO_EVENT_DTMF in eALGFXO_STATE_WAIT_T2CPID
024 001:28.846 [Tel-1 ] Code _actStoreDigit
025 001:28.850 [Tel-1 ] Code _actSetInterDigitTout
026 001:28.850 [Tel-1 ] Code New Tout 300
027 001:28.850 [Tel-1 ] Code eALGFXO_EVENT_DTMF in eALGFXO_STATE_WAIT_T2CPID no state change.
028 001:28.952 [Tel-1 ] Code _algProcessDspEvent 0x3 0x30 0x0
029 001:28.952 [Tel-1 ] Event Dtmf (0) On
030 001:29.042 [Tel-1 ] Code _algProcessDspEvent 0x4 0x30 0x0
031 001:29.042 [Tel-1 ] Event Dtmf (0) Off
032 001:29.044 [Tel-1 ] Code eALGFXO_EVENT_DTMF in eALGFXO_STATE_WAIT_T2CPID
033 001:29.044 [Tel-1 ] Code _actStoreDigit
034 001:29.044 [Tel-1 ] Code _actSetInterDigitTout
035 001:29.044 [Tel-1 ] Code New Tout 300
036 001:29.044 [Tel-1 ] Code eALGFXO_EVENT_DTMF in eALGFXO_STATE_WAIT_T2CPID no state change.
037 001:29.150 [Tel-1 ] Code _algProcessDspEvent 0x3 0x30 0x0
038 001:29.150 [Tel-1 ] Event Dtmf (0) On
039 001:29.240 [Tel-1 ] Code _algProcessDspEvent 0x4 0x30 0x0
040 001:29.240 [Tel-1 ] Event Dtmf (0) Off
041 001:29.242 [Tel-1 ] Code eALGFXO_EVENT_DTMF in eALGFXO_STATE_WAIT_T2CPID
042 001:29.242 [Tel-1 ] Code _actStoreDigit
043 001:29.242 [Tel-1 ] Code _actSetInterDigitTout
044 001:29.242 [Tel-1 ] Code New Tout 300
045 001:29.242 [Tel-1 ] Code eALGFXO_EVENT_DTMF in eALGFXO_STATE_WAIT_T2CPID no state change.
046 001:29.354 [Tel-1 ] Code _algProcessDspEvent 0x3 0x23 0x0
047 001:29.354 [Tel-1 ] Event Dtmf (#) On
048 001:29.450 [Tel-1 ] Code _algProcessDspEvent 0x4 0x23 0x0
049 001:29.450 [Tel-1 ] Event Dtmf (#) Off
050 001:29.452 [Tel-1 ] Code eALGFXO_EVENT_DTMF in eALGFXO_STATE_WAIT_T2CPID
051 001:29.452 [Tel-1 ] Code _actStoreDigit
052 001:29.452 [Tel-1 ] Code _actSetInterDigitTout
053 001:29.452 [Tel-1 ] Code New Tout 300
054 001:29.452 [Tel-1 ] Code eALGFXO_EVENT_DTMF in eALGFXO_STATE_WAIT_T2CPID no state change.
055 001:29.552 [Tel-1 ] Code _algProcessDspEvent 0x3 0x31 0x0
056 001:29.552 [Tel-1 ] Event Dtmf (1) On
057 001:29.642 [Tel-1 ] Code _algProcessDspEvent 0x4 0x31 0x0
058 001:29.642 [Tel-1 ] Event Dtmf (1) Off
059 001:29.644 [Tel-1 ] Code eALGFXO_EVENT_DTMF in eALGFXO_STATE_WAIT_T2CPID
060 001:29.644 [Tel-1 ] Code _actStoreDigit
061 001:29.644 [Tel-1 ] Code _actSetInterDigitTout
062 001:29.644 [Tel-1 ] Code New Tout 300
063 001:29.644 [Tel-1 ] Code eALGFXO_EVENT_DTMF in eALGFXO_STATE_WAIT_T2CPID no state change.
064 001:29.750 [Tel-1 ] Code _algProcessDspEvent 0x3 0x35 0x0
065 001:29.750 [Tel-1 ] Event Dtmf (5) On
066 001:29.852 [Tel-1 ] Code _algProcessDspEvent 0x4 0x35 0x0
067 001:29.852 [Tel-1 ] Event Dtmf (5) Off
068 001:29.854 [Tel-1 ] Code eALGFXO_EVENT_DTMF in eALGFXO_STATE_WAIT_T2CPID
069 001:29.854 [Tel-1 ] Code _actStoreDigit
070 001:29.854 [Tel-1 ] Code _actSetInterDigitTout
071 001:29.854 [Tel-1 ] Code New Tout 300
072 001:29.854 [Tel-1 ] Code eALGFXO_EVENT_DTMF in eALGFXO_STATE_WAIT_T2CPID no state change.
073 001:29.954 [Tel-1 ] Code _algProcessDspEvent 0x3 0x34 0x0
074 001:29.954 [Tel-1 ] Event Dtmf (4) On
075 001:30.050 [Tel-1 ] Code _algProcessDspEvent 0x4 0x34 0x0
076 001:30.050 [Tel-1 ] Event Dtmf (4) Off
077 001:30.052 [Tel-1 ] Code eALGFXO_EVENT_DTMF in eALGFXO_STATE_WAIT_T2CPID
078 001:30.052 [Tel-1 ] Code _actStoreDigit
079 001:30.052 [Tel-1 ] Code _actSetInterDigitTout
080 001:30.052 [Tel-1 ] Code New Tout 300
081 001:30.052 [Tel-1 ] Code eALGFXO_EVENT_DTMF in eALGFXO_STATE_WAIT_T2CPID no state change.
082 001:30.152 [Tel-1 ] Code _algProcessDspEvent 0x3 0x23 0x0
083 001:30.152 [Tel-1 ] Event Dtmf (#) On
084 001:30.254 [Tel-1 ] Code _algProcessDspEvent 0x4 0x23 0x0
085 001:30.254 [Tel-1 ] Event Dtmf (#) Off
086 001:30.256 [Tel-1 ] Code eALGFXO_EVENT_DTMF in eALGFXO_STATE_WAIT_T2CPID
087 001:30.256 [Tel-1 ] Code _actStoreDigit
088 001:30.256 [Tel-1 ] Code _actSetInterDigitTout
089 001:30.256 [Tel-1 ] Code New Tout 300
090 001:30.256 [Tel-1 ] Code eALGFXO_EVENT_DTMF in eALGFXO_STATE_WAIT_T2CPID no state change.
091 001:30.350 [Tel-1 ] Code _algProcessDspEvent 0x3 0x23 0x0
092 001:30.350 [Tel-1 ] Event Dtmf (#) On
093 001:30.452 [Tel-1 ] Code _algProcessDspEvent 0x4 0x23 0x0
094 001:30.452 [Tel-1 ] Event Dtmf (#) Off
095 001:30.454 [Tel-1 ] Code eALGFXO_EVENT_DTMF in eALGFXO_STATE_WAIT_T2CPID
096 001:30.454 [Tel-1 ] Code _actStoreDigit
097 001:30.454 [Tel-1 ] Code _actSetInterDigitTout
098 001:30.454 [Tel-1 ] Code New Tout 300
099 001:30.454 [Tel-1 ] Code eALGFXO_EVENT_DTMF in eALGFXO_STATE_WAIT_T2CPID no state change.
100 001:30.774 [Tel-1 ] Code eALGFXO_EVENT_TOUT in eALGFXO_STATE_WAIT_T2CPID
101 001:30.774 [Tel-1 ] Code _actSetCallConnected
102 001:30.774 [Tel-1 ] Code algFxoSetCallConnected 7dd618 (7)Answered
103 001:30.774 [Tel-1 ] Code algFxoChangeCallState() 7dd618 CONNECTED
104 001:30.776 [Tel-1 ] Code _actParseCPID
105 001:30.778 [Tel-1 ] Code _algProcessDtmfCpid() 154,->, (direct)
106 001:30.778 [Tel-1 ] Code _algFxoFsmReportNewCpid()
107 001:30.778 [Tel-1 ] Event Cpid (154,->,->,) (Direct)
108 001:30.780 [Tel-1 ] Code _algFxoGccCallGetInfo() 0x7dd618 pInfo: 0xe80980
109 001:30.782 [Tel-1 ] Code _algFxoGccCallGetInfo() 0x7dd618 pInfo: 0xe806a0
110 001:30.786 [Tel-1 ] Code _algFxoGccCallGetInfo() 0x7dd618 pInfo: 0xe80950
111 001:30.790 [Tel-1 ] Code New Tout -1
112 001:30.790 [Tel-1 ] Code eALGFXO_STATE_TALK <- eALGFXO_STATE_WAIT_T2CPID
113 001:30.812 [VoIP ] Prot
114 001:30.812 [VoIP ] Prot <----INVITE sip:Anonymous@192.168.0.100;transport=tcp SIP/2.0
115 001:30.812 [VoIP ] Prot From:"154"<sip:154@192.168.0.20:5060>;vnd.pimg.port=1;tag=58B2368
.
.
.

Line 001 shows us that the gateway is seeing an inbound call via the state transition to EVENT_RING.

Line 002 shows that the gateway is currently set for post answer (Type II) Call ID and is also set for auto-answering the calls via the telAutoAnswer parameter.

Line 012 shows the gateway taking the port off hook to answer the call.

Line 014 shows the gateway entering into the state where it is waiting to start getting post-answer call ID digits. The next line (Line 015) shows the 'Initial Wait for Inband CPID' timer started with its default value of 2000 msec.

Line 020 shows the first digit being received from the call source.

If you look at the time stamps between lines 012 (001:28.124) and 020 (001:28.754) you will see that only 630 msecs have passed. This is the way to determine the proper value for the 'Initial Wait for Inband CPID' timer. Using a value less than 630 in this case would result in the gateway missing the start of the digit stream because it did not wait long enough.

Line 025 shows the gateway entering the state between digits where it starts to watch the inter-digit timing. In fact on the next line (Line 026) you can see the 'Inband CPID Complete Timeout' value being set. In this case the default value of 300 msec is being used. 

You can watch the time stamps between each line where one DTMF digit ends and the next one starts to make sure that your 'Inband CPID Complete Timeout' value is set correctly. If the call source sends digits at an inconsistent rate you may need to watch this value over the course of a few calls and ensure that the value is set for the worst case you have seen to provide for proper operation.

Line 100 shows where the gateway eventually timed out (using the 'Inband CPID Complete Timeout' value) waiting for further in-band integration digits to comes form the source. This is the signal to the gateway that it has received all the digits it is going to get and that it should move on to process the call with the data it has collected. Note that if your 'Inband CPID Complete Timeout' value is too low, you may get this timeout, but you continue to receive integration digits. In this case, you should increase the timeout value and retest. 

Line 104 shows the gateway parsing the DTMF digit stream that it collected. If you also have adept debug enabled, you will see output form that process after this line showing that process work. 

Line 105 shows that the adept parser did its job the calling party has been extracted from the digit stream provided by the call source. 

Line 112 shows the gateway entering the talk state indicating that call setup is continuing after collection and parsing has been completed. 

Line 114 shows the start of a SIP Invite going out to the IP application with the From header set with the calling party as it was extracted from the integration digit stream.