NCC Field Name	ADI Field Name	Type/Unit	Example	Description
seizureacktime	seizureacktime	ms	10000	Outbound: Specifies time to wait for seizure acknowledgment after seizing the line.
seizurewaittime	seizurewaittime	ms	200	Outbound: Specifies the time to wait to be seized on a two-way trunk, after the TCP seized the line.
answerwaittime	answerwaittime	internal	90	Outbound: Specifies the maximum time for the protocol to wait after the call accepted indication until the phone is answered (seconds).
acceptwaittime	acceptwaittime	ms	20000	Outbound: 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	digitspilltime	ms	20000	Inbound: Specifies the total time the dialing process is allowed to take.
bitqualtime	bitqualtime	ms	20	Specifies the qualification time for bit changes.
interdigitreceivetime	interdigitreceivetime	ms	20000	Inbound: 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	winktime	ms	150	Inbound: 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	toneontime	ms	80	Specifies the time a DTMF tone should be ON while dialing.
toneofftime	toneofftime	ms	80	Specifies the time a DTMF tone should be OFF while dialing.
pulseontime	pulseontime	ms	50	Specifies the time a pulse should be ON while dialing with decadic pulses.
pulseofftime	pulseofftime	ms	50	Specifies the time a pulse should be OFF while dialing with decadic pulses.
hightoneamplitude	hightoneamplitude	IDU	352	Specifies the amplitude of the higher frequency of the DTMF tones while dialing.
lowtoneamplitude	lowtoneamplitude	IDU	440	Specifies the amplitude of the lower frequency of the DTMF tones while dialing.
interdigitsendtime	interdigitsendtime	ms	700	Outbound: Specifies the time between two trains of pulses while dialing with decadic pulses.
dialpulsemethod	signalingflags (bit 0)			Determines the dialing type: `0` `DTMF dialing` `1` `decadic dialing`
errorearlyanswer	signalingflags (bit 1)	mask	0x6	If this parameter is set to 1, an answer signal before all digits have been dialed is an error, and the TCP clears the call.
signalswep7in
NMScountry	NMScountry	internal	25 (Italy)	NMS code for the target country.
mintimeconnected	mintimeconnected	ms	200	Inbound: the minimum time the TCP has to remain in the connected state (in order to allow the switch to bill the call)
incomingqualtime	incomingqualtime	ms	60	Inbound: signaling bits qualification time while playing ring tone (Italy only)
releaseguardtime	releaseguardtime	ms	250	Inbound: minimum time the release guard signal must be on
timewaitunblock	timewaitunblock	ms	200	Time the TCP waits after receiving the command to unblock the line, before actually doing it and going to idle
timeinterdigit	timeinterdigit	ms	400	Inbound: minimum time between trains of decadic pulses
maxbillingpulse	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	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)

(Page 1 of 1 in this chapter) Version

Chapter 9

European Digital CAS Protocol

9.1 Introduction

9.2 Capability Mask

9.3 Signaling Overview

: 9.3.1 Italy (Norma CEI 103-1/7)
: 9.3.2 Sweden (P7/P8)
: 9.3.3 The Netherlands (ALS70D)
: 9.3.4 Register Signaling

9.4 Parameters

: 9.4.1 Editable Parameters
: 9.4.2 Non-editable Parameters

9.5 Special TCP Behavior

: 9.5.1 Inbound Calls: Retrieving Digits All at Once
: 9.5.2 Inbound Calls: Receiving Digits One at a Time
: 9.5.3 Outbound Calls: Digit Format
: 9.5.4 Billing Pulses

9.1 Introduction

This chapter describes the European Digital CAS (EUC) signaling protocol and TCP parameters.
This chapter provides the following information: Overview of the signaling performed by the protocols covered in the 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 three European countries, Italy, Sweden and The Netherlands. All of these countries define protocols that use two bits line signaling and DTMF digit spill register signaling, and are similar enough to be implemented by the same trunk control program.

9.2 Capability Mask

With the NCC service, an application can call nccQueryCapability to determine the capabilities of a protocol. nccQueryCapability returns a capabilitymask.
For information about the capabilities supported for AG CAS protocols with NCC call control, refer to Appendix B.

9.3 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 A_fand B_f in the forward direction, and A_b and B_b, 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 change. Their value is 0 and 1 respectively.
The line signaling for a typical call is illustrated by the following (country-specific) tables.

9.3.1 Italy (Norma CEI 103-1/7)


State	Outbound A_fB_f	Direction	Inbound A_bB_b
Idle	01		01
Seizure	10		01
Seizure Acknowledge	10		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 A_f 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		11-10-11 (150 ms)
End of selection - busy	10		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 should switch back to signaling AB = 01 (idle) thus clearing the line.
Ringing	00		11
Answer - conversation state	00		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	00
Billing pulses	00	10	00
Answer - conversation state	00	00	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		11
Clear forward (and release guard)	01		11
Idle	01		01
Outbound hangs up first: Clear forward	01		00
Release guard	01		11
Idle	01		01

9.3.2 Sweden (P7/P8)

P7/P8, the Swedish 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.
Moreover, two variations of incoming calls can be received: using the P7 or using the P8 protocol. The P7 protocol is two-way: it can be used both to place and to receive calls. The inbound (call reception) capability though does not support the transfer of DID digit, but acts essentially as a subscriber's telephone on a E1 timeslot. The P8 protocol is inbound only, and supports DID transmission.
Thus, three signaling diagrams are necessary to specify the protocol: Placing calls with P7 Receiving calls with P7 Receiving calls with P8

Placing calls with P7

State

Outbound A_fB_f (TCP)

Direction

Inbound A_bB_b (Network)

Idle

10

10

Seizure

00

10

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.

Dial tone

00

10

Once it has detected the dial tone, the outbound side starts to send the address information. This is done by mean of DTMF tones.

Register signaling: digit spill

DTMF

10

If the call is accepted, the inbound side plays a ring tone on the line and then flips the A_b bit to signal 00. Otherwise, it plays busy on the line.

Ringing

00

10

Answer - conversation state

00

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 = 01.

Answer - conversation state

00

00

Billing pulses

00

01

Answer - conversation state

00

00

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

10

Clear forward

10

00 or 10

Idle

10

10

State	Outbound A_fB_f (TCP)	Inbound A_bB_b (Network)
Idle	10	10
Seizure	00	10
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.
Dial tone	00	10
Once it has detected the dial tone, the outbound side starts to send the address information. This is done by mean of DTMF tones.
Register signaling: digit spill	DTMF	10
If the call is accepted, the inbound side plays a ring tone on the line and then flips the A_b bit to signal 00. Otherwise, it plays busy on the line.
Ringing	00	10
Answer - conversation state	00	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 = 01.
Answer - conversation state	00	00
Billing pulses	00	01
Answer - conversation state	00	00
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	10
Clear forward	10	00 or 10
Idle	10	10

Receiving calls with P7

State

Outbound A_fB_f (Network)

Direction

Inbound A_bB_b (TCP)

Idle

10

10

Seizure

01

10

Immediately when seized, the CPE (the TCP) plays ring tone on the line if the connected telephone is on-hook; busy tone if it's off-hook. If the tone is busy, the network abandons the call.
When the connected telephone is picked up, the TCP flips the A-bit to signal answer. The network then flips its B_f bit to signal that the call is through-connected to the remote caller.

Ringing

01

10

Answer

01

00

Through connection

00

00

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

10

Clear forward

10

00 or 10

Idle

10

10

If we have a clear back, i.e., the CPE clears the call first, and the network has a call waiting for that timeslot, the line can be seized immediately. In this case the sequence restarts from the Seizure (second row of this table).

Clear back

00

10

Seizure

01

10

State	Outbound A_fB_f (Network)	Inbound A_bB_b (TCP)
Idle	10	10
Seizure	01	10
Immediately when seized, the CPE (the TCP) plays ring tone on the line if the connected telephone is on-hook; busy tone if it's off-hook. If the tone is busy, the network abandons the call. When the connected telephone is picked up, the TCP flips the A-bit to signal answer. The network then flips its B_f bit to signal that the call is through-connected to the remote caller.
Ringing	01	10
Answer	01	00
Through connection	00	00
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	10
Clear forward	10	00 or 10
Idle	10	10
If we have a clear back, i.e., the CPE clears the call first, and the network has a call waiting for that timeslot, the line can be seized immediately. In this case the sequence restarts from the Seizure (second row of this table).
Clear back	00	10
Seizure	01	10

Receiving calls with P8

State

Outbound A_fB_f (Network)

Direction

Inbound A_bB_b (TCP)

Idle

10

10

Seizure

00

10

Proceed to send (Seizure Acknowledge)

00

00

Once it has detected the proceed to send signal, the outbound side starts to send the address information. This is done by mean of DTMF tones.

Register signaling: digit spill

DTMF

00

When all the digits have been received, the inbound side flips the A_b bit to signal that it has enough information. This state is maintained for at least 300 ms, and during ringing.

Number received

00

10

If the call is accepted, the inbound side play ring tones on the line and then flips the A_b bit to signal AB = 00. Otherwise, it plays busy tone and the network abandons the call.

Ringing

00

10

Answer - conversation state

00

00

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. Note that if the network clears the call first, the CPE must stay in connected (AB=00) for at least 150 ms but less than 250 ms.

Clear back

00

10

Clear forward

10

00 or 10

Idle

10

10

State	Outbound A_fB_f (Network)	Inbound A_bB_b (TCP)
Idle	10	10
Seizure	00	10
Proceed to send (Seizure Acknowledge)	00	00
Once it has detected the proceed to send signal, the outbound side starts to send the address information. This is done by mean of DTMF tones.
Register signaling: digit spill	DTMF	00
When all the digits have been received, the inbound side flips the A_b bit to signal that it has enough information. This state is maintained for at least 300 ms, and during ringing.
Number received	00	10
If the call is accepted, the inbound side play ring tones on the line and then flips the A_b bit to signal AB = 00. Otherwise, it plays busy tone and the network abandons the call.
Ringing	00	10
Answer - conversation state	00	00
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. Note that if the network clears the call first, the CPE must stay in connected (AB=00) for at least 150 ms but less than 250 ms.
Clear back	00	10
Clear forward	10	00 or 10
Idle	10	10

9.3.3 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 A_fB_f (TCP) Direction Inbound A_bB_b (Network) Idle 10 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 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 table, describing the inbound TCP behavior. Seizure Acknowledge 00 11 Here the inbound network side starts playing a dial tone on the voice channel, to mean that in-band (DTMF detector) 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 B_f 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 A_b bit to signal 01. Otherwise, it flips the B_b bit to signal 10 (idle). Ringing 00 11 Answer - conversation state 00 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 01 Billing pulses 00 00 Answer - conversation state 00 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 11 Clear forward 10 01 (or 11) Idle 10 10

The table for the inbound TCP is the following. State Outbound A_fB_f (Network) Direction Inbound A_bB_b (TCP) Idle 10 10 Seizure 00 10 Seizure Acknowledged 00 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 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 B_f 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 A_b bit to signal that it has enough information. This state is maintained for at least 300 ms. Number received 00 11 If the call is accepted, the inbound side play ring tones on the line and then flips the A_b bit to signal AB = 01. Otherwise, it plays busy and flips the B_b bit to signal AB = 10 (idle). Ringing 00 11 Answer - conversation state 00 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 11 Clear forward 10 01 (or 11) Idle 10 10

State	Outbound A_fB_f (TCP)	Inbound A_bB_b (Network)
Idle	10	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 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 table, describing the inbound TCP behavior.
Seizure Acknowledge	00	11
Here the inbound network side starts playing a dial tone on the voice channel, to mean that in-band (DTMF detector) 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 B_f 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 A_b bit to signal 01. Otherwise, it flips the B_b bit to signal 10 (idle).
Ringing	00	11
Answer - conversation state	00	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	01
Billing pulses	00	00
Answer - conversation state	00	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	11
Clear forward	10	01 (or 11)
Idle	10	10

State	Outbound A_fB_f (Network)	Inbound A_bB_b (TCP)
Idle	10	10
Seizure	00	10
Seizure Acknowledged	00	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	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 B_f 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 A_b bit to signal that it has enough information. This state is maintained for at least 300 ms.
Number received	00	11
If the call is accepted, the inbound side play ring tones on the line and then flips the A_b bit to signal AB = 01. Otherwise, it plays busy and flips the B_b bit to signal AB = 10 (idle).
Ringing	00	11
Answer - conversation state	00	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	11
Clear forward	10	01 (or 11)
Idle	10	10

9.3.4 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.
The Italian and Dutch 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.
The Swedish P8 protocol (setting up calls from the network to a CPE) can transfer other kinds of information. An incoming call with P8 can convey the following: ANI digits (caller ID); The last redirecting number (if the call was redirected from another terminal); or Both of the above.
To do this the protocol still uses a DTMF digit spill, but with special codes and separators that delimit the different fields.
The syntax is the following:
[Ac₁c₂c₃c₄c₅Dt₁...t_n[Dt₁...t_n]C]d₁...d_n
Where: The A, C, and D characters have to be taken literally (A=DTMF A) c_n is a DTMF tone used as a code element between the A and D digits t_n is a tone representing information about the call C represents the end of the call information part of the digit spill d_n is a DID digit.
A maximum of two D digits (separators) can be present, depending on the code that follows the A digit. If the first DTMF tone received is not A, only DID digits are present.
The possible codes are the following: code = 00000: only ANI information is available (one Dt₁...t_n sequence) code = 00030: only last forwarding number available (one Dt₁...t_n sequence) code = 00031: ANI and last forwarding number available (two Dt₁...t_n sequences, first ANI and second last redirecting number)

9.4 Parameters

The EUC TCP is programmed by the parameters described below to implement the specifications of the supported countries and network operators. These are stored within the parameter category NCC.X.ADI.EUC.
Parameters in this category fall into two groups: Parameters that program TCP/host interaction, or that act on features not regulated or that can change from switch to switch within the same network. You can freely edit these parameters to suit your implementation. Parameters that are signaling-specific: changing their values invalidates approvals for the board, and may cause the board to malfunction. These parameters are described here for reference purposes only.

9.4.1 Editable Parameters

The following table describes NCC.X.ADI.EUC parameters (within the parameter category NCC.X.ADI.EUC) that you may modify. Also listed are the equivalent ADI.EUC parameters, to assist with migration from ADI to NCC. NCC Field Name ADI Field Name Type/Unit Default Description digitnumber digitnumber number 7 Inbound: specifies number of incoming digits to expect. waitingplaybusy optionflags (bit 0) mask 1 This parameter and the waitingplayreorder parameter specify what to play as cleardown tone (the tone the TCP plays when an inbound call is released and the calling party has not hung up yet). If this parameter is 1,the busy tone is used as the cleardown tone. If neither of the parameters is set, the TCP remains silent. waitingplayreorder optionflags (bit 1) mask 0 This parameter and the waitingplaybusy parameter specify what to play as cleardown tone (the tone the TCP plays when an inbound call is released and the calling party has not hung up yet). If this parameter is 1,the fast busy (reorder) tone is used as the cleardown tone. If neither of the parameters is set, the TCP remains silent. trunkdirection optionflags (bits 2 and 8) mask 0 Determine trunk direction: 0 bidirectional 1 Inbound only (no calls can be placed on it) 2 Outbound only (no calls can be received on it) detectnetworkaudio optionflags (bit 5) mask 0 Setting this parameter to 1 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 connectmask to connect on SIGNAL. This saves DSP resources. lastdtmf optionflags (bits 13 - 18) number 0 These bits define the ST tone: the last received tone that outbound sends. 0 = ignored.

NCC Field Name	ADI Field Name	Type/Unit	Default	Description
digitnumber	digitnumber	number	7	Inbound: specifies number of incoming digits to expect.
waitingplaybusy	optionflags (bit 0)	mask	1	This parameter and the waitingplayreorder parameter specify what to play as cleardown tone (the tone the TCP plays when an inbound call is released and the calling party has not hung up yet). If this parameter is 1,the busy tone is used as the cleardown tone. If neither of the parameters is set, the TCP remains silent.
waitingplayreorder	optionflags (bit 1)	mask	0	This parameter and the waitingplaybusy parameter specify what to play as cleardown tone (the tone the TCP plays when an inbound call is released and the calling party has not hung up yet). If this parameter is 1,the fast busy (reorder) tone is used as the cleardown tone. If neither of the parameters is set, the TCP remains silent.
trunkdirection	optionflags (bits 2 and 8)	mask	0	Determine trunk direction: 0 bidirectional 1 Inbound only (no calls can be placed on it) 2 Outbound only (no calls can be received on it)
detectnetworkaudio	optionflags (bit 5)	mask	0	Setting this parameter to 1 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 connectmask to connect on SIGNAL. This saves DSP resources.
lastdtmf	optionflags (bits 13 - 18)	number	0	These bits define the ST tone: the last received tone that outbound sends. 0 = ignored.

9.4.2 Non-editable Parameters

The following NCC.X.ADI.EUC parameters are country or network-specific, and cannot be modified. Also listed are the equivalent ADI.EUC parameters, to assist with migration from ADI to NCC.

Caution:

Most of the parameters that follow are signaling-specific: changing their value will invalidate any approval certificate for the used board, and may cause the board to malfunction. These parameters are described here for reference purposes only.

NCC Field Name

ADI Field Name

Type/Unit

Example

Description

seizureacktime

seizureacktime

ms

10000

Outbound: Specifies time to wait for seizure acknowledgment after seizing the line.

seizurewaittime

seizurewaittime

ms

200

Outbound: Specifies the time to wait to be seized on a two-way trunk, after the TCP seized the line.

answerwaittime

answerwaittime

internal

90

Outbound: Specifies the maximum time for the protocol to wait after the call accepted indication until the phone is answered (seconds).

acceptwaittime

acceptwaittime

ms

20000

Outbound: 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

digitspilltime

ms

20000

Inbound: Specifies the total time the dialing process is allowed to take.

bitqualtime

bitqualtime

ms

20

Specifies the qualification time for bit changes.

interdigitreceivetime

interdigitreceivetime

ms

20000

Inbound: 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

winktime

ms

150

Inbound: 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

toneontime

ms

80

Specifies the time a DTMF tone should be ON while dialing.

toneofftime

toneofftime

ms

80

Specifies the time a DTMF tone should be OFF while dialing.

pulseontime

pulseontime

ms

50

Specifies the time a pulse should be ON while dialing with decadic pulses.

pulseofftime

pulseofftime

ms

50

Specifies the time a pulse should be OFF while dialing with decadic pulses.

hightoneamplitude

hightoneamplitude

IDU

352

Specifies the amplitude of the higher frequency of the DTMF tones while dialing.

lowtoneamplitude

lowtoneamplitude

IDU

440

Specifies the amplitude of the lower frequency of the DTMF tones while dialing.

interdigitsendtime

interdigitsendtime

ms

700

Outbound: Specifies the time between two trains of pulses while dialing with decadic pulses.

dialpulsemethod

signalingflags (bit 0)

Determines the dialing type:
0 DTMF dialing
1 decadic dialing

errorearlyanswer

signalingflags (bit 1)

mask

0x6

If this parameter is set to 1, an answer signal before all digits have been dialed is an error, and the TCP clears the call.

signalswep7in

NMScountry

NMScountry

internal

25 (Italy)

NMS code for the target country.

mintimeconnected

mintimeconnected

ms

200

Inbound: the minimum time the TCP has to remain in the connected state (in order to allow the switch to bill the call)

incomingqualtime

incomingqualtime

ms

60

Inbound: signaling bits qualification time while playing ring tone (Italy only)

releaseguardtime

releaseguardtime

ms

250

Inbound: minimum time the release guard signal must be on

timewaitunblock

timewaitunblock

ms

200

Time the TCP waits after receiving the command to unblock the line, before actually doing it and going to idle

timeinterdigit

timeinterdigit

ms

400

Inbound: minimum time between trains of decadic pulses

maxbillingpulse

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

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)
The following parameters are reserved for internal NMS use: alarmsonqualtime alarmsoffqualtime

*Caution:*	Most of the parameters that follow are signaling-specific: changing their value will invalidate any approval certificate for the used board, and may cause the board to malfunction. These parameters are described here for reference purposes only.

9.5 Special TCP Behavior

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

9.5.1 Inbound Calls: Retrieving Digits All at Once

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

9.5.2 Inbound Calls: Receiving Digits One at a Time

To receive digits one at a time make sure the NCC.START.OVERLAPPED.RECEIVING parameter is set.
The TCP does not recognize ANI or category digits. Digits are presented in the order in which they arrive. The NCC.X.ADI.EUC.digitnumber parameter determines how many digits to expect.
In the case of the P8 Swedish protocol with ANI and redirecting terminal information, the digit string can be received as follows:
# firstfield # [secondfield] # d₁ d_n
where firstfield and secondfield are contingent to the reception of the corresponding code. The code itself is not presented to the application.

9.5.3 Outbound Calls: Digit Format

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

9.5.4 Billing Pulses

If the network provides this service, an outbound call receives billing pulses during the Connected state. These are brief variations in the state of the signaling bits, that signal that a unit of cost has been billed to the call. The actual price of a unit of cost changes from network to network, as does the frequency with which billing pulses are received.
An application placing outbound calls can set the bit NCC_REPORT_BILLING in the NCC.START.eventmask parameter to enable the reception of billing pulse events. These are presented as NCCEVN_BILLING_INDICATION events by CT Access. The application can then count the events to calculate the cost of the call.

(Page 1 of 1 in this chapter) Version

tech_support@nmss.com