Version
Chapter 7
European Digital CAS Protocol
7.1 Introduction
7.2 Capability Mask
7.3 Signaling Overview
7.3.1 Italy (Norma CEI 103-1/7)
7.3.2 Sweden (P7/P8)
Placing Calls With P7
Receiving Calls With P7
Receiving Calls With P8
7.3.3 The Netherlands (ALS70D)
7.3.4 Register Signaling
7.4 Parameters
7.4.1 Editable Parameters
7.4.2 Non-editable Parameters
7.5 Special TCP Behavior
7.5.1 Inbound Calls: Retrieving Digits All at Once
7.5.2 Inbound Calls: Receiving Digits One at a Time
7.5.3 Outbound Calls: Digit Format
7.5.4 Billing Pulses
7.1 Introduction
This chapter describes the European Digital CAS (EUC) signaling protocol and TCP parameters. It 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.
7.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 NMS CAS protocols with NCC call control, refer to
Appendix A
.
7.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
f
and 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.
7.3.1 Italy (Norma CEI 103-1/7)
State
Outbound A
f
B
f
Direction
Inbound A
b
B
b
Idle
01
01
Seizure
10
01
Seizure Acknowledge
10
11
The outbound side starts to send the address information using DTMF tones or 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 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 is accepted, the inbound side plays a ring tone on the line, after resuming to signal AB = 11 (
seizure acknowledged
). If the call is rejected, the outbound side should switch back to signaling AB = 01 (
idle
), thus clearing the line.
Ringing
10
11
Answer - conversation state
10
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.
Billing pulses
10
00-10-00
(125 ms)
Depending on which side hangs up the call first, a
clear back
signal or a
clear forward
signal is generated. A period of
release guard
from inbound follows both signals, meaning of acknowledgment of the clear operation. Idle follows.
Inbound hangs up first: Clear back
10
01
Clear forward
01
01
Release guard
01
11
Idle
01
01
Outbound hangs up first: Clear forward
01
00
Release guard
01
11
Idle
01
01
7.3.2 Sweden (P7/P8)
P7/P8, the Swedish National CAS Protocol, is asymmetrical, meaning 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 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.
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
f
B
f
(TCP)
Direction
Inbound A
b
B
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
f
B
f
(Network)
Direction
Inbound A
b
B
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, for example, 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
f
B
f
(Network)
Direction
Inbound A
b
B
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
7.3.3 The Netherlands (ALS70D)
ALS70D, the Dutch National CAS Protocol, is asymmetrical, meaning 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
f
B
f
(TCP)
Direction
Inbound A
b
B
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
The inbound network side starts playing a dial tone on the voice channel, meaning 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 using DTMF tones or 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 was 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 side hangs up the call first, a
clear forward
signal or a
clear back
signal is generated, followed by a
clear forward
. Idle follows.
Clear back
00
11
Clear forward
10
01 (or 11)
Idle
10
10
The following table represents the signaling carried out by the inbound TCP:
State
Outbound A
f
B
f
(Network)
Direction
Inbound A
b
B
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 detects the
ready to receive
signal, the outbound side starts to send the address information using DTMF tones or 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 plays 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 side hangs up the call first, a
clear forward
signal or a
clear back
signal is generated, followed by a
clear forward
. Idle follows.
Clear back
00
11
Clear forward
10
01 (or 11)
Idle
10
10
7.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:
[
A
c
1
c
2
c
3
c
4
c
5
D
t
1
...
t
n
[
D
t
1
...
t
n
]
C
]
d
1
...
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
D
t
1
...
t
n
sequence)
code =
00030
: only last forwarding number available (one
D
t
1
...
t
n
sequence)
code =
00031
: ANI and last forwarding number available (two
D
t
1
...
t
n
sequences, first ANI and second last redirecting number)
7.4 Parameters
The EUC TCP is programmed by the following parameters to implement the specifications of the supported countries and network operators. These parameters 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
.
7.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
count
7
Inbound
: specifies number of incoming digits to expect.
waitingplaybusy
optionflags
(bit 0)
mask
0x1
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
0x0
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
0x0
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
0x0
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 value will not start call progress detection if the user sets the
connectmask
to connect on SIGNAL. The 0 value saves DSP resources.
lastdtmf
optionflags
(bits 13 - 18)
mask
0x0
These bits define the ST tone: the last received tone that outbound sends. 0 = ignored.
7.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
Default
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
count
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)
mask
0
Determines the dialing type:
0
DTMF dialing
1
decadic dialing
errorearlyanswer
signalingflags
(bit 1)
mask
0x0
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
signalingflags
(bit 2)
mask
0x0
Configures protocol for inbound P7.
NMScountry
NMScountry
count
25 (Italy)
NMS code for the target country.
mintimeconnected
mintimeconnected
ms
200
Inbound
: the minimum time the TCP must 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
7.5 Special TCP Behavior
The following sections describe operations that are specific to the EUC TCP within the framework of Natural Call Control.
7.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.
7.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
1
d
n
where
firstfield
and
secondfield
are contingent to the reception of the corresponding code. The code itself is not presented to the application.
7.5.3 Outbound Calls: Digit Format
EUC TCPs expect the digit string to be formatted as follows:
d
1
d
n
ANI and category indicators are not used in EUC TCPs.
7.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 Natural Access. The application can then count the events to calculate the cost of the call.
Version
Want to send us feedback on our documentation? Email:
Tech_Pubs@nmss.com
Copyright © 2001, Natural MicroSystems, Inc. All rights reserved.