Etsi isup inap_iw_book

NT Europe SIM Specification

DMS Implementation of ETSIISUP / INAP interworkingRelease 4 ETSI ISUP/INAP Interworking SIM

Date:

Version:

13 December 1996

PRE 0.2 (draft)

Originated by: BNR Department EP11

Classification: 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 orfitness for any particular purpose. The entire risk as to quality and performance of the informationprovided is with the user. Should the information prove defective, the user assumes the cost of allnecessary 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 beupdated, 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 anadministrative process developed to manage the evolution of interface specifications throughauthorisation, 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 apreliminary stage, and as such should be treated as a ‘draft’ document. External distributionis limited.

AUT: Following the authorisation of the document by NT and BNR design the prefix of the revisionstatus is promoted to AUT. AUT implies that the document has been fully authorised and thatit represents the agreed interface product undergoing development.

APP: Upon completion of the design and test of the interface product the prefix of the document ispromoted 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 toVER. This document represents the final release of the interface product in its currentversion.

Document signoff

BNR DesignApproval

Kathy Shaw Senior Manager,WT INDevelopment(7020)

Signature:

Date:

BNR PlanningApproval

Iain Donaldson Senior Manager,Product PlanningSwitching(EP10)

Signature:

Date:

NT ProductManagementApproval

David Ainsworth Director,Product LineManagement

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 Planningreview 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, andrelevant comments from BTUP review.

NIS 94-80nn World Trade IN Release 4 ETSI ISUP/INAP InterworkingPRE 0.2 (draft) Preface

13 December 1996 Page v

Preface

Purpose

This document is a Strategic Interface Management (SIM) specification for theWorld Trade Intelligent Network (IN) project. The aim of the project is to plan anddevelop a DMS Service Switching Point (SSP), i.e. software that will enable aDMS-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 theinterworking features of Release 4 of the DMS SSP product. Features introducedin Release 4 are:

• Support for the bearerCapability parameter of the INAP operation IntialDP

• Support for an Ethernet Link Interface Unit, which allows CCS7 messages tobe encapsulated in TCP/IP packets and sent over an Ethernet Local AreaNetwork

Content

This document describes DMS SSP support for interworking between ETSI ISUPand the Intelligent Network Application Part (INAP). Such interworking enablesthe DMS SSP to support IN services for calls that originate in the PSTN and arriveat the DMS SSP via ETSI ISUP trunks.

Release 4 ETSI ISUP/INAP Interworking World Trade IN NIS 94-80nnPreface 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 ofparameters 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 willenable BNR Planning and NT Marketing to assess its applicability forpotential customers.

• To examine possible implementations of the interworking and compare thesewith current and planned DMS SSP capabilities. This will enable BNRPlanning, BNR Design and NT Product Management to decide on the bestmethod of supporting the interworking.

• To define all the requirements of the agreed implementation method to alevel of detail sufficient to enable BNR Design to build it, and to serve as thedefinitive BNR and NT source of reference information on the interworkingafter it has been built.

The specification will be subject to regular review, and will be updated toincorporate comments, to capture new information, and to reflect evolvingrequirements for ETSI ISUP / INAP interworking within the World Trade INproject.

NIS 94-80nn World Trade IN Release 4 ETSI ISUP/INAP InterworkingPRE 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

Release 4 ETSI ISUP/INAP Interworking World Trade IN NIS 94-80nnPreface PRE 0.2 (draft)

Page viii 13 December 1996

NIS 94-80nn World Trade IN Release 4 ETSI ISUP/INAP InterworkingPRE 0.2 (draft) Abbreviations

13 December 1996 Page ix

Abbreviations

ACM Address Complete Message (ETSI ISUP)AMA Automatic Message AccountingANM Answer Message (ETSI ISUP)ANSI American National Standards InstituteASF ActivateServiceFiltering (INAP operation)AUT AUThorised for releaseBCSM Basic Call State MachineCCF Call Control FunctionCCS7 Common Channel Signalling System No 7CDR Call Detail RecordingCIRP 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 SystemDP Detection PointDRAM Digital Recorded Announcement MachineDTC Digital Trunk ControllerEDP Event Detection PointEDRAMEnhanced (single-card) DRAMELIU Ethernet Link Interface UnitERB EventReportBCSM (INAP operation)ETC EstablishTemporaryConnection (INAP operation)ETSI European Telecommunications Standards Institute

(CEPT standards body)FCI FurnishChargingInformation (INAP operation)FN Functional SpecificationFSM Finite State MachineIAM Initial Address Message (ETSI ISUP)IDP InitialDP (INAP operation)IN Intelligent NetworkINAP Intelligent Networks Applications PartIP Intelligent PeripheralISDN Integrated Services Digital Network

Release 4 ETSI ISUP/INAP Interworking World Trade IN NIS 94-80nnAbbreviations PRE 0.2 (draft)

Page x 13 December 1996

ISUP ISDN User Part (part of CCS7)ITU International Telecommunications UnionLE Local ExchangeMTP Message Transfer Part (part of CCS7)NT Northern TelecomNUP National User PartOAM Operations, Administration and MaintenanceOSI Open Standard for InterconnectionP&C PromptAndCollectUserInformation (INAP operation)PA PlayAnnouncement (INAP operation)PDU Protocol Data UnitPIC Point In CallPOTS Plain Ordinary Telephone ServicePRE PREliminary statusPRI ISDN Primary Rate InterfacePSTN Public Switched Telephone NetworkRES 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 FunctionSCP Service Control PointSDL State (machine) Description LanguageSDT SDL ToolSFR ServiceFilteringResponse (INAP operation)SIM Strategic Interface ManagementSRF Specialised Resource FunctionSRR SpecializedResourceReport (INAP operation)SRSM Specialised Resource State MachineSSF Service Switching FunctionSSME SSF Management EntitySSN Subsystem Number (identifies CCS7 user or application part within node)SSP Service Switching PointSTP Signalling Transfer PointSUS Suspend (ETSI ISUP message)TCAP Transaction Capabilities Application PartTDP Trigger Detection Point

NIS 94-80nn World Trade IN Release 4 ETSI ISUP / INAP InterworkingPRE 0.2 (draft) Table of Contents

13 December 1996 Page xi

Table of Contents

Preface v

Abbreviations ix

Table of Contents xi

1 Introduction 11.1 The Need for Interworking 1

1.1.1 Access Signalling and IN Signalling 11.1.2 Terminating Signalling 21.1.3 External IP Signalling 21.1.4 Functional Elements Involved in Interworking 3

1.2 DMS SSP Support for IN capabilities 51.2.1 INAP Operation Support 51.2.2 BCSM Support 6

1.2.2.1 Overview of the BCSM 61.2.2.2 Detection Point Types 71.2.2.3 DMS SSP Support for TDPs 81.2.2.4 DMS SSP Support for EDPs 8

1.3 DMS SSP Support for ETSI ISUP 91.4 Overview of ETSI ISUP / INAP Interworking 9

1.4.1 IN Interaction Involving the SCF 101.4.2 IN Interaction Handled by SSF (Service Filtering) 12

2 Triggering IN Interaction 152.1 Introduction 152.2 IN Interaction with ETSI ISUP En-Bloc Signalling 16

2.2.1 Overview of En-Bloc Signalling 162.2.2 Sequence of Events 17

2.2.2.1 Call Arrival (PIC_1) 172.2.2.2 Digit Collection (PIC_2) 182.2.2.3 Triggering at TDP-2 (Collected Info) 182.2.2.4 Digit Translation (PIC_3) 182.2.2.5 Triggering at TDP-3 (Analysed Info) 18


13 December 1996 Page xii

2.2.2.6 Trigger Processing 192.2.2.7 Initiating IN Interaction 20

2.3 IN Interaction with ETSI ISUP Overlap Signalling 212.3.1 Overview 212.3.2 Sequence of Events 21

2.3.2.1 Call Arrival (PIC_1) 222.3.2.2 Digit Collection (PIC_2) 232.3.2.3 Triggering at TDP-2 (Collected Info) 232.3.2.4 Digit Translation (PIC_3) 242.3.2.5 Triggering at TDP-3 (Analyzed Info) 242.3.2.6 Trigger Processing 252.3.2.7 Initiating IN Interaction 29

2.4 Feature interaction Before First IN trigger 292.5 Error handling 30

2.5.1 Errors Detected by INAP 302.5.2 Timer Expiry 302.5.3 Errors Detected by TCAP 302.5.4 Errors Detected by ETSI ISUP 30

3 Call Processing Suspended 313.1 Overview 313.2 Billing 32

3.2.1 AMA Billing Records 323.3 User Interaction 33

3.3.1 INAP Operations Used 333.3.2 User Interaction Using an Integrated IP 35

3.3.2.1 Message Flow Overview 353.3.2.2 Sequence of Events 38

3.3.3 User Interaction Using an External IP 393.3.3.1 Message Flow Overview 393.3.3.2 Sequence of Events 42

3.4 Resumption of O_BCSM call processing 443.4.1 Call Completion (Connect) 443.4.2 Call Clearing (ReleaseCall) 46

3.5 Error Handling 463.5.1 Errors Detected by INAP 46

3.5.1.1 Errors Detected by the SCF 463.5.1.2 Errors Detected by the SSF/SRF 46

3.5.2 Timer Expiry 473.5.2.1 Expiry of TSSF 483.5.2.2 Expiry of TSRF 49

3.5.3 Errors Detected by TCAP 503.5.3.1 Errors Detected by the SCF 503.5.3.2 Errors Detected by the SSF 50

3.5.4 User-Initiated Abort 503.5.5 Errors Detected by ETSI ISUP 51


13 December 1996 Page xiii

4 Call Processing Resumed 534.1 Call Completion (after Connect) 534.2 Call Clearing (after ReleaseCall) 554.3 Returning Requested Call Information 564.4 Monitoring 56

4.4.1 Monitoring for DP-4 (Route_Select_Failure) 574.5 Error Handling 58

4.5.1 Errors Detected by INAP 584.5.1.1 Errors Detected at the SCF 584.5.1.2 Errors Detected at the SSF or SRF 58

4.5.2 Timer Expiry 584.5.3 Errors Detected by TCAP 58

4.5.3.1 Errors Detected at the SCF 584.5.3.2 Errors Detected at the SSF or SRF 60

4.5.4 Errors Detected by ETSI ISUP 60

5 Service Filtering 615.1 Activation of Service Filtering 615.2 Call Processing during Service Filtering 63

5.2.1 Overview 635.2.2 Sequence of Events for a Filtered IN Call 63

5.3 Termination of Service Filtering 665.4 Error Handling 66

5.4.1 Errors Detected by INAP 665.4.1.1 Errors Detected at the SCF 665.4.1.2 Errors Detected at the SSF or SRF 67

5.4.2 Timer Expiry 675.4.3 Errors Detected by TCAP 675.4.4 Errors Detected by ETSI ISUP 67

A Forward Setup (IAM to InitialDP) 69A.1 Mappings between Parameters 69A.2 Deriving INAP Parameter Values from ETSI ISUP 69

A.2.1 ServiceKey 70A.2.2 EventTypeBCSM 70A.2.3 CallingPartysCategory 70A.2.4 CalledPartyNumber 70A.2.5 CallingPartyNumber 71A.2.6 BearerCapability 71A.2.7 Extensions 72

B Forward Setup (Connect to IAM) 73B.1 Mappings between Parameters 73B.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 75B.2.3 Extensions 75

C Backward Setup (ACM and ANM) 77

D PRI Interworking for External IP Connection 79D.1 Establishing a Connection 79

D.1.1 Deriving PRI Parameter Values from INAP 80D.1.1.1 assistingSSPIPRoutingAddress -->

Called Party Number 80D.1.1.2 correlationID --> User to User Information 80

D.2 Terminating a Connection 82D.3 Interworking Restrictions 83

E Call Clearing Parameters 85E.1 Mapping INAP Cause Values 85E.2 Call Clearing Initiated by DMS SSP 86

E.2.1 SCP Sends ReleaseCall 86E.2.2 SCP Sends DisconnectLeg 86E.2.3 Routing Failure Within the DMS SSP 86

E.3 Call Clearing Initiated Elsewhere 87E.3.1 Calling Party Disconnects Before Call is Completed 87E.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 aprerequisite for Intelligent Networking (IN):

• IN signalling, i.e. the interface used for inter-node signalling between INfunctions. This is the Intelligent Network Application Part (INAP).

• IN access signalling, i.e. interfaces over which IN functionality is accessedfrom the underlying network (e.g. PSTN, VPN). The access signallinginterface considered in this specification is ETSI ISUP Version 1 (referred toin this document simply as ETSI ISUP).

This specification describes DMS SSP support for interworking between ETSIISUP and INAP. Such interworking enables the DMS SSP to support IN servicesfor 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 comprisingthe Transaction Capabilities Application Part (TCAP), the Signalling ConnectionControl Part (SCCP) and the Message Transfer Part (MTP); INAPoperations areconveyed in TCAP components within MTP Message Signal Units (MSUs). ETSIISUP uses only the MTP; ETSI ISUPmessages are packaged directly in MSUs. Inprotocol terms, interworking between ETSI ISUP and INAP involves (but is notlimited to) mapping INAP operations and ETSI ISUP messages.

Section 1: World Trade IN NIS 94-80nnIntroduction 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 initiallydistinguished from non-IN calls on the same ETSI ISUP trunks, which requirenormal call processing, by means of the digits dialled by the calling party. Specialnumbers (e.g. an 0800 FreePhone number or equivalent) are recognised asrequiring 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 ISUPBasic Call State Machine (BCSM) then waits for the result of the IN interactionbefore routing the call to its final destination.

1.1.2 Terminating Signalling

If IN interaction results in a call being routed on through the PSTN, outward callcompletion may take place either over the access signalling system (ETSI ISUP) orover any other signalling system with which the access signalling system caninterwork (see theDMS-SSP Product Description for a list of the signallingsystems with which ETSI ISUP can interwork).

1.1.3 External IP Signalling

If an external Intelligent Peripheral (IP) is used (e.g. for collecting furtherinformation from the user, for playing announcements to the user, or to providespeech recognition facilities), a connection is set up between the DMS SSP and theexternal IP over an ETSI PRI trunk.

Tandemor localswitch

SCP

ININ

PSTNDMSSSP

Access signalling

ETSI ISUP/INAP

pointinterworking

(e.g. ETSI ISUP)

signalling(INAP)

Call can be routed onwardto any ETSI

ISUP-compatible interface

ExternalIPPRI

ELIUSCPTCP/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 SSPwill be ETSI PRI, setting up a link to an external IP may involve interworking withother agents. However, depending on how the address of the external IP isspecified, 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 toas functional entities or simply functions) that have the following characteristics:

• Each functional element is clearly defined at a logical level as a statemachine (or a set of related state machines).

• A given functional element is always allocated to a single physical node, buta given node may accommodate two or more functional elements.

• Communication within the IN is defined in terms of information flowsbetween functional elements (which cause changes to the respective statemachines), rather than in terms of messages between nodes.

Functional elements on different nodes communicate using INAP. The followinglist defines the most important IN functional elements:

SCF Service Control FunctionTypically, an IN service is implemented by means of service logic and adatabase under SCF control. The role of the SCF is to respond to servicerequests from the SSF, e.g. by providing routing information that makes itpossible to complete a call. The SCF is usually allocated to an SCP (ServiceControl Point) node. The DMS SSP uses INAP to communicate with an SCFon an SCP.

Note: As a low cost alternative to supplying a CCS7 interface between theDMS SSP and the SCP, the DMS SSP supports an Ethernet Link InterfaceUnit (ELIU), which allows CCS7 messages to be encapsulated in TCP/IPpackets for transmission to a ServiceBuilder SCP connected via an EthernetLocal Area Network.

SSF Service Switching FunctionThe SSF provides the interface between the PSTN and the IN. Its key tasksare to recognise PSTN calls that require IN service processing, and tointeract with CCF call processing and SCF service logic to ensure that thosecalls are successfully completed. The SSF is usually allocated to an SSP(Service Switching Point) node. The DMS SSP supports an SSF Finite StateMachine (FSM).



SRF Specialised Resource FunctionThe SRF provides any specialised resources that are required for interactionwith the end user, either to provide information or to obtain it. Information istypically provided in the form of announcements or tones, and is typicallycollected as dialled digits. The SRF is logically allocated to anIntelligentPeripheral (IP), which may be integrated with an SSP or may be a separatenode attached to an SSP.

The DMS SSP supports an integrated IP, in which the DMS switch itselfprovides features for digit collection and playing recorded announcements.

The DMS SSP also supports connections to an external IP, which providesSRF-type services. The DMS SSP uses a PRI trunk to set up a link to theexternal IP, which can then communicate directly with the SCP withoutfurther involvement by the DMS SSP.

CCF Call Control FunctionThe CCF is not, strictly speaking, an IN functional element, but a standardBasic Call State Machine (BCSM) for which trigger criteria are defined thatdetermine the conditions under which a given call requires IN service access.Because it interacts closely with the SSF, the CCF usually resides with theSSF in an SSP node. The DMS SSP supports CCF functions by means of aETSI ISUP BCSM with access to trigger tables that specify which dialleddigits will initiate IN service access.

Figure 2 shows how these functional elements, particularly those implemented onthe 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 SSPwill be ETSI PRI, setting up a link to an external IP may involve interworking withother agents.

DMSSSP

SCP

INAP

ETSI ISUP

SSF

SCF

CCF

Terminatinginterface/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 besummarised 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 ofthe operations defined in Q.1218). The operations supported by the DMS SSP canbe roughly divided into the following categories:

• Call setup operations for single-stage calls (no user interaction required):

InitialDPConnect

• Call setup operations for two-stage calls (with SCP-initiated userinteraction):

ConnectToResourceEstablishTemporaryConnectionPromptAndCollectUserInformationPlayAnnouncementSpecializedResourceReportDisconnectForwardConnection

The ConnectToResource operation is used to set up a connection to the DMSSSP’s integrated IP. With such a connection there is no direct communicationbetween the SCF and the SRF. The SSF can be regarded as relayingoperations between the SCF and the SRF.

The EstablishTemporaryConnection operation is used to set up a temporaryconnection to another node in the network (e.g. an external IP, whichprovides SRF-type services). With such a connection there is directcommunication between the SCF and the external IP, with the SSF beinginvolved only in setting up and taking down the connection. There is norelaying 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 acall during user interaction.

• Call-independent operations:

ActivateServiceFilteringServiceFilteringResponse

• Call clearing (call cannot be completed):

ReleaseCall

This interworking specification describes how the sending and receiving ofoperations relates to the sending and receiving of ETSI ISUP messages. Fordetailed operation descriptions, see the separate specificationDMSImplementation 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 theprocessing of a basic call proceeds and the way in which basic call processinginteracts 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 indicatethe 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 theBCSM at which the SCF can become involved in order to provide an INservice. DPs are located between PICs, i.e. interaction with the IN takesplace 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 beinteraction between call processing and the IN (specifically, interaction with theSCF via the SSF). Ten DPs are defined for the O_BCSM. A given DP can be set upin any of four ways, as shown in Table 1.

TDPs may be defined as conditional or non-conditional. A non-conditional TDPhas no associated trigger criteria, and all calls that encounter the TDP trigger INinteraction (if the trigger is armed). A conditional TDP has one or more associatedtrigger criteria, and calls that encounter the TDP trigger IN interaction only if thecriteria match.

Table 1: DP types defined in Q.1214

TDP-R(Trigger Detection Point - Response)A trigger detection point causesinteraction to take place between callprocessing and the SCF when staticdatafill-defined criteria are met. Theresponse suffix means that information isrequired from the SCF as a result of theinteraction, and BCSM call processing issuspended awaiting this response.

TDP-N(Trigger Detection Point - Notification)A trigger detection point causesinteraction to take place between callprocessing and the IN when staticdatafill-defined criteria are met. Thenotification suffix means that the SCF issimply told of what has happened; noinformation is expected from it, and BCSMcall processing continues.

EDP-R(Event Detection Point - Response)An event detection point is set up for aparticular call in response to a requestfrom the SCF, asking to be notified when agiven call processing event takes place.The response suffix means thatinformation is required from the SCF as aresult of the interaction, and BCSM callprocessing is suspended awaiting thisresponse.

EDP-N(Event Detection Point - Notification)An event detection point is set up for aparticular call in response to a requestfrom the SCF, asking to be notified when agiven call processing event takes place.The notification suffix means that theSCF is simply told of what has happened;no information is expected from it, andBCSM 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 anunconditional TDP (i.e. a call always triggers at TDP-2 if it is armed), and asa conditional TDP with either of the following trigger criteria:

- Feature Code. A feature code is a string of dialled digits consisting ofthe character * or # followed by up to three digits. Feature codes aretypically used for such things as special feature activation/deactivation.A call triggers at TDP-2 if the TDP is armed and the collected digitsmatch a datafilled feature code.

- Specific Digit String. A call triggers at TDP-2 if the TDP is armed andthe first N collected digits match a datafilled digit string.

• DP-3 in the O_BCSM (Analyzed_Info). TDP-3 is supported only as aconditional TDP with the Specific Called Party Number String criterion. Acall triggers at TDP-3 if the TDP is armed and the first N digits of thetranslated 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 theSCF 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, madevia an RequestReportBCSMEvent (RRBE) operation specifying one of twomonitoring 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 ofdisarming previously armed EDPs.

The DMS SSP supports only one EDP on outgoing ETSI ISUP trunks. This isEDP-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 basictelephony, but also ISDN data calls, and a range of supplementary services based onthe exchange of information using out-of-band messages.

ISUP performs the functions of OSI Layers 4 to 7, but in fact operates as a singlelayer, i.e. no information is added or removed for the intermediate layers, and ISUPinformation has exactly the same format at Level 7 as at Level 4. It uses the MessageTransfer Part (MTP) to support message transfer, i.e. ISUP messages are conveyedbetween 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 SpecificationIssue Aut 1.214 March 1991NIS 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 TransactionCapabilities 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, INinteraction is directly controlled by the SCF. This is the normal case, and isdescribed in Section 1.4.1.

• The SCF delegates IN processing to the SSF (service filtering). INinteraction is handled primarily by the SSF, which periodically reportsresults 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 completionof a call (e.g. to a FreePhone or Primary Rate number). There are three stages in theprocessing 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 specification are organisedin 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 setupsignalling is always en-bloc; ETSI ISUP does not support overlapsignalling)

- 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 collectinformation from the user)

- Arming DPs as EDPs to monitor call completion once O_BCSM callprocessing resumes

Note: Only EDP-4, Route_Select_Failure, is supported on outgoingDPNSS 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 thecorresponding 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 informationreceived via ETSI ISUP

SCF sends Connectwith call setup information

SCF-initiated interactionwith caller to collect

further information; speechpath through-connectedbackward via ETSI ISUP

Charging informationreceived from SCF

(optional)

Call triggers on armed TDP;IN interaction initiated andcall processing suspended

Collected digits are translated

Incoming ETSI ISUP call received by DMS

Call origination

Call termination

Callprocessingbeforetriggeringof INinteraction

Callprocessingsuspendedduring INinteraction

Callprocessingresumedafter INinteraction

1-stagecall

setup

2-stagecall

setup

SCF sends ReleaseCallwith 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 INinteraction

SCF tells SSF to armEDPs (note that they will

be disarmed when the callis connected)

Call setupwith 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 specifiednumber, or the number of calls made to each one of a series of numbers (e.g. forTeleVoting). This counting is done by the SSF; there is no SCF involvement,except that the SCF initiates service filtering and the SSF periodically reportsresults 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 inSection 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 SSPCall origination

PRI callprocessingbeforetriggering

Call count incremented

Translate collected digits

Test translated digits for criteria match

TDP-2 triggers

Activationof servicefiltering

Service filteringterminates when final

report sent to SCF

Filteringresultscollectedandreported

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 callprocessingcontinuedat SSF

Call cleared withspecified Cause value

Call billed as specified

Specified announcementplayed to caller

Final report of call countsprovided when specified

duration of filtering expires

Interim reports of callcounts provided atspecified intervals

Terminationof servicefiltering

Call termination

TDP-3 triggers

Not armed

No INinteraction

No match

Filtered call



NIS 94-80nn World Trade IN Section 2: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 theO_BCSM), until and unless an armed TDP is encountered.

If an armed TDP is encountered, the SSF FSM moves to the state TriggerProcessing 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 aTDP-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 thecall is not an IN call, the SSF FSM returns to the state Idle and O_BCSM callprocessing continues with no IN interaction.

Section 2: World Trade IN NIS 94-80nnTriggering IN Interaction Release 4 ETSI ISUP / INAP Interworking PRE 0.2 (draft)


2.2 IN Interaction with ETSI ISUP En-BlocSignalling

2.2.1 Overview of En-Bloc Signalling

In the case of en-bloc signalling, the IAM message from the originating sidecontains 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

StartTSSF

Originatingside

BCSM

TDP-2 armed?

Waiting forInstructions

SSF FSM

Criteriamatch

PIC_1

PIC_2

Collect digits

PIC_3

Translatedigits

TDP-3 armed?

Idle

TriggerProcessing

TriggerProcessing

IdleCallproceedswith no INinteraction

PIC_4

Criteriamatch

Nomatch

Nomatch



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), andpossibly triggers interaction between the O_BCSM and the SSF (see Section2.2.2.3).

3. The DMS SSP translates the collected digits (see Section 2.2.2.4), andpossibly triggers interaction between the O_BCSM and the SSF (see Section2.2.2.5).

4. If the call has not triggered at this point, it completes without any INinteraction.

Trigger processing is described in Section 2.2.2.6. Trigger processing may initiateIN 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), itcreates 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 thetrigger subscription(s) ineffect at the switch. Two types of subscription are supported:

• Office or switch-wide subscription, which means that all incoming ETSIISUP calls are treated as potential IN calls.

• Trunk group subscription, which means that only ETSI ISUP calls incomingon 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 fromPIC_1 to PIC_2. The DMS SSP does not support the arming of TDP-1 (OriginatingAttempt 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 AddressSignals 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 bearmed 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 MinimumDigits. If Minimum Digits is datafilled with a valuen (n>0), the call will triggeronly if the number of dialled digits is greater than or equal ton.

If the call is marked as a potential IN call, and TDP-2 is armed, this initiatesinteraction between the O_BCSM and the SSF. The SSF FSM moves from stateIdle to state Trigger Processing. See Section 2.2.2.6 for a description of whathappens in this state.

Otherwise, the O_BCSM moves from PIC_2 to PIC_3 without initiatinginteraction 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 bearmed as a TDP-R, with trigger criterion Specific Called Party Number String.




Otherwise, the O_BCSM moves from PIC_3 to PIC_4 without initiatinginteraction with the SSF, and the SSF FSM remains in state Idle. Since the DMSSSP supports no TDPs after TDP-3, the call will now progress to completionwithout any IN interaction.

2.2.2.6 Trigger Processing

An armed TDP will only initiate IN processing if the trigger criterion associatedwith the TDP matches one of the datafilled values at the switch.

If a TDP has triggered, the SSF tests whether trigger criteria match a valuedatafilled at the switch:

• If TDP-2 is armed with Minimum Digits as the trigger criterion, is thenumber of dialled digits greater than or equal to the datafilled value?

Note: If Minimum Digits is datafilled with the value 0, the call will alwaysinitiate IN processing. The TDP is an unconditional TDP.

• If TDP-2 is armed with Feature Code as the trigger criterion, do the collecteddigits match a datafilled feature code for an IN service?

• If TDP-2 is armed with Specific Digit String as the trigger criterion, do thecollected digits match a datafilled digit string associated with an IN service?

• If TDP-3 is armed with Specific Called Party Number String as the triggercriterion, do the translated collected digits match a datafilled called partynumber associated with an IN service?

If there is no criteria match, the call is not recognised as an IN call, and the SSFFSM moves from state Trigger Processing back to state Idle. The O_BCSM movesto PIC_3 (see Section 2.2.2.4) or to PIC_4 (in which case the call progresses tocompletion 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_BCSMprocessing is suspended and the SSF initiates IN interaction as described in Section2.2.2.7.

Note: If IAM does not include a Calling Party Number parameter, and the servicekey 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 andsending this to the SCF in a TCAP BEGIN package. The parameters of theInitialDP operation are assembled partly from ETSI ISUP message parameters, andpartly from triggering information datafilled at the switch, as follows:

For a more detailed description of IAM / InitialDP parameter mapping, refer toAppendix A.

When the SSF has sent InitialDP, the SSF FSM moves from state TriggerProcessing to state Waiting For Instructions, and waits for a response from theSCF. Call processing in the O_BCSM remains suspended.

See Chapter 3 for a description of the interaction between ETSI ISUP and INAPwhile 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

<datafill for dialled digits> ServiceKey

Supplied by DMS SSP EventTypeBCSM

Transmission Medium Requirement bearerCapability



2.3 IN Interaction with ETSI ISUP OverlapSignalling

Handling of incoming ETSI ISUP overlap calls is similar to that of ETSI ISUPen-bloc calls. The primary differences are:

• The initial IAM message does not contain all the information necessary tocomplete 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 anddescribed 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), andpossibly triggers interaction between the O_BCSM and the SSF (see Section2.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_BCSMand the SSF (see Section 2.3.2.5).

4. If the call has not triggered at this point, it completes without any INinteraction.

Trigger processing is described in Section 2.3.2.6. Trigger processing may initiateIN 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), itcreates 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 thetrigger subscription(s) ineffect at the switch. Two types of subscription are supported:

• Office or switch-wide subscription, which means that all incoming ETSIISUP calls are treated as potential IN calls.

IAM

DMS SSP SCP

SAM(s)

Originatingside

TDP-2 armed?

BCSM SSF FSM

PIC_2

Collect digits

PIC_1Idle

TriggerProcessing

Waiting forInstructions

Nomatch

PIC_3

Translatedigits

TDP-3 armed? TriggerProcessing

Callproceedswith no INinteraction

PIC_4

Idle

Nomatch

Criteriamatch(additionalinfo not req’d)

InitialDP

StartTSSF

Potentialmatch

Potentialmatch

Startinter-digittimer



• Trunk group subscription, which means that only ETSI ISUP calls incomingon 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 fromPIC_1 to PIC-2. The SSF FSM (with which no interaction has yet taken place) is instate Idle. The DMS SSP does not support the arming of TDP-1 (OriginatingAttempt 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 AddressSignals parameter of the IAM message.

The O_BCSM leaves PIC_2, even though digit collection is still in progress. TheSSF FSM remains in state Idle.

The procedure for collecting further digits is described below. Although it isdescribed here for convenience, it should be understood that the O_BCSM willhave moved out of PIC_2 by the time further digits arrive.

After receiving the IAM message, the DMS SSP starts an inter-digit timer. Theoriginating side will provide further digits in one or more SAM messages. Eachtime a SAM message is received, the inter-digit timer is restarted. Digit collectionis complete when the DMS SSP receives a SAM message with an end of digitsindicator from the originating side, or when the inter-digit timer expires. If theinter-digit timer expires without a complete number having been received, the callis 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 bearmed as a TDP-R, either unconditionally or with the Specific Digit String triggercriteria.

TDP-2 is armed unconditionally by datafilling a value of 0 for Minimum Digits. IfMinimum Digits is datafilled with the valuen (>0), TDP-2 is triggered only whenat leastn digits have been collected from the originating side.

Note: If the DMS SSP receives an indication that sending is complete (e.g. receiptof a SAM message with an end of digits indicator) before it has received thespecified minimum number of digits for triggering, the call will not trigger.




Otherwise, the O_BCSM moves from PIC_2 to PIC_3 without initiatinginteraction 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. Thenumber that is translated consists of whatever digits have been collected so far inIAM and SAM messages.

When translations produce a routing address, the O_BCSM leaves PIC_3.

Note: This condition may be satisfied before digit collection is complete, so digitcollection 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 bearmed as a TDP-R, with trigger criterion Specific Called Party Number String.


Otherwise, once all digits have been collected and translated, the O_BCSM movesfrom PIC_3 to PIC_4 without initiating interaction with the SSF. The SSF FSMremains in state Idle. Since the DMS SSP supports no TDPs after TDP-3, the callwill now progress to completion without any IN interaction.



2.3.2.6 Trigger Processing

The interactions between overlap signalling and trigger processing are illustratedin Figure 7.

Figure 7 Interactions Between Overlap Signalling and Trigger Processing

An armed TDP will only initiate IN processing if both of the following conditionsare true:

• The trigger criterion associated with the TDP matches one of the datafilledvalues at the switch. SeeEstablishing a Criteria Match.

Call triggers atan armed TDP

Is it aconditional

TDP?

Is there acriteriamatch?

Is digitcollectioncomplete?

Can we sendInitialDP with partial

CdPN?

Send InitialDPGo to state WFI

Start TSSF

No

Yes

Go to next PICGo to state Idle

NoYes

Wait for next SAMmessage or inter-digit

timeout

No

Potential*

Wait for next SAMmessage or inter-digit

timeout

* A potential criteria match existswhen digit collection is still in progressand collected digits may provide acriteria match when combined withdigits still to be collected.

Wait for next SAMmessage or

inter-digit timeout

Have we collectedthe minimum

number of digitsrequired?

Yes

No

No

Yes

Yes

Continue digitcollection if

InitialDP sent withpartial CdPN

Is digitcollectioncomplete?

No

Yes



• The DMS SSP has received sufficient information to initiate IN interaction.The datafilled service key for a service will indicate what information theSSF requires before it can send InitialDP:

- Does InitialDP require a complete called party number, or can it besent with a partial called party number?

- If InitialDP can be sent with a partial called party number, have theminimum number of digits been collected (as specified by thedatafilled value for Minimum Digits)?

SeeDetermining When to Send InitialDP.

Establishing a Criteria Match

If a conditional TDP has triggered, the SSF tests whether the associated triggercriterion matches any of the values datafilled at the switch:

• If TDP-2 is armed with Specific Digit String as the trigger criterion, do thecollected digits match a datafilled digit string associated with an IN service?

• If TDP-3 is armed with Specific Called Party Number String as the triggercriterion, do the translated digits collected so far match a datafilled calledparty 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 withoutproducing a match, or enough digits have already been collected to rule outthe possibility of a match. For example, 1234 has been collected, and all thedatafilled 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 enoughinformation to initiate IN interaction (seeDetermining When to SendInitialDP ).

Note: There may be cases when collected digits match one of the datafilledcriteria, but further digits may produce a different match. For example, 1234has been collected, and the datafilled criteria for Specific Called PartyNumber String include both 1234 (an actual match) and 12345 (a potentialmatch). In such ambiguous cases, the SSF will wait for further digits andcheck again for a match.

• There is a potential match. Although no actual match has been found, digitcollection is still in progress and may produce digits which, when combinedwith digits already collected, produce a match. For example, 123 has been



collected, and the datafilled criteria for Specific Called Party Number Stringincludes 1234.

The O_BCSM remains suspended at the current TDP, and the SSF FSMremains in state Trigger Processing. As each SAM message arrives withmore digits, the SSF repeats the test for a criteria match, incorporating thenewly received digits. (Note: The newly received digits go throughtranslations before the SSF tests for a criteria match.)

This process continues until either the SSF determines that a match definitelydoes or does not exist (in which case the appropriate action is taken, asdescribed above), or until digit collection completes without producing amatch (in which case the O_BCSM moves to the next PIC, and the SSF FSMmoves 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 INinteraction (seeDetermining When to Send InitialDP).

Determining When to Send InitialDP

Once the SSF has determined that it should initiate IN interaction (for anunconditional TDP, or for a conditional TDP for which a criteria match has beenfound), it must determine whether enough information has been provided to startthe interaction (i.e. by sending InitialDP to the SCF).

The service key associated with the IN service with which the call is matched willindicate whether InitialDP can be sent with a full or partial called party number. IfInitialDP can be sent with a partial called party number, the datafilled value forMinimum Digits will specify the minimum number of digits that must be collectedbefore 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 notincluded in the initial IAM message, the call will be cleared. There are no facilitiesfor 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 acomplete called party number, it has been collected and digit collection iscomplete).

• The minimum number of digits have been collected.

O_BCSM processing is suspended and the SSF initiates IN interaction, asdescribed in Section 2.3.2.7. The DMS SSP can continue to collect AddressSignals 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 ofMinimum 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 acomplete called party number has been received.

• The number of digits collected exceeds the datafilled value for MinimumDigits.

• The inter-digit timer expires.

In the first two cases, the DMS SSP suspends O_BCSM processing and the SSFinitiates IN interaction, as described in Section 2.3.2.7.

If the inter-digit timer expires before sufficient digits have been collected, the callwill be cleared.

Note: If digit collection is completed before the required minimum number ofdigits has been collected, the call will not trigger. The SSF will move to the nextPIC, 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 operationand sending this to the SCF in a TCAP BEGIN package. The parameters of theInitialDP operation are assembled partly from ETSI ISUP message parameters, andpartly from triggering information datafilled at the switch, as follows:

For a more detailed description of IAM / InitialDP parameter mapping, refer toAppendix A.

Having sent the InitialDP, the SSF FSM moves from state Trigger Processing tostate Waiting For Instructions, and waits for a response from the SCF. Callprocessing in the O_BCSM remains suspended.

See Chapter 3 for a description of the interaction between ETSI ISUP and INAPwhile 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, thismay have an impact on the way in which the call interacts with IN. Such possibleimpacts are currently being investigated, and will be documented in a future issueof 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 oferrors arising from sending of InitialDP is covered in Section 3, as they arereported 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 callprocessing is suspended.

2.5.3 Errors Detected by TCAP

No errors are detected by TCAP during this stage of call processing. Detection oferrors arising from sending of InitialDP is covered in Section 3, as they arereported 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 bystandard ETSI ISUP mechanisms (e.g. call clearing). There is no ETSI ISUP/INAPinteraction.

NIS 94-80nn World Trade IN Section 3: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 underthe 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 anannouncement and/or collecting information from the user

• Reset the timer used by the SSF to control how long it will wait for aresponse from the SCF

• Resume O_BCSM call processing, having provided a complete or partialreplacement for the original called party number

• Clear the call

Note: The SSF may initiate call monitoring by arming EDPs, or request the SSF toprovide information about call completion. However, ETSI ISUP does not supportthese features. When the call is connected, any armed EDPs will be disarmed anddefault values for will not be provided for any requested call information.

Section 3: World Trade IN NIS 94-80nnCall 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 callhas been through translations, unless translations indicate that no billing record isto be generated.

If a call triggers at TDP-3, therefore, a billing record may or may not already existfor the call. If the SCF sends FCI operations containing billing information, thisinformation is added to the existing billing record, or a billing record is created ifone does not already exist.

If a call triggers at TDP-2, the call has not yet been through translations, so nobilling record exists for the call. If the SCF sends FCI operations containing billinginformation, a billing record will be created for the call. In this case, the DMS SSPwill be prevented from creating another billing record when the call goes throughtranslations.

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, andupdates fields in AMA records using a combination of FCI parameter values andinformation datafilled against the trigger criteria for a service (specifically, theCalled Party Number and Calling Party Number, as used to provide values for theInitialDP operation). AMA modules are used as follows:

• In the base AMA record for an IN call, the fields Terminating Open Digits 1and Terminating Open Digits 2 (normally used to store translated called partynumber digits) are filled with hexadecimal Fs (1111). These will eventuallybe overwritten with the final called party number, as modified/provided byConnect.

• Appended to the base record may be either a Type 40 (Digits) module or aType 28 (Additional Digits Dialled) module, as specified by datafilledservice data.

The Type 40 module uses its Dialled Digits 1 and Dialled Digits 2 fields torecord the translated dialled digits available when the InitialDP operation issent for the call (i.e. the same digits conveyed in the CalledPartyNumberparameter of InitialDP).

The Type 28 module uses its Additional Digits Dialled field to recordadditional authorisation and PIN digits dialled by a VPN user.



• The SCF can send an FCI operation to instruct the DMS SSP to append anAMA Type 199 module to the base record. This module type containsoperator-defined data. This allows network operators great flexibility indetermining what billing information they wish to record, particularly sincesuccessive FCI operations can be used to append a number of Type 199modules to the base record.

The processing of the billing information provided by the SCF is handled entirelywithin the SSF, and requires no interaction with ETSI ISUP.

For a more detailed description of AMA billing for IN calls, see AG4629 (TDP-3billing) and AG5150 (TDP-2 billing).

3.3 User Interaction

The SCF can initiate, control and terminate direct in-band interaction with thecalling 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 toan announcement, if the InitialDP operation does not provide the SCF with enoughinformation 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, althoughonly one type of IP can be in use at any given moment; that is, if a call is connectedto one type of IP, that connection must be closed before the call can be connectedto the other type of IP.

3.3.1 INAP Operations Used

The following operations are concerned with establishing a connection betweenthe 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 specialisedresource, typically so that it can provide instructions to the calling party orobtain additional information.



The DMS SSP supports the CTR operation for connections to the integratedDMS IP, i.e. to MTM EDRAM announcements or DTC tone generation anddetection. In this scenario, the SSF then relays SCF-to-SRF operations to theintegrated 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 theconnection is fully established (see the description of theAssistRequestInstructions operation below), operations are exchangeddirectly between the SCF and the external IP, with no further involvementfrom the SSF.

• AssistRequestInstructions (ARI)Sent from the SRF to the SCF to complete the connection between the SCFand 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 onlydifference is that for an integrated IP connection they will be sent to the SSF, whichrelays them to an internal SRF. For an external IP connection, operations areexchanged directly between the SCF and the external IP:

• PlayAnnouncement (PA)Sent from the SCF to the SRF after a user-SRF connection has beenestablished under SCF control, to tell the SRF to provide a specified tone orannouncement in-band. There is no input from the user.

• SpecializedResourceReport (SRR)Sent from the SRF to the SCF to confirm that a specified tone orannouncement 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 beenestablished under SCF control, to tell the SRF to provide a specified tone orannouncement in-band and to collect information (e.g. digits in-band) fromthe user. The collected information is sent to the SCF via the TCAP ReturnResult defined for the P&C operation.



The following INAP operation is concerned with the timer that the DMS SSP usesto control how long it will wait for a response from the SCP or an external IPbefore timing out:

• ResetTimer (RT)Sent from the SCF to the SSF to tell it to restart the TSSF timer with aspecified period. This allows the SCF to prevent the SSF from timing out acall in cases where IN processing takes longer than usual (e.g. while waitingfor a response from an external IP, or while executing complex servicelogic).

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/SCFcontrol relationship.

The following INAP operation is concerned with terminating the connectionbetween 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 SRFconnection for a call. This indicates that no further interaction with the useris 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 initiatedisconnection (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 communicationwith the caller (voice prompts, network tones, DTMF digits and so on). In a callwithout user interaction, the speech path would be set up in response to an ANSmessage from the terminating side. If user interaction is required before the call isrouted to the terminating side (i.e. before the SCF issues Connect), the DMS SSPmust 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 ISUPmessages 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 hasreceived a complete called party number. If this has already happened by thetime user interaction is requested, ACM will already have been sent, so itisn’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 thespeech path to be set up earlier than would be the case if it was set up in response toETSI 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 messageswill break the trace.

No early setup messages are sent if a speech path has already been set up. This willbe 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 beenreceived from the terminating side).

When the call is finally routed, the terminating side will eventually return thefollowing ETSI ISUP messages to the DMS SSP:

ACMANS

These are the messages that would normally cause the speech path to be set up tothe caller. However, since the speech path has already been set up to handle userinteraction, these messages do not need to be relayed to the originating side, sothey are simply discarded by the DMS SSP.




Figure 8 ETSI ISUP call with IN user interaction (integrated IP)

DMS SSP SCP

state cWaiting forInstructions

BCSM SSF FSMSSRM

state 1Idle

state 2Connected

state dWaiting forEnd of UserInteraction

To state 1Idle

To state cWaiting forInstructions

ACM

ANM

CTR

SRR or

PA or P&C

DFC

PA or P&C

state 2Connected

state dWaiting forEnd of UserInteraction

Any subsequentConnectToResource

does not require ETSIISUP interaction, as

speech path is alreadythrough-connected

state 3User

Interaction

ETSI ISUP ACM (if notalready sent) and ANM

sent to open speech pathprior to user interaction

In-banduser interaction

tone/announcement

digits (RR)

tone/announcement

P&C(RR)

Originatingside

RT

RT

RT

O_BCSM remainssuspendedthroughout

Optionalfurther

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 stateIdle.

2. When the SSF receives an INAP CTR operation from the SCF, the followingcall 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 oneup, as described in Section 3.3.2.1.

3. The calling party is now through connected to on-board DMS SSP tone andannouncement capabilities (provided by the SRF/integrated IP).

4. User interaction can begin, as described in the specificationDMSImplementation of CS-IR INAP (ETSI Core INAP Subset), andsummarised in Figure 8. No further ETSI ISUP interaction is necessaryduring interaction with the user.

5. The SCF terminates user interaction by sending an INAP DFC operation tothe SSF. The following call processing actions take place within the DMSSSP:

- 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 usesthe speech path already set up.

At any point while call processing is suspended, the SCF can send a ResetTimeroperation to the SSF. The effect of ResetTimer is to restart the TSSF timer, which isused to control the amount of time for which the SSF will wait for some kind ofresponse 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 sendingsome other kind of response to the SSF (e.g. CTR, Connect). However, aftersending such a response, the SCF can send as many ResetTimer operations as itwishes. 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 communicationwith the caller (voice prompts, network tones, DTMF digits and so on). In a callwithout user interaction, the speech path would be set up in response to an ANSmessage from the terminating side. If user interaction is required before the call isrouted to the terminating side (i.e. before the SCF issues Connect), the DMS SSPmust set up the speech path at an earlier stage in the progress of the call. SeeSetting Up a Speech Path.

If user interaction is handled via an external IP rather than the DMS SSP’sintegrated IP, the DMS SSP also needs to set up a link to the external IP andconnect the caller’s speech path to this link. SeeConnecting 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 messagesto 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 hasreceived a complete called party number. If this has already happened by thetime user interaction is requested, ACM will already have been sent, so itisn’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 thespeech path to be set up earlier than would be the case if it was set up in response toETSI 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 messageswill break the trace.



Figure 9 ETSI ISUP call with IN user interaction (external IP)

DMS SSP SCP


BCSM SSF FSM SSRM

state 1Idle

state 2Connected

To state 1Idle

To state cWaiting forInstructions

ACM

ANM

SRR or

PA or P&C

DFC

PA or P&C

state 2Connected

Any subsequent ETCdoes not require ETSIISUP interaction, as

speech path is alreadyopen

state 3User

Interaction

ETSI ISUP ACM andANM, or in some casesANM only, sent to open

speech path prior to userinteraction, but only if not

In-banduser interaction

tone/announcement

digits (RR)

tone/announcement

P&C(RR)

Originatingside

External IP

ETC

SETUP

ALERTING/PROGRESS

CONNECT

ARI

DISCONNECT

RELEASECOMPLETE

RT

RT

DISCONNECT

RELEASECOMPLETE

O_BCSM remainssuspendedthroughout

state eWaiting For

End OfTemporaryConnection

state eWaiting For

End OfTemporaryConnection

Optionalfurther

CTR

Disconnectioninitiated byexternal IP

CALLPROCEEDING



No early setup messages are sent if a speech path has already been set up. This willbe 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 beenreceived from the terminating side).

When the call is finally routed, the terminating side will eventually return thefollowing ETSI ISUP messages to the DMS SSP:

ACMANS

These are the messages that would normally cause the speech path to be set up tothe caller. However, since the speech path has already been set up to handle userinteraction, these messages do not need to be relayed to the originating side, sothey 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 messageon an outgoing PRI trunk. The external IP responds by sending the following PRImessages to the DMS SSP:

1. CALL PROCEEDING. This message is in response to the initial SETUPmessage.

2. ALERTING. This message causes the speech path to be set up between thecaller and the external IP.

3. CONNECT. This message indicates that the link to the external IP has beenestablished successfully, and user interaction can begin.

Note: The connection between the DMS SSP and the external IP need not bedirect. Although the outgoing trunk from the DMS SSP will be ETSI PRI, settingup 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 berestrictions 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 DFCoperation to the SSF), the DMS SSP breaks the connection to the external IP bysending a PRI DISCONNECT message with Cause value 16 (normal callclearing). The external IP responds with a PRI RELEASE message, and the DMSSSP completes the disconnection by sending a PRI RELEASE COMPLETEmessage to the external IP.

The speech path between the caller and the DMS SSP remains open, and can beused for subsequent user interactions (either with the external IP or with the DMSSSP’s integrated IP). However, subsequent user interaction using the external IPwill 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 PRIDISCONNECT to the DMS SSP. If the external IP disconnects before it hasanswered a connection attempt, the SSF reports this to the SCF by returning anETCFailed error in response to the ETC operation. If the external IP disconnectsafter a connection has been established, the SSF FSM simply returns to stateWaiting 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 stateIdle.

2. When the SSF receives an INAP ETC operation from the SCF, the followingcall processing actions occur within the DMS SSP:

- The SSF FSM moves to state Waiting For End Of TemporaryConnection.

- If no speech path to the caller exists, the DMS SSP sets one up, asdescribed inSetting Up a Speech Path.

- The DMS SSP sets up a link to the external IP, as described inConnecting to an External IP.



3. When the external IP receives the SETUP message from the DMS SSP, thefollowing 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 theconnection with the DMS SSP.

- The SSRM moves to state Connected.

- The SRF sends an INAP ARI operation directly to the SCF to establishthe direct connection between the external IP and the SCF.

4. The calling party is now through connected to the tone and announcementcapabilities provided by the external IP.

5. User interaction can begin, as described in the specificationDMSImplementation of CS-1R INAP (ETSI Core INAP Subset), andsummarised in Figure 9. No further ETSI ISUP interaction is necessaryduring interaction with the user.

6. The SCF terminates user interaction by sending an INAP DFC operation tothe SSF. The following call processing actions take place:

- The SSF sends a PRI DISCONNECT message to the external IP withCause 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 ForInstructions.

The speech path to the caller remains open. Any subsequent interaction usesthe speech path already set up.

7. The external IP can initiate disconnection by sending a PRI DISCONNECTmessage to the DMS SSP. The DMS SSP responds by sending RELEASE tothe external IP, and the external IP completes disconnection by sendingRELEASE COMPLETE to the DMS SSP. The effect on the SSRM and SSFFSM are the same as for SCF-initiated disconnect (see step 6).

See Appendix D for details of the parameters of the PRI messages involved inexternal IP connection and disconnection.



At any point while call processing is suspended, the SCF can send a ResetTimeroperation to the SSF. The effect of ResetTimer is to restart the TSSF timer, which isused to control the amount of time for which the SSF will wait for some kind ofresponse 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 sendingsome other kind of response to the SSF (e.g. ETC, Connect). However, aftersending such a response, the SCF can send as many ResetTimer operations as itwishes. 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 fromthe SCF to the SSF to indicate that a call should be routed to a specifieddestination, thus successfully completing IN interaction. Two types of routinginformation may be provided:

dRA destinationRoutingAddress parameterA destination routing address (a complete or partial replacement for theoriginal called party address).

cAP CutAndPaste parameterOptional cut-and-paste instructions on how the original dialled numbershould be manipulated to generate a new called party address.


• 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 isreceived are ignored.

• The SCF can provide a replacement prefix in the dRA parameter, in whichcase the cAP parameter specifies how many prefix digits should be removedfrom the original dialled number and replaced. For example, a Connectoperation might replace a general-purpose IN prefix in the original diallednumber (e.g. 0800) with the prefix of a specific switch where the requestedservice is actually provided.



Note: If the SSF receives a Connect operation with a cAP parameter of 0, theeffect is to append the dialled digits to the destination number supplied inConnect.

Note: DMS SSP digit translation takes place at two points:

• On the number initially dialled, e.g. to take into account the caller’s customergroup.

• After the IN query, which means that further digit manipulation may takeplace before routing.

The resumption of call processing on receipt of a Connect is illustrated in Figure10. The ETSI ISUP interactions implied by receipt of a Connect take place aftercall 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

Digitmanipulation viaDMS translations

IN interactiontriggered on CdPN

Result of IN queryused to manipulate

full CdPN (dRAreplaces all or first n

CdPN digits)

SSF

SSF sendsInitialDP

SCF

SCF sendsConnect

INAP operationparameters

Called party

Onward routing

More digits may reach SCF via SRF interactionwith calling party (no effect on BCSM or SSF)

Mandatory service key,optional CdPN

Mandatory destinationRoutingAddress (dRA);

optional cutAndPaste to replace prefix

Dialled digits(out-of-band)

Digitmanipulation viaDMS translations



3.4.2 Call Clearing (ReleaseCall)

If the SCF determines that a call cannot be completed (e.g. because the caller is notauthorised), it sends a ReleaseCall operation to the SSF. This operation provides areleaseCause value to be used in initiating ETSI ISUP call clearing; for example:

21 (call rejected)31 (normal unspecified)

The mapping between releaseCall values and ETSI ISUP Cause values is describedin Appendix E.

The ETSI ISUP interactions implied by receipt of a ReleaseCall take place aftercall 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 actionrequiring ETSI ISUP interaction takes place until call processing is resumed andthe call can be completed or cleared.


3.5.1.1 Errors Detected by the SCF

While O_BCSM call processing is suspended, a number of errors may be detectedand 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 SSFterminates the SCF/SSF dialogue and initiates backward call clearing with anappropriate Cause value (31 = normal, unspecified), which ensures that the callerhears 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 inINAP 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 aTCAP CONTINUE message. The SCF has the option of clearing the call with aReleaseCall operation or taking some other action.

3.5.2 Timer Expiry

This section describes how the SSF handles the conditions that result from theexpiry of one of its internal timers. There are two such timers: TSSF and TSRF. TheSSF uses both these timers to guard against excessive call suspension times whilewaiting 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

ET

CF

aile

d

Impr

oper

Cal

lerR

espo

nsea

Mis

sing

Par

amet

er

Par

amet

erO

utO

fRan

ge

Req

uest

edIn

foE

rror

Sys

tem

Fai

lure

Task

Ref

used

Une

xpec

tedC

ompo

nent

Seq

uenc

e

Une

xpec

tedD

ataV

alue

Une

xpec

tedP

aram

eter

ActivateServiceFiltering ✓ ✓ ✓ ✓ ✓ ✓

CallInformationRequest ✓ ✓ ✓ ✓ ✓ ✓ ✓

Connect ✓ ✓ ✓ ✓

ConnectToResource ✓ ✓ ✓

DisconnectForwardConnection ✓ ✓

EstablishTemporaryConnection ✓ ✓ ✓ ✓ ✓ ✓ ✓

FurnishChargingInformation ✓ ✓ ✓ ✓ ✓

PlayAnnouncement ✓ ✓ ✓ ✓ ✓ ✓

PromptAndCollectUserInformation ✓ ✓ ✓ ✓ ✓ ✓ ✓

ReleaseCallb

ResetTimer ✓ ✓ ✓ ✓ ✓



Note: The usage of TSRF depends on whether an integrated or external IPconnection is being used for user interaction.

3.5.2.1 Expiry of T SSF

The SSF starts (or restarts) the timer TSSF:

• When the SSF FSM moves into state c (Waiting For Instructions) (e.g. aftersending an InitialDP or EventReportBCSM operation to the SCF). In thissituation, the timer can have a value from 1 to 10 seconds.

• When the SSF FSM moves into state d (Waiting For End Of UserInteraction) (e.g. after receiving a CTR operation from the SCF). In thissituation, the timer can have a value from 1 to 60 minutes.

• When the SSF FSM moves into state e (Waiting For End Of TemporaryConnection) (e.g. after receiving a ETC operation from the SCF). In thissituation, the timer can have a value from 1 to 60 minutes.

• When the SSF receives a ResetTimer operation from the SCF. In thissituation, the value of the timer is specified in a parameter of the ResetTimeroperation, and may be one of the following:

1 to 10 seconds1 to 10 minutes15, 20, 25, 30, 35, 40, 45, 50, 55 or 60 minutes

If the specified timer value is not one of the above, the nearest legal value isused.

If the SSF does not receive a valid operation from the SCF before the TSSF timerexpires, 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 TSSFtimer. If an operation received from the SCF contains an error, the TSSF timercontinues to run after the SSF has sent an error indication. The SCF therefore hasthe opportunity to send a correct operation before the timer expires.



An external IP can close the connection with the DMS SSP, either during or afterconnection of the speech path, by sending a PRI RELEASE message to the DMSSSP. 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 yetanswered; 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 T SRF

This section describes the use of the TSRF timer if an integrated IP connection isused for user interaction.

Note: If an external IP connection is used for user interaction, standard signallingsystem 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 1to 10 seconds.

If the SRF does not receive a valid PA or P&C operation from the SCF before theTSRF timer expires, the following call processing actions occur within the SSF:

1. SRF resources are released. This is equivalent to receiving a DFC operationfrom 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 fromthe 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 DFCoperation from the SCF.

The SSF restarts the TSRF timer under the following circumstances:

• When it receives a valid PA or P&C operation from the SCF

• After sending a SRR operation to the SCF (on successful completion of apreceding PA operation)

• After sending the Return Result for a preceding P&C operation

If an operation received from the SCF contains an error, the TSRF timer continuesto run after the SSF has sent an error indication. The SCF therefore has theopportunity to send a correct operation before the timer expires.


3.5.3.1 Errors Detected by the SCF

If the SCF detects an error in the TCAP component in which an INAP operation issent, it sends a Reject component in an END package to the SSF. The SSFresponds by terminating the dialogue and initiating backward call clearing bysending 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 issent, it sends a Reject component in a CONTINUE package to the SCF. The actiontaken depends on the SCF, which can either resend the component or release thecall.

3.5.4 User-Initiated Abort

Either the SCF or the SSF can abort a dialogue by sending a TCAP ABORTpackage. This is called user-initiated abort (where “user” refers to INAP as beingthe 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, asdescribed in Section 4.2.




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



NIS 94-80nn World Trade IN Section 4:PRE 0.2 (draft) Release 4 ETSI ISUP / INAP Interworking Call Processing Resumed


4 Call Processing Resumed

This section describes what the DMS SSP does when call processing is resumedafter IN interaction. It deals with:

• Normal call completion after receipt of a Connect operation

• Call clearing after receipt of a ReleaseCall operation

• Error handling

Note: Throughout this section it is assumed, unless stated otherwise, that a callthat is routed on through the network is routed over an ETSI ISUP trunk.

4.1 Call Completion (after Connect)

After receiving a Connect operation from the SCF, 0_BCSM call processingresumes in PIC_3. The DMS SSP re-enters translations with the number wholly orpartly provided in Connect, selects an appropriate routeset, and attempts tocomplete the call.

Note: If the call originally triggered at TDP-2, it will not be allowed to re-triggerat TDP-3.

The DMS SSP sends an IAM to the terminating exchange. If the called party is notbusy, the DMS SSP will receive an ACM and, when the called party answers, anANM. The DMS SSP relays both of these messages back to the originatingexchange (unless they have already been sent), completing the speech pathbetween the calling and called parties.

If the called party answers quickly, it is possible that no ACM will be sent, onlyANM.

Section 4: World Trade IN NIS 94-80nnCall Processing Resumed Release 4 ETSI ISUP / INAP Interworking PRE 0.2 (draft)


Note: If there has previously been some user interaction with the calling party (asdescribed in Section 3.3), an early ACM and ANM will already have been sent tothe calling party to open the speech path to allow in-band interaction. In this case,the ACM/ANM received from the terminating side are discarded by the DMS SSP.They are not relayed to the originating side.

The ETSI ISUP/INAP interaction for normal call completion after Connect is asshown in Figure 11. See Appendix B for details of parameter value mappingbetween Connect and IAM.

Figure 11 Normal call completion

Note: As shown in Figure 11, the SCF can send a CIRQ operation before sendingConnect, requesting the SSF to return information about the call when itcompletes. However, this feature is not currently supported where the outgoing

DMS SSP

Connect

BCSM

SSF FSM

state aIdle

SCP


IAM

ACM

ANM

ACM

ANM

Speech path through-connected

Complete replacementrouting address orreplacement prefix

Call routed onwardusing informationprovided in Connect

ACM and ANMsent back onlyif there has beenno user interaction

Originatingside

Terminatingside

Request for call information

CIRQ



trunk is ETSI ISUP, so the SSF will return default values for any requested callinformation.

4.2 Call Clearing (after ReleaseCall)

If the SCF determines that a call cannot be completed (e.g. because the caller is notauthorised), it sends a ReleaseCall operation to the SSF. This operation provides aCause value to be used in initiating ETSI ISUP call clearing; for example:

21 call rejected31 normal unspecified

The DMS SSP will initiate call clearing by sending an ETSI ISUP REL message tothe originating side with a Cause mapped from the Reason value provided in theReleaseCall operation. By definition, this is backward clearing of an incoming callattempt. The REL message sent by the DMS SSP must be confirmed by a RLC(Release Complete) message from the originating side.

The ETSI ISUP/INAP interaction for call clearing is shown in Figure 12. SeeAppendix E for details of parameter value mapping from ReleaseCall to REL.

Figure 12 Call clearing after ReleaseCall

Originatingside

DMS SSP

ReleaseCall

BCSM SSF FSM

state aIdle

SCP


RLC

Cause value

NofurtherINinteraction

REL

Call cleared (INAPCause value mappedon to REL Cause value)



4.3 Returning Requested Call Information

The SCF may request call completion information by sending one or more CIRQoperations to the SSF before sending Connect. However, the provision of callinformation is not currently supported if the outgoing trunk is ETSI ISUP. Whenthe SCF sends Connect and the SSF determines that the outgoing trunk is ETSIISUP (the SCF cannot make this determination when it sends CIRQ), the SSFreturns default values for any requested call information.

4.4 Monitoring

If the SCF decides that an IN call is to be completed, it can instruct the SSF tomonitor the progress of the call through to disconnection. When the SSF detects aparticular event in the progress of the call, it reports the event to the SCF. The onlycall processing event that can be monitored in this way is failure to route the call toits destination.

Before the SCF issues a Connect operation to complete a call, it can arm one ormore DPs as EDPs, each of which corresponds to a possible event in the progressof the call. The SCF arms a DP as an EDP by sending aRequestReportBCSMEvent (RRBE) operation, specifying one of two monitoringmodes:

• NotifyAndContinue, which causes the DP to be armed as an EDP-N.

• Interrupted, which causes the DP to be armed as an EDP-R.

Note: An RRBE operation can specify a third mode, Transparent, which causesthe operation to disarm a previously armed EDP.

The SCF can send RRBE before it sends Connect, or after (providing a controlrelationship still exists between the SCF and SSF).

In Release 4 the use of the legID parameter of RRBE is supported. This means thatan EDP can be armed for a specific leg of a 2-party or multi-party call, so that theEDP is triggered only if the relevant event occurs on the specified leg of the call.

When an armed EDP is encountered, the SSF notifies the SCF by sending anEventReportBCSMEvent (ERB) operation. In the case of an EDP-R, callprocessing is suspended while the SSF waits for a response from the SCF. In thecase of an EDP-N, call processing continues (no response is expected from theSCF).



The DMS SSP supports the arming of only one DP as an EDP on outgoing ETSIISUP trunks. This is DP-4, Route_Select_Failure, which can be armed as anEDP-R.

4.4.1 Monitoring for DP-4 (Route_Select_Failure)

The SCF arms DP-4 as an EDP-R by sending an RRBE operation with:

DP-4 is encountered if the SSF is informed that the call cannot be routed to itsspecified destination, e.g. because of congestion, failure of an exchange furtheralong the route, or a failure within the DMS SSP itself.

If the failure is detected at another switch, that switch sends a REL message to theDMS SSP. The CRM message contains an appropriate Cause from the switchwhere the failure was detected. The DMS SSP acknowledges the REL message bysending an RLC message to the terminating side.

If the failure is detected at the DMS SSP itself (e.g. all routes to the specifieddestination are busy,) no INAP messaging is involved.

Note: In Release 4 the DMS SSP does not support the detection of route selectfailure at another exchange. EDP-4 can only be triggered by a routing failurewithin the DMS SSP.

The DMS SSP suspends O_BCSM call processing. The SSF then sends an ERBoperation to the SCF with:

RRBE Parameter Value

EventTypeBCSM 4 (routeSelectFailure)

legID The call leg to be monitored for route selectfailure

monitorMode interrupted

ERB Parameter Value

EventTypeBCSM 4 (routeSelectFailure)

misCallInfo request

legID The call leg on which route select failure wasdetected

EventSpecificInformation:failureCause (optional)

routeSelectFailureSpecificInfo:The appropriate value from the switch



Note: When EDP-4 is encountered, the DMS SSP sends an early NAM to theoriginating side (if one has not already been sent). This is to prevent the call timingout while the SSF waits for a response from the SCF.

The SSF-SCF control relationship is maintained so that the SCF can takeappropriate action, e.g. another Connect. Note that the SCF can send one or moreResetTimer operations to prevent the SSF timing out the call while waiting for aresponse to the ERB operation.

The ETSI ISUP/INAP interaction involved in monitoring for routing failure is asshown in Figure 13.

4.5 Error Handling


4.5.1.1 Errors Detected at the SCF

No INAP errors can be detected and reported by the SCF after call processing isresumed (with Connect). There is therefore no ETSI ISUP interaction.

4.5.1.2 Errors Detected at the SSF or SRF

The SSF/SRF detects and reports errors as described in Section 3.5.1.2. If the SCFdecides to release a call in response to an error reported by the SSR/SRF, the ETSIISUP interaction is as described in Section 4.2.

4.5.2 Timer Expiry

Actions on expiry are as described in Section 3.5.2.1.



If the SCF detects an error in the TCAP package conveying an operation, it sends aTCAP Reject component in an END package to the SSF, which initiates backwardcall clearing as described in Section 4.2.



Figure 13 Monitoring for routing failure

DMS SSP

ConnectBCSM

SSF FSM

state fMonitoring

SCP


IFAM

REL/CNA/CONG/TCONG

Complete replacementrouting address orreplacement prefix

Call routed onwardusing informationprovided in Connect

Originatingside

Terminatingside

RequestReportBCSMEvent

Arms DP-4(Route_Select_Failure)

as an EDP-R

(DP-4 monitoring begins)

detectedDP-4

Possible Reason values:2 Network termination7 ISDN congestion15 Telephony congestion


EventReportBCSM

Reports detection of DP-4TSSFstarted

Originating side of call remains suspendedpending further instructions from SCF:• Speech path open after user interaction• Awaiting IAM response otherwise

Routing failure detectedwithin the SSP

REL

CTF

ANM

If notalready

sent

Subsequent actiondetermined by SCF




If the SSF or SRF detects an error in the TCAP package conveying an operation, itsends a TCAP Reject component to the SCF in a CONTINUE package. If the SCFdecides to release a call in response to an error reported by the SSF/SRF, the ETSIISUP interaction is as described in Section 4.2.


ETSI ISUP errors are handled by standard call processing mechanisms. There is nospecific INAP interaction. Call clearing by the caller at any point causes the SSF tosend TCAP ABORT to the SCF (provided there has been some previous responsefrom the SCF).

NIS 94-80nn World Trade IN Section 5:PRE 0.2 (draft) Release 4 ETSI ISUP / INAP Interworking Service Filtering


5 Service Filtering

This section describes service filtering. It deals with:

• Activation of service filtering

• Call processing during service filtering

• Termination of service filtering

• Error handling

5.1 Activation of Service Filtering

Service filtering is activated by means of an ActivateServiceFiltering operation.Table 3 describes the parameters of ActivateServiceFiltering.

Note: An ASF operation is also used to change filtering parameters specified in aprevious ASF operation.

There is no direct ETSI ISUP interaction with the ActivateServiceFilteringoperation, but after the SSF receives it there will be ETSI ISUP/INAP interactionfor all calls that meet the trigger criteria, as described in Section 5.2.

Section 5: World Trade IN NIS 94-80nnService Filtering Release 4 ETSI ISUP / INAP Interworking PRE 0.2 (draft)


Table 3 ActivateServiceFiltering parameters

ASF Parameter: Specifies:

filteredCallTreatment • The charging to be applied for service filtering

• The announcement or tone to be played to callers

• The number of counters to be used (maximum20, default 1)

• The REL Cause value to use when theannouncement has been played (default=31,normal unspecified)

filteringCharacteristics Whether counts should be reported at fixed intervals,or whenever a specified number of filtered calls havebeen received.

Note: Reporting of interim results can be suppressedby setting the interval value to -1, or the number ofcalls to 0.

filteringTimeout When filtering should end (at which point a finalcount should be provided), either after a specifiedinterval or at a specified time

filteringCriteria The criteria to be used to filter calls, either:

• A service key• A combination of a service key and a complete

called party number

If multiple counters are to be used (e.g. for TeleVot-ing), the criteria must include a complete calledparty number. This must be the lowest number in acontinuous range of numbers, the incoming calls towhich are to be separately logged. For example, if20 counters are to be used and the specified calledparty number is 0800-654321, calls to numbers inthe range 654321 to 654340 will be separatelycounted



5.2 Call Processing during Service Filtering

5.2.1 Overview

The ETSI ISUP/INAP interaction for SSP service filtering is as shown in Figure14.

Two types of processing are initiated for each call that matches the trigger criteria:

• ETSI ISUP call processing, which typically involves connecting the caller toa standard announcement and then initiating normal backward call clearing.

Note: The playing of an announcement to the caller is handled entirelywithin the DMS SSP. There is no SCF involvement (i.e. no CTR/PAoperations are used).

• INAP processing, which involves incrementing the appropriate counter andmay also involve reporting counter values to the SCF in an SFR operation.

Note: Non-filtered IN calls (i.e. calls that trigger IN interaction but which do notmatch filtering criteria) are handled as described in Section 2.

5.2.2 Sequence of Events for a Filtered IN Call

Up to the point at which triggering occurs and the call is recognised as an IN callthat should be filtered, the detailed sequence of events is as described for normaltriggering in Section 2.2.2. This section should be regarded as a replacement forlist item 8 in the sequence of events description (beginning “The SSF initiates INcall processing”).

Note: A filtered call may trigger at TDP-2 or TDP-3.

The sequence of events for a filtered IN call is:

1. The appropriate counter is incremented.

2. The SSF checks to see whether it should send its final report and terminatefiltering. The filteringTimeOut parameter of ASF specifies one of thefollowing:

- The duration for which service filtering is to be active

- The time at which service filtering is to be terminated



Figure 14 Service filtering

DMS SSP

ASF

BCSM SSF FSM

state bTrigger

processing

SCP

state aIdle

ACM

ANM

Service filtering instructions

Originatingexchange

Announcement

REL

RLC

IAM

SFRFinal service filtering results

SSME FSMgoes from

IdleManagement toNon Call Associated

Treatment

to IdleManagement

Non Call AssociatedTreatment

SSME FSMgoes from

TDP armed

Incrementcounter

Sendinterimreport?

Y

N

Sendfinal

report?

Y

N

Back toIdle toawaitnext call

Back to Idle(filtering ends)

No furtherIN interactionfor this call

Normal

clearingbackward

InitialDP

SFRInterim service filtering results

InitialDP

SeeNote

SeeNote

Note: Treatment of non-filteredcall depends entirely on the SCP.Main options are:• User interaction (PA/P&C)• Onward routing (Connect)• Clearing (ReleaseCall)

SSF tells CCFto terminatefiltered callwith appropriatetreatment

The call isrecognised as one

that requires filtering

ASF

SFR

InitialDP

Sent only if thecall triggers

InitialDP

Further ASFs may bereceived which modify theexisting filtering criteria, in

which case the currentcounter values are reported

to the SCP

Unless reporting ofinterim results hasbeen suppressed



If the duration timer has expired, or if the stop time has been reached, theSSF will:

- Suspend O_BCSM call processing for the call

- Send an InitialDP to the SCF, enabling it to handle the callappropriately

- Send an SFR to the SCF, reporting the final counter values

- Terminate service filtering

3. The SSF checks to see whether it should send an interim report. ThefilteringCharacteristics parameter of ASF specifies one of the following:

- The interval after which an interim report is to be sent

- The number of filtered IN calls after which an interim report is to besent

If the interval timer has expired, or if the specified number of filtered IN callshas been received since starting filtering or since sending the last interimreport, the SSF will:

- Suspend O_BCSM call processing for the call

- Send an InitialDP to the SCF, enabling it to handle the callappropriately

- Send an SFR to the SCF, reporting the latest counter values

- Restart the interval timer or reset the call counter and resume filtering

Note: If the specified interval value is -1, or if the specified number of calls is0, the reporting of interim results is suppressed.

4. If there is no need to send a report, the SSF instructs the CCF to terminateO_BCSM call processing for the call that triggered, providing a Cause valuethat ensures the caller will receive appropriate treatment (this is provided bythe releaseCause parameter of ASF).



5.3 Termination of Service Filtering

The SSF terminates service filtering in accordance with the value of thefilteringTimeout parameter in the original ActivateServiceFiltering operation. Thisspecifies one of two criteria to be used:

• durationService filtering stops after a specified number of seconds.

• stopTimeService filtering stops at a specified date and time.

Note: The SCF can terminate service filtering that is already in progress bysending another ASF with the same filteringCriteria parameter, and specifying oneof the following:

• A duration of 0

• A stopTime that is earlier than the current date and time

The SSF checks the termination criterion after incrementing the appropriatecounter when a call triggers service filtering. If this indicates that filtering shouldstop, the SSF sends an InitialDP to the SCF followed by a final SFR.

5.4 Error Handling



The only operations sent by the SSF to the SCF while service filtering is active areInitialDP and ServiceFilteringResponse.

Errors associated with InitialDP are reported as described in Section 3.5.1.1. Anerror in InitialDP will cause backward call clearing, as described in Section 4.2.

There are no INAP errors associated with SFR, so none are reported by the SCF.There is therefore no ETSI ISUP interaction.




Errors are detected and reported as described in Section 3.5.1.2. If the SCF decidesto release a call in response to an error reported by the SSF or SRF, the ETSI ISUPinteraction is as described in Section 4.2.

5.4.2 Timer Expiry

TSSF is not used, as the SSF is not waiting at any point for a response from theSCF.


TCAP component and package errors are detected and reported as described inSection 3.5.3.


ETSI ISUP errors detected during service filtering are handled entirely by ETSIISUP call processing mechanisms, and involve no ETSI ISUP/INAP interaction.From an IN perspective, an incoming ETSI ISUP call either triggers servicefiltering or does not.



NIS 94-80nn World Trade IN Appendix APRE 0.2 (draft) Release 4 ETSI ISUP / INAP Interworking Forward Setup


A Forward Setup (IAM to InitialDP)

A.1 Mappings between Parameters

InitialDP is generated from information received in the incoming ETSI ISUP IAM.Table 4 summarises how IAM parameters are mapped onto InitialDP parameters.

A.2 Deriving INAP Parameter Values from ETSIISUP

This section discusses parameter value mapping, i.e. how each InitialDP parameteris assigned a specific value. Parameters in InitialDP may be:

• Derived from an ETSI ISUP parameter with a similar function

• Supplied by the DMS SSP itself

a. CPC is always provided.b. Calling Party Number is provided only if requested (by datafill against the service key).

Table 4 ETSI ISUP IAM --> INAP InitialDP parameter mapping

ETSI ISUP IAMparameter

(Opt /Mand)

INAP InitialDPparameter

Opt /Mand

Value mappingdefined in

<no equivalent> ServiceKey M Section A.2.1

<no equivalent> EventTypeBCSM M Section A.2.2

Calling Party’s Category M CallingPartysCategorya O Section A.2.3

Called Party Number M CalledPartyNumber O Section A.2.4

Calling Party Number O CallingPartyNumberb O Section A.2.5

Transmission MediumRequirement

M BearerCapability O Section A.2.6

<no equivalent> Extensions O Section A.2.7

Appendix A World Trade IN NIS 94-80nnForward Setup Release 4 ETSI ISUP / INAP Interworking PRE 0.2 (draft)


A.2.1 ServiceKey

This parameter is mandatory in the InitialDP operation, and is always provided bythe DMS SSP from datafill against the trigger criteria.

A.2.2 EventTypeBCSM

Although this parameter is optional in the InitialDP operation, it is alwaysprovided by the DMS SSP.

The EventTypeBCSM parameter specifies which TDP triggered the IN interactionthat caused this InitialDP operation to be sent. The parameter can have one of thefollowing values:

2 Call triggered at TDP-2 (Collected Info)3 Call triggered at TDP-3 (Analysed Info)

A.2.3 CallingPartysCategory

Although defined as optional in the CS-1R INAP specification, this parameter isalways mapped from the Calling Party’s Category in the IAM message.

The CS-1R INAP specification states that the INAP CallingPartysCategoryparameter has the same format as the ISUP Calling Party’s Category parameter.The value of the INAP parameter is therefore derived directly from its ETSI ISUPequivalent.

All values of the ETSI ISUP Calling Party’s Category parameter are mappedtransparently onto the INAP CallingPartysCategory parameter.

A.2.4 CalledPartyNumber

Although defined as optional in the CS-1R INAP specification, this parameter isalways taken from the Called Party Number parameter in IAM.

The CS-1R INAP specification states that the INAP CalledPartyNumber parameterhas the same format as the ISUP Called Party Number parameter. The values of theINAP parameter elements are therefore derived directly from their ETSI ISUPequivalents.

All values of the ETSI ISUP Called Party Number parameter are mappedtransparently onto the INAP CalledPartyNumber parameter.

NIS 94-80nn World Trade IN Appendix APRE 0.2 (draft) Release 4 ETSI ISUP / INAP Interworking Forward Setup


A.2.5 CallingPartyNumber

Although defined as optional in the CS-1R INAP specification, this parameter isalways taken from the Calling Party Number parameter in IAM.

Note: CallingPartyNumber is only provided in InitialDP if requested by thedatafill against the trigger criteria. If CallingPartyNumber is required in InitialDPbut is not provided in IAM, the call will be failed.

The CS-1R INAP specification states that the INAP CallingPartyNumberparameter has the same format as the ISUP Calling Party Number parameter. Thevalues of the INAP parameter elements are therefore derived directly from theirETSI ISUP equivalents.

All values of the ETSI ISUP Calling Party Number parameter are mappedtransparently onto the INAP CallingPartyNumber parameter.

A.2.6 BearerCapability

The InitialDP operation sent by the SSF can include an optional bearerCapabilityparameter. The Transmission Medium Requirement (TMR) sub-parameter of thebearerCapability parameter indicates the bearer capability required by the user (e.gvoice, digital information, 3.1 kHz audio). The SCF can use this information as oneof the criteria for its routing decision.

The value of the InitialDP TMR sub-parameter is mapped from the TMRparameter in the IAM message. Table 5 shows how values of the ETSI ISUP TMRparameter map onto values of the INAP TMR sub-parameter:

a. Any other value in the TMR field will cause the call to be sent to treatment.b. If the SSP subsequently receives a CTR operation for a call with this bearerCapability, the

call will be failed.

Table 5 Derivation of INAP bearerCapability values

INAP bearerCapability(sub-parameter Transmission

Medium Requirement)

ETSI ISUP Transmission MediumRequirementa

Meaning Value Value Meaning

Speech 00000000 00000000 Speech

64 kbit/s unrestricted 0000001000000010 64 kbit/s unrestrictedb

00000110 64 kbit/s preferred

3.1 kHz audio 00000011 00000011 3.1 kHz audio

Appendix A World Trade IN NIS 94-80nnForward Setup Release 4 ETSI ISUP / INAP Interworking PRE 0.2 (draft)


A.2.7 Extensions

The InitialDP operation sent by the SSF can include an optional Extensionsparameter. The Extensions parameter is used to contain proprietary informationused in the implementation of certain IN services (e.g. Registered Site Access).

See theDMS Implementation of CS-1R INAP (ETSI Core INAP Subset) for moreinformation about the Extensions parameter.

NIS 94-80nn World Trade IN Appendix BPRE 0.2 (draft) Release 4 ETSI ISUP / INAP Interworking Forward Setup


B Forward Setup (Connect to IAM)

This appendix describes the mapping of parameters in an INAP Connect operationonto the corresponding parameters of a forwarded ETSI ISUP IAM message.

B.1 Mappings between Parameters

The onward IAM message from the DMS SSP towards the called party isgenerated from a combination of the following:

• Information received in the incoming ETSI ISUP IAM.

• Information received in the Connect operation from the SCF, which mayoverwrite or modify the information provided in the incoming IAM.

The mapping of parameters is summarised in Table 6 for those IAM parametersthat may be affected by the Connect operation. Parameters not shown are mappedfrom the incoming call setup message in which they were received.

Table 6 Connect -> ETSI ISUP IAM parameter mapping

New or replacementinformation provided in

Connect operation

Information to be modified(originally provided in incomingETSI ISUP call setup messages)

Valuemappingdefined

inINAP Connectparameter

Opt /Mand

ETSI ISUP IAMparameter

Opt /Mand

DestinationRoutingAddress MCalled Party Number M

SectionB.2.1CutAndPaste O

CallingPartysCategory O Calling Party’s Category MSectionB.2.2

Extensions O no ETSI ISUP equivalentSection B.

2.3

Appendix B World Trade IN NIS 94-80nnForward Setup Release 4 ETSI ISUP / INAP Interworking PRE 0.2 (draft)


B.2 Deriving ETSI ISUP Parameter Values fromINAP

B.2.1 DestinationRoutingAddress/CutAndPaste -> Called PartyNumber

Two types of routing information may be provided:

dRA destinationRoutingAddress parameterA destination routing address (consisting of digits for a called party number)

cAP CutAndPaste parameterOptional cut-and-paste instructions on how the original dialled numbershould be manipulated to generate a new called party address.


• The dRA parameter provides a called party number that completely replacesthe Called Party Number in the incoming IAM message. There is no cAPparameter.

Note: If there is no cAP parameter, any digits that arrive after Connect isreceived are ignored.

• The cAP parameter specifies how many digits are to be removed from thefront of the Called Party Number supplied in the incoming IAM message.The deleted digits are replaced by a new prefix supplied in the dRAparameter.

Note: If the SCF supplies a cAP parameter with the value zero, the effect isto append the original Called Party Number to the value of the supplied dRAparameter.

Components of the dRA parameter in Connect are mapped transparently onto thecorresponding components of the Called Party Number parameter of the forwardIAM message, with the following exceptions:

• The value of the Internal Network Number (INN) indicator returned inConnect is ignored. The value received in the incoming IAM message isused.

• The value of the Numbering Plan Inidicator in the forward IAM messagewill be set to ISDN, regardless of the value returned in Connect. If the valuereturned in Connect is not ISDN, a log will be generated.

NIS 94-80nn World Trade IN Appendix BPRE 0.2 (draft) Release 4 ETSI ISUP / INAP Interworking Forward Setup


B.2.2 CallingPartysCategory

This parameter is defined as optional in the CS-1R INAP specification, but theequivalent Calling Party’s Category parameter is mandatory in the ongoing IAM.

The CS-1R INAP specification states that the INAP CallingPartysCategoryparameter has the same format as the ISUP Calling Party’s Category parameter.The value of the ETSI ISUP parameter is therefore derived directly from its INAPequivalent.

If no CallingPartysCategory value is included in the Connect operation, the CallingParty’s Category parameter in the ongoing IAM will be derived from the incomingIAM.

All values of the INAP CallingPartysCategory parameter are mapped transparentlyonto the ETSI ISUP Calling Party’s Category parameter.

B.2.3 Extensions

In some cases the Connect operation returned by the SCF can include an optionalExtensions parameter. The Extensions parameter is used to contain proprietaryinformation used in the implementation of certain IN services (e.g. Registered SiteAccess).

The information in the Extensions parameter is not mapped onto the forwardedIAM. It is used within the DMS SSP to set up translations and billing data.

See theDMS Implementation of CS-1R INAP (ETSI Core INAP Subset) for moreinformation about the Extensions parameter.

Appendix B World Trade IN NIS 94-80nnForward Setup Release 4 ETSI ISUP / INAP Interworking PRE 0.2 (draft)


NIS 94-80nn World Trade IN Appendix CPRE 0.2 (draft) Release 4 ETSI ISUP / INAP Interworking Backward Setup


C Backward Setup (ACM and ANM)

Backward setup messages (ACM and ANM) are sent by the DMS SSP in thefollowing circumstances:

• The DMS SSP can relay ACM and ANM messages from the terminating sideback to the originating side to complete call setup after call processing hasbeen resumed following a Connect. In this case, the parameter settings arenot affected by the IN involvement in call completion; the DMS SSP simplyrelays the received ACM and ANM messages.

• The DMS SSP can send an “early” ACM and ANM to the originating side.This is an ACM or ANM message that is generated by the DMS SSP ratherthan one that is received from the terminating side and relayed to theoriginating side.

Note: If Malicious call trace is in progress, the sending of early ACM/ANMwill break the trace.

During normal call setup, the only parameter that may be included in an ACM toprovide information is Backward Call Indicators. Table 7 shows the default valuesassigned to the Backward Call Indicators parameter of an early ACM messagegenerated by the DMS SSP.

Table 7 Backward Call Indicators values in an early ACM

Bit(s) Purpose Value Meaning

BA Charge Indicator 00 No indication

DCCalled Party’s Status

Indicator00 No indication

FECalled Party’s Category

Indicator00 No indication

HGEnd-to-End Method

Indicator00 No end to end method available

I Interworking Indicator 0 No interworking encountered

JEnd-to-End Information

Indicator0 No end-to-end information available

K ISDN User Part Indicator 1 ISDN ISUP used all the way

Appendix C World Trade IN NIS 94-80nnBackward Setup Release 4 ETSI ISUP / INAP Interworking PRE 0.2 (draft)


L Holding Indicator 0 Holding not required

M ISDN Access Indicator 0 Terminating access non-ISDN

Table 7 Backward Call Indicators values in an early ACM

Bit(s) Purpose Value Meaning

NIS 94-80nn World Trade IN Appendix DPRE 0.2 (draft) Release 4 ETSI ISUP / INAP Interworking External IP


D PRI Interworking for External IPConnection

This appendix describes the parameter mappings [if any] that take place when anSCF establishes or terminates a connection with an external IP.

D.1 Establishing a Connection

When the SCF sends an EstablishTemporaryConnection command to the SSF, theSSF initiates the connection process by sending a PRI SETUP message over anoutgoing PRI trunk. This appendix describes the mapping between the parametersof the INAP ETC operation and the PRI SETUP message.

Note: The only ETSI ISUP interaction during connection to an external IP is thegeneration of early ACM and ANM messages as the connection is established. Thecontents of these early ACM and ANM messages are described in Appendix C.

Table 8 summarises how parameters of the INAP ETC operation received from theSCF are mapped onto parameters of the PRI SETUP message sent to the externalIP:

a. The correlation ID may be supplied as part of assistingSSPIPRoutingAddress, in whichcase it is mapped onto Called Party Number rather than User to User Information.

Table 8 INAP EstablishTemporaryConnection --> PRI SETUP parametermapping

ETC parameter(Opt /Mand)

SETUP parameterOpt /Mand

Value mappingdefined in

assistingSSPIPRoutingAddress

M Called Party Number M Section D.1.1.1

correlationIDa O User to User Information O Section D.1.1.2

Appendix D World Trade IN NIS 94-80nnExternal IP Release 4 ETSI ISUP / INAP Interworking PRE 0.2 (draft)


D.1.1 Deriving PRI Parameter Values from INAP

D.1.1.1 assistingSSPIPRoutingAddress --> Called Party Number

The EstablishTemporaryConnection command sent by the SCP includes theparameter assistingSSPIPRoutingAddress, which gives the network address of anexternal IP.

Note: The assistingSSPIPRoutingAddress parameter may also include acorrelation ID (see Section D.1.1.2 for a description of its use). A network operatorcan choose to supply the correlation ID in this way rather than as a separateparameter in ETC.

assistingSSPIPRoutingAddress has the format of an ISUP Generic Number. Table9 shows how components of the assistingSSPIPRoutingAddress parameter inEstablishTemporaryConnection map onto the corresponding components of theCalled Party Number parameter of the PRI SETUP message.

D.1.1.2 correlationID --> User to User Information

The EstablishTemporaryConnection command sent by the SCP includes theparameter correlationID. This value is forwarded to the external IP in the User toUser Information parameter of the PRI SETUP message. The external IP includesthis value in the AssistRequestInstructions command that it sends to the SCP tocomplete the connection. The purpose of the correlation ID is to allow the SCP toestablish a relationship between two separate transactions (betweeen the SCP andthe SSP, and between the SCP and the external IP).

Note: A network operator can choose to supply a correlation ID as part of theassistingSSPIPRoutingAddress parameter of ETC rather than as a separateparameter. See Section D.1.1.1.

correlationID has the format of an ISUP Generic Digits parameter. Table 9 showshow components of the correlationID parameter in EstablishTemporaryConnectionmap onto the corresponding components of the User to User Informationparameter of the PRI SETUP message.



a. Note that this is a component of the Called Party Subaddress parameter, not the Called Party Numberparameter.

b. Any other value from the SCF will cause an error.c. Nature of Address always maps to subscriber, but the final Type of Number depends on the number of

digits left in the assistingSSPIPRoutingAddress field after the datafilled prefix fence has been applied:<10 digits Subscriber=10 digits National>10 digits International

d. Address Signals may contain up to 30 digits.e. If assistingSSPIPRoutingAddress includes a correlation ID, it is encoded as part of Number Digits. The

nature of the encoding is a matter for agreement between the SCP and external IP providers.

Table 9 Derivation of Called Party Number in the SETUP to external IP

ETC assistingSSPIPRoutingAddress SETUP Called Party Number

Component Meaning Value Value Meaning Component

Number QualifierIndicator

The DMS SSP ignores whatevervalue is sent by the SCP.

This value is not mapped to Called Party Number.

Odd/even indicator

Even no of addresssignals

0 0Even no of addresssignals Odd/even

indicatoraOdd no of addresssignals

1 1Odd no of addresssignals

Nature of addressindicator Unknownb 0000010

001 International

Type of Numberc010 National

100 Subscriber

NumberIncompleteindicator

There is no equivalent parameter in Called PartyNumber. Any value sent by the SCF is ignored.

Numbering planindicator

All other values 0001 ISDN /telephony Numbering planidentificationPrivate 101 1001 Private

Presentationindicator

There is no equivalent parameter in Called PartyNumber. Any value sent by the SCF is ignored.

Screening indicator There is no equivalent parameter in Called PartyNumber. Any value sent by the SCF is ignored.

Address Signalsd

Digit 0 0000 IA5 coding for ANumber Digitse

PRI codes numberdigits in IA5 format,one per octet

Digits 1 to 90001

to1001

IA5 Digit 1 to 9

Code 11 1011 IA5 coding for *

Code 12 1100 IA5 coding for #



D.2 Terminating a Connection

When the SCF sends a DisconnectForwardConnection command to the SSF, theSSF terminates the connection to the external IP by sending a PRI DISCONNECTmessage to the external IP. shows the values of the various components of theCause parameter of this DISCONNECT message:

Note: Since the DFC operation has no parameters, there is no interworkingbetween DFC and the PRI DISCONNECT operation.

a. Any encoding scheme other than BCD even or BCD odd is rejected with the UnexpectedDataValueerror.

b. The Digits field can contain up to 32 digits.

Table 10 Derivation of User to User Information in the SETUP to external IP

ETC correlationID SETUP User to User Information

Component Meaning Value Value Meaning Component

This value is hard-coded by the DMS SSP. It does notcorrespond to any parameter in the ETC operation. 00000000

User-specifiedprotocol

ProtocolDiscriminator

Encoding scheme Value mapped transparentlyaByte 1 of UserInformationType of digits Value mapped transparently

DigitsbThe correlation ID is encoded asspecified by the Encodingscheme/Type of digits parameters

Byte 2 and onwardsof User Information

Table 11 Cause parameter in DISCONNECT message to external IP

Component Value

Coding Standard 00 (CCITT)

Location 0000 (User)

Cause 16 (Normal clearing)



D.3 Interworking Restrictions

An external IP may not be directly connected to the DMS SSP. Although theSETUP message will be sent out over an ETSI PRI trunk, interworking with othersignalling systems may be required to complete the connection.

The degree to which interworking is possible when connecting to an external IPdepends on how the correlation ID for the connection is supplied by the SCF. TheSCF can supply the correlation ID in either of two ways (selectable by the networkoperator):

• As a separate correlationID parameter in the ETC operation

• As a component of the assistingSSPIPRoutingAddress parameter in the ETCoperation

If the correlation ID is supplied as a separate parameter in ETC, it is mapped ontothe User to User Information parameter of the SETUP message, as described inSection D.1.1.2. However, since this parameter may not successfully map ontoparameters in other signalling systems, this may limit the degree of interworkingthat is possible.

If the correlation ID is supplied as part of the routing address, it will be mapped,along with the routing address, onto the Called Party Number parameter of theSETUP message, as described in Section D.1.1.1. The correlation ID will beextracted by the external IP. Since the Called Party Number parameter will alwaysmap successfully to a corresponding parameter in other signalling systems, thismethod of supplying the correlation ID does not restrict interworking in the waythat supplying a separate correlationID parameter does. However, the fact that bothvalues must be encoded in the same parameter means that fewer digits areavailable than if they were encoded separately.



NIS 94-80nn World Trade IN Appendix EPRE 0.2 (draft) Release 4 ETSI ISUP / INAP Interworking Call Clearing Parameters


E Call Clearing Parameters

This appendix describes the parameter mappings that take place between INAPoperations and ETSI ISUP messages when a call is cleared, either by the DMS SSPor by some other party.

E.1 Mapping INAP Cause Values

Figure 15 illustrates the mechanism used by the DMS to map an INAP Cause valueonto a value that is appropriate to the protocol with which it is interworking.

Figure 15 DMS Mechanism for Mapping INAP Cause Values

An INAP Cause value (as defined in Q.763) is mapped by the Release Cause maptable (RLSCMAP) to an internal DMS treatment value. This internal treatmentvalue in turn is mapped by the Treatment map table (TMTMAP) onto aprotocol-specific value to be included in the appropriate backward message.

Note: This mapping is also used in forward call clearing when a passive leg isdisconnected as a result of a DisconnectLeg operation.

Internal DMStreatment value

INAP Cause value (asdefined in Q.763)

Protocol-specificbackward message

or tone

TMTMAP RLSCMAP

BTUP

ETSIISUP

Appendix E World Trade IN NIS 94-80nnCall Clearing Parameters Release 4 ETSI ISUP / INAP Interworking PRE 0.2 (draft)


These DMS tables are datafilled. Consequently, the mapping between INAP Causevalues and specific protocols is not fixed, but can be configured to the requirementsof a particular operator.

E.2 Call Clearing Initiated by DMS SSP

This section describes the circumstances in which the DMS SSP can initiate callclearing.

E.2.1 SCP Sends ReleaseCall

If the SSF receives ReleaseCall from the SCF instead of Connect:

• The DMS SSP sends a REL message to the originating side, with a Causeparameter mapped from the Cause parameter in the ReleaseCall operation.

If the call originates at the DMS SSP (i.e. the DMS SSP is also theoriginating side), the DMS SSP applies a tone rather than sending a RELmessage.

• The originating side (and, if appropriate, the terminating side) acknowledgesreceipt of REL with an RLC message.

E.2.2 SCP Sends DisconnectLeg

If the SSF receives DisconnectLeg from the SCF:

• The DMS SSP sends REL message to the terminating side, with a Reasonparameter mapped from the Cause parameter in the DisconnectLegoperation.

• The terminating side acknowledges receipt of REL with RLC.

E.2.3 Routing Failure Within the DMS SSP

Call routing may fail after Connect due to a failure within the DMS SSP (DP-4,Route_Select_Failure, is armed as an EDP-R):

• Detection of the internal route select failure triggers EDP-4.

Note: Release 4 does not support the detection of external route select failure(i.e. failure at another exchange). However, external events can lead to

NIS 94-80nn World Trade IN Appendix EPRE 0.2 (draft) Release 4 ETSI ISUP / INAP Interworking Call Clearing Parameters


detection of internal route select failure. If the DMS SSP attempts to re-routea call after receiving a REL message from the terminating side, or afterencountering a glare (dual seizure condition), EDP-4 can be hit if noalternate routes have been datafilled, or if none of the datafilled alternateroutes are available.

• The SSF sends an EventReportBCSM operation whoseeventSpecificInformationBCSM parameter contains a failureCause mappedfrom a value generated by the switch, and awaits instructions from the SCF.

• The DMS SSP sends an early ANM to the originating side to prevent the calltiming out while the SSF waits for a response from the SCF. See Table 7 fora description of the parameters of this early ANM.

If the response from the SCF is ReleaseCall, the DMS SSP initiates backward callclearing, as described in Section E.2.1.

E.3 Call Clearing Initiated Elsewhere

The following sections describe the circumstances in which call clearing isinitiated by some other party than the DMS SSP.

E.3.1 Calling Party Disconnects Before Call is Completed

If the calling party disconnects before the call is completed:

• The originating side sends a REL message with Cause value 16 (normalclearing) to the DMS SSP.

• The SSF sends TCAP ABORT to SCF to terminate the dialogue.

• The terminating leg is released if it has been set up.

There is no further INAP messaging.

E.3.2 Call Fails to Complete After Connect

If the call fails to complete for ETSI ISUP reasons after Connect:

• The DMS SSP receives a REL message from the terminating side with anappropriate Cause value, and acknowledges by sending an RLC message tothe terminating side.

Appendix E World Trade IN NIS 94-80nnCall Clearing Parameters Release 4 ETSI ISUP / INAP Interworking PRE 0.2 (draft)


• The DMS SSP initiates backward clearing by relaying the REL with itsCause value to the originating side.

There is no further INAP messaging.

Technology

Etsi isup inap_iw_book