Etsi isup inap_iw_book

NT Europe SIM Speciﬁcation
DMS Implementation of ETSI
ISUP / INAP interworking
Release 4 ETSI ISUP/INAP Interworking SIM
Date:
Version:
13 December 1996
PRE 0.2 (draft)
Originated by: BNR Department EP11
Classiﬁcation: RESTRICTED
Activity ID: 10-95-0070
NIS number: 94-80nn
Acknowledgements:
7020 Design Team

Notice
This document and the information contained herein is provided “as is” with no warranty of any kind,
expressed or implied. This includes, but is not limited to, the implied warranties of merchantability or
fitness for any particular purpose. The entire risk as to quality and performance of the information
provided is with the user. Should the information prove defective, the user assumes the cost of all
necessary servicing, repair, or correction. In no event is Northern Telecom liable for any damages,
direct, indirect, or consequential.
Northern Telecom may, but is not obliged to, update the information, or arrange for the information to be
updated, and make the updates available to users from time to time.
Release Process
This document adheres to the Strategic Interface Management (SIM) process. The SIM process is an
administrative process developed to manage the evolution of interface specifications through
authorisation, approval and verification stages.
The four stages of an interface document that follows the SIM process are:
PRE: This is the initial recommendation. The prefix PRE indicates that this document is at a
preliminary stage, and as such should be treated as a ‘draft’ document. External distribution
is limited.
AUT: Following the authorisation of the document by NT and BNR design the prefix of the revision
status is promoted to AUT. AUT implies that the document has been fully authorised and that
it represents the agreed interface product undergoing development.
APP: Upon completion of the design and test of the interface product the prefix of the document is
promoted to APP. At this stage the document broadly relates to BCS IS quality.
VER: Following final verification of the interface in the field, the document's prefix is promoted to
VER. This document represents the final release of the interface product in its current
version.

Document signoff
BNR Design
Approval
Kathy Shaw Senior Manager,
WT IN
Development
(7020)
Signature:
Date:
BNR Planning
Approval
Iain Donaldson Senior Manager,
Product Planning
Switching
(EP10)
Signature:
Date:
NT Product
Management
Approval
David Ainsworth Director,
Product Line
Management
Signature:
Date:

Change history
Version Date of Release Summary of Changes
PRE 0.1 (draft) 11 October 1996 First release of preliminary draft for internal Planning
review and limited distribution outside Planning.
Draft based on Release 4 IBN7 interworking spec.
PRE 0.2 (draft) 13 December 1996 Incorporate ETSI ISUP review comments, and
relevant comments from BTUP review.

NIS 94-80nn World Trade IN Release 4 ETSI ISUP/INAP Interworking
PRE 0.2 (draft) Preface
13 December 1996 Page v
Preface
Purpose
This document is a Strategic Interface Management (SIM) speciﬁcation for the
World Trade Intelligent Network (IN) project. The aim of the project is to plan and
develop a DMS Service Switching Point (SSP), i.e. software that will enable a
DMS-100E to provide IN SSP functionality as well as its usual network functions.
The purpose of this issue of the document is to describe accurately the
interworking features of Release 4 of the DMS SSP product. Features introduced
in Release 4 are:
• Support for the bearerCapability parameter of the INAP operation IntialDP
• Support for an Ethernet Link Interface Unit, which allows CCS7 messages to
be encapsulated in TCP/IP packets and sent over an Ethernet Local Area
Network
Content
This document describes DMS SSP support for interworking between ETSI ISUP
and the Intelligent Network Application Part (INAP). Such interworking enables
the DMS SSP to support IN services for calls that originate in the PSTN and arrive
at the DMS SSP via ETSI ISUP trunks.

Release 4 ETSI ISUP/INAP Interworking World Trade IN NIS 94-80nn
Preface PRE 0.2 (draft)
Page vi 13 December 1996
Structure
The specification is organised into the following sections:
• Section 1: Introduction on page 1
• Section 2: Triggering IN Interaction on page 15
• Section 3: Call Processing Suspended on page 31
• Section 4: Call Processing Resumed on page 53
• Section 5: Service Filtering on page 61
There are also appendices that provide detailed information about the mapping of
parameters between ETSI ISUP messages and INAP operations.
Readership
The specification is intended to serve three purposes:
• To provide a functional view of ETSI ISUP / INAP interworking that will
enable BNR Planning and NT Marketing to assess its applicability for
potential customers.
• To examine possible implementations of the interworking and compare these
with current and planned DMS SSP capabilities. This will enable BNR
Planning, BNR Design and NT Product Management to decide on the best
method of supporting the interworking.
• To define all the requirements of the agreed implementation method to a
level of detail sufficient to enable BNR Design to build it, and to serve as the
definitive BNR and NT source of reference information on the interworking
after it has been built.
The specification will be subject to regular review, and will be updated to
incorporate comments, to capture new information, and to reflect evolving
requirements for ETSI ISUP / INAP interworking within the World Trade IN
project.

PRE 0.2 (draft) Preface
13 December 1996 Page vii
References
Related World Trade IN Documents
[1] NIS 94-8000 World Trade IN Document Roadmap
[2] NIS 94-8008 DMS Implementation of CS-1R INAP (ETSI Core INAP
Subset)
[3] AG5307 Ethernet LIU
[4] AG5313 Bearer Capability
[5] DMS SSP Product Description
Technical References
[6] ETS 300 374-1 ETSI specification of Core INAP for IN Capability Set 1
[7] Q.1214 Distributed Functional Plane for Intelligent Network CS-1
[8] Q.1218 Interface Recommendation for Intelligent Network CS-1
[9] Q.1224 Distributed Functional Plane for Intelligent Network CS-2
[10] Q.1228 Interface Recommendation for Intelligent Network CS-2
[11] Q.771 to Q.775 ITU-T TCAP specifications (Blue Book)
[12] Q.711 to Q.714 ITU-T SCCP specifications (Blue Book)
[13] Q.701 to Q.704 ITU-T MTP specifications (Blue Book)
NT/BNR Process Documentation used by BNR Planning
[14] NQAPR102 Strategic Interface Management (SIM) Process
[15] NQAPR103 Document Control Process
[16] NQAPR104 Document Review Process

Preface PRE 0.2 (draft)
Page viii 13 December 1996

PRE 0.2 (draft) Abbreviations
13 December 1996 Page ix
Abbreviations
ACM Address Complete Message (ETSI ISUP)
AMA Automatic Message Accounting
ANM Answer Message (ETSI ISUP)
ANSI American National Standards Institute
ASF ActivateServiceFiltering (INAP operation)
AUT AUThorised for release
BCSM Basic Call State Machine
CCF Call Control Function
CCS7 Common Channel Signalling System No 7
CDR Call Detail Recording
CIRP CallInformationReport (INAP operation)
CIRQ CallInformationRequest (INAP operation)
CS-1 Capability Set 1 (for IN)
CS-2 Capability Set 2 (for IN)
CTR ConnectToResource (INAP operation)
DFC DisconnectForwardConnection (INAP operation)
DMS Digital Multiplex System
DP Detection Point
DRAM Digital Recorded Announcement Machine
DTC Digital Trunk Controller
EDP Event Detection Point
EDRAMEnhanced (single-card) DRAM
ELIU Ethernet Link Interface Unit
ERB EventReportBCSM (INAP operation)
ETC EstablishTemporaryConnection (INAP operation)
ETSI European Telecommunications Standards Institute
(CEPT standards body)
FCI FurnishChargingInformation (INAP operation)
FN Functional Speciﬁcation
FSM Finite State Machine
IAM Initial Address Message (ETSI ISUP)
IDP InitialDP (INAP operation)
IN Intelligent Network
INAP Intelligent Networks Applications Part
IP Intelligent Peripheral
ISDN Integrated Services Digital Network

Abbreviations PRE 0.2 (draft)
Page x 13 December 1996
ISUP ISDN User Part (part of CCS7)
ITU International Telecommunications Union
LE Local Exchange
MTP Message Transfer Part (part of CCS7)
NT Northern Telecom
NUP National User Part
OAM Operations, Administration and Maintenance
OSI Open Standard for Interconnection
P&C PromptAndCollectUserInformation (INAP operation)
PA PlayAnnouncement (INAP operation)
PDU Protocol Data Unit
PIC Point In Call
POTS Plain Ordinary Telephone Service
PRE PREliminary status
PRI ISDN Primary Rate Interface
PSTN Public Switched Telephone Network
RES Resume message (ETSI ISUP)
RRBE RequestReportBCSMEvent (INAP operation)
RT ResetTimer (INAP operation)
SAM Subsequent Address Message (ETSI ISUP)
SCCP Signalling Connection Control Part (part of CCS7)
SCF Service Control Function
SCP Service Control Point
SDL State (machine) Description Language
SDT SDL Tool
SFR ServiceFilteringResponse (INAP operation)
SIM Strategic Interface Management
SRF Specialised Resource Function
SRR SpecializedResourceReport (INAP operation)
SRSM Specialised Resource State Machine
SSF Service Switching Function
SSME SSF Management Entity
SSN Subsystem Number (identiﬁes CCS7 user or application part within node)
SSP Service Switching Point
STP Signalling Transfer Point
SUS Suspend (ETSI ISUP message)
TCAP Transaction Capabilities Application Part
TDP Trigger Detection Point

NIS 94-80nn World Trade IN Release 4 ETSI ISUP / INAP Interworking
PRE 0.2 (draft) Table of Contents
13 December 1996 Page xi
Table of Contents
Preface v
Abbreviations ix
Table of Contents xi
1 Introduction 1
1.1 The Need for Interworking 1
1.1.1 Access Signalling and IN Signalling 1
1.1.2 Terminating Signalling 2
1.1.3 External IP Signalling 2
1.1.4 Functional Elements Involved in Interworking 3
1.2 DMS SSP Support for IN capabilities 5
1.2.1 INAP Operation Support 5
1.2.2 BCSM Support 6
1.2.2.1 Overview of the BCSM 6
1.2.2.2 Detection Point Types 7
1.2.2.3 DMS SSP Support for TDPs 8
1.2.2.4 DMS SSP Support for EDPs 8
1.3 DMS SSP Support for ETSI ISUP 9
1.4 Overview of ETSI ISUP / INAP Interworking 9
1.4.1 IN Interaction Involving the SCF 10
1.4.2 IN Interaction Handled by SSF (Service Filtering) 12
2 Triggering IN Interaction 15
2.1 Introduction 15
2.2 IN Interaction with ETSI ISUP En-Bloc Signalling 16
2.2.1 Overview of En-Bloc Signalling 16
2.2.2 Sequence of Events 17
2.2.2.1 Call Arrival (PIC_1) 17
2.2.2.2 Digit Collection (PIC_2) 18
2.2.2.3 Triggering at TDP-2 (Collected Info) 18
2.2.2.4 Digit Translation (PIC_3) 18
2.2.2.5 Triggering at TDP-3 (Analysed Info) 18

13 December 1996 Page xii
2.2.2.6 Trigger Processing 19
2.2.2.7 Initiating IN Interaction 20
2.3 IN Interaction with ETSI ISUP Overlap Signalling 21
2.3.1 Overview 21
2.3.2 Sequence of Events 21
2.3.2.1 Call Arrival (PIC_1) 22
2.3.2.2 Digit Collection (PIC_2) 23
2.3.2.3 Triggering at TDP-2 (Collected Info) 23
2.3.2.4 Digit Translation (PIC_3) 24
2.3.2.5 Triggering at TDP-3 (Analyzed Info) 24
2.3.2.6 Trigger Processing 25
2.3.2.7 Initiating IN Interaction 29
2.4 Feature interaction Before First IN trigger 29
2.5 Error handling 30
2.5.1 Errors Detected by INAP 30
2.5.2 Timer Expiry 30
2.5.3 Errors Detected by TCAP 30
2.5.4 Errors Detected by ETSI ISUP 30
3 Call Processing Suspended 31
3.1 Overview 31
3.2 Billing 32
3.2.1 AMA Billing Records 32
3.3 User Interaction 33
3.3.1 INAP Operations Used 33
3.3.2 User Interaction Using an Integrated IP 35
3.3.2.1 Message Flow Overview 35
3.3.2.2 Sequence of Events 38
3.3.3 User Interaction Using an External IP 39
3.3.3.1 Message Flow Overview 39
3.3.3.2 Sequence of Events 42
3.4 Resumption of O_BCSM call processing 44
3.4.1 Call Completion (Connect) 44
3.4.2 Call Clearing (ReleaseCall) 46
3.5 Error Handling 46
3.5.1.1 Errors Detected by the SCF 46
3.5.1.2 Errors Detected by the SSF/SRF 46
3.5.2.1 Expiry of TSSF 48
3.5.2.2 Expiry of TSRF 49
3.5.3.1 Errors Detected by the SCF 50
3.5.3.2 Errors Detected by the SSF 50
3.5.4 User-Initiated Abort 50

13 December 1996 Page xiii
4 Call Processing Resumed 53
4.1 Call Completion (after Connect) 53
4.2 Call Clearing (after ReleaseCall) 55
4.3 Returning Requested Call Information 56
4.4 Monitoring 56
4.4.1 Monitoring for DP-4 (Route_Select_Failure) 57
4.5.1.1 Errors Detected at the SCF 58
4.5.1.2 Errors Detected at the SSF or SRF 58
5 Service Filtering 61
5.1 Activation of Service Filtering 61
5.2 Call Processing during Service Filtering 63
5.2.1 Overview 63
5.2.2 Sequence of Events for a Filtered IN Call 63
5.3 Termination of Service Filtering 66
A Forward Setup (IAM to InitialDP) 69
A.1 Mappings between Parameters 69
A.2 Deriving INAP Parameter Values from ETSI ISUP 69
A.2.1 ServiceKey 70
A.2.2 EventTypeBCSM 70
A.2.3 CallingPartysCategory 70
A.2.4 CalledPartyNumber 70
A.2.5 CallingPartyNumber 71
A.2.6 BearerCapability 71
A.2.7 Extensions 72
B Forward Setup (Connect to IAM) 73
B.1 Mappings between Parameters 73
B.2 Deriving ETSI ISUP Parameter Values from INAP 74
B.2.1 DestinationRoutingAddress/CutAndPaste ->
Called Party Number 74

13 December 1996 Page xiv
B.2.2 CallingPartysCategory 75
B.2.3 Extensions 75
C Backward Setup (ACM and ANM) 77
D PRI Interworking for External IP Connection 79
D.1 Establishing a Connection 79
D.1.1 Deriving PRI Parameter Values from INAP 80
D.1.1.1 assistingSSPIPRoutingAddress -->
Called Party Number 80
D.1.1.2 correlationID --> User to User Information 80
D.2 Terminating a Connection 82
D.3 Interworking Restrictions 83
E Call Clearing Parameters 85
E.1 Mapping INAP Cause Values 85
E.2 Call Clearing Initiated by DMS SSP 86
E.2.1 SCP Sends ReleaseCall 86
E.2.2 SCP Sends DisconnectLeg 86
E.2.3 Routing Failure Within the DMS SSP 86
E.3 Call Clearing Initiated Elsewhere 87
E.3.1 Calling Party Disconnects Before Call is Completed 87
E.3.2 Call Fails to Complete After Connect 87

NIS 94-80nn World Trade IN Section 1:
PRE 0.2 (draft) Release 4 ETSI ISUP / INAP Interworking Introduction
13 December 1996 Page 1
1 Introduction
1.1 The Need for Interworking
1.1.1 Access Signalling and IN Signalling
Support for interworking between the following types of signalling is a
prerequisite for Intelligent Networking (IN):
• IN signalling, i.e. the interface used for inter-node signalling between IN
functions. This is the Intelligent Network Application Part (INAP).
• IN access signalling, i.e. interfaces over which IN functionality is accessed
from the underlying network (e.g. PSTN, VPN). The access signalling
interface considered in this speciﬁcation is ETSI ISUP Version 1 (referred to
in this document simply as ETSI ISUP).
This speciﬁcation describes DMS SSP support for interworking between ETSI
ISUP and INAP. Such interworking enables the DMS SSP to support IN services
for calls that arrive at the DMS SSP via ETSI ISUP trunks, as shown in Figure 1.
INAP and ETSI ISUP are both Common Channel Signalling System No7 (CCS7)
interfaces. INAP is the top layer of a CCS7 Blue Book protocol stack comprising
the Transaction Capabilities Application Part (TCAP), the Signalling Connection
Control Part (SCCP) and the Message Transfer Part (MTP); INAP operations are
conveyed in TCAP components within MTP Message Signal Units (MSUs). ETSI
ISUP uses only the MTP; ETSI ISUP messages are packaged directly in MSUs. In
protocol terms, interworking between ETSI ISUP and INAP involves (but is not
limited to) mapping INAP operations and ETSI ISUP messages.

Section 1: World Trade IN NIS 94-80nn
Introduction Release 4 ETSI ISUP / INAP Interworking PRE 0.2 (draft)
Page 2 13 December 1996
Figure 1 Interworking between access signalling and IN signalling
Subscribers access the IN by means of basic calls. IN service calls are initially
distinguished from non-IN calls on the same ETSI ISUP trunks, which require
normal call processing, by means of the digits dialled by the calling party. Special
numbers (e.g. an 0800 FreePhone number or equivalent) are recognised as
requiring IN processing by comparing them with trigger criteria held at the switch.
If a match occurs, the call triggers and IN processing is initiated. The ETSI ISUP
Basic Call State Machine (BCSM) then waits for the result of the IN interaction
before routing the call to its ﬁnal destination.
1.1.2 Terminating Signalling
If IN interaction results in a call being routed on through the PSTN, outward call
completion may take place either over the access signalling system (ETSI ISUP) or
over any other signalling system with which the access signalling system can
interwork (see the DMS-SSP Product Description for a list of the signalling
systems with which ETSI ISUP can interwork).
1.1.3 External IP Signalling
If an external Intelligent Peripheral (IP) is used (e.g. for collecting further
information from the user, for playing announcements to the user, or to provide
speech recognition facilities), a connection is set up between the DMS SSP and the
external IP over an ETSI PRI trunk.
Tandem
or local
switch
SCP
IN
IN
PSTN
DMS
SSP
Access signalling
ETSI ISUP/INAP
point
interworking
(e.g. ETSI ISUP)
signalling
(INAP)
Call can be routed onward
to any ETSI
ISUP-compatibleinterface
External
IPPRI
ELIU
SCPTCP/IP
CCS7

Note: Although Figure 1 shows an external IP directly connected to the DMS SSP,
the connection need not be direct. Although the outgoing trunk from the DMS SSP
will be ETSI PRI, setting up a link to an external IP may involve interworking with
other agents. However, depending on how the address of the external IP is
specified, there may be restrictions on interworking; see Appendix D for details.
1.1.4 Functional Elements Involved in Interworking
An intelligent network is defined to consist of functional elements (also referred to
as functional entities or simply functions) that have the following characteristics:
• Each functional element is clearly defined at a logical level as a state
machine (or a set of related state machines).
• A given functional element is always allocated to a single physical node, but
a given node may accommodate two or more functional elements.
• Communication within the IN is defined in terms of information flows
between functional elements (which cause changes to the respective state
machines), rather than in terms of messages between nodes.
Functional elements on different nodes communicate using INAP. The following
list defines the most important IN functional elements:
SCF Service Control Function
Typically, an IN service is implemented by means of service logic and a
database under SCF control. The role of the SCF is to respond to service
requests from the SSF, e.g. by providing routing information that makes it
possible to complete a call. The SCF is usually allocated to an SCP (Service
Control Point) node. The DMS SSP uses INAP to communicate with an SCF
on an SCP.
Note: As a low cost alternative to supplying a CCS7 interface between the
DMS SSP and the SCP, the DMS SSP supports an Ethernet Link Interface
Unit (ELIU), which allows CCS7 messages to be encapsulated in TCP/IP
packets for transmission to a ServiceBuilder SCP connected via an Ethernet
Local Area Network.
SSF Service Switching Function
The SSF provides the interface between the PSTN and the IN. Its key tasks
are to recognise PSTN calls that require IN service processing, and to
interact with CCF call processing and SCF service logic to ensure that those
calls are successfully completed. The SSF is usually allocated to an SSP
(Service Switching Point) node. The DMS SSP supports an SSF Finite State
Machine (FSM).

SRF Specialised Resource Function
The SRF provides any specialised resources that are required for interaction
with the end user, either to provide information or to obtain it. Information is
typically provided in the form of announcements or tones, and is typically
collected as dialled digits. The SRF is logically allocated to an Intelligent
Peripheral (IP), which may be integrated with an SSP or may be a separate
node attached to an SSP.
The DMS SSP supports an integrated IP, in which the DMS switch itself
provides features for digit collection and playing recorded announcements.
The DMS SSP also supports connections to an external IP, which provides
SRF-type services. The DMS SSP uses a PRI trunk to set up a link to the
external IP, which can then communicate directly with the SCP without
further involvement by the DMS SSP.
CCF Call Control Function
The CCF is not, strictly speaking, an IN functional element, but a standard
Basic Call State Machine (BCSM) for which trigger criteria are deﬁned that
determine the conditions under which a given call requires IN service access.
Because it interacts closely with the SSF, the CCF usually resides with the
SSF in an SSP node. The DMS SSP supports CCF functions by means of a
ETSI ISUP BCSM with access to trigger tables that specify which dialled
digits will initiate IN service access.
Figure 2 shows how these functional elements, particularly those implemented on
the DMS SSP, interact to support interworking.
Figure 2 Interaction between IN functional elements to support interworking
Note: Although Figure 2 shows an external IP directly connected to the DMS SSP,
the connection need not be direct. Although the outgoing trunk from the DMS SSP
will be ETSI PRI, setting up a link to an external IP may involve interworking with
other agents.
DMS
SSP
SCP
INAP
ETSI ISUP
SSF
SCF
CCF
Terminating
interface/agent
SRF
Interworking
External IP
PRI
SRF
Integrated IP
INAP

1.2 DMS SSP Support for IN capabilities
The DMS SSP implementation of IN is based on ITU-T CS-1R (Capability Set 1)
procedures and the ETSI Core INAP protocol. Its support for IN capabilities can be
summarised under two headings:
• Support for the INAP operations defined in Q.1218 and ETS 300 374-1
• Support for the Basic Call State Machine (BCSM) defined in Q.1214
1.2.1 INAP Operation Support
ETS 300 374-1 defines a total of 29 Core INAP operations (these are a subset of
the operations defined in Q.1218). The operations supported by the DMS SSP can
be roughly divided into the following categories:
• Call setup operations for single-stage calls (no user interaction required):
InitialDP
Connect
• Call setup operations for two-stage calls (with SCP-initiated user
interaction):
ConnectToResource
EstablishTemporaryConnection
PromptAndCollectUserInformation
PlayAnnouncement
SpecializedResourceReport
DisconnectForwardConnection
The ConnectToResource operation is used to set up a connection to the DMS
SSP’s integrated IP. With such a connection there is no direct communication
between the SCF and the SRF. The SSF can be regarded as relaying
operations between the SCF and the SRF.
The EstablishTemporaryConnection operation is used to set up a temporary
connection to another node in the network (e.g. an external IP, which
provides SRF-type services). With such a connection there is direct
communication between the SCF and the external IP, with the SSF being
involved only in setting up and taking down the connection. There is no
relaying involving the SSF.
• Call billing operations (can be used with 1-stage or 2-stage call setup):
FurnishChargingInformation

• Timer control operations (can be used with 1-stage or 2-stage call setup):
ResetTimer
The SCF can use the ResetTimer operation to prevent the SSF timing out a
call during user interaction.
• Call-independent operations:
ActivateServiceFiltering
ServiceFilteringResponse
• Call clearing (call cannot be completed):
ReleaseCall
This interworking specification describes how the sending and receiving of
operations relates to the sending and receiving of ETSI ISUP messages. For
detailed operation descriptions, see the separate specification DMS
Implementation of CS-1R INAP (ETSI Core INAP Subset) (NIS 94-8008).
1.2.2 BCSM Support
1.2.2.1 Overview of the BCSM
The BCSM defined in Q.1214 provides a standard abstract view of how the
processing of a basic call proceeds and the way in which basic call processing
interacts with IN query processing. Q.1214 defines two BCSM entities:
• The Originating BCSM (O_BCSM)
• The Terminating BCSM (T_BCSM)
The DMS SSP supports only the Originating BCSM.
The BCSM defines the progress of a call in terms of the following:
• Points In Call (PICs), which are equivalent to states.
• Transitions between PICs, which correspond to state changes and indicate
the possible flow of call processing from one PIC to another.
• Events, which are associated with Transitions, and cause them to take place.
• Detection Points (DPs), which provide IN entry points, i.e. points in the
BCSM at which the SCF can become involved in order to provide an IN
service. DPs are located between PICs, i.e. interaction with the IN takes
place not within PICs but during transitions between them.

Sections 1.2.2.2 to 1.2.2.4 discuss DPs in more detail.
1.2.2.2 Detection Point Types
DPs are intermediate points between BCSM PICs, at which there may be
interaction between call processing and the IN (specifically, interaction with the
SCF via the SSF). Ten DPs are defined for the O_BCSM. A given DP can be set up
in any of four ways, as shown in Table 1.
TDPs may be defined as conditional or non-conditional. A non-conditional TDP
has no associated trigger criteria, and all calls that encounter the TDP trigger IN
interaction (if the trigger is armed). A conditional TDP has one or more associated
trigger criteria, and calls that encounter the TDP trigger IN interaction only if the
criteria match.
Table 1: DP types defined in Q.1214
TDP-R
(Trigger Detection Point - Response)
A trigger detection point causes
interaction to take place between call
processing and the SCF when static
datafill-defined criteria are met. The
response suffix means that information is
required from the SCF as a result of the
interaction, and BCSM call processing is
suspended awaiting this response.
TDP-N
(Trigger Detection Point - Notification)
A trigger detection point causes
interaction to take place between call
processing and the IN when static
datafill-defined criteria are met. The
notification suffix means that the SCF is
simply told of what has happened; no
information is expected from it, and BCSM
call processing continues.
EDP-R
(Event Detection Point - Response)
An event detection point is set up for a
particular call in response to a request
from the SCF, asking to be notified when a
given call processing event takes place.
The response suffix means that
information is required from the SCF as a
result of the interaction, and BCSM call
processing is suspended awaiting this
response.
EDP-N
(Event Detection Point - Notification)
An event detection point is set up for a
particular call in response to a request
from the SCF, asking to be notified when a
given call processing event takes place.
The notification suffix means that the
SCF is simply told of what has happened;
no information is expected from it, and
BCSM call processing continues.

1.2.2.3 DMS SSP Support for TDPs
The DMS SSP supports the following DPs as TDP-Rs:
• DP-2 in the O_BCSM (Collected_Info). TDP-2 is supported both as an
unconditional TDP (i.e. a call always triggers at TDP-2 if it is armed), and as
a conditional TDP with either of the following trigger criteria:
- Feature Code. A feature code is a string of dialled digits consisting of
the character * or # followed by up to three digits. Feature codes are
typically used for such things as special feature activation/deactivation.
A call triggers at TDP-2 if the TDP is armed and the collected digits
match a datafilled feature code.
- Specific Digit String. A call triggers at TDP-2 if the TDP is armed and
the first N collected digits match a datafilled digit string.
• DP-3 in the O_BCSM (Analyzed_Info). TDP-3 is supported only as a
conditional TDP with the Specific Called Party Number String criterion. A
call triggers at TDP-3 if the TDP is armed and the first N digits of the
translated called party number (up to and including the whole number)
matches a datafilled number string.
When a TDP is triggereD, it causes the SSF to send an InitialDP operation to the
SCF to initiate IN interaction.
1.2.2.4 DMS SSP Support for EDPs
DPs are dynamically armed as EDPs in response to a request from the SCF, made
via an RequestReportBCSMEvent (RRBE) operation specifying one of two
monitoring modes:
• NotifyAndContinue, which causes the DP to be armed as an EDP-N.
• Interrupted, which causes the DP to be armed as an EDP-R.
An RRBE operation can specify a third mode, Transparent, which has the effect of
disarming previously armed EDPs.
The DMS SSP supports only one EDP on outgoing ETSI ISUP trunks. This is
EDP-4, Route_Select_Failure, which can be armed as an EDP-R.

1.3 DMS SSP Support for ETSI ISUP
The ISDN User Part (ISUP) is the CCS7 user part that supports not only basic
telephony, but also ISDN data calls, and a range of supplementary services based on
the exchange of information using out-of-band messages.
ISUP performs the functions of OSI Layers 4 to 7, but in fact operates as a single
layer, i.e. no information is added or removed for the intermediate layers, and ISUP
information has exactly the same format at Level 7 as at Level 4. It uses the Message
Transfer Part (MTP) to support message transfer, i.e. ISUP messages are conveyed
between nodes in MTP Message Signal Units (MSUs).
ETSI ISUP [requires a description of what ETSI ISUP actually is].
The ETSI ISUP interface supported by DMS-100E switch is fully documented in:
ETSI ISUP Interface Speciﬁcation
Issue Aut 1.2
14 March 1991
NIS D313-1
[This references needs to be amended to show an ETSI ISUP reference.]
This is a set of documents describing the ISDN User Part (ISUP), the Transaction
Capabilities Application Part (TCAP), the Signalling Connection Control Part
(SCCP), the Message Transfer Part (MTP), and ETSI ISUP network services.
1.4 Overview of ETSI ISUP / INAP Interworking
There are two cases to consider:
• After the SSF has recognised that a call requires IN processing, IN
interaction is directly controlled by the SCF. This is the normal case, and is
described in Section 1.4.1.
• The SCF delegates IN processing to the SSF (service ﬁltering). IN
interaction is handled primarily by the SSF, which periodically reports
results to the SCF. This case is described in Section 1.4.2.

1.4.1 IN Interaction Involving the SCF
The aim of IN interaction directly controlled by the SCF is usually the completion
of a call (e.g. to a FreePhone or Primary Rate number). There are three stages in the
processing of a call that encounters such IN interaction:
• Triggering
• Suspension of call processing while IN processing takes place
• Resumption of call processing using information obtained from the SCF
These are illustrated in Figure 3. Sections 2 to 4 of this speciﬁcation are organised
in accordance with this structure, as follows:
• Section 2: Triggering IN Interaction on page 15, which deals with:
- Triggering via ETSI ISUP signalling (note that ETSI ISUP call setup
signalling is always en-bloc; ETSI ISUP does not support overlap
signalling)
- The impact of feature interactions before triggering
• Section 3: Call Processing Suspended on page 31, which deals with:
- Updating billing records with IN-related information
- User interaction with the caller (to play an announcement or to collect
information from the user)
- Arming DPs as EDPs to monitor call completion once O_BCSM call
processing resumes
Note: Only EDP-4, Route_Select_Failure, is supported on outgoing
DPNSS trunks.
- Resumption of O_BCSM call processing
• Section 4: Call Processing Resumed on page 53, which deals with:
- Normal call completion after receipt of a Connect operation
- Call clearing after receipt of a ReleaseCall operation
Each of these sections also includes a section on error handling during the
corresponding stage of an IN call.

Figure 3 Stages in the processing of an IN call
SSP routes call onward,
using information from
SCF to modify information
received via ETSI ISUP
SCF sends Connect
with call setup information
SCF-initiated interaction
with caller to collect
further information; speech
path through-connected
backward via ETSI ISUP
Charging information
received from SCF
(optional)
Call triggers on armed TDP;
IN interaction initiated and
call processing suspended
Collected digits are translated
Incoming ETSI ISUP call received by DMS
Call origination
Call termination
Call
processing
before
triggering
of IN
interaction
Call
processing
suspended
during IN
interaction
Call
processing
resumed
after IN
interaction
1-stage
call
setup
2-stage
call
setup
SCF sends ReleaseCall
with release code
Test TDP-2 to see if it is armed
Test translated digits for criteria match
Not armed
No match
TDP-2 triggers
TDP-3 triggers
No IN
interaction
SCF tells SSF to arm
EDPs (note that they will
be disarmed when the call
is connected)
Call setup
with monitoring

1.4.2 IN Interaction Handled by SSF (Service Filtering)
The aim of service filtering is to count the number of calls made to a specified
number, or the number of calls made to each one of a series of numbers (e.g. for
TeleVoting). This counting is done by the SSF; there is no SCF involvement,
except that the SCF initiates service filtering and the SSF periodically reports
results to the SCF. The stages are:
• Activation of service filtering
• Triggering for calls to be filtered
• Processing of calls that trigger service filtering
• Termination of service filtering
These are illustrated in Figure 4. Service filtering is described in more detail in
Section 5: Service Filtering on page 61.

Figure 4 Stages in service filtering
Call triggers at an armed TDP;
IN interaction initiated
Test TDP-2 to see if it is armed
Incoming ETSI ISUP call received by DMS SSP
Call origination
PRI call
processing
before
triggering
Call count incremented
Translate collected digits
Test translated digits for criteria match
TDP-2 triggers
Activation
of service
filtering
Service filtering
terminates when final
report sent to SCF
Filtering
results
collected
and
reported
SCF tells SSF to begin filtering, specifying:
• Call processing information
• How long filtering is to last
• How often to report results
• Numbers for which to provide counts of incoming calls
PRI call
processing
continued
at SSF
Call cleared with
specified Cause value
Call billed as specified
Specified announcement
played to caller
Final report of call counts
provided when specified
duration of filtering expires
Interim reports of call
counts provided at
specified intervals
Termination
of service
filtering
Call termination
TDP-3 triggers
Not armed
No IN
interaction
No match
Filtered call

PRE 0.2 (draft) Release 4 ETSI ISUP / INAP Interworking Triggering IN Interaction
2 Triggering IN Interaction
2.1 Introduction
On receipt of an incoming ETSI ISUP call on the originating side of the DMS SSP,
the SSF remains in the state Idle, while the CCF (which contains the O_BCSM)
processes the call as normal (traversing through the various PICs and DPs of the
O_BCSM), until and unless an armed TDP is encountered.
If an armed TDP is encountered, the SSF FSM moves to the state Trigger
Processing and determines whether DP criteria conditions have been met.
If the TDP is armed as an unconditional TDP, or if criteria conditions are met
(criteria match established) for a conditional TDP, and the TDP encountered is a
TDP-R, the call triggers and the SSF will:
1. Suspend O_BCSM call processing at the current DP
2. Start the guard timer TSSF
3. Generate an INAP InitialDP operation and send it to the SCF
4. Move to the state Waiting For Instructions
If criteria conditions are not met (criteria match not established), e.g. because the
call is not an IN call, the SSF FSM returns to the state Idle and O_BCSM call
processing continues with no IN interaction.

Triggering IN Interaction Release 4 ETSI ISUP / INAP Interworking PRE 0.2 (draft)
2.2 IN Interaction with ETSI ISUP En-Bloc
Signalling
2.2.1 Overview of En-Bloc Signalling
In the case of en-bloc signalling, the IAM message from the originating side
contains complete called party information.
The ETSI ISUP/INAP interaction is as shown in Figure 5.
Figure 5 Incoming ETSI ISUP call (successful trigger)
IAM
DMS SSP SCP
InitialDP
Start
TSSF
Originating
side
BCSM
TDP-2 armed?
Waiting for
Instructions
SSF FSM
Criteria
match
PIC_1
PIC_2
Collect digits
PIC_3
Translate
digits
TDP-3 armed?
Idle
Trigger
Processing
Trigger
Processing
IdleCall
proceeds
with no IN
interaction
PIC_4
Criteria
match
No
match
No
match

2.2.2 Sequence of Events
The sequence of events is as follows:
1. A call arrives at the DMS SSP. See Section 2.2.2.1.
2. The DMS SSP collects digits from the caller (see Section 2.2.2.2), and
possibly triggers interaction between the O_BCSM and the SSF (see Section
2.2.2.3).
3. The DMS SSP translates the collected digits (see Section 2.2.2.4), and
2.2.2.5).
4. If the call has not triggered at this point, it completes without any IN
interaction.
Trigger processing is described in Section 2.2.2.6. Trigger processing may initiate
IN interaction, as described in Section 2.2.2.7.
2.2.2.1 Call Arrival (PIC_1)
When the DMS SSP receives a ETSI ISUP Initial Address Message (IAM), it
creates a new instance of the ETSI ISUP Originating Basic Call State Machine
(O_BCSM), which will initially be in PIC_1.
The call is marked as a potential IN call according to the trigger subscription(s) in
effect at the switch. Two types of subscription are supported:
• Office or switch-wide subscription, which means that all incoming ETSI
ISUP calls are treated as potential IN calls.
• Trunk group subscription, which means that only ETSI ISUP calls incoming
on specified trunk groups are treated as potential IN calls.
Trunk group subscription takes priority over office subscription.
No significant processing takes place within PIC_1, so the O_BCSM moves from
PIC_1 to PIC_2. The DMS SSP does not support the arming of TDP-1 (Originating
Attempt Authorised), so this TDP cannot trigger interaction with the SSF.
The SSF FSM (with which no interaction has yet taken place) is in state Idle.

2.2.2.2 Digit Collection (PIC_2)
In PIC_2, the DMS SSP collects dialled digits, which are provided in the Address
Signals parameter of the IAM message.
The O_BCSM leaves PIC_2. The SSF FSM remains in state Idle.
2.2.2.3 Triggering at TDP-2 (Collected Info)
On leaving PIC_2, the O_BCSM encounters TDP-2 (Collected Info). This can be
armed as a TDP-R, either unconditionally or with the following trigger criteria:
• Feature Code
• Specific Digit String
Note: TDP-2 is armed unconditionally by datafilling a value of 0 for Minimum
Digits. If Minimum Digits is datafilled with a value n (n>0), the call will trigger
only if the number of dialled digits is greater than or equal to n.
If the call is marked as a potential IN call, and TDP-2 is armed, this initiates
interaction between the O_BCSM and the SSF. The SSF FSM moves from state
Idle to state Trigger Processing. See Section 2.2.2.6 for a description of what
happens in this state.
Otherwise, the O_BCSM moves from PIC_2 to PIC_3 without initiating
interaction with the SSF. The SSF FSM remains in state Idle.
2.2.2.4 Digit Translation (PIC_3)
In PIC_3 the digits received from the originating side go through translations.
After translations, the O_BCSM leaves PIC_3.
The SSF FSM remains in state Idle.
2.2.2.5 Triggering at TDP-3 (Analysed Info)
On leaving PIC_3, the O_BCSM encounters TDP-3 (Analyzed Info). This can be
armed as a TDP-R, with trigger criterion Specific Called Party Number String.

interaction with the SSF, and the SSF FSM remains in state Idle. Since the DMS
SSP supports no TDPs after TDP-3, the call will now progress to completion
without any IN interaction.
2.2.2.6 Trigger Processing
An armed TDP will only initiate IN processing if the trigger criterion associated
with the TDP matches one of the datafilled values at the switch.
If a TDP has triggered, the SSF tests whether trigger criteria match a value
datafilled at the switch:
• If TDP-2 is armed with Minimum Digits as the trigger criterion, is the
number of dialled digits greater than or equal to the datafilled value?
Note: If Minimum Digits is datafilled with the value 0, the call will always
initiate IN processing. The TDP is an unconditional TDP.
• If TDP-2 is armed with Feature Code as the trigger criterion, do the collected
digits match a datafilled feature code for an IN service?
• If TDP-2 is armed with Specific Digit String as the trigger criterion, do the
collected digits match a datafilled digit string associated with an IN service?
• If TDP-3 is armed with Specific Called Party Number String as the trigger
criterion, do the translated collected digits match a datafilled called party
number associated with an IN service?
If there is no criteria match, the call is not recognised as an IN call, and the SSF
FSM moves from state Trigger Processing back to state Idle. The O_BCSM moves
to PIC_3 (see Section 2.2.2.4) or to PIC_4 (in which case the call progresses to
completion without any IN interaction), depending on which TDP has triggered.
If there is a criteria match, the call is recognised as an IN call. O_BCSM
processing is suspended and the SSF initiates IN interaction as described in Section
2.2.2.7.
Note: If IAM does not include a Calling Party Number parameter, and the service
key indicates that CLI is required, the call will be cleared.

2.2.2.7 Initiating IN Interaction
The SSF initiates IN interaction by assembling an INAP InitialDP operation and
sending this to the SCF in a TCAP BEGIN package. The parameters of the
InitialDP operation are assembled partly from ETSI ISUP message parameters, and
partly from triggering information dataﬁlled at the switch, as follows:
For a more detailed description of IAM / InitialDP parameter mapping, refer to
Appendix A.
When the SSF has sent InitialDP, the SSF FSM moves from state Trigger
Processing to state Waiting For Instructions, and waits for a response from the
SCF. Call processing in the O_BCSM remains suspended.
See Chapter 3 for a description of the interaction between ETSI ISUP and INAP
while call processing is suspended.
a.If datafill does not explicitly request that Calling Party Number be included in Ini-
tialDP, it is not included, even if it is provided in IAM.
ETSI ISUP IAM parameter INAP InitialDP parameter
Calling Party’s Category
(in IAM Message Indicators)
CallingPartysCategory
Called Party Number CalledPartyNumber
Calling Party Numbera
CallingPartyNumber
<dataﬁll for dialled digits> ServiceKey
Supplied by DMS SSP EventTypeBCSM
Transmission Medium Requirement bearerCapability

2.3 IN Interaction with ETSI ISUP Overlap
Signalling
Handling of incoming ETSI ISUP overlap calls is similar to that of ETSI ISUP
en-bloc calls. The primary differences are:
• The initial IAM message does not contain all the information necessary to
complete the call.
• Triggering may occur before all called party digits have been received.
This results in more complex interaction, which is summarised in Section 2.3.1 and
described in detail in Section 2.3.2.
2.3.1 Overview
2.3.2 Sequence of Events
The sequence of events is as follows:
1. A call arrives at the DMS SSP. See Section 2.3.2.1.
2. The DMS SSP collects digits from the caller (see Section 2.3.2.2), and
2.3.2.3).
3. The DMS SSP translates the collected digits (and may collect more digits)
(see Section 2.3.2.4), and possibly triggers interaction between the O_BCSM
and the SSF (see Section 2.3.2.5).
4. If the call has not triggered at this point, it completes without any IN
interaction.
Trigger processing is described in Section 2.3.2.6. Trigger processing may initiate
IN interaction, as described in Section 2.3.2.7.

Figure 6 Incoming ETSI ISUP overlap call (successful trigger)
2.3.2.1 Call Arrival (PIC_1)
When the DMS SSP receives an ETSI ISUP Initial Address Message (IAM), it
creates a new instance of the ETSI ISUP Originating Basic Call State Machine
(O_BCSM), which will initially be in PIC_1.
The call is marked as a potential IN call according to the trigger subscription(s) in
effect at the switch. Two types of subscription are supported:
• Ofﬁce or switch-wide subscription, which means that all incoming ETSI
ISUP calls are treated as potential IN calls.
IAM
DMS SSP SCP
SAM(s)
Originating
side
TDP-2 armed?
BCSM SSF FSM
PIC_2
Collect digits
PIC_1
Idle
Trigger
Processing
Waiting for
Instructions
No
match
PIC_3
Translate
digits
TDP-3 armed? Trigger
Processing
Call
proceeds
with no IN
interaction
PIC_4
Idle
No
match
Criteria
match
(additional
info not req’d)
InitialDP
Start
TSSF
Potential
match
Potential
match
Start
inter-digit
timer

• Trunk group subscription, which means that only ETSI ISUP calls incoming
on specified trunk groups are treated as potential IN calls.
Trunk group subscription takes priority over office subscription.
No significant processing takes place within PIC_1, so the O_BCSM moves from
PIC_1 to PIC-2. The SSF FSM (with which no interaction has yet taken place) is in
state Idle. The DMS SSP does not support the arming of TDP-1 (Originating
Attempt Authorised), so this TDP cannot trigger interaction with the SSF.
The SSF FSM (with which no interaction has yet taken place) is in state Idle.
2.3.2.2 Digit Collection (PIC_2)
In PIC_2, the DMS SSP collects dialled digits, which are provided in the Address
Signals parameter of the IAM message.
The O_BCSM leaves PIC_2, even though digit collection is still in progress. The
SSF FSM remains in state Idle.
The procedure for collecting further digits is described below. Although it is
described here for convenience, it should be understood that the O_BCSM will
have moved out of PIC_2 by the time further digits arrive.
After receiving the IAM message, the DMS SSP starts an inter-digit timer. The
originating side will provide further digits in one or more SAM messages. Each
time a SAM message is received, the inter-digit timer is restarted. Digit collection
is complete when the DMS SSP receives a SAM message with an end of digits
indicator from the originating side, or when the inter-digit timer expires. If the
inter-digit timer expires without a complete number having been received, the call
is cleared.
2.3.2.3 Triggering at TDP-2 (Collected Info)
On leaving PIC_2, the O_BCSM encounters TDP-2 (Collected Info). This can be
armed as a TDP-R, either unconditionally or with the Specific Digit String trigger
criteria.
TDP-2 is armed unconditionally by datafilling a value of 0 for Minimum Digits. If
Minimum Digits is datafilled with the value n (>0), TDP-2 is triggered only when
at least n digits have been collected from the originating side.
Note: If the DMS SSP receives an indication that sending is complete (e.g. receipt
of a SAM message with an end of digits indicator) before it has received the
specified minimum number of digits for triggering, the call will not trigger.

interaction with the SSF. The SSF FSM remains in state Idle.
2.3.2.4 Digit Translation (PIC_3)
In PIC_3 the digits received from the originating side go through translations. The
number that is translated consists of whatever digits have been collected so far in
IAM and SAM messages.
When translations produce a routing address, the O_BCSM leaves PIC_3.
Note: This condition may be satisﬁed before digit collection is complete, so digit
collection may continue after the O_BCSM leaves PIC_3.
The SSF FSM remains in state Idle.
2.3.2.5 Triggering at TDP-3 (Analyzed Info)
On leaving PIC_3, the O_BCSM encounters TDP-3 (Analyzed Info). This can be
armed as a TDP-R, with trigger criterion Speciﬁc Called Party Number String.
Otherwise, once all digits have been collected and translated, the O_BCSM moves
from PIC_3 to PIC_4 without initiating interaction with the SSF. The SSF FSM
remains in state Idle. Since the DMS SSP supports no TDPs after TDP-3, the call
will now progress to completion without any IN interaction.

2.3.2.6 Trigger Processing
The interactions between overlap signalling and trigger processing are illustrated
in Figure 7.
Figure 7 Interactions Between Overlap Signalling and Trigger Processing
An armed TDP will only initiate IN processing if both of the following conditions
are true:
• The trigger criterion associated with the TDP matches one of the dataﬁlled
values at the switch. See Establishing a Criteria Match.
Call triggers at
an armed TDP
Is it a
conditional
TDP?
Is there a
criteria
match?
Is digit
collection
complete?
Can we send
InitialDP with partial
CdPN?
Send InitialDP
Go to state WFI
Start TSSF
No
Yes
Go to next PIC
Go to state Idle
NoYes
Wait for next SAM
message or inter-digit
timeout
No
Potential*
Wait for next SAM
message or inter-digit
timeout
* A potential criteria match exists
when digit collection is still in progress
and collected digits may provide a
criteria match when combined with
digits still to be collected.
Wait for next SAM
message or
inter-digit timeout
Have we collected
the minimum
number of digits
required?
Yes
No
No
Yes
Yes
Continue digit
collection if
InitialDP sent with
partial CdPN
Is digit
collection
complete?
No
Yes

• The DMS SSP has received sufficient information to initiate IN interaction.
The datafilled service key for a service will indicate what information the
SSF requires before it can send InitialDP:
- Does InitialDP require a complete called party number, or can it be
sent with a partial called party number?
- If InitialDP can be sent with a partial called party number, have the
minimum number of digits been collected (as specified by the
datafilled value for Minimum Digits)?
See Determining When to Send InitialDP.
Establishing a Criteria Match
If a conditional TDP has triggered, the SSF tests whether the associated trigger
criterion matches any of the values datafilled at the switch:
• If TDP-2 is armed with Specific Digit String as the trigger criterion, do the
collected digits match a datafilled digit string associated with an IN service?
• If TDP-3 is armed with Specific Called Party Number String as the trigger
criterion, do the translated digits collected so far match a datafilled called
party number associated with an IN service?
A test for a match may yield any of three results:
• No match is possible. Either digit collection has completed without
producing a match, or enough digits have already been collected to rule out
the possibility of a match. For example, 1234 has been collected, and all the
datafilled criteria for Specific Called Party Number String begin with 1233.
The O_BCSM moves to the next PIC. The SSF FSM moves to state Idle.
• A match has been found. The SSF now determines if it has enough
information to initiate IN interaction (see Determining When to Send
InitialDP).
Note: There may be cases when collected digits match one of the datafilled
criteria, but further digits may produce a different match. For example, 1234
has been collected, and the datafilled criteria for Specific Called Party
Number String include both 1234 (an actual match) and 12345 (a potential
match). In such ambiguous cases, the SSF will wait for further digits and
check again for a match.
• There is a potential match. Although no actual match has been found, digit
collection is still in progress and may produce digits which, when combined
with digits already collected, produce a match. For example, 123 has been

collected, and the datafilled criteria for Specific Called Party Number String
includes 1234.
The O_BCSM remains suspended at the current TDP, and the SSF FSM
remains in state Trigger Processing. As each SAM message arrives with
more digits, the SSF repeats the test for a criteria match, incorporating the
newly received digits. (Note: The newly received digits go through
translations before the SSF tests for a criteria match.)
This process continues until either the SSF determines that a match definitely
does or does not exist (in which case the appropriate action is taken, as
described above), or until digit collection completes without producing a
match (in which case the O_BCSM moves to the next PIC, and the SSF FSM
moves to state Idle).
If an unconditional TDP has triggered, there are no trigger criteria to be matched.
The SSF only needs to consider whether it has enough information to initiate IN
interaction (see Determining When to Send InitialDP).
Determining When to Send InitialDP
Once the SSF has determined that it should initiate IN interaction (for an
unconditional TDP, or for a conditional TDP for which a criteria match has been
found), it must determine whether enough information has been provided to start
the interaction (i.e. by sending InitialDP to the SCF).
The service key associated with the IN service with which the call is matched will
indicate whether InitialDP can be sent with a full or partial called party number. If
InitialDP can be sent with a partial called party number, the datafilled value for
Minimum Digits will specify the minimum number of digits that must be collected
before InitialDP can be sent.
There are two possibilities:
• No further information is required.
• Addtional called party digits are required.
Note: If the service key indicates that CLI is required and the CLI was not
included in the initial IAM message, the call will be cleared. There are no facilities
for requesting CLI from the originating side.

No Further Information Required
No further information is required in the following cases:
• InitialDP can be sent with a partial called party number (or, if it requires a
complete called party number, it has been collected and digit collection is
complete).
• The minimum number of digits have been collected.
O_BCSM processing is suspended and the SSF initiates IN interaction, as
described in Section 2.3.2.7. The DMS SSP can continue to collect Address
Signals while IN call processing takes place.
Addtional Called Party Digits Required
Additional called party digits (only) are required in the following cases:
• The service key indicates that a complete called party number is required,
and digit collection is still in progress.
• The number of digits collected so far is less than the datafilled value of
Minimum Digits.
The DMS SSP will collect additional digits, received in SAM messages, until:
• A SAM message is received with an end of digits indicator, indicating that a
complete called party number has been received.
• The number of digits collected exceeds the datafilled value for Minimum
Digits.
• The inter-digit timer expires.
In the first two cases, the DMS SSP suspends O_BCSM processing and the SSF
initiates IN interaction, as described in Section 2.3.2.7.
If the inter-digit timer expires before sufficient digits have been collected, the call
will be cleared.
Note: If digit collection is completed before the required minimum number of
digits has been collected, the call will not trigger. The SSF will move to the next
PIC, and the SSF FSM will move to state Idle.

2.3.2.7 Initiating IN Interaction
The SSF initiates IN call processing by assembling an INAP InitialDP operation
and sending this to the SCF in a TCAP BEGIN package. The parameters of the
InitialDP operation are assembled partly from ETSI ISUP message parameters, and
partly from triggering information datafilled at the switch, as follows:
For a more detailed description of IAM / InitialDP parameter mapping, refer to
Appendix A.
Having sent the InitialDP, the SSF FSM moves from state Trigger Processing to
state Waiting For Instructions, and waits for a response from the SCF. Call
processing in the O_BCSM remains suspended.
See Chapter 3 for a description of the interaction between ETSI ISUP and INAP
while call processing is suspended.
2.4 Feature interaction Before First IN trigger
If the incoming call has been routed via a switch-based Virtual Private Network
(VPN) and authorisation checks have already been carried out on the caller, this
may have an impact on the way in which the call interacts with IN. Such possible
impacts are currently being investigated, and will be documented in a future issue
of this specification.
a.If datafill does not explicitly request that CLI be included in InitialDP, it is not in-
cluded, even if it is provided in IAM.
ETSI ISUP parameter INAP InitialDP parameter
IAM Message Indicators
(Calling Party Category)
CallingPartysCategory
Called Address CalledPartyNumber
Line Identitya
(from IAM)
CallingPartyNumber
<datafill for dialled digits> ServiceKey
Supplied by DMS SSP EventTypeBCSM
Transmission Medium Requirement bearerCapability

2.5 Error handling
2.5.1 Errors Detected by INAP
No errors are detected by INAP during this stage of call processing. Detection of
errors arising from sending of InitialDP is covered in Section 3, as they are
reported to the SSF while call processing is suspended.
2.5.2 Timer Expiry
Expiry of TSSF after InitialDP is sent is covered in Section 3, as it occurs while call
processing is suspended.
2.5.3 Errors Detected by TCAP
No errors are detected by TCAP during this stage of call processing. Detection of
errors arising from sending of InitialDP is covered in Section 3, as they are
reported to the SSF while call processing is suspended.
2.5.4 Errors Detected by ETSI ISUP
ETSI ISUP errors that occur before IN triggering takes place are handled by
standard ETSI ISUP mechanisms (e.g. call clearing). There is no ETSI ISUP/INAP
interaction.

PRE 0.2 (draft) Release 4 ETSI ISUP / INAP Interworking Call Processing
3 Call Processing Suspended
3.1 Overview
When there has been a criteria match at an armed TDP-R in the O_BCSM,
O_BCSM call processing is suspended to allow IN interaction to take place under
the control of the SCF.
During O_BCSM call suspension, while there is an SSF/SCF control relationship,
the SCF can interact with the SSF in the following ways:
• Update billing records with IN-related information
• Initiate and control user interaction with the caller by playing an
announcement and/or collecting information from the user
• Reset the timer used by the SSF to control how long it will wait for a
response from the SCF
• Resume O_BCSM call processing, having provided a complete or partial
replacement for the original called party number
• Clear the call
Note: The SSF may initiate call monitoring by arming EDPs, or request the SSF to
provide information about call completion. However, ETSI ISUP does not support
these features. When the call is connected, any armed EDPs will be disarmed and
default values for will not be provided for any requested call information.

Call Processing SuspendedRelease 4 ETSI ISUP / INAP Interworking PRE 0.2 (draft)
3.2 Billing
For non-IN calls, the DMS SSP generates a billing record for a call after the call
has been through translations, unless translations indicate that no billing record is
to be generated.
If a call triggers at TDP-3, therefore, a billing record may or may not already exist
for the call. If the SCF sends FCI operations containing billing information, this
information is added to the existing billing record, or a billing record is created if
one does not already exist.
If a call triggers at TDP-2, the call has not yet been through translations, so no
billing record exists for the call. If the SCF sends FCI operations containing billing
information, a billing record will be created for the call. In this case, the DMS SSP
will be prevented from creating another billing record when the call goes through
translations.
See Section 3.2.1 for more information about billing records.
3.2.1 AMA Billing Records
The DMS SSP supports Automated Message Accounting (AMA) for billing, and
updates fields in AMA records using a combination of FCI parameter values and
information datafilled against the trigger criteria for a service (specifically, the
Called Party Number and Calling Party Number, as used to provide values for the
InitialDP operation). AMA modules are used as follows:
• In the base AMA record for an IN call, the fields Terminating Open Digits 1
and Terminating Open Digits 2 (normally used to store translated called party
number digits) are filled with hexadecimal Fs (1111). These will eventually
be overwritten with the final called party number, as modified/provided by
Connect.
• Appended to the base record may be either a Type 40 (Digits) module or a
Type 28 (Additional Digits Dialled) module, as specified by datafilled
service data.
The Type 40 module uses its Dialled Digits 1 and Dialled Digits 2 fields to
record the translated dialled digits available when the InitialDP operation is
sent for the call (i.e. the same digits conveyed in the CalledPartyNumber
parameter of InitialDP).
The Type 28 module uses its Additional Digits Dialled field to record
additional authorisation and PIN digits dialled by a VPN user.

• The SCF can send an FCI operation to instruct the DMS SSP to append an
AMA Type 199 module to the base record. This module type contains
operator-deﬁned data. This allows network operators great ﬂexibility in
determining what billing information they wish to record, particularly since
successive FCI operations can be used to append a number of Type 199
modules to the base record.
The processing of the billing information provided by the SCF is handled entirely
within the SSF, and requires no interaction with ETSI ISUP.
For a more detailed description of AMA billing for IN calls, see AG4629 (TDP-3
billing) and AG5150 (TDP-2 billing).
3.3 User Interaction
The SCF can initiate, control and terminate direct in-band interaction with the
calling party by means of INAP operations. Such interaction might, for example,
involve the calling party dialling digits (e.g. a PIN for authorisation) in response to
an announcement, if the InitialDP operation does not provide the SCF with enough
information to screen and route a call.
User interaction can be handled in either of two ways:
• By the DMS SSP’s integrated IP/SRF. This is described in Section 3.3.2.
• By an external IP/SRF. This is described in Section 3.3.3.
Both types of IP can be used for user interaction within the same call, although
only one type of IP can be in use at any given moment; that is, if a call is connected
to one type of IP, that connection must be closed before the call can be connected
to the other type of IP.
3.3.1 INAP Operations Used
The following operations are concerned with establishing a connection between
the SCF and the provider of SRF-type services:
• ConnectToResource (CTR)
EstablishTemporaryConnection (ETC)
Sent from the SCF to the SSF to tell it to set up a connection to a specialised
resource, typically so that it can provide instructions to the calling party or
obtain additional information.

The DMS SSP supports the CTR operation for connections to the integrated
DMS IP, i.e. to MTM EDRAM announcements or DTC tone generation and
detection. In this scenario, the SSF then relays SCF-to-SRF operations to the
integrated IP.
The DMS SSP supports the ETC operation for connections to an external IP.
The DMS SSP sets up a link to the external IP over a PRI trunk. Once the
connection is fully established (see the description of the
AssistRequestInstructions operation below), operations are exchanged
directly between the SCF and the external IP, with no further involvement
from the SSF.
• AssistRequestInstructions (ARI)
Sent from the SRF to the SCF to complete the connection between the SCF
and an external IP.
Note: The ARI operation does not involve any SSF interaction.
The following INAP operations apply to both types of IP connection. The only
difference is that for an integrated IP connection they will be sent to the SSF, which
relays them to an internal SRF. For an external IP connection, operations are
exchanged directly between the SCF and the external IP:
• PlayAnnouncement (PA)
Sent from the SCF to the SRF after a user-SRF connection has been
established under SCF control, to tell the SRF to provide a specified tone or
announcement in-band. There is no input from the user.
• SpecializedResourceReport (SRR)
Sent from the SRF to the SCF to confirm that a specified tone or
announcement has been provided in-band via a PA operation.
• PromptAndCollectUserInformation (P&C)
Sent from the SCF to the SRF after a user-SRF connection has been
established under SCF control, to tell the SRF to provide a specified tone or
announcement in-band and to collect information (e.g. digits in-band) from
the user. The collected information is sent to the SCF via the TCAP Return
Result defined for the P&C operation.

The following INAP operation is concerned with the timer that the DMS SSP uses
to control how long it will wait for a response from the SCP or an external IP
before timing out:
• ResetTimer (RT)
Sent from the SCF to the SSF to tell it to restart the TSSF timer with a
speciﬁed period. This allows the SCF to prevent the SSF from timing out a
call in cases where IN processing takes longer than usual (e.g. while waiting
for a response from an external IP, or while executing complex service
logic).
Note: Use of the ResetTimer operation is not restricted to user interaction.
The SCF can send ResetTimer to the SSF at any point during an SSF/SCF
control relationship.
The following INAP operation is concerned with terminating the connection
between the SCF and the SRF, and applies to both integrated and external IPs:
• DisconnectForwardConnection (DFC)
Sent from the SCF to the SSF to tell the SSF to disconnect the forward SRF
connection for a call. This indicates that no further interaction with the user
is required for the moment, but the SCF/SSF connection remains in place.
Note: In the case of a connection to an external IP, the SRF can initiate
disconnection (see Section 3.3.3.2).
3.3.2 User Interaction Using an Integrated IP
This section describes user interaction using the DMS SSP’s integrated IP.
3.3.2.1 Message Flow Overview
User interaction requires the presence of a speech path for in-band communication
with the caller (voice prompts, network tones, DTMF digits and so on). In a call
without user interaction, the speech path would be set up in response to an ANS
message from the terminating side. If user interaction is required before the call is
routed to the terminating side (i.e. before the SCF issues Connect), the DMS SSP
must set up the speech path at an earlier stage in the progress of the call.

To set up the speech path, the DMS SSP generates the following ETSI ISUP
messages and sends them to the originating side:
1. ACM. This tells the caller to stop sending digits.
The DMS SSP usually sends ACM when it has determined that it has
received a complete called party number. If this has already happened by the
time user interaction is requested, ACM will already have been sent, so it
isn’t necessary to send it again.
2. ANS. This causes the speech path to be set up.
These messages are referred to as “early” setup messages, because they cause the
speech path to be set up earlier than would be the case if it was set up in response to
ETSI ISUP messages received from the terminating side after the call is routed.
Note: If Malicious call trace is in progress, the sending of early setup messages
will break the trace.
No early setup messages are sent if a speech path has already been set up. This will
be the case if:
• There has already been user interaction earlier in the call.
• The call has tried unsuccessfully to connect (ACM, but not ANS, has been
received from the terminating side).
When the call is ﬁnally routed, the terminating side will eventually return the
following ETSI ISUP messages to the DMS SSP:
ACM
ANS
These are the messages that would normally cause the speech path to be set up to
the caller. However, since the speech path has already been set up to handle user
interaction, these messages do not need to be relayed to the originating side, so
they are simply discarded by the DMS SSP.

Figure 8 ETSI ISUP call with IN user interaction (integrated IP)
DMS SSP SCP
state c
Waiting for
Instructions
BCSM SSF FSMSSRM
state 1
Idle
state 2
Connected
state d
Waiting for
End of User
Interaction
To state 1
Idle
To state c
Waiting for
Instructions
ACM
ANM
CTR
SRR or
PA or P&C
DFC
PA or P&C
state 2
Connected
state d
Waiting for
End of User
Interaction
Any subsequent
ConnectToResource
does not require ETSI
ISUP interaction, as
speech path is already
through-connected
state 3
User
Interaction
ETSI ISUP ACM (if not
already sent) and ANM
sent to open speech path
prior to user interaction
In-band
user interaction
tone/announcement
digits (RR)
tone/announcement
P&C(RR)
Originating
side
RT
RT
RT
O_BCSM remains
suspended
throughout
Optional
further
CTR

3.3.2.2 Sequence of Events
The sequence of events for user interaction via an integrated IP is as follows:
1. Before receiving an INAP CTR operation:
- The SSF FSM is in state Waiting For Instructions
- O_BCSM call processing is suspended
- The SSRM (with which no interaction has yet taken place) is in state
Idle.
2. When the SSF receives an INAP CTR operation from the SCF, the following
call processing actions occur within the DMS SSP:
- The SSF FSM moves to state Waiting For End Of User Interaction.
- The SSRM moves to state Connected.
- If no speech path to the caller has been set up, the DMS SSP sets one
up, as described in Section 3.3.2.1.
3. The calling party is now through connected to on-board DMS SSP tone and
announcement capabilities (provided by the SRF/integrated IP).
4. User interaction can begin, as described in the speciﬁcation DMS
Implementation of CS-IR INAP (ETSI Core INAP Subset), and
summarised in Figure 8. No further ETSI ISUP interaction is necessary
during interaction with the user.
5. The SCF terminates user interaction by sending an INAP DFC operation to
the SSF. The following call processing actions take place within the DMS
SSP:
- The SSRM moves to state Idle.
- The SSF FSM moves to state Waiting For Instructions.
The speech path to the caller remains open. Any subsequent interaction uses
the speech path already set up.
At any point while call processing is suspended, the SCF can send a ResetTimer
operation to the SSF. The effect of ResetTimer is to restart the TSSF timer, which is
used to control the amount of time for which the SSF will wait for some kind of
response from the SCF (see Section 3.5.2.1 for more information about TSSF).

Note: The SCF is allowed to send only one ResetTimer operation before sending
some other kind of response to the SSF (e.g. CTR, Connect). However, after
sending such a response, the SCF can send as many ResetTimer operations as it
wishes. This is illustrated in Figure 8.
3.3.3 User Interaction Using an External IP
This section describes user interaction using an external IP.
3.3.3.1 Message Flow Overview
User interaction requires the presence of a speech path for in-band communication
with the caller (voice prompts, network tones, DTMF digits and so on). In a call
without user interaction, the speech path would be set up in response to an ANS
message from the terminating side. If user interaction is required before the call is
routed to the terminating side (i.e. before the SCF issues Connect), the DMS SSP
must set up the speech path at an earlier stage in the progress of the call. See
Setting Up a Speech Path.
If user interaction is handled via an external IP rather than the DMS SSP’s
integrated IP, the DMS SSP also needs to set up a link to the external IP and
connect the caller’s speech path to this link. See Connecting to an External IP.
The ETSI ISUP/INAP and PRI/INAP interactions are as shown in Figure 9.
Setting Up a Speech Path
To set up the speech path, the DMS SSP sends the following ETSI ISUP messages
to the originating side:
1. ACM. This tells the caller to stop sending digits.
The DMS SSP usually sends ACM when it has determined that it has
received a complete called party number. If this has already happened by the
time user interaction is requested, ACM will already have been sent, so it
isn’t necessary to send it again.
2. ANS. This causes the speech path to be set up.
These messages are referred to as “early” setup messages, because they cause the
speech path to be set up earlier than would be the case if it was set up in response to
ETSI ISUP messages received from the terminating side after the call is routed.
Note: If Malicious call trace is in progress, the sending of early setup messages
will break the trace.

Figure 9 ETSI ISUP call with IN user interaction (external IP)
DMS SSP SCP
state c
Waiting for
Instructions
BCSM SSF FSM SSRM
state 1
Idle
state 2
Connected
To state 1
Idle
To state c
Waiting for
Instructions
ACM
ANM
SRR or
PA or P&C
DFC
PA or P&C
state 2
Connected
Any subsequent ETC
does not require ETSI
ISUP interaction, as
speech path is already
open
state 3
User
Interaction
ETSI ISUP ACM and
ANM, or in some cases
ANM only, sent to open
speech path prior to user
interaction, but only if not
In-band
user interaction
tone/announcement
digits (RR)
tone/announcement
P&C(RR)
Originating
side
External IP
ETC
SETUP
ALERTING/
PROGRESS
CONNECT
ARI
DISCONNECT
RELEASE
COMPLETE
RT
RT
DISCONNECT
RELEASE
COMPLETE
O_BCSM remains
suspended
throughout
state e
Waiting For
End Of
Temporary
Connection
state e
Waiting For
End Of
Temporary
Connection
Optional
further
CTR
Disconnection
initiated by
external IP
CALL
PROCEEDING

No early setup messages are sent if a speech path has already been set up. This will
be the case if:
• There has already been user interaction earlier in the call.
• The call has tried unsuccessfully to connect (ACM, but not ANS, has been
received from the terminating side).
When the call is ﬁnally routed, the terminating side will eventually return the
following ETSI ISUP messages to the DMS SSP:
ACM
ANS
These are the messages that would normally cause the speech path to be set up to
the caller. However, since the speech path has already been set up to handle user
interaction, these messages do not need to be relayed to the originating side, so
they are simply discarded by the DMS SSP.
Connecting to an External IP
The DMS SSP sets up a link to the external IP by sending a PRI SETUP message
on an outgoing PRI trunk. The external IP responds by sending the following PRI
messages to the DMS SSP:
1. CALL PROCEEDING. This message is in response to the initial SETUP
message.
2. ALERTING. This message causes the speech path to be set up between the
caller and the external IP.
3. CONNECT. This message indicates that the link to the external IP has been
established successfully, and user interaction can begin.
Note: The connection between the DMS SSP and the external IP need not be
direct. Although the outgoing trunk from the DMS SSP will be ETSI PRI, setting
up a link to an external IP may involve interworking with other agents. However,
depending on how the address of the external IP is speciﬁed, there may be
restrictions on interworking; see Appendix D for details.

Disconnecting From an External IP
When the SCF signals that user interaction is complete (by sending an INAP DFC
operation to the SSF), the DMS SSP breaks the connection to the external IP by
sending a PRI DISCONNECT message with Cause value 16 (normal call
clearing). The external IP responds with a PRI RELEASE message, and the DMS
SSP completes the disconnection by sending a PRI RELEASE COMPLETE
message to the external IP.
The speech path between the caller and the DMS SSP remains open, and can be
used for subsequent user interactions (either with the external IP or with the DMS
SSP’s integrated IP). However, subsequent user interaction using the external IP
will require the DMS SSP to make a new connection to the external IP.
Note: The SRF can initiate disconnection of the external IP by sending a PRI
DISCONNECT to the DMS SSP. If the external IP disconnects before it has
answered a connection attempt, the SSF reports this to the SCF by returning an
ETCFailed error in response to the ETC operation. If the external IP disconnects
after a connection has been established, the SSF FSM simply returns to state
Waiting For Instructions (the SSF assumes that the IP has informed the SCF).
3.3.3.2 Sequence of Events
The sequence of events for user interaction via an external IP is as follows:
1. Before receiving an INAP ETC operation:
- The SSF FSM is in state Waiting For Instructions.
- O_BCSM call processing is suspended.
- The SSRM (with which no interaction has yet taken place) is in state
Idle.
2. When the SSF receives an INAP ETC operation from the SCF, the following
call processing actions occur within the DMS SSP:
- The SSF FSM moves to state Waiting For End Of Temporary
Connection.
- If no speech path to the caller exists, the DMS SSP sets one up, as
described in Setting Up a Speech Path.
- The DMS SSP sets up a link to the external IP, as described in
Connecting to an External IP.

3. When the external IP receives the SETUP message from the DMS SSP, the
following actions occur within the IP:
- A CALL PROCEEDING message is sent to the DMS SSP in response.
- An ALERTING or PROGRESS message is sent to the DMS SSP,
followed by a PRI CONNECT message, which establishes the
connection with the DMS SSP.
- The SSRM moves to state Connected.
- The SRF sends an INAP ARI operation directly to the SCF to establish
the direct connection between the external IP and the SCF.
4. The calling party is now through connected to the tone and announcement
capabilities provided by the external IP.
5. User interaction can begin, as described in the speciﬁcation DMS
Implementation of CS-1R INAP (ETSI Core INAP Subset), and
summarised in Figure 9. No further ETSI ISUP interaction is necessary
during interaction with the user.
6. The SCF terminates user interaction by sending an INAP DFC operation to
the SSF. The following call processing actions take place:
- The SSF sends a PRI DISCONNECT message to the external IP with
Cause value 16 (normal call clearing).
- The external IP acknowledges by returning a RELEASE message.
- The SSF sends a RELEASE COMPLETE message to the external IP.
- At the external IP, the SSRM moves to state Idle.
- At the DMS SSP, the SSF FSM moves to state Waiting For
Instructions.
The speech path to the caller remains open. Any subsequent interaction uses
the speech path already set up.
7. The external IP can initiate disconnection by sending a PRI DISCONNECT
message to the DMS SSP. The DMS SSP responds by sending RELEASE to
the external IP, and the external IP completes disconnection by sending
RELEASE COMPLETE to the DMS SSP. The effect on the SSRM and SSF
FSM are the same as for SCF-initiated disconnect (see step 6).
See Appendix D for details of the parameters of the PRI messages involved in
external IP connection and disconnection.

At any point while call processing is suspended, the SCF can send a ResetTimer
operation to the SSF. The effect of ResetTimer is to restart the TSSF timer, which is
used to control the amount of time for which the SSF will wait for some kind of
response from the SCF (see Section 3.5.2.1 for more information about TSSF).
Note: The SCF is allowed to send only one ResetTimer operation before sending
some other kind of response to the SSF (e.g. ETC, Connect). However, after
sending such a response, the SCF can send as many ResetTimer operations as it
wishes. This is illustrated in Figure 9.
3.4 Resumption of O_BCSM call processing
3.4.1 Call Completion (Connect)
O_BCSM call processing typically resumes when a Connect operation is sent from
the SCF to the SSF to indicate that a call should be routed to a specified
destination, thus successfully completing IN interaction. Two types of routing
information may be provided:
dRA destinationRoutingAddress parameter
A destination routing address (a complete or partial replacement for the
original called party address).
cAP CutAndPaste parameter
Optional cut-and-paste instructions on how the original dialled number
should be manipulated to generate a new called party address.
There are two possibilities:
• The SCF can provide a complete replacement number in the dRA parameter,
in which case no cAP parameter is supplied.
Note: If there is no cAP parameter, any digits that arrive after Connect is
received are ignored.
• The SCF can provide a replacement prefix in the dRA parameter, in which
case the cAP parameter specifies how many prefix digits should be removed
from the original dialled number and replaced. For example, a Connect
operation might replace a general-purpose IN prefix in the original dialled
number (e.g. 0800) with the prefix of a specific switch where the requested
service is actually provided.

Note: If the SSF receives a Connect operation with a cAP parameter of 0, the
effect is to append the dialled digits to the destination number supplied in
Connect.
Note: DMS SSP digit translation takes place at two points:
• On the number initially dialled, e.g. to take into account the caller’s customer
group.
• After the IN query, which means that further digit manipulation may take
place before routing.
The resumption of call processing on receipt of a Connect is illustrated in Figure
10. The ETSI ISUP interactions implied by receipt of a Connect take place after
call processing has resumed, and are described in Section 4.1.
Figure 10 Resumption of call processing on receipt of a Connect
Calling party
Dialled digits
(in-band)
CCF / BCSM
Digit
manipulation via
DMS translations
IN interaction
triggered on CdPN
Result of IN query
used to manipulate
full CdPN (dRA
replaces all or ﬁrst n
CdPN digits)
SSF
SSF sends
InitialDP
SCF
SCF sends
Connect
INAP operation
parameters
Called party
Onward
routing
More digits may reach SCF via SRF interaction
with calling party (no effect on BCSM or SSF)
Mandatory service key,
optional CdPN
Mandatory
destinationRoutingAddress (dRA);
optional cutAndPaste to replace preﬁx
Dialled digits
(out-of-band)
Digit
manipulation via
DMS translations

3.4.2 Call Clearing (ReleaseCall)
If the SCF determines that a call cannot be completed (e.g. because the caller is not
authorised), it sends a ReleaseCall operation to the SSF. This operation provides a
releaseCause value to be used in initiating ETSI ISUP call clearing; for example:
21 (call rejected)
31 (normal unspeciﬁed)
The mapping between releaseCall values and ETSI ISUP Cause values is described
in Appendix E.
The ETSI ISUP interactions implied by receipt of a ReleaseCall take place after
call processing has resumed, and are described in Section 4.2.
3.5 Error Handling
Note that if errors are detected while call processing is suspended, no action
requiring ETSI ISUP interaction takes place until call processing is resumed and
the call can be completed or cleared.
3.5.1 Errors Detected by INAP
3.5.1.1 Errors Detected by the SCF
While O_BCSM call processing is suspended, a number of errors may be detected
and reported by the SCF in response to:
• An InitialDP operation sent by the SSF
• An AssistRequestInstructions operation sent by the SRF
These are reported in Return Error components in TCAP END messages. The SSF
terminates the SCF/SSF dialogue and initiates backward call clearing with an
appropriate Cause value (31 = normal, unspeciﬁed), which ensures that the caller
hears an appropriate tone.
3.5.1.2 Errors Detected by the SSF/SRF
While O_BCSM call processing is suspended, the SSF or SRF may detect errors in
INAP operations sent by the SCF, as summarised in Table 2.

In each case, the error is reported to the SCF in a Return Error component in a
TCAP CONTINUE message. The SCF has the option of clearing the call with a
ReleaseCall operation or taking some other action.
3.5.2 Timer Expiry
This section describes how the SSF handles the conditions that result from the
expiry of one of its internal timers. There are two such timers: TSSF and TSRF. The
SSF uses both these timers to guard against excessive call suspension times while
waiting for IN processing.
a. This is detected by the SRF when the caller’s response is not as specified by the SCF.
b. No INAP errors are reported for this operation.
Table 2 INAP operation errors reported by the DMS SSP while call processing is suspended
Operation
Error
ETCFailed
ImproperCallerResponsea
MissingParameter
ParameterOutOfRange
RequestedInfoError
SystemFailure
TaskRefused
UnexpectedComponentSequence
UnexpectedDataValue
UnexpectedParameter
ActivateServiceFiltering
CallInformationRequest
Connect
ConnectToResource
DisconnectForwardConnection
EstablishTemporaryConnection
FurnishChargingInformation
PlayAnnouncement
PromptAndCollectUserInformation
ReleaseCallb
ResetTimer

Note: The usage of TSRF depends on whether an integrated or external IP
connection is being used for user interaction.
3.5.2.1 Expiry of TSSF
The SSF starts (or restarts) the timer TSSF:
• When the SSF FSM moves into state c (Waiting For Instructions) (e.g. after
sending an InitialDP or EventReportBCSM operation to the SCF). In this
situation, the timer can have a value from 1 to 10 seconds.
• When the SSF FSM moves into state d (Waiting For End Of User
Interaction) (e.g. after receiving a CTR operation from the SCF). In this
situation, the timer can have a value from 1 to 60 minutes.
• When the SSF FSM moves into state e (Waiting For End Of Temporary
Connection) (e.g. after receiving a ETC operation from the SCF). In this
situation, the timer can have a value from 1 to 60 minutes.
• When the SSF receives a ResetTimer operation from the SCF. In this
situation, the value of the timer is speciﬁed in a parameter of the ResetTimer
operation, and may be one of the following:
1 to 10 seconds
1 to 10 minutes
15, 20, 25, 30, 35, 40, 45, 50, 55 or 60 minutes
If the speciﬁed timer value is not one of the above, the nearest legal value is
used.
If the SSF does not receive a valid operation from the SCF before the TSSF timer
expires, the following call processing actions occur within the SSF:
1. The SSF FSM moves to state a (Idle).
2. The SSF performs a user-initiated abort (see Section 3.5.4).
Each time the SSF receives a valid operation from the SCF, it restarts the TSSF
timer. If an operation received from the SCF contains an error, the TSSF timer
continues to run after the SSF has sent an error indication. The SCF therefore has
the opportunity to send a correct operation before the timer expires.

An external IP can close the connection with the DMS SSP, either during or after
connection of the speech path, by sending a PRI RELEASE message to the DMS
SSP. On receiving this RELEASE message, the SSF:
• Stops the TSSF timer
• Sends an ETCFailed error to the SCF (only if the external IP hasn’t yet
answered; i.e. it hasn’t returned a PRI CONNECT)
• Moves to state Waiting For Instructions
• Restarts the TSSF timer with its WFI value
3.5.2.2 Expiry of TSRF
This section describes the use of the TSRF timer if an integrated IP connection is
used for user interaction.
Note: If an external IP connection is used for user interaction, standard signalling
system protocol timers are used to control connection setup. TSRF is not used.
The SSF starts the timer TSRF when the SRSM moves into state 2 (Connected)
after receiving a CTR operation from the SCF. The timer can have a value from 1
to 10 seconds.
If the SRF does not receive a valid PA or PC operation from the SCF before the
TSRF timer expires, the following call processing actions occur within the SSF:
1. SRF resources are released. This is equivalent to receiving a DFC operation
from the SCF.
2. The SRSM moves to state 1 (Idle).
3. The SSF FSM moves to state c (Waiting For Instructions).
4. The TSSF timer (maximum value 10 seconds) is restarted.
5. If the TSSF timer expires without the SSF receiving a valid operation from
the SCP:
a. The SSF FSM moves to state a (Idle).
b. The SSF performs a user-initiated abort (see Section 3.5.4).
In this situation, the TSSF timer acts as a backup to the TSRF timer.

Note: The expiry of the TSRF timer has the same effect as the receipt of a DFC
operation from the SCF.
The SSF restarts the TSRF timer under the following circumstances:
• When it receives a valid PA or PC operation from the SCF
• After sending a SRR operation to the SCF (on successful completion of a
preceding PA operation)
• After sending the Return Result for a preceding PC operation
If an operation received from the SCF contains an error, the TSRF timer continues
to run after the SSF has sent an error indication. The SCF therefore has the
opportunity to send a correct operation before the timer expires.
3.5.3 Errors Detected by TCAP
3.5.3.1 Errors Detected by the SCF
If the SCF detects an error in the TCAP component in which an INAP operation is
sent, it sends a Reject component in an END package to the SSF. The SSF
responds by terminating the dialogue and initiating backward call clearing by
sending a REL message with a Cause value of 2 (network termination).
3.5.3.2 Errors Detected by the SSF
If the SSF detects an error in the TCAP component in which an INAP operation is
sent, it sends a Reject component in a CONTINUE package to the SCF. The action
taken depends on the SCF, which can either resend the component or release the
call.
3.5.4 User-Initiated Abort
Either the SCF or the SSF can abort a dialogue by sending a TCAP ABORT
package. This is called user-initiated abort (where “user” refers to INAP as being
the user of the TCAP layer). User-initiated abort can occur when:
• The caller hangs up during call processing
• The TSSF timer expires
The SSF responds to a user-initiated abort by initiating backward call clearing, as
described in Section 4.2.

3.5.5 Errors Detected by ETSI ISUP
The only errors that can be detected by ETSI ISUP while call processing is
suspended are problems with setting up and through-connecting a speech path back
to the caller for user interaction (see Section 3.3), e.g. caller hangs up or network
problem. In either case, the call attempt will be cleared using standard ETSI ISUP
call clearing messaging. When the O_BCSM informs the SSF that the call has been
cleared, it will inform the SCF by sending a TCAP ABORT package.

Etsi isup inap_iw_book

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (8)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Etsi isup inap_iw_book

Ähnlich wie Etsi isup inap_iw_book (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Etsi isup inap_iw_book