(Page 1 of 1 in this chapter)

Chapter 13

European Digital CAS Protocol

13.1 Introduction

13.2 Signaling Overview

: 13.2.1 Register Signaling

13.3 Parameters

: 13.3.1 Editable Parameters
: 13.3.2 Non-editable Parameters

13.4 Special TCP Behavior

: 13.4.1 Inbound Calls: Retrieving Digits All at Once
: 13.4.2 Inbound Calls: Retrieving Digits One at a Time
: 13.4.3 Outbound Calls: Digit Format

13.1 Introduction

This chapter provides the following information: · Overview of the signaling performed by the protocols covered in the European Digital CAS (EUC) TCP · EUC TCP parameters · Operations that are specific to the EUC TCP within the framework of Natural Call Control
The EUC TCP implements the national CAS specifications of two European countries, Italy and The Netherlands, both of which define protocols that use two bits line signaling and DTMF digit spill register signaling. The two protocols are similar enough to be implemented by the same trunk control program.

13.2 Signaling Overview

Although E1 Channel Associated Signaling (CAS) framing supports 4 signaling bits per direction, only 2 of them are used for the protocols implemented by the EUC TCP. Thus the signaling channels supporting the line signaling of these protocols are referred to as Af and Bf in the forward direction, and Ab and Bb, in the backward direction. The forward channel indicates the condition of the outbound switch equipment and reflects the condition of the calling party's line. The backward channel indicates the condition of the called party's line (the inbound equipment). The C and D bits never changes and their value is 0 and 1 respectively.
The line signaling for a typical call is illustrated by the following (country-specific) tables. Italy (Norma CEI 103-1/7) State Outbound AfBf Direction Inbound AbBb Idle 01 \xdf 01 Seizure 10 01 Seizure Acknowledge 10 \xdf 11 Here the outbound side starts to send the address information. This can be done by means of DTMF tones, or by decadic pulses. If the method is decadic pulses, the Af bit is switched off (pulse on) and on (pulse off) repeatedly to signal the digits. Register signaling: digit spill DTMF 11 Register signaling: pulse dial 00 pulse on 11 10 pulse off 11 All the address information has been transferred, now the inbound side must accept or reject the call. It does so by sending a wink: a temporary change in the bit pattern. The bit pattern is AB=10 if the inbound accepts the call, AB=01 if it rejects the call. End of selection - free 10 \xdf 11-10-11 (150 ms) End of selection - busy 10 \xdf 11-01-11 (150 ms) If the call has been accepted, the inbound side plays a ring tone on the line, after resuming to signal AB = 11 (seizure acknowledged). If the call has been rejected instead, the outbound side is supposed to switch back to signaling AB = 01 (idle) thus clearing the line. Ringing 00 \xdf 11 Answer - conversation state 00 \xdf 00 The outbound protocol can receive billing pulses, to signal that a unit of cost has been billed to the call. In this case the answer pattern (AB = 00) from inbound temporarily changes to AB = 10. Billing pulses are generated by the network, not by the inbound terminal. Answer - conversation state 00 00 \xdf 00 Billing pulses 00 10 \xdf 00 Answer - conversation state 00 00 \xdf 00 Depending on which of the sides hangs up the call first, we have a clear back signal, or a clear forward signal. A period of release guard from inbound follows both signals, with the meaning of acknowledgment of the clear operation. Idle follows. Inbound hangs up first: Clear back 00 \xdf 11 Clear forward (and release guard) 01 11 Idle 01 \xdf 01 Outbound hangs up first: Clear forward 01 00 Release guard 01 \xdf 11 Idle 01 \xdf 01 The Netherlands (ALS70D)
ALS70D, the Dutch National CAS Protocol, is asymmetrical. This means that the terminal equipment sends and receives different signals to perform call setup with respect to the near-end switch. Thus, two signaling diagrams are necessary to specify the protocol, one for the TCP placing calls (outbound), and one for the TCP receiving calls (inbound).
The first table represents the signaling carried out by the outbound TCP. State Outbound AfBf (TCP) Direction Inbound AbBb (Network) Idle 10 \xdf 10 Seizure 00 10 The normal behavior after the outbound TCP signals seizure is the detection of a seizure acknowledged. However, call collision can occur, and the TCP can receive a seizure from the network as well. If the seizure from the network comes within a time of 200 ms from the original seizure, then the outbound TCP must send seizure acknowledged and receive a call. It will then behave as shown by the following table, describing the inbound TCP behavior. Seizure Acknowledge 00 \xdf 11 Here the inbound network side starts playing a dial tone on the voice channel, to mean that in-band (DTMF detectors) resources are available to receive the address information. Once it has detected the dial tone, the outbound side starts to send the address information. This can be done by mean of DTMF tones, or by pulse dial. If the method is pulse dial, the Bf bit is switched on (pulse on) and off (pulse off) repeatedly to signal each digit. Register signaling: digit spill DTMF 11 Register signaling: pulse dial 01 pulse on 11 00 pulse off 11 If the call is accepted, the inbound side plays a ring tone on the line and then flips the Ab bit to signal 01. Otherwise, it flips the Bb bit to signal 10 (idle). Ringing 00 \xdf 11 Answer - conversation state 00 \xdf 01 The outbound protocol can receive billing pulses, to signal that a unit of cost has been billed to the call. In this case the answer pattern (AB = 01) from inbound temporarily changes to AB = 00. Answer - conversation state 00 \xdf 01 Billing pulses 00 \xdf 00 Answer - conversation state 00 \xdf 01 Depending on which of the sides hangs up the call first, we have a clear forward signal, or a clear back signal, followed by a clear forward. Idle follows. Clear back 00 \xdf 11 Clear forward 10 01 (or 11) Idle 10 \xdf 10
The table for the inbound TCP instead is the following. State Outbound AfBf (Network) Direction Inbound AbBb (TCP) Idle 10 \xdf 10 Seizure 00 10 Seizure Acknowledged 00 \xdf 11 The seizure acknowledged line state for the inbound TCP lasts for a certain time period. This time period is set to 100 ms in the TCP. After that, a ready to receive bit transition is sent, to signal the network that the TCP is ready to receive the address information. This signal means that the resource dedicated to detect DTMF tones has been allocated. Ready to receive 00 \xdf 01 Once it has detected the ready to receive signal, the outbound side starts to send the address information. This can be done by mean of DTMF tones, or by pulse dial. If the method is pulse dial, the Bf bit is switched on (pulse on) and off (pulse off) repeatedly to signal each digit. Register signaling: digit spill DTMF 01 Register signaling: pulse dial 01 pulse on 01 00 pulse off 01 When all the digits have been received, the inbound side flips the Ab bit to signal that it has enough information. This state is maintained for at least 300 ms. Number received 00 \xdf 11 If the call is accepted, the inbound side play ring tones on the line and then flips the Ab bit to signal AB = 01. Otherwise, it plays busy and flips the Bb bit to signal AB = 10 (idle). Ringing 00 \xdf 11 Answer - conversation state 00 \xdf 01 Depending on which of the sides hangs up the call first, we have a clear forward signal, or a clear back signal, followed by a clear forward. Idle follows. Clear back 00 \xdf 11 Clear forward 10 01 (or 11) Idle 10 \xdf 10

State	Outbound AfBf	Direction	Inbound AbBb
Idle	01	\xdf	01
Seizure	10		01
Seizure Acknowledge	10	\xdf	11
Here the outbound side starts to send the address information. This can be done by means of DTMF tones, or by decadic pulses. If the method is decadic pulses, the Af bit is switched off (pulse on) and on (pulse off) repeatedly to signal the digits.
Register signaling: digit spill	DTMF		11
Register signaling: pulse dial	00 pulse on		11
	10 pulse off		11
All the address information has been transferred, now the inbound side must accept or reject the call. It does so by sending a wink: a temporary change in the bit pattern. The bit pattern is AB=10 if the inbound accepts the call, AB=01 if it rejects the call.
End of selection - free	10	\xdf	11-10-11 (150 ms)
End of selection - busy	10	\xdf	11-01-11 (150 ms)
If the call has been accepted, the inbound side plays a ring tone on the line, after resuming to signal AB = 11 (seizure acknowledged). If the call has been rejected instead, the outbound side is supposed to switch back to signaling AB = 01 (idle) thus clearing the line.
Ringing	00	\xdf	11
Answer - conversation state	00	\xdf	00
The outbound protocol can receive billing pulses, to signal that a unit of cost has been billed to the call. In this case the answer pattern (AB = 00) from inbound temporarily changes to AB = 10. Billing pulses are generated by the network, not by the inbound terminal.
Answer - conversation state	00	00 \xdf	00
Billing pulses	00	10 \xdf	00
Answer - conversation state	00	00 \xdf	00
Depending on which of the sides hangs up the call first, we have a clear back signal, or a clear forward signal. A period of release guard from inbound follows both signals, with the meaning of acknowledgment of the clear operation. Idle follows.
Inbound hangs up first: Clear back	00	\xdf	11
Clear forward (and release guard)	01		11
Idle	01	\xdf	01
Outbound hangs up first: Clear forward	01		00
Release guard	01	\xdf	11
Idle	01	\xdf	01

State	Outbound AfBf (TCP)	Direction	Inbound AbBb (Network)
Idle	10	\xdf	10
Seizure	00		10
The normal behavior after the outbound TCP signals seizure is the detection of a seizure acknowledged. However, call collision can occur, and the TCP can receive a seizure from the network as well. If the seizure from the network comes within a time of 200 ms from the original seizure, then the outbound TCP must send seizure acknowledged and receive a call. It will then behave as shown by the following table, describing the inbound TCP behavior.
Seizure Acknowledge	00	\xdf	11
Here the inbound network side starts playing a dial tone on the voice channel, to mean that in-band (DTMF detectors) resources are available to receive the address information.
Once it has detected the dial tone, the outbound side starts to send the address information. This can be done by mean of DTMF tones, or by pulse dial. If the method is pulse dial, the Bf bit is switched on (pulse on) and off (pulse off) repeatedly to signal each digit.
Register signaling: digit spill	DTMF		11
Register signaling: pulse dial	01 pulse on		11
	00 pulse off		11
If the call is accepted, the inbound side plays a ring tone on the line and then flips the Ab bit to signal 01. Otherwise, it flips the Bb bit to signal 10 (idle).
Ringing	00	\xdf	11
Answer - conversation state	00	\xdf	01
The outbound protocol can receive billing pulses, to signal that a unit of cost has been billed to the call. In this case the answer pattern (AB = 01) from inbound temporarily changes to AB = 00.
Answer - conversation state	00	\xdf	01
Billing pulses	00	\xdf	00
Answer - conversation state	00	\xdf	01
Depending on which of the sides hangs up the call first, we have a clear forward signal, or a clear back signal, followed by a clear forward. Idle follows.
Clear back	00	\xdf	11
Clear forward	10		01 (or 11)
Idle	10	\xdf	10

State	Outbound AfBf (Network)	Direction	Inbound AbBb (TCP)
Idle	10	\xdf	10
Seizure	00		10
Seizure Acknowledged	00	\xdf	11
The seizure acknowledged line state for the inbound TCP lasts for a certain time period. This time period is set to 100 ms in the TCP. After that, a ready to receive bit transition is sent, to signal the network that the TCP is ready to receive the address information. This signal means that the resource dedicated to detect DTMF tones has been allocated.
Ready to receive	00	\xdf	01
Once it has detected the ready to receive signal, the outbound side starts to send the address information. This can be done by mean of DTMF tones, or by pulse dial. If the method is pulse dial, the Bf bit is switched on (pulse on) and off (pulse off) repeatedly to signal each digit.
Register signaling: digit spill	DTMF		01
Register signaling: pulse dial	01 pulse on		01
	00 pulse off		01
When all the digits have been received, the inbound side flips the Ab bit to signal that it has enough information. This state is maintained for at least 300 ms.
Number received	00	\xdf	11
If the call is accepted, the inbound side play ring tones on the line and then flips the Ab bit to signal AB = 01. Otherwise, it plays busy and flips the Bb bit to signal AB = 10 (idle).
Ringing	00	\xdf	11
Answer - conversation state	00	\xdf	01
Depending on which of the sides hangs up the call first, we have a clear forward signal, or a clear back signal, followed by a clear forward. Idle follows.
Clear back	00	\xdf	11
Clear forward	10		01 (or 11)
Idle	10	\xdf	10

13.2.1 Register Signaling

In general the protocols supported by the EUC TCPs use either in-band DTMF tones or out-of-band decadic pulses to transfer register signaling information.
These protocols only transfer DID (direct inward dialing - the called address) information. To do this the outbound side sends either a stream of DTMF tones or a sequence of decadic pulses to the inbound side, then considers the dialing done and waits for some confirmation from the inbound side. This register signaling technique, in which the outbound side has no acknowledgment from the inbound side until the dialing is finished, is called "digit spill".

13.3 Parameters

The EUC TCP is programmed by the parameters described below to implement the specifications of the supported countries and network operators. Caution: Most of the parameters that follow are signaling-specific: changing their value would not only invalidate any approval certificate for the used board, but would also most likely cause the board to malfunction. These parameters are described here for reference purposes only.
Other parameters program the interaction the TCP has with the host, or act on features not regulated or that can change from switch to switch within the same network. These are changeable, and indeed, the application developer is often asked to do so. These parameters are in the first table below.

Caution:	Most of the parameters that follow are signaling-specific: changing their value would not only invalidate any approval certificate for the used board, but would also most likely cause the board to malfunction. These parameters are described here for reference purposes only.

13.3.1 Editable Parameters

Users can modify the following ADI.EUC parameters: Field Name Type/Unit Default Desription digitnumber number 7 Inbound: specifies number of incoming digits to expect optionflags number 0x9 bit 0 and 1 (& 0x3): these two bits specify what to play as cleardown tone. This is the tone the TCP plays when an inbound call is released and the calling party hasn't hung up yet. The bits specify: · &0x1: play busy · &0x2: play reorder If none of the bits is set, the TCP remains silent. · bit 2 (& 0x4): if specified, the trunk is inbound only (outbound calls are not allowed) · bit 3 (&0x8): if specified, the trunk is outbound only (a seizure from the switch is treated as a fault) · bit 4 (&0x10): if specified, the TCP signals the network that the call is accepted when rejecting with user audio. With some protocols this is the only way to make a spoken reject message go through. · bit 5 (&0x20) specifying this bit forces the TCP to perform call progress, when all digits have been delivered to the network in an outbound call, even for protocols that give a positive indication of the state of the call. The default value is 0. This will not start call progress detection if the user sets the connect mask to connect on SIGNAL. This saves DSP resources debugmask mask 0x0 Specifies generated trace messages are generated (run agtrace 1000 or higher to see them): · 0x01: Show all states as they are entered · 0x02: Show sent and received digits · 0x04: Show signaling bits · 0x08: Print a description of timeout- related errors These values can be ORed for cumulative effect.

Field Name	Type/Unit	Default	Desription
`digitnumber`	number	`7`	Inbound: specifies number of incoming digits to expect
`optionflags`	number	`0x9`	bit 0 and 1 (& 0x3): these two bits specify what to play as cleardown tone. This is the tone the TCP plays when an inbound call is released and the calling party hasn't hung up yet. The bits specify: · &0x1: play busy · &0x2: play reorder If none of the bits is set, the TCP remains silent. · bit 2 (& 0x4): if specified, the trunk is inbound only (outbound calls are not allowed) · bit 3 (&0x8): if specified, the trunk is outbound only (a seizure from the switch is treated as a fault) · bit 4 (&0x10): if specified, the TCP signals the network that the call is accepted when rejecting with user audio. With some protocols this is the only way to make a spoken reject message go through. · bit 5 (&0x20) specifying this bit forces the TCP to perform call progress, when all digits have been delivered to the network in an outbound call, even for protocols that give a positive indication of the state of the call. The default value is 0. This will not start call progress detection if the user sets the connect mask to connect on SIGNAL. This saves DSP resources
`debugmask`	mask	`0x0`	Specifies generated trace messages are generated (run `agtrace 1000 or higher to see them):` · `0x01: Show all states as they are entered` · `0x02: Show sent and received digits` · `0x04: Show signaling bits` · `0x08: Print a description of timeout- related errors` These values can be ORed for cumulative effect.

13.3.2 Non-editable Parameters

The following ADI.EUC parameters are country or network-specific, and cannot be modified. Field Name Type/Unit Example Description seizureacktime ms 10000 Relevant to outbound protocols. Specifies time to wait for seizure acknowledgment after seizing the line. seizurewaittime ms 200 Relevant to outbound protocols. Specifies the time to wait to be seized in a two-way trunk, after the TCP seized the line. answerwaittime internal 90 Relevant to outbound protocols. Specifies the maximum time for the protocol to wait after the call accepted indication until the phone is answered (seconds). acceptwaittime ms 20000 Relevant to outbound protocols. Specifies the maximum time for the protocol to wait after dialing before being notified that either the call has been accepted and the phone is ringing, or that the call has been rejected. digitspilltime ms 40000 Relevant to inbound protocols. Specifies the total time the dialing process is allowed to take. waitforPCtime ms 10000 Relevant to inbound protocols. Specifies the time the protocol waits for the host to decide if an inbound call should be accepted or rejected. bitqualtime ms 20 Specifies the qualification time for bit changes. interdigitreceivetime ms 5000 Relevant to inbound protocols. While receiving decadic pulses, if the number of expected incoming digits is not known, this parameter specifies the time between two trains of pulses to conclude that the incoming dial string is finished. winktime ms 150 Relevant to inbound protocols. Specifies the duration of an inbound wink. Depending on the target country, the wink has a different meaning and occurs at different phases of call setup. toneontime ms 80 Specifies the time a DTMF tone should be ON while dialing. toneofftime ms 80 Specifies the time a DTMF tone should be OFF while dialing. pulseontime ms 50 Specifies the time a pulse should be ON while dialing with decadic pulses. pulseofftime ms 50 Specifies the time a pulse should be OFF while dialing with decadic pulses. hightoneamplitude IDU 352 Specifies the amplitude of the higher frequency of the DTMF tones while dialing. lowtoneamplitude IDU 440 Specifies the amplitude of the lower frequency of the DTMF tones while dialing. interdigitsendtime ms 700 Relevant to outbound protocols. Specifies the time between two trains of pulses while dialing with decadic pulses. ringfreq Hz 425 Relevant to inbound protocols. Specifies the ring tone frequency. ringontime ms 1000 Relevant to inbound protocols. Specifies the time the ring tone is on in a ring cycle. ringofftime ms 4000 Relevant to inbound protocols. Specifies the time the ring tone is off in a ring cycle. busyfreq Hz 425 Relevant to inbound protocols. Specifies the busy tone frequency. busyontime ms 500 Relevant to inbound protocols. Specifies the time the busy tone is on in a busy cycle. busyofftime ms 500 Relevant to inbound protocols. Specifies the time the busy tone is off in a busy cycle. fastbusyontime ms 250 Relevant to inbound protocols. Specifies the time the congestion tone is on. fastbusyofftime ms 250 Relevant to inbound protocols. Specifies the time the congestion tone is off. CPtoneslevel IDU 350 Relevant to inbound protocols. Specifies the amplitude of call progress tones (ring and busy). signalingflags mask 0x1 Two bytes devoted to the protocol's signaling flags. They are: 0 DTMF 1 decadic AND the value of the parameter with this value to extract them. · bit 0 (&0x1) DTMF (0) or decadic (1) dialing. · bit 1 (&0x2) if set, an answer signal before all digits have been dialed is an error, and the TCP clears the call. NMScountry internal 25 (Italy) NMS code for the target country. Timers related to the AG Quad board resource management resourcegettimes internal 0x0a0f This parameter addresses a special need of protocols running on a AG Quad board with resource management enabled. If this is the case, for certain operations it is necessary to acquire a resource from a resource pool on the board. The parameter defines to timeouts after which the operation is aborted if a resource is not available. This is a very unlikely occurrence though. · Low byte: time to wait for resource before placing a call (15 s) · High byte: time to wait for resource when a resource is needed by inbound to release a call (e.g. to play a cleardown tone) (10 s) Miscellaneous mintimeconnected ms 250 inbound: the minimum time the TCP has to remain in the connected state (in order to allow the switch to bill the call) incomingqualtime ms 65 inbound: signaling bits qualification time while playing ring tone (Italy only) releaseguardtime ms 250 inbound: minimum time the release guard signal must be on timewaitunblock ms 200 time the TCP waits after receiving the command to unblock the line, before actually doing it and going to idle timeinterdigit ms 400 inbound: minimum time between trains of decadic pulses maxbillingpulse time (ms) 200 outbound: maximum duration of billing pulse (for those protocols in which the line code of a billing pulse is the same as clear back) maxdecadicpulse time (ms) 100 inbound: maximum duration of decadic pulse (for those protocols in which the line code of a decadic pulse is the same as clear forward)

Field Name	Type/Unit	Example	Description
`seizureacktime`	ms	`10000`	Relevant to outbound protocols. Specifies time to wait for seizure acknowledgment after seizing the line.
`seizurewaittime`	ms	`200`	Relevant to outbound protocols. Specifies the time to wait to be seized in a two-way trunk, after the TCP seized the line.
`answerwaittime`	internal	`90`	Relevant to outbound protocols. Specifies the maximum time for the protocol to wait after the call accepted indication until the phone is answered (seconds).
`acceptwaittime`	ms	`20000`	Relevant to outbound protocols. Specifies the maximum time for the protocol to wait after dialing before being notified that either the call has been accepted and the phone is ringing, or that the call has been rejected.
`digitspilltime`	ms	`40000`	Relevant to inbound protocols. Specifies the total time the dialing process is allowed to take.
`waitforPCtime`	ms	`10000`	Relevant to inbound protocols. Specifies the time the protocol waits for the host to decide if an inbound call should be accepted or rejected.
`bitqualtime`	ms	`20`	Specifies the qualification time for bit changes.
`interdigitreceivetime`	ms	`5000`	Relevant to inbound protocols. While receiving decadic pulses, if the number of expected incoming digits is not known, this parameter specifies the time between two trains of pulses to conclude that the incoming dial string is finished.
`winktime`	ms	`150`	Relevant to inbound protocols. Specifies the duration of an inbound wink. Depending on the target country, the wink has a different meaning and occurs at different phases of call setup.
`toneontime`	ms	`80`	Specifies the time a DTMF tone should be ON while dialing.
`toneofftime`	ms	`80`	Specifies the time a DTMF tone should be OFF while dialing.
`pulseontime`	ms	`50`	Specifies the time a pulse should be ON while dialing with decadic pulses.
`pulseofftime`	ms	`50`	Specifies the time a pulse should be OFF while dialing with decadic pulses.
`hightoneamplitude`	IDU	`352`	Specifies the amplitude of the higher frequency of the DTMF tones while dialing.
`lowtoneamplitude`	IDU	`440`	Specifies the amplitude of the lower frequency of the DTMF tones while dialing.
`interdigitsendtime`	ms	`700`	Relevant to outbound protocols. Specifies the time between two trains of pulses while dialing with decadic pulses.
`ringfreq`	Hz	`425`	Relevant to inbound protocols. Specifies the ring tone frequency.
`ringontime`	ms	`1000`	Relevant to inbound protocols. Specifies the time the ring tone is on in a ring cycle.
`ringofftime`	ms	`4000`	Relevant to inbound protocols. Specifies the time the ring tone is off in a ring cycle.
`busyfreq`	Hz	`425`	Relevant to inbound protocols. Specifies the busy tone frequency.
`busyontime`	ms	`500`	Relevant to inbound protocols. Specifies the time the busy tone is on in a busy cycle.
`busyofftime`	ms	`500`	Relevant to inbound protocols. Specifies the time the busy tone is off in a busy cycle.
`fastbusyontime`	ms	`250`	Relevant to inbound protocols. Specifies the time the congestion tone is on.
`fastbusyofftime`	ms	`250`	Relevant to inbound protocols. Specifies the time the congestion tone is off.
`CPtoneslevel`	IDU	`350`	Relevant to inbound protocols. Specifies the amplitude of call progress tones (ring and busy).
`signalingflags`	mask	`0x1`	Two bytes devoted to the protocol's signaling flags. They are: `0 DTMF` `1 decadic` `AND the value of the parameter with this value to extract them.` · bit 0 (&0x1) DTMF (0) or decadic (1) dialing. · bit 1 (&0x2) if set, an answer signal before all digits have been dialed is an error, and the TCP clears the call.
`NMScountry`	internal	`25` `(`Italy`)`	NMS code for the target country.
Timers related to the AG Quad board resource management
`resourcegettimes`	internal	`0x0a0f`	This parameter addresses a special need of protocols running on a AG Quad board with resource management enabled. If this is the case, for certain operations it is necessary to acquire a resource from a resource pool on the board. The parameter defines to timeouts after which the operation is aborted if a resource is not available. This is a very unlikely occurrence though. · Low byte: time to wait for resource before placing a call (15 s) · High byte: time to wait for resource when a resource is needed by inbound to release a call (e.g. to play a cleardown tone) (10 s)
Miscellaneous
`mintimeconnected`	ms	250	inbound: the minimum time the TCP has to remain in the connected state (in order to allow the switch to bill the call)
`incomingqualtime`	ms	65	inbound: signaling bits qualification time while playing ring tone (Italy only)
`releaseguardtime`	ms	250	inbound: minimum time the release guard signal must be on
`timewaitunblock`	ms	200	time the TCP waits after receiving the command to unblock the line, before actually doing it and going to idle
`timeinterdigit`	ms	400	inbound: minimum time between trains of decadic pulses
`maxbillingpulse`	time (ms)	200	outbound: maximum duration of billing pulse (for those protocols in which the line code of a billing pulse is the same as clear back)
`maxdecadicpulse`	time (ms)	100	inbound: maximum duration of decadic pulse (for those protocols in which the line code of a decadic pulse is the same as clear forward)

13.4 Special TCP Behavior

The following sections describe operations that are specific to the EUC TCP within the framework of Natural Call Control

13.4.1 Inbound Calls: Retrieving Digits All at Once

With EUC TCPs, after ADIEVN_INCOMING_CALL is received, the calledaddr field in the ADI_CALL_STATUS structure contains all received digits. The callingaddr, usercategory and tollcategory fields are NULL.
The parameter ADI.EUC.digitnumber determines the number of digits the TCP should expect from the calling party. Default is 7.

13.4.2 Inbound Calls: Retrieving Digits One at a Time

The TCP does not recognize ANI or category digits. Digits are presented in the order in which they arrive. The ADI.EUC.digitnumber parameter determines how many digits to expect.

13.4.3 Outbound Calls: Digit Format

EUC TCPs expect the digit string to be formatted as follows:
d1 dn
ANI and category indicators are not used in EUC TCPs.

(Page 1 of 1 in this chapter)

tech_support@nmss.com