(Page 1 of 1 in this chapter)
Version
Chapter 18
System R1.5 Protocol
18.1 Introduction
18.2 Capability Mask
18.3 Signaling Overview
18.4 Parameters
18.4.1 Editable Parameters
18.4.2 Non-editable Parameters
18.5 Special TCP Behavior
18.5.1 Inbound Calls: Retrieving Digits All at Once
18.5.2 Inbound Calls: Recieving Digits One at a Time
18.1 Introduction
This chapter describes the System R1.5 (R15) signaling protocol and TCP parameters.
This chapter provides the following information:
Overview of signaling performed by the System R 1.5 protocol, implemented by the R15 TCP.
R15 TCP parameters.
Operations specific to the R15 TCP within the framework of Natural Call Control.
The R15 TCPs implement a number of different protocols that are in use in the Russian telephone network. The protocols run on E1 trunks. Two separate TCPs are used for inbound and outbound calls, since the protocols' structure excludes the possibility of two-way trunks. They are named
r150.tcp
and
r151.tcp
. Separate call setup schemes are used for local and long distance calls as well; both TCPs support both schemes.
18.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
.
18.3 Signaling Overview
The R1.5 protocols use two signaling bits per direction to control the state of calls. The bits used are the A and B bits. Line signaling is a combination of signaling bit variations and in-band tones.
Register signaling is usually performed by acknowledged MF tones. This means that the outbound equipment plays a forward tone (representing one of the address digits), and the inbound equipment requests the next tone by playing a backward MF tone. Both tones are timed, not compelled.
However, it is possible for the outbound to be requested to switch to decadic pulse dialing during setup of a call, since not all switches in the Russian networks are equipped with MF tone detectors.
MF-Pulse Shuttle protocol is the default register signaling for both inbound and outbound protocols and can be combined or replaced with some other types of register signaling.
18.4 Parameters
The R15 inbound and outbound TCPs are programmed for operation within different countries and networks by a number of TCP-specific parameters. These are stored within the parameter category NCC.X.ADI.ADI.R15.
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
.
18.4.1 Editable Parameters
The following table describes
NCC.X.ADI.R15
parameters (within the parameter category
NCC.X.ADI.R15
) that you may modify. Also listed are the equivalent
ADI.R15
parameters, to assist with migration from ADI to NCC.
NCC Field Name
ADI Field Name
Type/Unit
Default
Description
DIDnumber
DIDnumber
number
7
Inbound
. Specifies the number of incoming DID digits to expect.
ANInumber
ANInumber
number
8
Inbound
. Specifies the number of ANI digits to expect. If this parameter is set to 0, then the inbound protocol does not attempt to request the ANIs. If this parameter is set to any other number, the inbound protocol will request the ANIs, and will receive as many as the outbound side will provide.
decadicsignalmethod
optionflags
(bit 0)
mask
0x0
Set to 1
to do decadic dialing (for both inbound and outbound protocols).
longdistanceinbound
optionflags
(bit 1)
mask
0x0
Set to 1
for long distance inbound protocol.
mustsendANI
optionflags
(bit 2)
mask
0x0
Set to 1
to make the transmission of ANIs mandatory (relevant to the outbound protocol).
mustgetANI
optionflags
(bit 3)
mask
0x0
Set to 1
to make the reception of ANIs mandatory (relevant to the inbound protocol).
waitingplaybusy
optionflags
(bit 4)
mask
0x0
Set to 1
to play busy on timeout.
waitingplayreorder
optionflags
(bit 5)
mask
0x0
Set to 1
to play fast busy on timeout.
waitingplaysilence
optionflags
(bit 6)
mask
0x0
Set to 1
to play silence on timeout.
longdistancedecadic
optionflags
(bit 9)
mask
0x0
Reserved.
switchtoDecadic
optionflags
(bit 10)
mask
0x0
Reserved.
sendANIsingledigit
optionflags
(bit 12)
mask
0x0
Set to 1
to enable the detection of ANIs one at a time. The information will be presented in the form of an
NCCEVN_PROTOCOL_EVENT
with a value
R15_ANI_DIGIT
. The value of the digit may be retrieved by looking at the
size
field.
firstcommand
firstcommand
number
1
Inbound
. First command for inbound protocol.
1
Send first digit.
2
Send next digit.
3
Send previous digit.
If the value is set to 2 or 3, make sure that
DIDnumber
is set to a correct value.
anirequestattempts
anirequestattempts
number
3
Inbound
. The parameter specifies the number of attempts to obtain ANIs. If the parameter is set to 0, no attempts will be made.
When reception of ANIs is mandatory (bit
0x8
in
optionflags
is set) and no ANIs are received after the first attempt, this parameter can be used to perform additional ANI requests before clearing back.
dialstartposition
dialstartposition
number
4
Outbound
. The value of this parameter is used to define the starting position within a dial string; i.e, when the first request from the inbound side, defined by
NCC.X.ADI.R15.firstcommand
, is B2 (send next digit) or B3 (send the previous digit) the first DID that is presented by the outbound side is located in the
NCC.X.ADI.R15.dialstartposition
position.
18.4.2 Non-editable Parameters
The following
NCC.X.ADI.R15
parameters are country- or network-specific, and cannot be modified. Also listed are the equivalent
ADI.R15
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
qualtime
qualtime
ms
20
Specifies the qualification time for bit changes.
waitbegintime
waitbegintime
ms
60
Specifies the delay before starting to play the forward and backward tones.
Outbound Timers
seizetime
seizetime
ms
400
Specifies the maximum time to receive the seizure acknowledge.
waitbacksignaltime
waitbacksignaltime
ms
4000
Specifies the maximum time to receive a backward request.
pausefrstdigittime
pausefrstdigittime
ms
300
Specifies the initial wait before dialing the first decadic pulse.
interdigittime
interdigittime
ms
750
Specifies the time between two trains of pulses while dialing with decadic pulses.
confirmanswertime
confirmanswertime
ms
275
Specifies the timeout for differentiating answer vs. ANI request which is the same line code but accompanied by a 500 Hz tone.
Inbound Timers
waitfrwdsignaltime
waitfrwdsignaltime
ms
350
Maximum time to receive a forward signal.
waitfrwddeksignaltime
waitfrwddeksignaltime
ms
40000
Maximum time to receive a decadic digit.
inbinterdigittime
inbinterdigittime
ms
400
Specifies the time to wait before deciding that a train of decadic pulses is over.
Inbound ANI Detector Timers
anitonetimeout
anitonetimeout
ms
100
Specifies the time to wait before deciding that the transmission of ANIs is over.
anirequesttimeout
anirequesttimeout
ms
1000
Specifies the timeout to get the first ANI.
answersignalontime
answersignalontime
ms
500
Specifies the duration of line signal AB-10 (answer) when requesting ANIs.
requestdelaytime
requestdelaytime
ms
100
Specifies the delay between A-12 and the ANI request line signal AB-10.
tonedelaytime
tonedelaytime
ms
150
Specifies the delay between signaling answer during the ANI request and sending the 500 Hz tone.
Note
: This value has been optimized for use within the Russian network. It should be decreased for back-to-back testing.
Dialing Control
toneontime
toneontime
ms
45
Specifies the duration of the MF tone used to convey DID information (backward and forward).
toneofftime
toneofftime
ms
45
Specifies the silence between the MF tones used to convey DID information (backward and forward) - also used for echo cancellation.
pulseontime
pulseontime
ms
50
Outbound
: Specifies the time a pulse should be ON while dialing with decadic pulses.
pulseofftime
pulseofftime
ms
50
Outbound
: Specifies the time a pulse should be OFF while dialing with decadic pulses.
anitoneontime
anitoneontime
ms
40
Outbound
: Specifies the duration of the MF tone used to convey ANI information.
toneslevel
toneslevel
IDU
315
Specifies the amplitude of MF (call setup) tones (forward and backward).
anirequestontime
anirequestontime
ms
110
Specifies the duration of the 500 Hz tone during an ANI request.
The following parameters are reserved for NMS internal use:
alarmsonqualtime
alarmsoffqualtime
18.5 Special TCP Behavior
The following sections describe operations that are specific to the R15 TCPs within the framework of Natural Call Control.
18.5.1 Inbound Calls: Retrieving Digits All at Once
When the application receives the
NCCEVN_INCOMING_CALL
event, not all information regarding the inbound call is available. For local calls, the missing information is the caller's category and ANI digits. This is because the R1.5 local outbound protocol sends the category and ANI digits only after the call has been accepted by the inbound party. Thus the
NCC_CALL_STATUS
has only one relevant field that is filled if the application calls
nccGetCallStatus
after an
NCCEVN_INCOMING_CALL
event:
Field
Description
calledaddr
The called number. Also referred to as the Direct Inward Dial (DID) number.
If the application accepts the call, the TCP collects the caller's category and ANI digits. Once they are available, the application can receive an
NCCEVN_CALL_STATUS_UPDATE
with a value of
NCC_CALL_STATUS_CALLINGADDR
,
or
NCCEVN_EXTENDED_CALL_STATUS_UPDATE
with a value of
NCC_EXTENDED_CALL_STATUS_CATEGORY
.
Note:
The reception of this event must be explicitly enabled before starting the protocol, by setting the
NCC_REPORT_STATUSINFO
bit in the
NCC.START.eventmask
parameter.
A subsequent call to
nccGetCallStatus
yields the following new field:
callingaddr
The calling number (if available). Also referred to as the
Automatic Number Identification (ANI) number.
Another call to
nccGetExtendedCallStatus
yields the following new field:
usercategory
The calling party category, e.g., normal subscriber, operator,
maintenance equipment.
Two
NCC.X.ADI.R15
parameters affect the way the R15 TCPs accept and process digits:
Parameter
Description
DIDnumber
This parameter determines the number of Direct Inward Dial (DID) digits the TCP should expect from the calling party. Default is 7.
ANInumber
This parameter determines the number of ANI and category digits the TCP should expect from the calling party. For local inbound calls, if the parameter is set to 0, the ANI request will not be attempted; otherwise the TCP retrieves all the digits the calling party will send. This parameter is not relevant for long distance inbound calls.
18.5.2 Inbound Calls: Recieving Digits One at a Time
The R15 TCP sends the incoming DID digits to the application one at a time in the following sequence:
d
1
d
n
where
n
is determined by the
NCC.X.ADI.R15.DIDnumber
parameter.
If the application sets the
NCC.X.ADI.sendanisingledigit
parameter., the TCP also provides the ANI digits and the caller category as they arrive. This happens after the call is accepted by the application. Due to the working of the protocol, ANI digits may be:
Reversed (last digit of the calling number first in sequence)
Presented more than once, since the switch sends the category and ANI digits in a fast spill which can be repeated several times
Note:
ANI digits for the R1.5 protocol are presented through the
NCCEVN_PROTOCOL
event when the value is
R15_ANI_DIGIT
. The
size
field of the event structure contains the actual digit value.
(Page 1 of 1 in this chapter)
Version
tech_support@nmss.com
Copyright © 1999, Natural MicroSystems, Inc. All rights reserved.