Conceptio › Archive › ECMA International

ECMA Internationalopen access

ECMA-202 — Private Integrated Services Network (PISN) - Specification, functional model and information flows - Call intrusion supplementary service (CISD) (June 1997)

ECMA International · ECMA International

ECMA International · Standards · License: Open Access

ecma ecmainternational flows information integrated intrusion model network

ecma, standard, ecma international, specification, ecma-202, ecma 202, 202, private, integrated, services, network, pisn, functional, model, and, information, flows, call, intrusion, supplementary, service, cisd

Standard ECMA-202 2nd E dition - J une 1997

Standardizing

Information

and

Communication

Systems

Private Integrated Services Network (PISN) Specification, Functional Model and Information Flows Call Intrusion Supplementary Service

P h o n e : + 4 1 2 2 8 4 9 . 6 0 . 0 0 - F a x : + 4 1 2 2 8 4 9 . 6 0 . 0 1 - U R L : h t t p : / / www. e c m a . c h - I n t e r n e t : h e l p d e s k @ e c m a . c h

Standard ECMA-202 2nd E dition - J une 1997

Standardizing

Information

and

Communication

Systems

Private Integrated Services Network (PISN) Specification, Functional Model and Information Flows Call Intrusion Supplementary Service (CISD)

P h o n e : + 4 1 2 2 8 4 9 . 6 0 . 0 0 - F a x : + 4 1 2 2 8 4 9 . 6 0 . 0 1 - U R L : h t t p : / / www. e c m a . c h - I n t e r n e t : h e l p d e s k @ e c m a . c h IW E-202-ii.doc

18-08-97 16,57

Brief History

This Standard is one of a series of ECMA Standards defining services and signalling protocols applicable to Private Integrated Services Networks (PISNs). The series uses ISDN concepts as developed by ITU-T and conforms to the framework of International Standards for Open Systems Interconnection as defined by ISO/IEC. It has been produced under ITSTC work item M-IT-05 2.2 and under ETSI work item DE/ECMA-00010. This particular Standard specifies the Call Intrusion (CI) supplementary service. This Standard is based upon the practical experience of ECMA member companies and the results of their active and continuous participation in the work of ISO/IEC JTC1, ITU-T, ETSI and other international and national standardization bodies. It represents a pragmatic and widely based consensus. Compared to the 1st Edition of Standard ECMA-202 (published by ECMA in December 1993), this 2nd Edition incorporates changes in order to achieve complete alignment with International Standard ISO/IEC 14845:1996(E) published by ISO/IEC in September 1996.

Adopted as 2nd Edition of Standard ECMA-202 by the General Assembly of June 1997.

- i -

Table of contents 1 Scope

2 Conformance

3 References (normative)

4 Definitions

4.1 External definitions

4.2 Other definitions

4.2.1 Busy

4.2.2 Conference type connection

4.2.3 Consultation

4.2.4 Consultation timer

4.2.5 Established call

4.2.6 Forced release

4.2.7 Immediate invocation

4.2.8 Impending intrusion state

4.2.9 Impending intrusion warning notification

4.2.10 Implementation option

4.2.11 Intruding call

4.2.12 Intrusion state

4.2.13 Intruding call connected notification

4.2.14 Isolation

4.2.15 Path retention

4.2.16 Aerved user

4.2.17 Time to intrusion

4.2.18 User B

4.2.19 User C

4.2.20 Wait on busy state

5 Acronyms

6 SS-CI stage 1 specification

6.1 Description

6.1.1 General description

6.1.2 Qualifications on applicability to telecommunication services

6.2 Procedures

6.2.1 Provision/withdrawal

6.2.2 Normal procedures

6.2.3 Exceptional procedures

6.3 Interactions with other supplementary services and ANFs

6.3.1 Calling Line Identification Presentation (SS-CLIP)

6.3.2 Connected Line Identification Presentation (SS-COLP)

- ii -

6.3.3 Calling/Connected Line Identification Restriction (SS-CLIR)

6.3.4 Calling Name Identification Presentation (SS-CNIP)

6.3.5 Connected Name Identification Presentation (SS-CONP)

6.3.6 Calling/Connected Name Identification Restriction (SS-CNIR)

6.3.7 Completion of Calls to Busy Subscriber (SS-CCBS)

6.3.8 Completion of Calls on No Reply (SS-CCNR)

6.3.9 Call Transfer (SS-CT)

6.3.10 Call Forwarding Unconditional (SS-CFU)

6.3.11 Call Forwarding Busy (SS-CFB)

6.3.12 Call Forwarding No Reply (SS-CFNR)

6.3.13 Call Deflection (SS-CD)

6.3.14 Path Replacement (ANF-PR)

6.3.15 Do Not Disturb (DND)

6.3.16 Do Not Disturb Override (DNDO)

6.3.17 Call Offer (CO)

6.4 Interworking considerations

6.5 Overall SDL

7 SS-CI stage 2 specification

7.1 Functional model

7.1.1 Functional model description

7.1.2 Description of functional entities

7.1.3 Relationship of functional model to basic call functional model

7.2 Information flows

7.2.1 Definition of information flows

7.2.2 Relationship of information flows to basic call information flows

7.2.3 Examples of information flow sequences

7.3 Functional entity actions

7.3.1 Functional entity actions of FE1

7.3.2 Functional entity actions of FE2

7.3.3 Functional entity actions of FE3

7.3.4 Functional entity actions of FE4

7.3.5 Functional entity actions of FE5

7.4 Functional entity behaviour

7.4.1 Behaviour of FE1

7.4.2 Behaviour of FE2

7.4.3 Behaviour of FE3

7.4.4 Behaviour of FE4

7.4.5 Behaviour of FE5

7.5 Allocation of functional entities to physical equipment

7.6 Interworking considerations

Scope This Standard specifies the Call Intrusion supplementary service (SS-CI), which is applicable to various basic services supported by Private Integrated Services Networks (PISN). Basic services are specified in ECMA-142. Call Intrusion (SS-CI) is a supplementary service which, on request from the served user, enables the served user to establish communication with a busy called user (user B) by breaking into an established call between user B and a third user (user C). Supplementary service specifications are produced in three stages, according to the method described in ETS 300 387. This Standard contains the stage 1 and stage 2 specifications of SS-CI. The stage 1 specification (clause 6) specifies the supplementary service as seen by users of PISNs. The stage 2 specification (clause 7) identifies the functional entities involved in the supplementary service and the information flows between them. NOTE For this Standard, stage 2 does not consider the split of functionality between a functional terminal at user B and the local PINX. Terminal functions and local PINX functions at user B are included in the same Functional Entity.

Conformance In order to conform to this Standard, a stage 3 standard shall specify signalling protocols and equipment behaviour that are capable of being used in a PISN which supports the supplementary service specified in this Standard. This means that, to claim conformance, a stage 3 standard is required to be adequate for the support of those aspects of clause 6 (stage 1) and clause 7 (stage 2) which are relevant to the interface or equipment to which the stage 3 standard applies.

References (normative) The following standards contain provisions which, through reference in this text, constitute provisions of this Standard. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. In the case of references to ECMA Standards that are aligned with ISO/IEC International Standards, the number of the appropriate ISO/IEC International Standard is given in brackets after the ECMA reference. ECMA-142

Private Integrated Services Network - Circuit-mode 64 kbit/s Bearer Services - Service Description, Functional Capabilities and Information Flows (International Standard ISO/IEC 11574)

ECMA-148

Private Integrated Services Network - Specification, Functional Model and Information Flows Identification Supplementary Services (International Standard ISO/IEC 14136)

ECMA-163

Private Integrated Services Network - Specification, Functional Model and Information Flows Name Identification Supplementary Services (International Standard ISO/IEC 13864)

ECMA-173

Private Integrated Services Network - Specification, Functional Model and Information Flows Call Diversion Supplementary Services (International Standard ISO/IEC 13872)

ECMA-175

Private Integrated Services Network - Specification, Functional Model and Information Flows Path Replacement Additional Network Feature (International Standard ISO/IEC 13863)

ECMA-177

Private Integrated Services Network - Specification, Functional Model and Information Flows Call Transfer Supplementary Service (International Standard ISO/IEC 13865)

ECMA-185

Private Integrated Services Network - Specification, Functional Model and Information Flows Call Completion Supplementary Services (International Standard ISO/IEC 13866)

ECMA-191

Private Integrated Services Network - Specification, Functional Model and Information Flows Call Offer Supplementary Service (International Standard ISO/IEC 14841)

ECMA-193

Private Integrated Services Network - Specification, Functional Model and Information Flows Do Not Disturb and Do Not Disturb Override Supplementary Services (International Standard ISO/IEC 14842)

- 2 -

ISO/IEC 11571

Information technology - Telecommunications and information exchange between systems Numbering and sub-addressing in private integrated services networks

ISO/IEC 11579-1

Information technology - Telecommunications and information exchange between systems Private Integrated Services Network - Part 1: Reference configuration for PISN Exchanges (PINX)

ETS 300 387

Private Telecommunication Network (PTN); Method for the specification of basic and supplementary services (1994)

ITU-T Rec. I.112

Vocabulary of terms for ISDNs (1993)

ITU-T Rec. I.210

Principles of telecommunication services supported by an ISDN and the means to describe them (1993)

ITU-T Rec. I.221

Common specific characteristics of services (1993)

ITU-T Rec. Z.100

Specification and description language (1993)

Definitions For the purposes of this Standard, the following definitions apply.

4.1

External definitions This Standard uses the following terms defined in other documents: − Basic service

(ITU-T Rec. I.210)

− Calling Party Name

(ECMA-163)

− Connection

(ITU-T Rec. I.112)

− Integrated Services Digital Network

(ITU-T Rec. I.112)

− Name

(ECMA-163)

− Network Determined User Busy

(ITU-T Rec. I.221)

− Number

(ISO/IEC 11571)

− Private Integrated Services Network (PISN)

(ISO/IEC 11579-1)

− Private Integrated Services Network Exchange (PINX)

(ISO/IEC 11579-1)

− Service

(ITU-T Rec. I.112)

− Signalling

(ITU-T Rec. I.112)

− Subaddress

(ISO/IEC 11571)

− Supplementary Service

(ITU-T Rec. I.210)

− User

(ECMA-142)

− User Determined User Busy

(ITU-T Rec. I.221)

This Standard refers to the following basic call functional entity (FEs) defined in ECMA-142: − Call Control (CC) − Call Control Agent (CCA) This Standard refers to the following basic call inter-FE relationships defined in ECMA-142: − r1 − r2 − r3

- 3 -

This Standard refers to the following basic call information flows defined in ECMA-142: − Disconnect request/indication − Release request/indication − Release response/confirmation − Setup request/indication − Setup response/confirmation. This Standard refers to the following basic call information flow service elements defined in ECMA-142: − Destination Number − Connection type. This Standard refers to the following information flow elements defined in ECMA-148: − Originating number − Originating subaddress.

4.2 4.2.1

Other definitions Busy A property of a user for whom either a Network Determined User Busy or User Determined User Busy condition exists.

4.2.2

Conference type connection A connection between the served user, user B and user C, where all users have user information connection with each other.

4.2.3

Consultation Invocation of SS-CI after the calling user has been informed that a call has failed because of busy at the destination.

4.2.4

Consultation timer A timer governing the time in which the calling user is allowed to request invocation of SS-CI after being informed that a call has failed because of busy at the destination. The duration of the timer is an implementation option.

4.2.5

Established call The active call that is selected for intruding on.

4.2.6

Forced release The release of the established call on request from the served user during the intrusion state.

4.2.7

Immediate invocation Invocation of SS-CI as part of the initial call set up.

4.2.8

Impending intrusion state The condition of an established call and an intruding call after provision of an impending intrusion warning notification and before establishment of communication between the served user and user B.

4.2.9

Impending intrusion warning notification A notification provided before communication is established between the served user and user B.

4.2.10

Implementation option An option for the implementor of the service to include or not to include in the service providing system.

4.2.11

Intruding call A call in which the served user requests SS-CI.

- 4 -

4.2.12

Intrusion state The condition of an established call after establishment of communication between the served user and user B and prior to termination of SS-CI or invocation of wait on busy.

4.2.13

Intruding call connected notification A notification provided on establishment of communication between the served user and user B.

4.2.14

Isolation The breaking of the user information connection to and from user C during the intrusion state.

4.2.15

Path retention The retaining of the network connection between the originating CC and the destination CC so that a supplementary service (such as SS-CI) can be invoked without establishing a new connection.

4.2.16

Served user The user who requests SS-CI.

4.2.17

Time to intrusion The duration of the impending intrusion state.

4.2.18

User B The wanted user that is subject to the call intrusion.

4.2.19

User C The other user in the established call.

4.2.20

Wait on busy state A state that can be entered from the intrusion state and in which the intruding call is disconnected from user B and is waiting for user B to answer the call.

Acronyms ANF

Additional Network Feature

Call Control (functional entity)

CCA

Call Control Agent (functional entity)

CCBS

Call Completion to Busy Subscriber

CCNR

Call Completion No Reply

Call Deflection

CFB

Call Forwarding Busy

CFNR

Call Forwarding No Reply

CFU

Call Forwarding Unconditional

Call Intrusion

CICL

Call Intrusion Capability Level

CIPL

Call Intrusion Protection Level

CLIP

Calling Line Identification Presentation

CLIR

Calling/Connected Line Identification Restriction

CNIP

Calling Name Identification Presentation

CNIR

Calling/Connected Name Identification Restriction

Call Offer

COLP

Connected Line Identification Presentation

- 5 -

CONP

Connected Name Identification Presentation

Call Transfer

DND

Do Not Disturb

DNDO

Do Not Disturb Override

Functional Entity

ISDN

Integrated Services Digital Network

NDUB

Network Determined User Busy

PINX

Private Integrated Services Network Exchange

PISN

Private Integrated Services Network

SDL

Specification and Description Language

Supplementary Service

Terminal Equipment

UDUB

User Determined User Busy

WOB

Wait On Busy

SS-CI stage 1 specification

6.1 6.1.1

Description General description Call Intrusion (SS-CI) is a supplementary service which, on request from the served user, enables the served user to establish communication with a busy called user (user B) by breaking into an established call between user B and a third user (user C). On successful intrusion, user C is either connected in a conference type connection with the served user and user B or disconnected from user B (isolated). An intrusion request is only accepted if the served user has a higher Call Intrusion Capability Level (CICL) than the Call Intrusion Protection Level (CIPL) of both user B and user C. There are three implementation options that provide the served user with additional capabilities following successful intrusion: • Forced release, allowing the served user to release the established call; • Isolation, allowing the served user, if a conference type connection has been established, to isolate user C; • Wait on busy, allowing the served user to cause a transition from the intrusion state to the wait on busy state.

6.1.2

Qualifications on applicability to telecommunication services SS-CI is applicable to all basic services defined in ECMA-142.

6.2 6.2.1

Procedures Provision/withdrawal SS-CI shall be provided or withdrawn after pre-arrangement with the service provider. SS-CI shall be provided on a per PISN number basis. For each PISN number, the supplementary service may be provided for those basic services for which it is considered meaningful (see 6.1.2) provided at that PISN number or for only some of these basic services provided at that PISN number. A Call Intrusion Capability Level (CICL) shall be allocated to the served user. Call Intrusion Protection Levels (CIPLs) shall be allocated to potential individual users B and C within the PISN and to gateways to other networks (for use on behalf of users outside the PISN). The procedure by which CICL and CIPL are allocated is outside the scope of this Standard. CICL shall have a value in the range 1 (lowest capability) to 3 (highest capability). At least one of the CICL values shall be offered.

- 6 -

CIPL shall have a value in the range 0 (no protection) to 3 (total protection). CIPL values 0 and 3 shall be offered, and values 1 and 2 may, as an implementation option, be offered. NOTE It is not precluded that CIPL values can be variable, e.g. a user may have the possibility to change the CIPL value with a user procedure. CIPL values assigned to gateways may also be variable, e.g. depending on whether the gateway is used for an incoming or outgoing call to the PISN. The details of such capabilities are outside the scope of this Standard. At least one of the methods of invoking SS-CI (see 6.2.2.2.1) shall be supported. If both methods given in 6.2.2.2.1 are supported, then a user may be provided with one or both methods. A number of implementation options concern features available to the served user during call intrusion. The served user may, at time of provision of SS-CI, be given the choice of being provided with some, all or none of these or the options may be generally available. These implementation options are: forced release, isolation, and wait on busy. When these options are selectable on a per served user basis, they may be selectable separately for each basic service for which SS-CI is provided, or selectable only for all basic services for which SS-CI is provided. 6.2.2

Normal procedures

6.2.2.1

Activation/deactivation/registration/interrogation SS-CI shall be activated by the service provider upon provision, and deactivated upon withdrawal. Registration and interrogation shall not apply.

6.2.2.2 6.2.2.2.1

Invocation and operation Methods of invoking SS-CI There are two different ways to invoke SS-CI. A PISN shall offer one or both of these ways. These ways are: i) Consultation: the served user, on being informed that a call has failed because of busy at the destination, shall be able, within a defined period (consultation timer), to request SS-CI. ii) Immediate invocation: the served user shall be able to request SS-CI as part of the initial call set up.

6.2.2.2.2

Verification and selection of compatible call If the consultation method is provided to the served user, the following procedure shall apply. If a call fails due to busy at the called user B and the PISN is not aware that intrusion is not allowed (e.g. because of insufficient CICL), the PISN shall notify the served user that the call has failed because of busy at the called user B and that intrusion may be possible. The served user may then request SS-CI. If the immediate invocation method is provided to the served user, the served user may request SS-CI with the initial call set up. For both invocation alternatives the following shall apply. Upon receiving an intrusion invocation request from the served user, the PISN shall check that the user B's number used by the served user, when requesting the service, is also a number involved in a compatible call in the active state. A called user's subaddress supplied by the served user shall not be taken into account when selecting a call to intrude on. Further, the PISN checks that the CIPL values of the users in the active call are lower than the CICL value of the served user. If user B's CIPL value is lower than the CICL value and user B has several compatible calls in the active state, the CIPL values of the other users in the calls shall be checked, in any order, until a CIPL value lower than the CICL value is found. A call that passes these checks shall be selected as the established call. When the established call has been selected, the users in the established call may as an option be provided with an Impending intrusion warning notification and a short delay (not exceeding 10s) before the connection between the served user and user B is formed. If this notification is provided, it shall be sent to both users in the established call and optionally to the served user and the impending intrusion state shall be entered.

- 7 -

NOTE The Impending intrusion warning notification can be accompanied by an in-band tone or announcement to user B and user C. An in-band tone or announcement can be given to the served user. If no Impending intrusion warning notification is provided, the procedures of 6.2.2.2.4 for setting up the connection between the served user and user B shall apply immediately. 6.2.2.2.3 6.2.2.2.3.1

Actions during impending intrusion state Impending intrusion state ends A time period, time to intrusion (1-10 seconds, implementation option), after the Impending intrusion warning notification has been provided the impending intrusion state shall be terminated and the procedures of 6.2.2.2.4 for setting up the connection between the served user and user B shall apply.

6.2.2.2.3.2

Release of intruding call If the served user releases the intruding call during the impending intrusion state, user B and user C shall each be notified that intrusion has terminated. SS-CI shall be terminated.

6.2.2.2.3.3

Release of established call If user B or user C releases the established call, the served user shall be notified that intrusion is no longer applicable. SS-CI shall be terminated and the network shall attempt to present the call from the served user to user B and continue in accordance with basic call procedure.

6.2.2.2.4

Setting up the connection between served user, user B and user C There are two different ways (implementation options) for the served user to be connected to user B. Either the network shall form a conference type connection between user B, user C and the served user, or the network shall isolate user C and connect the served user only to user B. In either case, when the connection has been established, the intrusion state shall be entered. If the first option is implemented, the users in the established call shall be provided with an Intruding call connected notification when the served user is connected. The served user shall receive confirmation that the intrusion request has been accepted and that a conference type connection has been formed. NOTE The three users can also receive a superimposed in-band indication (e.g. a repeated tone) while the conference type connection exists. If the latter option is implemented, user C shall be given a notification that isolation has occurred and user B shall be informed that user C has been isolated and that an intrusion has occurred. The served user shall receive confirmation that the intrusion request has been accepted and that isolation has occurred. The served user and user B shall be connected and no conference type connection shall be formed. The established call shall remain in progress but with the user information connection to user C broken. NOTE User C can also receive an in-band tone or announcement while isolated. NOTE The option selected can depend on the particular basic service being used.

6.2.2.2.5 6.2.2.2.5.1

Actions during intrusion state Release of intruding call If the served user releases the intruding call, the established call shall revert to the state that existed before the intrusion state, and the intrusion state shall be terminated. User B and user C shall be notified that the intrusion state has been terminated. If user B releases the intruding call, the established call shall revert to the state that existed before the intrusion state, and the intrusion state shall be terminated. User C shall be notified that the intrusion state has terminated.

- 8 -

6.2.2.2.5.2

Release of the established call If user B or user C releases the established call, the served user shall be notified that call intrusion has terminated. If user C releases the established call, user B shall be notified that intrusion has terminated. The intruding call shall become an ordinary call between user B and the served user.

6.2.2.2.5.3

Forced release As an implementation option the served user may, during the intrusion state, request a forced release of user C. User C may be isolated or in a conference type connection when the request is made. A successful forced release shall be notified to the served user, to user B and to user C. The intruding call shall continue as an ordinary call between the served user and user B, the established call shall be released, and the intrusion state shall be terminated.

6.2.2.2.5.4

Isolation on request from served user If a conference type connection is used, user C may (implementation option) be isolated from the conference type connection on request from the served user. If the request is accepted the served user shall receive confirmation and the established call shall be disconnected from user B, but not released. The served user shall be connected only to user B. The intrusion state shall continue and the ensuing situation shall be identical to the situation where isolation occurred when the intrusion state was entered. User C and user B shall be notified that user C has been isolated.

6.2.2.2.5.5

Transition from intrusion state to wait on busy state As an implementation option it may be possible for the served user to request transition from the intrusion state to the wait on busy state. On acceptance of such a request, the served user shall receive a confirmation, the established call shall revert back to the state that existed before intrusion, user B shall be reconnected to user C if isolated, the intruding call shall be disconnected from user B and the intrusion state shall be terminated. The intruding call shall not be released but shall enter the wait on busy state. User B shall be notified that the intrusion has terminated and wait on busy has been invoked. User C shall be notified that the intrusion has terminated.

6.2.2.2.6

Actions during wait on busy state

6.2.2.2.6.1

Served user releases If the served user releases during the wait on busy state, user B shall be notified and SS-CI terminated.

6.2.2.2.6.2

User B answers the waiting call If user B answers the waiting call, SS-CI shall be terminated, and the served user shall be notified and connected to user B. The call shall become an ordinary call between user B and the served user.

6.2.2.2.6.3

Re-intrusion request When the network receives a request for re-intrusion, the network shall verify the request and select an established call in accordance with 6.2.2.2.2 and set up the connection in accordance with 6.2.2.2.3 (if applicable) and 6.2.2.2.4.

6.2.2.2.6.4

User B becomes not busy If the PISN detects that the necessary resources have become available, it shall transfer an incoming call indication to user B. If user B starts alerting, the served user shall receive an appropriate indication.

6.2.3 6.2.3.1

Exceptional procedures Activation/deactivation/registration/interrogation Not applicable.

6.2.3.2

Invocation and operation If the served user requests invocation of SS-CI as part of the initial call request, and immediate invocation is not provided to the served user, then the request shall be ignored and the call shall proceed as if the request had not been made.

- 9 -

If a SS-CI or re-intrusion request is rejected, the served user shall be informed, and may be given an indication of the reason for the rejection. Possible reasons to reject a SS-CI or re-intrusion request are e.g.: − served user has a lower or equal CICL compared with user B's and/or user C's CIPL value; − user B is busy but not involved in a compatible call in the active state; − temporary lack of resources; − the established call is already being intruded upon; − the established call is intruding on another call. If SS-CI is requested and user B is found to be not busy, the call shall be treated as a normal incoming call to user B. If a forced release, isolate or wait on busy request from the served user is denied by the PISN, the served user shall be notified and may be given an indication for the reason of the denial. The intrusion state shall remain. If an intrusion request from the wait on busy state is rejected, the wait on busy state shall remain. If consultation applies to the call, the call shall be released either if the served user does not request invocation within the defined time period (consultation timer) or if the served user requests invocation within the defined time period (consultation timer) and this request is rejected. Consultation shall not apply if the called user is busy and the PISN is aware that intrusion is not allowed. Basic call procedures shall apply.

6.3

Interactions with other supplementary services and ANFs Interactions with other supplementary services and ANFs for which PISN standards were available at the time of publication of this Standard are specified below.

6.3.1

Calling Line Identification Presentation (SS-CLIP) User B shall, as part of the intruding call, receive the Calling Line Identification of the served user, unless Calling Line Identification Restriction (CLIR) applies and user B has no override capability. No indication of the served user's identity shall be provided to user C.

6.3.2

Connected Line Identification Presentation (SS-COLP) The served user shall receive the Connected Line Identification of user B when the intrusion state is entered, unless CLIR applies. The served user shall not receive the Connected Line Identification of user C.

6.3.3

Calling/Connected Line Identification Restriction (SS-CLIR) When CLIR is invoked at the served user, Calling Line Identification shall not be presented to user B, unless user B has an override capability. When CLIR is invoked at user B, Connected Line Identification shall not be presented to the served user, unless the served user has an override capability.

6.3.4

Calling Name Identification Presentation (SS-CNIP) User B shall, as part of the intruding call, receive the Calling Name Identification of the served user, unless Calling Name Identification Restriction applies and user B has no override capability. No indication of the served user's name shall be provided to user C.

6.3.5

Connected Name Identification Presentation (SS-CONP) The served user shall receive the Connected Name Identification of user B when the intrusion state is entered, unless CNIR applies. The served user shall not receive the Connected Name Identification of user C.

6.3.6

Calling/Connected Name Identification Restriction (SS-CNIR) When CNIR is invoked at user B, Connected Name Identification shall not be presented to the served user, unless the served user has an override capability.

- 10 -

When CNIR is invoked at the served user, Calling Name Identification shall not be presented to user B, unless user B has an override capability. 6.3.7

Completion of Calls to Busy Subscriber (SS-CCBS) SS-CCBS requested by the served user while in the intrusion state shall be rejected. While in the wait on busy state, the served user may be able to invoke SS-CCBS. While in the wait on busy state the intruding call shall have priority over any SS-CCBS request against that same user B, when resources at that user B become available. NOTE If a call fails because of busy at the destination, either SS-CI or SS-CCBS or both can be applied.

6.3.8

Completion of Calls on No Reply (SS-CCNR) No interaction.

6.3.9

Call Transfer (SS-CT) The served user shall not be able to invoke SS-CT during the impending intrusion state or the intrusion state. It shall be possible for a served user, during the wait on busy state, to invoke call transfer for transferring a third user to user B provided that the call between the served user and the third user is in the active state. However, it shall not be possible to transfer two calls both of which are in the wait on busy state. Transfer during the wait on busy state shall operate in a similar manner to call transfer during the alerting state, except that the wait on busy state shall continue. The third user may be notified that the call is waiting for a busy called user. If user B subsequently enters an alerting phase and a notification that the call is waiting at a busy called user has been given to the third user, the third user shall be notified that user B is alerting. If user B subsequently answers the call and a notification that the call is waiting at a busy called user has been given to the third user, the third user shall be notified that user B has answered. During the impending intrusion state or the intrusion state, user B shall not be able to transfer an established or intruding call. During the wait on busy state, user B shall not be able to transfer an intruding call. A user C may be able to transfer an established call in the intrusion state and the impending intrusion state. If transfer occurs, the user that becomes connected to user B shall become the new user C. If transfer occurs during the impending intrusion state, the new user C shall receive an impending intrusion warning notification. If transfer occurs during intrusion state, the new user C shall receive an intruding call connected notification or a notification that isolation has occurred, as appropriate.

6.3.10

Call Forwarding Unconditional (SS-CFU) SS-CI, if invoked, shall be applied to a busy user that has been forwarded to as a result of one or more invocations of SS-CFU, provided neither SS-CFNR nor Call Deflection from Alert has taken place.

6.3.11

Call Forwarding Busy (SS-CFB) If SS-CI is requested as part of the initial call set up, and if the called user is busy and has SS-CFB active, the call shall be forwarded. If the call is forwarded to a user who is also busy, SS-CI shall be applied to the forwarded to user. If the call undergoes more than one diversion, at least one of which is SS-CFB, but none of which is either SS-CFNR or Call Deflection from Alert, then SS-CI shall be applied to the final diverted-to user if that user is busy. If the calling user is informed that a call has failed because of busy at the destination, and if SS-CI is subsequently invoked, SS-CI shall be applied to the SS-CFB forwarding user or to the SS-CFB forwarded to user. If the call has undergone more than one diversion, at least one of which is SS-CFB, but none of which is either SS-CFNR or Call Deflection from Alert, then SS-CI shall be applied either to the first SS-CFB forwarding user or to the final diverted-to user. Choice between the two is an implementation option. An implementation may permit the calling user to make the choice.

6.3.12

Call Forwarding No Reply (SS-CFNR) SS-CI, if invoked, shall not be applied to a busy user arrived at as a result of one or more diversions, at least one of which is SS-CFNR. The procedures of SS-CFNR shall apply. A wait on busy call that is alerting user B shall not be subject to SS-CFNR.

- 11 -

6.3.13

Call Deflection (SS-CD) SS-CI, if invoked, shall operate on a busy user that has been diverted to as a result of one or more invocations of Call Deflection Immediate, provided neither SS-CFNR nor Call Deflection from Alert has taken place. SS-CI, if invoked, shall not operate on a busy user arrived at as a result of one or more diversions, at least one of which is Call Deflection Alert. The procedures of SS-CD shall apply. A wait on busy call that is alerting user B shall not be subject to Call Deflection from Alert.

6.3.14

Path Replacement (ANF-PR) Path replacement may be denied while a call is in intrusion state. This applies both to the established call and the intruding call.

6.3.15

Do Not Disturb (DND) If a call for which SS-CI has been invoked as part of the initial call set up (immediate invocation) fails because of SS-DND active, then the invocation of SS-CI shall be rejected.

6.3.16

Do Not Disturb Override (DNDO) If a called user has SS-DND active, and SS-DNDO is successfully invoked, then: • if SS-CI immediate invocation is applicable to the call, then the invocation of SS-CI shall apply to the call after SS-DND has been overridden; • if SS-CI consultation is applicable to the call, it shall apply after SS-DND has been overridden.

6.3.17

Call Offer (CO) A SS-CO request made after a SS-CI request has been accepted by the PISN shall be rejected. NOTE SS-CI service includes a similar service to SS-CO - wait on busy. This can be used instead of SS-CO. A SS-CI request made after a SS-CO request has been accepted by the PISN shall be allowed. If the request is rejected due to intrusion not allowed, the SS-CO state shall remain. If SS-CI is accepted by the PISN, the SS-CO request shall be cancelled. If both SS-CI immediate invocation and SS-CO immediate invocation are requested at call set up, the services shall be rejected, and the call shall proceed as if neither of the services had been requested. If the served user is provided with SS-CO network invocation (immediate) and the served user requests SS-CI immediate invocation, the network shall not invoke SS-CO. NOTE If a call fails because of busy at the destination, either SS-CI or SS-CO can be applied.

6.4

Interworking considerations When interworking with another network which supports an equivalent feature, it may be possible to cooperate with the other network to provide SS-CI. If a call is made with invocation request of SS-CI to a destination in a network that does not support SS-CI, then the invocation request of SS-CI shall be rejected and the call shall proceed as if there had been no SS-CI invocation request.

6.5

Overall SDL Figure 1 contains the dynamic description of SS-CI using the Specification and Description Language (SDL) defined in ITU-T Rec. Z.100 (1993). The SDL process represents the behaviour of the PISN in providing SS-CI to a served user. Input signals from the left and output signals to the left represent primitives from and to the served user. Input signals from the right represent either primitives from user B, or inputs from the basic call process, or inputs from an internal process. Output signals to the right represent primitives to user B or user C.

- 12 -

Process CALLINT

1 (8)

Call Intrusion Stage 1 SDL sheet 7

idle

Call request with SS-CI request

Call request without SS-CI request

Immediate invocation not implemented

Immediate invocation implemented Consultation implemented Consultation not implemented Immediate invocation provided?

Consultation provided? No

No Yes

Yes

wait_2

Continue as basic call

idle

Figure 1 - SS-CI, overall SDL (part 1 of 8)

wait_1

- 13 -

Process CALLINT

2 (8)

Call Intrusion Stage 1 SDL sheet 7

wait_2

Dest. identified User B not busy

Continue as basic call

Dest. identified and busy

Basic call cleared

User B involved in compatible call that can be intruded upon?

No Yes

idle

SS-CI rejected

idle

Figure 1 - SS-CI, overall SDL (part 2 of 8)

- 14 -

Process CALLINT

3 (8)

Call Intrusion Stage 1 SDL sheet 7

wait_1

Dest. identified User B not busy

Dest. identified user B busy

Basic call cleared

Continue as basic call

SS-CI not allowed?

idle

Yes No

idle

User B busy SS-CI possible

Start consultation timer

consulting

Figure 1 - SS-CI, overall SDL (part 3 of 8)

- 15 -

Process CALLINT

4 (8)

Call Intrusion Stage 1 SDL sheet 7

consulting

Consultation timer expiry

Call to fail as per basic call

User B involved in a compatible call which can be intruded upon?

idle

SS-CI Request

Basic call cleared

stop consultation timer

user B busy?

idle

Yes

1 Yes

No impending intrusion notification

SS-CI rejected

Impending intrusion notification notify user B of impending intrusion

Call to fail as per basic call

Continue as basic call

notify user C of impending intrusion

idle

Notification to served user Notification of impending intrusion

start impending intrusion timer

No notification to served user

impending intrusion

Figure 1 - SS-CI, overall SDL (part 4 of 8)

- 16 -

Process CALLINT

5 (8)

Call Intrusion Stage 1 SDL sheet 7

impending intrusion

impending intrusion timer expiry

served user clears intruding call

Stop impending intrusion timer

Isolate user C

user B clears established call

Stop impending intrusion timer

Do Not isolate user C

Connect user B and served user and disconnect user C

Connect user B, user C and served user

notify user B of SS-CI termination

SS-CI rejected

Notify user B of isolation

Notify user B of intrusion (conf. type conn.)

notify user C of SS-CI termination

Continue as basic call

Notify user C of isolation

Notify user C of intrusion (conf. type conn.)

idle

SS-CI confirm (isolated)

SS-CI confirm (conf. type conn.)

intrusion

Figure 1 - SS-CI, overall SDL (part 5 of 8)

idle

user C clears established call

- 17 -

Figure 1 - SS-CI, overall SDL (part 6 of 8)

- 18 -

Figure 1 - SS-CI, overall SDL (part 7 of 8)

- 19 -

Figure 1 - SS-CI, overall SDL (part 8 of 8)

- 20 -

SS-CI stage 2 specification The stage 2 specification provides two different methods for operation of SS-CI within the network. With the path retention method, if a busy user is encountered the network connection between the originating CC and the destination CC is not released in accordance with ECMA142 but is instead retained awaiting a possible SS-CI request. With the non-retention method, if a busy called user is encountered and the basic call SETUP request/indication was not accompanied by a request for SS-CI, the network connection is released in accordance with ECMA-142. Therefore, with the non-retention method, if SS-CI is requested after encountering a busy called user a new network connection has to be established. Either one of the methods can be used to support any one of the two methods of invoking SS-CI: • Immediate invocation can be supported by the non-retention method by accompanying the SETUP request/indication with a request for SS-CI. • Immediate invocation can be supported by the path retention method by accompanying the SETUP request/indication with a request for path retention and then, when the path is retained because the called user is busy, requesting SS-CI. • Consultation can be supported by the non-retention method by not accompanying the SETUP request/indication with a request for SS-CI and then, when the connection is released because the called user is busy, consulting the calling user. SS-CI can then be requested if necessary by repeating the SETUP request/indication, this time accompanied by a request for SS-CI. • Consultation can be supported by the path retention method by accompanying the SETUP request/indication with a request for path retention and then, when the path is retained because the called user is busy, consulting the calling user. SS-CI can then be requested if necessary using the retained connection. If it is determined that SS-CI is not required, the connection is released. The stage 3 standard for SS-CI at the Q reference point shall support both options, shall permit a PINX supporting FE2 functionality to support either path retention or non-retention or both, and shall require a PINX supporting FE3 functionality to support both path retention and non-retention.

7.1 7.1.1

Functional model Functional model description The functional model shall comprise the following functional entities: FE1 FE2 FE3 FE4 FE5

SS-CI requesting entity; Served user's service control entity; SS-CI control entity, and user B's control entity; User C's control entity; User C's agent.

The following functional relationships shall exist between these FEs: ra rb rc rd

between FE1 and FE2; between FE2 and FE3; between FE3 and FE4; between FE4 and FE5.

Figure 2 shows these FEs and relationships.

- 21 -

FE 5

FE4 rd

rc FE3

FE 1

FE2

ECMA-93-0010-A

Figure 2 - Functional model for SS-CI The further division of FE3 into an FE that is collocated with user B's CCA (and therefore allocatable to a functional TE) and an FE that is collocated with user B's CC (and therefore allocatable to a PINX) is outside the scope of this Standard. 7.1.2 7.1.2.1

Description of functional entities SS-CI requesting entity, FE1 This functional entity: • receives requests from the served user and passes these on to FE2; • receives information from FE2 and passes it on to the served user.

7.1.2.2

Served user's service control entity, FE2 This functional entity: • at the time of original basic call r1_SETUP_request/indication: − receives and validates request from FE1 for immediate invocation of SS-CI; − determines if immediate invocation or consultation is applicable for the call; − if SS-CI is applicable for the call, determines if the path retention method or the non-retention method is to be used and, as appropriate, sends a path retention request or immediate invocation request to FE3 at the time of the original basic call r2_SETUP-request/indication, or retains the call setup information; • if consultation applies to the call and all conditions for performing consultation are met: − informs FE1 that the original call has encountered busy and that SS-CI may be requested; − limits the length of the consultation by clearing the call if the served user has not responded, by clearing the call or requesting SS-CI, within the consultation time; − receives request, during consultation, from FE1 for invocation of SS-CI, sends an appropriate SS-CI invocation request (depending on whether path retention or non-retention is used) to FE3, and sends the result of the invocation request to FE1; • if immediate invocation applies and path retention is used, on receipt of the information from FE3 that the original call has encountered busy and SS-CI is allowed, sends a SS-CI invocation request to FE3; • receives request from FE1 for isolation, forced release and wait on busy, and passes these on to FE3 if allowed; • receives request from FE1 for re-intrusion following wait on busy, and passes this on to FE3 if allowed; • receives from FE3 responses to requests and passes them on to FE1; • receives from FE3 information concerning progress of intrusion (e.g. intrusion impending, intrusion commenced, end of intrusion) and passes them on to FE1.

- 22 -

7.1.2.3

Intrusion service control entity and user B's control entity, FE3 This functional entity: • on an incoming call with an SS-CI request to a called user who is busy, checks if SS-CI is allowed and accepts or rejects the request accordingly; • on an incoming call without an SS-CI request but with a path retention request to a called user who is busy, checks if SS-CI would be allowed, taking into account the CICL value and the called user's CIPL value, and if so retains the path from FE2 and offers FE2 the possibility of invoking SS-CI; • having retained the path and offered FE2 the possibility of invoking SS-CI, and on receipt of an SS-CI request from FE2, checks if SS-CI is allowed and accepts or rejects the request accordingly; • to check whether intrusion is allowed, the FE checks that the CIPL values of the users in the active call are lower than the CICL value; see also 6.2.2.2.2; • selects the established call; • if intrusion is accepted, forms a conference type connection or isolates user C; • on request from FE2, performs isolation of user C; • on request from FE2 converts from the intrusion state to the wait on busy state; • on request from FE2, initiates forced release of user C; • sends request for CIPL value of potential user C to FE4 and receives responses; • handles termination of intrusion through release of intruding or established call; • sends to FE2 responses to requests and information concerning progress of intrusion; • provides notifications to user B; • sends to FE4 information for providing notifications to user C.

7.1.2.4

User C's control entity, FE4 This functional entity: • provides FE3 with user C's CIPL value; • receives information flows from FE3 and forwards these to FE5.

7.1.2.5

User C agent, FE5 This functional entity: • receives information flows from FE4 and informs the user.

7.1.3

Relationship of functional model to basic call functional model An example of a relationship between the FEs for SS-CI and the FEs for the basic call is shown in figure 3.

- 23 -

CCA FE5

CCA

FE4 rd

FE1

FE3

FE2 CC

CCA

r2 r3

ECMA- 93-0011- A

Figure 3 - Example relationship between models for SS-CI and basic call

7.2

Information flows

7.2.1

Definition of information flows In the tables listing the service elements in information flows, the column headed "Request" indicates which of these service elements are mandatory (M) and which are optional (O) in a request/indication information flow, and the column headed "Confirm" indicates which of these service elements are mandatory (M) and which are optional (O) in a response/confirmation information flow.

7.2.1.1 7.2.1.1.1

Relationship ra INFORM INFORM is an unconfirmed information flow across ra from FE2 to FE1 which is used to inform FE1 that the called user is busy and that SS-CI may be requested. There are no service elements in this information flow.

7.2.1.1.2

CI_INV CI_INV is a confirmed information flow sent across ra between FE1 and FE2 which is used to invoke intrusion. The response indicates one of the following: • intrusion performed, user C isolated; • intrusion performed, user C not isolated; • intrusion not performed with reason. Table 1 lists the service elements within the CI_INV information flow. Table 1 - Content of CI_INV Service element

Request

Confirm

Result

M (Note 1)

User C isolated

O (Note 2)

NOTE 1 This service element takes one of the values: short term denial, not authorized, not applicable, success, long term denial. NOTE 2 This service element is sent if intrusion is successful and user C has been isolated.

- 24 -

7.2.1.1.3

WARNING WARNING is an unconfirmed information flow across ra between FE1 and FE2 which is used to notify the served user of the impending intrusion. There are no service elements in this information flow.

7.2.1.1.4

ISOLATE ISOLATE is a confirmed information flow across ra between FE1 and FE2 which is used to request isolation of user C. The response indicates one of the following: • user C isolated; • user C not isolated with reason. Table 2 lists the service elements within the ISOLATE information flow. Table 2 - Content of ISOLATE information flow Service element

Request

Result

Confirm M (Note 3)

NOTE 3 The element takes one of the values: success, not applicable, long term denial. 7.2.1.1.5

FORCE_REL FORCE_REL is a confirmed information flow across ra between FE1 and FE2 which is used to request the forced release of user C. The response indicates one of the following: • user C released; • user C not released with reason. Table 3 lists the service elements within the FORCE_REL information flow. Table 3 - Content of FORCE_REL information flow Service element

Request

Result

Confirm M (Note 4)

NOTE 4 The element takes one of the values: success, not applicable, long term denial. 7.2.1.1.6

EST_TERM EST_TERM is an unconfirmed information flow across ra between FE1 and FE2 which is used to inform FE1 that the established call has been released. There are no service elements in this information flow.

7.2.1.1.7

REQUEST_WOB REQUEST_WOB is a confirmed information flow sent across ra between FE1 and FE2 which is used to request wait on busy. The response indicates one of the following: • wait on busy request accepted; • wait on busy request not accepted with reason. Table 4 lists the service elements within the REQUEST_WOB information flow.

- 25 -

Table 4 - Content of REQUEST_WOB information flow Service element

Request

Result

Confirm M (Note 5)

NOTE 5 The element takes one of the values: success, not applicable, long term denial. 7.2.1.1.8

B_ALERTING B_ALERTING is an unconfirmed information flow sent across ra between FE1 and FE2 which is used to inform FE1 that user B is alerting. There are no service elements in this information flow.

7.2.1.1.9

B_ANSWER B_ANSWER is an unconfirmed information flow sent across ra between FE1 and FE2 which is used to inform FE1 that user B has answered the waiting call. There are no service elements in this information flow.

7.2.1.2 7.2.1.2.1

Relationship rb CI_ACT CI_ACT is an unconfirmed information flow across rb between FE2 and FE3 which is used to indicate to FE3 that path retention is required if intrusion is possible. Table 5 lists the service elements within the CI_ACT information flow. Table 5 - Content of CI_ACT information flow Service element CICL

Request

Confirm

M (Note 6)

NOTE 6 This element takes one of the values: 1, 2, 3. 7.2.1.2.2

ISOLATE ISOLATE is a confirmed information flow across rb from FE2 to FE3 which is used to request isolation of user C. The response indicates one of the following: • user C isolated; • user C not isolated with reason. Table 6 lists the service elements within the ISOLATE information flow. Table 6 - Content of ISOLATE information flow Service element Result

Request

Confirm M (Note 7)

NOTE 7 The element takes one of the values: success, not applicable, long term denial.

- 26 -

7.2.1.2.3

WARNING WARNING is an unconfirmed information flow across rb between FE2 and FE3 which is used to notify FE2 of the impending intrusion. There are no service elements in this information flow.

7.2.1.2.4

FORCE_REL FORCE_REL is a confirmed information flow across rb between FE2 and FE3 which is used to request the forced release of user C. The response indicates one of the following: • user C released; • user C not released with reason. Table 7 lists the service elements within the FORCE_REL information flow. Table 7 - Content of FORCE_REL information flow Service element

Request

Result

Confirm M (Note 8)

NOTE 8 The element takes one of the values: success, not applicable, long term denial. 7.2.1.2.5

EST_TERM EST_TERM is an unconfirmed information flow across rb between FE2 and FE3 which is used to inform FE2 that the established call has been released. There are no service elements in this information flow.

7.2.1.2.6

REQUEST_WOB REQUEST_WOB is a confirmed information flow sent across rb between FE2 and FE3 which is used to request wait on busy. The response indicates one of the following: • wait on busy request accepted; • wait on busy request not accepted with reason. Table 8 lists the service elements within the REQUEST_WOB information flow. Table 8 - Content of REQUEST_WOB information flow Service element

Request

Result

Confirm M (Note 9)

NOTE 9 The element takes one of the values: success, not applicable, long term denial. 7.2.1.2.7

CI_AVAIL CI_AVAIL is an unconfirmed information flow across rb between FE2 and FE3 which is used to inform FE2 that the path has been retained and intrusion may be possible. There are no service elements in this information flow.

- 27 -

7.2.1.2.8

CI_INV CI_INV is a confirmed information flow sent across rb between FE2 and FE3 which is used to invoke intrusion. The response indicates one of the following: • intrusion performed, user C isolated; • intrusion performed, user C not isolated; • intrusion not performed with reason. Table 9 lists the service elements within the CI_INV information flow. Table 9 - Content of CI_INV Service element

Request

Confirm

Result

M (Note 10)

User C isolated

O (Note 11)

CICL

M (Note 12)

NOTE 10 This element takes one of the values; short term denial, not authorized, not applicable, success, long term denial. NOTE 11 This element is sent if intrusion is successful and user C has been isolated. NOTE 12 This element takes one of the values: 1, 2, 3. 7.2.1.2.9

B_ALERTING B_ALERTING is an unconfirmed information flow sent across rb between FE2 and FE3 which is used to inform FE2 that user B is alerting. There are no service elements in this information flow.

7.2.1.2.10

B_ANSWER B_ANSWER is an unconfirmed information flow sent across rb between FE2 and FE3 which is used to inform FE2 that user B has answered the waiting call. There are no service elements in this information flow.

7.2.1.3 7.2.1.3.1

Relationship rc INFO_REQ INFO_REQ is a confirmed information flow sent across rc between FE3 and FE4 which is used to request user C's CIPL. Table 10 lists the service elements within the INFO_REQ information flow. Table 10 - Content of INFO_REQ information flow Service element CIPL

Request

Confirm M (Note 13)

- 28 -

NOTE 13 This element takes one of the values: 0, 1, 2, 3. 7.2.1.3.2

WARNING WARNING is an unconfirmed information flow sent across rc between FE3 and FE4 which is used to inform FE4 that intrusion is impending. There are no service elements in this information flow.

7.2.1.3.3

C_INTR C_INTR is an unconfirmed information flow sent across rc between FE3 and FE4 which is used to inform FE4 that intrusion is in progress and user C is in conference type connection. There are no service elements in this information flow.

7.2.1.3.4

C_ISOLATED C_ISOLATED is an unconfirmed information flow sent across rc between FE3 and FE4 which is used to inform FE4 that user C has been isolated. There are no service elements in this information flow.

7.2.1.3.5

C_FORCED_REL C_FORCED_REL is an unconfirmed information flow sent across rc between FE3 and FE4 which is used to inform FE4 that user C has been forced released. There are no service elements in this information flow.

7.2.1.3.6

INTR_TERM INTR_TERM is an unconfirmed information flow sent across rc between FE3 and FE4 which is used to inform FE4 that the intrusion state has terminated. There are no service elements in this information flow.

7.2.1.4 7.2.1.4.1

Relationship rd WARNING WARNING is an unconfirmed information flow sent across rd between FE4 and FE5 which is used to inform FE5 that intrusion is impending. There are no service elements in this information flow.

7.2.1.4.2

C_INTR C_INTR is an unconfirmed information flow sent across rd between FE4 and FE5 which is used to inform FE5 that intrusion is in progress and user C is in conference type connection. There are no service elements in this information flow.

7.2.1.4.3

C_ISOLATED C_ISOLATED is an unconfirmed information flow sent across rd between FE4 and FE5 which is used to inform FE5 that user C has been isolated. There are no service elements in this information flow.

7.2.1.4.4

C_FORCED_REL C_FORCED_REL is an unconfirmed information flow sent across rd between FE4 and FE5 which is used to inform FE5 that user C has been forced released. There are no service elements in this information flow.

7.2.1.4.5

INTR_TERM INTR_TERM is an unconfirmed information flow sent across rd between FE4 to FE5 which is used to inform FE5 that the intrusion state has terminated. There are no service elements in this information flow.

- 29 -

7.2.2 7.2.2.1

Relationship of information flows to basic call information flows Information flows over ra INFORM request/indication shall be sent independently of a basic call information flow. CI_INV request/indication shall be sent: • together with basic call information flow r1_SETUP request/indication if this is sent at the same time; • otherwise independently of a basic call information flow. In the case of re-intrusion, CI_INV response/confirmation shall be sent independently of basic call information flow otherwise it shall be sent: • if success: − together with basic call information flow r1_SETUP response/confirmation; • if failure: − together with basic call information flow r1_REPORT request/indication if this is sent at the same time (e.g. if the called user enters an alerting phase); − with basic call information flow r1_SETUP response/confirmation if this is sent at the same time (e.g. if called user is busy but SS-CI not provided); − with basic call information flow r1_DISCONNECT request/indication if this is sent at the same time (e.g. if called user is busy but SS-CI not possible at the time of invocation). ISOLATE request/indication shall be sent independently of a basic call information flow. ISOLATE response/confirmation shall be sent independently of a basic call information flow. FORCE_REL request/indication shall be sent independently of a basic call information flow. FORCE_REL response/confirmation shall be sent independently of a basic call information flow. EST_TERM request/indication shall be sent independently of a basic call information flow. REQUEST_WOB request/indication shall be sent independently of a basic call information flow. REQUEST_WOB response/confirmation shall be sent independently of a basic call information flow. WARNING request/indication shall be sent independently of basic call information flow. B_ALERTING request/indication shall be sent independently of a basic call information flow. B_ANSWER request/indication shall be sent independently of a basic call information flow.

7.2.2.2

Information flows over rb CI_ACT request/indication shall be sent in conjunction with basic call information flow r2_SETUP. CI_AVAIL request/indication shall be sent independently of a basic call information flow. CI_INV request/indication shall be sent: • together with basic call information flow r2_SETUP request/indication if this is sent at the same time; • otherwise independently of a basic call information flow. In the case of re-intrusion, CI_INV response/confirmation shall be sent independently of basic call information flow otherwise it shall be sent: • if success: − together with basic call information flow r2_SETUP response/confirmation; • if failure: − together with basic call information flow r2_REPORT request/indication if this is sent at the same time (e.g. if the called user enters an alerting phase);

- 30 -

− with basic call information flow r2_SETUP response/confirmation if this is sent at the same time (e.g. if called user is busy but SS-CI not provided); − with basic call information flow r2_RELEASE request/indication if this is sent at the same time (e.g. if called user is busy but SS-CI not possible at the time of invocation). ISOLATE request/indication shall be sent independently of a basic call information flow. ISOLATE response/confirmation shall be sent independently of a basic call information flow. FORCE_REL request/indication shall be sent independently of a basic call information flow. FORCE_REL response/confirmation shall be sent independently of a basic call information flow. EST_TERM request/indication shall be sent independently of a basic call information flow. REQUEST_WOB request/indication shall be sent independently of a basic call information flow. REQUEST_WOB response/confirmation shall be sent independently of a basic call information flow. WARNING request/indication shall be sent independently of basic call information flow. B_ALERTING request/indication shall be sent independently of a basic call information flow. B_ANSWER request/indication shall be sent independently of a basic call information flow. 7.2.2.3

Information flows over rc INFO_REQ request/indication shall be sent independently of a basic call information flow. INFO_REQ response/confirmation shall be sent independently of a basic call information flow. WARNING request/indication shall be sent independently of basic call information flow. C_INTR request/indication shall be sent independently of basic call information flow. C_ISOLATED request/indication shall be sent independently of basic call information flow. C_FORCED_REL request/indication shall be sent together with basic call information flow r2_RELEASE request/indication. INTR_TERM request/indication shall be sent independently of basic call information flow.

7.2.2.4

Information flows over rd WARNING request/indication shall be sent independently of basic call information flow. C_INTR request/indication shall be sent independently of basic call information flow. C_ISOLATED request/indication shall be sent independently of basic call information flow. C_FORCED_REL request/indication shall r1_/r3_DISCONNECT request/indication.

sent

together

with

basic

call

INTR_TERM request/indication shall be sent independently of basic call information flow.

information

flow

- 31 -

7.2.2.5

Summary Table 11 summarizes the relationships of the SS-CI information flows with those of the basic call. Table 11 - Relationship of the SS-CI information flows with the basic call

request request

Independent of basic call flow yes yes

With basic flow no yes

CI_INV ISOLATE ISOLATE FORCE_REL FORCE_REL EST_TERM REQUEST_WOB REQUEST_WOB WARNING B_ALERTING B_ANSWER CI_AVAIL CI_ACT CI_INV

confirm request confirm request confirm request request confirm request request request request request request

yes yes yes yes yes yes yes yes yes yes yes yes no yes

yes no no no no no no no no no no no yes yes

CI_INV ISOLATE ISOLATE FORCE_REL FORCE_REL EST_TERM REQUEST_WOB REQUEST_WOB WARNING B_ALERTING B_ANSWER INFO_REQ INFO_REQ WARNING C_INTR C_ISOLATE C_FORCED_REL INTR_TERM WARNING C_INTR C_ISOLATED C_FORCED_REL

confirm request confirm request confirm request request confirm request request request request confirm request request request request request request request request request

yes yes yes yes yes yes yes yes yes yes yes yes yes yes yes yes no yes yes yes yes no

no no no no no no no no no no no no no no no no yes no no no no yes

INTR_TERM

request

yes

Information flow ra INFORM CI_INV

Basic call flows r1_SETUP req/ind r1_REPORT req/ind r1_SETUP resp/conf r1_DISCONNECT req/ind

r2_SETUP req/ind r2_SETUP req/ind r2_REPORT req/ind r2_SETUP resp/conf r2_RELEASE req/ind

r2_RELEASE req/ind

r1_/r3_DISCONNECT req/ind

- 32 -

7.2.3

Examples of information flow sequences A stage 3 standard for SS-CI shall provide signalling procedures in support of the information flow sequences specified below. In addition, signalling procedures should be provided to cover other sequences arising from error situations, interactions with basic call, interactions with other supplementary services, different topologies, etc.. In the figures, SS-CI information flows are represented by solid arrows and basic call information flows are represented by broken arrows. An ellipse embracing two information flows indicates that the two information flows occur simultaneously. Within a column representing an SS-CI functional entity, the numbers refer to functional entity actions listed in 7.3. The following abbreviations are used: req

request

ind

indication

resp

response

cfm

confirmation

The timers used through all the figures: T1 = Consultation timer; T2 = Time to intrusion. 7.2.3.1

Normal operation, consultation, path retention Figure 4 shows the information flow sequence for a successful intrusion attempt, using consultation and path retention. In this particular sequence an impending intrusion warning notification is given to user B and user C and after a delay a conference type connection is formed. FE1

SETUP req.ind

FE2

921

FE3

FE4

FE5

SETUP req.ind CI_ACT req.ind

931 93A

923

CI_AVAIL req.ind

935

CI_INV req.ind

936

911

INFORM req.ind

912

CI_INV req.ind

924

INFO_REQ 932

925 913

CI_INV resp.conf

req.ind

941

933 934

INFO_REQ

937 T2

WARNING req.ind

942

938

C_INTR req.ind

943

resp.conf

WARNING req.ind C_INTR

951

952

93B

SETUP resp.conf

Figure 4 - Information flow sequence - normal operation of SS-CI, normal operation, consultation, path retention

- 33 -

7.2.3.2

Normal operation, consultation, non-retention Figure 5 shows the information flow sequence for a successful intrusion attempt using consultation and nonretention. In this particular sequence an impending intrusion warning notification is given to user B and user C and after a delay a conference type connection is formed. ra

FE1

SETUP req.ind

FE2

92E

FE3

FE4

FE5

SETUP req.ind RELEASE req.ind

911

912

INFORM req.ind CI_INV req.ind

92H T1

92F

SETUP req.ind CI_INV req.ind

936 932

933 934

925 913

CI_INV resp.conf

INFO_REQ

941

req.ind INFO_REQ resp.conf

937 T2

WARNING req.ind

942

938

C_INTR req.ind

943

93B

WARNING req.ind

C_INTR

951

952

req.ind

SETUP resp.conf

SETUP resp. conf

ECMA-93-0013-A

Figure 5 - Information flow sequence - normal operation of SS-CI, normal operation, consultation, non-retention

- 34 -

7.2.3.3

Normal operation, immediate invocation, non-retention Figure 6 shows the information flow sequence for a successful intrusion attempt using immediate invocation and non-retention. In this particular sequence an impending intrusion warning notification is given to user B and user C and after a delay a conference type connection is formed. ra

FE1

FE2

SETUP req.ind

912

FE3

FE4

FE5

SETUP req.ind

CI_INV req.ind

92I

CI_INV req.ind

936 INFO_REQ 932

933 934

925 913

CI_INV

resp.conf

SETUP resp.conf

941 req.ind INFO_REQ resp.conf

937 T2

WARNING req.ind

942

WARNING req.ind

951

938

C_INTR req.ind

943

C_INTR req.ind

952

93B

ECMA-93-0014-A

Figure 6 - Information flow sequence - normal operation of SS-CI, normal operation, immediate invocation, non-retention

- 35 -

7.2.3.4

Normal operation, immediate invocation, path retention Figure 7 shows the information flow sequence for a successful intrusion attempt, using immediate invocation and path retention. In this particular sequence an impending intrusion warning notification is given to user B and user C and after a delay a conference type connection is formed. ra

FE1

rb FE2

SETUP req.ind 912

CI_INV req.ind

rc FE3

rd FE4

FE5

SETUP req.ind 92G

CI_ACT req.ind

931 93A

922

CI_AVAIL req.ind

935

CI_INV req.ind

936

932

925 913

CI_INV resp.conf

INFO_REQ

933 934

INFO_REQ resp.conf

937 T2

WARNING req.ind

938 93B

941

req.ind

942

C_INTR req.ind

WARNING req.ind C_INTR

943

req.ind

951

952

SETUP resp.conf

ECMA-93-0015-A

Figure 7 - Information flow sequence - normal operation of SS-CI, normal operation, immediate invocation, path retention

- 36 -

7.2.3.5

Normal operation, immediate invocation, path retention, user C isolated at intrusion Figure 8 shows the information flow sequence for a successful intrusion attempt using immediate invocation and path retention. In this particular sequence an impending intrusion warning notification is given to user B and user C and after a delay user C is isolated and served user is connected to user B. During the intrusion state the intruding call is released, the isolation of user C is terminated, user C and user B are reconnected. ra

FE1

rb FE2

SETUP req.ind 912

CI_INV req.ind

FE3

FE4

FE5

SETUP req.ind 92G

CI_ACT req.ind

931 93A

CI_AVAIL 922

req.ind

935

CI_INV req.ind

936 INFO_REQ 932

req.ind INFO_REQ resp.conf

933 934

WARNING

937 T2

925 CI_INV 913

resp.conf SETUP resp.conf

CI_INV

939

941

req.ind

942

C_ ISOLATED req.ind

944

WARNING req.ind C_ISOLATED

951

953

93B

resp. conf SETUP resp.conf

INTRUSION IN PROGRESS INTR_TERM 93C

INTRUSION TERMINATED. ESTABLISHED CALL REESTABLISHED

req.ind

INTR_TERM 946

req.ind

955

USER B - USER C

ECMA-93-0016-A

Figure 8 - Information flow sequence - normal operation of SS-CI, normal operation, immediate invocation, path retention, user C is isolated

- 37 -

7.2.3.6

Normal operation, immediate invocation, immediate intrusion, non-retention Figure 9 shows the information flow sequence for a successful intrusion attempt using immediate invocation and non-retention. In this particular sequence a conference type connection is formed immediately without an impending intrusion warning notification. ra

FE1

rb FE2

SETUP req.ind

912

rd FE4

FE5

SETUP req.ind

CI_INV req.ind

rc FE3

92I

CI_INV req.ind

936 INFO_REQ 932

933 934

93H

CI_INV 913

resp.conf

925

CI_INV resp.conf

req.ind

941

INFO_REQ resp.conf

C_INTR req.ind

C_INTR 943

req.ind

952

93B

SETUP resp.conf SETUP resp.conf

ECMA-93-0017-A

Figure 9 - Information flow sequence - normal operation of SS-CI, normal operation, immediate invocation, immediate intrusion, non-retention

- 38 -

7.2.3.7

Normal operation, immediate invocation, path retention Figure 10 shows the information flow sequence for a successful intrusion attempt, using immediate invocation and path retention. In this particular sequence an impending intrusion warning notification is given to served user, user B and user C and after a delay a conference type connection is formed. FE1

rb FE2

SETUP req.ind

req.ind

rd FE4

FE5

SETUP req.ind CI_ACT

CI_INV 912

FE3

92G

req.ind

931

93A 922

CI_AVAIL req.ind

935

CI_INV req.ind

936

INFO_REQ 932

933 934

91D

WARNING req.ind

92J

WARNING req.ind

937 T2

941

req.ind INFO_REQ resp.conf

WARNING req.ind

942

C_INTR 938

925 CI_INV 913

resp.conf

CI_INV resp.conf

req.ind

WARNING req.ind

C_INTR 943

req.ind

951

952

93B

SETUP resp.conf

ECMA-93-0018-A

Figure 10 - Information flow sequence - normal operation of SS-CI, normal operation, immediate invocation, path retention

- 39 -

7.2.3.8

Normal operation, isolation of user C Figure 11 below shows the information flow sequence for a successful isolation on request from served user, after intrusion has been accepted and a conference type connection has been formed. ra

FE1

FE2

FE3

FE4

FE5

INTRUSION IN PROGRESS

ISOLATE 914

req.ind

927

ISOLATE req.ind

93D

C_ISOLATED req.ind

944

C_ISOLATED req.ind

ISOLATE 915

928

953

ISOLATE resp.conf

resp.conf

INTRUSION IN PROGRESS, USER C ISOLATED

ECMA-93-0019-A

Figure 11 - Information flow sequence - normal operation of SS-CI, normal operation, isolation of user C

7.2.3.9

Normal operation, Forced Release of user C Figure 12 below shows the information flow sequence for a successful forced release of user C. ra

FE1

FE2

FE3

FE4

rd FE5

INTRUSION IN PROGRESS

FORCED_REL 916

req.ind

929

FORCED_REL req.ind

93F

C_FORCED_ REL req.ind

FORCED_REL 917

resp.conf

945

C-FORCEDREL req. ind

954

FORCED_REL 92A

resp.conf

RELEASE DISCONNECT req.ind

req. ind

INTRUSION TERMINATED, USER C HAS BEEN FORCED RELEASED

ECMA-93-0020-A

Figure 12 - Information flow sequence - normal operation of SS-CI, normal operation, forced release of user C

- 40 -

7.2.3.10

Normal operation, user B or user C releases the established call Figure 13 below shows the information flow sequence when the established call is released by user B or user C during the intrusion state. ra

FE1

FE2

rc FE3

FE4

FE5

INTRUSION IN PROGRESS

EST_TERM 918

EST_TERM

req.ind

92B

req.ind

93G

INTRUSION TERMINATED, SERVED USER CONNECTED TO USER B

ECMA-93-0021-A

Figure 13 - Information flow sequence - normal operation of SS-CI, user B or user C releases the established call

7.2.3.11

Normal operation, release of the intruding call Figure 14 below shows the information flow sequence when the intruding call is released by served user or user B during the intrusion state. ra FE1

FE2

rc FE3

rd FE4

FE5

INTRUSION IN PROGRESS

INTR_TERM 93C

req.ind

946

INTR_TERM req.ind

955

INTRUSION TERMINATED, ESTABLISHED CALL REMAINS BETWEEN USER B - USER C

ECMA-93-0022-A

Figure 14 - Information flow sequence - normal operation of SS-CI, intruding call released during the intrusion state

- 41 -

7.2.3.12

Normal operation, wait on busy requested Figure 15 below shows the information flow sequence for a successful wait on busy request made by the served user. In this particular sequence user B subsequently starts alerting and answers the call. ra

FE1

FE2

rc FE3

rd FE4

FE5

INTRUSION IN PROGRESS

919

REQUEST_WOB req.ind

92C

REQUEST_WOB req.ind

93E

INTR_TERM req.ind

REQUEST_WOB 91A

92D

946

INTR_TERM req.ind

REQUEST_WOB

955

resp.conf

WAIT ON BUSY

B_ALERTING 91B

req.ind

B_ALERTING 92K

B_ANSWER 91C

req.ind

93I

B_ANSWER 92L

req.ind

93J

WAIT ON BUSY TERMINATED

ECMA-93-0023-A

Figure 15 - Information flow sequence - normal operation of SS-CI, normal operation, wait on busy requested

- 42 -

7.2.3.13

Normal operation, new intrusion during wait on busy Figure 16 below shows the information flow sequence for a successful new intrusion requested during the wait on busy state. In this particular sequence an impending intrusion warning notification is given to user B and user C and after a delay a conference type connection is formed. ra

FE1

WAIT ON BUSY

912

FE2

FE3

FE4

rd FE5

IN PROGRESS

CI_INV req.ind

926 CI_INV req.ind

936 INFO_REQ 932

933 934

req.ind

941

INFO_REQ resp.conf WARNING

937 T2

req.ind C_INTR

938

CI_INV 925 CI_INV 913

resp.conf

req.ind

WARNING 942

943

951 req. ind C_INTR

952

req. ind

93B

resp.conf INTRUSION PERFORMED, INTRUSION IN PROGRESS

ECMA-93-0024-A

Figure 16 - Information flow sequence - normal operation of SS-CI, normal operation, new intrusion during the wait on busy state is requested

7.3

Functional entity actions The following FE actions shall occur at the points indicated in the figures of 7.2.3.

7.3.1

Functional entity actions of FE1 911

The FE shall receive an INFORM req.ind information flow and inform the served user that the called user is busy and that intrusion may be possible.

912

The FE shall receive the user's request for call intrusion and send the CI_INV req.ind to FE2.

913

The FE shall receive the CI_INV resp.conf information flow from FE2 and inform the served user of the result of the request for intrusion.

914

In response to a request from the served user to isolate user C, the FE shall send the ISOLATE req.ind information flow to FE2.

915

The FE shall receive the ISOLATE resp.conf information flow from FE2 and inform the served user of the result of the request.

916

In response to a forced release request from the served user, the FE shall send the FORCED_REL information flow to FE2.

917

The FE shall receive the FORCED_REL resp.conf information flow from FE2 and indicate the result to the served user.

918

The FE shall receive the EST_TERM req.ind information flow from FE2. The FE shall inform the served user that the established call has been released.

- 43 -

7.3.2

919

In response to a wait on busy request from the served user, the FE shall send the REQUEST_WOB req.ind information flow to FE2.

91A

The FE shall receive the REQUEST_WOB resp.conf information flow from FE2 and indicate the result to the served user.

91B

The FE shall receive the B_ALERTING req.ind information flow from FE2 and inform the served user.

91C

The FE shall receive the B_ANSWER req.ind information flow from FE2 and inform the served user.

91D

The FE shall receive the WARNING req.ind information flow from FE2 and inform the served user.

Functional entity actions of FE2 921

The FE shall check whether the user is provided with SS-CI using the consultation method and, if provided, send a CI_ACT req.ind information flow together with basic call SETUP information flow to FE3.

922

The FE shall receive the CI_AVAIL req.ind information flow from FE3 and send the CI_INV req.ind information flow to FE3.

923

The FE shall receive the CI_AVAIL req.ind information flow from FE3. The FE shall start timer T1 (consultation timer) and store the call information for the duration of T1. The FE shall send an INFORM req.ind information flow to FE1.

924

The FE shall receive the CI_INV req.ind information flow from FE1. The FE shall stop the timer T1 and send CI_INV req.ind information flow to FE3.

925

The FE shall receive the CI_INV resp.conf information flow from FE3 and send the CI_INV resp.conf information flow to FE1.

926

The FE shall receive the CI_INV req.ind information flow from FE1 and send the CI_INV req.ind information flow to FE3.

927

The FE shall receive the ISOLATE req.ind information flow from FE1. The FE shall check whether the user is provided with isolation capability. If provided, the FE shall send the ISOLATE req.ind information flow to FE3.

928

The FE shall receive the ISOLATE resp.conf information flow from FE3 and send the ISOLATE resp.conf information flow to FE1.

929

The FE shall receive the FORCE_REL req.ind information flow from FE1, check whether the user is provided with forced release, and send the FORCE_REL req.ind information flow to FE3.

92A

The FE shall receive the FORCE_REL resp.conf information flow from FE3 and send the FORCE_REL resp.conf information flow to FE1.

92B

The FE shall receive the EST_TERM req.ind information flow from FE3 and send the EST_TERM req.ind information flow to FE1.

92C

The FE shall receive the REQUEST_WOB req.ind information flow from FE1, check whether the user is provided with wait on busy, and send the REQUEST_WOB req.ind information flow to FE3.

92D

The FE shall receive the REQUEST_WOB resp.conf information flow from FE3 and send the REQUEST_WOB resp.conf information flow to FE1.

92E

All information in the basic call SETUP information flow shall be retained.

92F

The FE shall receive the CI_INV req.ind information flow. The FE shall stop the timer T1 (consultation). The basic call process shall be stimulated to setup a new call with the information retained from the original setup. A CI_INV req.ind information flow shall be sent, together with the basic call information flow SETUP req.ind to FE3.

92G

The FE shall receive the CI_INV req.ind information flow from FE1, check whether the user is provided with SS-CI using immediate invocation method, and send the CI_ACT req.ind information flow to FE3 together with the basic call information flow SETUP req.ind.

- 44 -

7.3.3

92H

The FE shall start a timer T1 (consultation timer) and store the call information for the duration of T1. The FE shall send the INFORM req.ind information flow to FE1 informing FE1 that called user is busy and intrusion may be possible.

92I

The FE shall receive the CI_INV req.ind information flow from FE1 and check whether the user is provided with SS-CI using the immediate invocation method. If provided, the FE shall send the CI_INV req.ind information flow to FE3.

92J

The FE shall receive the WARNING req.ind information flow from FE3 and send the WARNING req.ind information flow to FE1.

92K

The FE shall receive the B_ALERTING req.ind information flow from FE3 and send the B_ALERTING req.ind information flow to FE1.

92L

The FE shall receive the B_ANSWER req.ind information flow from FE3 and send the B_ANSWER req.ind information flow to FE1.

Functional entity actions of FE3 931

The FE shall receive the CI_ACT req.ind information flow from FE2.

932

The FE shall send the INFO_REQ req.ind information flow to FE4.

933

The FE shall receive the INFO_REQ resp.conf information flow from FE4.

934

The FE shall compare the CICL with the CIPLs for user B and user C and determine whether intrusion is allowed or not.

935

If intrusion may be possible, the FE shall inform FE2 by sending the CI_AVAIL req.ind information flow. If intrusion is not possible, normal basic call release procedure shall take place.

936

The FE shall receive the information flow CI_INV req.ind from FE2.

937

The FE shall send the WARNING req.ind information flow to FE4. The FE may also send the optional WARNING req.ind information flow to FE2. The FE shall start timer T2. The FE shall inform user B. The FE may also apply an in-band tone or announcement to user B and user C.

938

The FE shall determine that a conference type connection is to be formed. When the timer T2 has elapsed, the FE shall establish the intrusion connection by joining the served user, user B and user C in a conference type connection. The FE shall send the C_INTR req.ind information flow to FE4. The FE shall inform user B that intrusion is in progress. The FE may also apply an in-band indication to connected users during the intrusion state.

939

The FE shall determine that user C is to be automatically isolated. The FE shall isolate user C when timer T2 elapses. The FE shall send the C_ISOLATED req.ind information flow to FE4. The FE shall inform user B that user C has been isolated. The FE shall set up a connection between served user and user B.

93A

The FE shall compare the CICL value with the CIPL value for user B and determine whether intrusion is allowed or not.

93B

The FE shall send the CI_INV resp.conf information flow to FE2.

93C

If the intruding call is released, the FE shall send an INTR_TERM req.ind information flow to FE4. The FE terminates the intrusion. The established call shall revert back to the state that existed before the intrusion took place. User B shall be informed that intrusion has terminated.

93D

The FE shall receive the ISOLATE req.ind information flow from FE2. The FE shall send the C_ISOLATED req.ind information flow to FE4. The FE shall isolate user C from the conference type connection. The FE shall inform user B regarding the isolation. The FE shall send an ISOLATE resp.conf information flow to FE2, with the result of the requested isolation. The FE shall remove the in-band warning indication, if applicable.

93E

The FE shall receive the REQUEST_WOB req.ind information flow from FE2. The FE shall send the INTR_TERM req.ind information flow to FE4. The FE shall make the established call revert back to the state that existed before the intrusion occurred. User B shall be informed that the intrusion is

- 45 -

terminated, and that a wait on busy state applies. The FE shall send the REQUEST_WOB resp.conf information flow to FE2.

7.3.4

7.3.5

7.4

93F

The FE shall receive the FORCE_REL req.ind information flow from FE2. The FE shall initiate a disconnect and release of the established call. The FE shall send the C_FORCED_REL req.ind information flow to FE4. The FE shall inform user B of the forced release of user C. The FE shall send the FORCE_REL resp.conf information flow to FE2. The FE shall remove the in-band warning indication tone, if applicable.

93G

If user B or user C releases the established call during the intrusion state (handled by basic call procedures) the FE shall send a EST_TERM req.ind information flow to FE2. The FE makes the intruding call an ordinary call between served user and user B. The intrusion state is terminated.

93H

The FE shall establish the intrusion connection by joining the served user, user B and user C in a conference type connection. The FE shall send the C_INTR req.ind information flow to FE4. The FE shall inform user B that intrusion is in progress. The FE may also apply an in-band indication to connected users during the intrusion state.

93I

If user B makes available resources and starts alerting, the FE shall send the B_ALERTING req.ind information flow to FE2.

93J

If user B answers the waiting call during the wait on busy state, the FE shall send the B_ANSWER req.ind information flow to FE2.

Functional entity actions of FE4 941

The FE shall receive the INFO_REQ req.ind information flow from FE3 and send the INFO_REQ resp.conf information flow to FE3.

942

The FE shall receive the WARNING req.ind information flow from FE3 and send the WARNING req.ind information flow to FE5.

943

The FE shall receive the C_INTR req.ind information flow from FE3 and send the C_INTR req.ind information flow to FE5.

944

The FE shall receive the C_ISOLATED req.ind information flow from FE3 and send the C_ISOLATED req.ind information to FE5.

945

The FE shall receive the C_FORCED_REL req.ind information flow from FE3 and send the C_FORCED_REL req.ind information flow to FE5.

946

The FE shall receive the INTR_TERM req.ind information flow from FE3 and send the INTR_TERM req.ind information flow to FE5.

Functional entity actions of FE5 951

The FE shall receive the WARNING req.ind information flow. The FE shall provide the user with the impending intrusion warning indication.

952

The FE shall receive the C_INTR req.ind information flow from FE4. The FE shall inform the user.

953

The FE shall receive the C_ISOLATED req.ind information flow from FE4. The FE shall inform the user.

954

The FE shall receive the C_FORCED_REL req.ind information flow from FE4. The FE shall inform the user.

955

The FE shall receive the INTR_TERM req.ind information flow from FE4. The FE shall inform the user.

Functional entity behaviour The FE behaviours shown below are intended to illustrate typical FE behaviour in terms of information flows sent and received. The behaviour of each FE is shown using the Specification and Description Language (SDL) defined in ITU-T Rec. Z.100 (1993).

- 46 -

7.4.1

Behaviour of FE1 Figure 17 shows the normal behaviour of FE1. Input signals from the left and output signals to the left represent primitives from and to the served user. Input signals from the right and output signals to the right represent information flows from and to FE2 and input signals from the collocated CCA.

Call intrusion is requested

CI IDLE

Intrusion request as part of initial call request

INFORM req.ind

911, ra, FE2

Consultation implemented Consultation not implemented

CI IDLE

Inform user about intrusion posibility

Wait for user response on inform

Immediate Immediate invocation implemented invocation not implemented

Served user requests intrusion

Basic call to proceed

CI_INV req.ind with or witout basic call SETUP

CI IDLE

Wait for response on CI_INV

912, ra, FE2

Figure 17 - SS-CI, SDL for functional entity FE1 (part 1 of 8)

- 47 -

Invocation in progress

Wait for response on CI_INV

WARNING req.ind CI_INV resp.conf

913, ra, FE2

91D, ra, FE2

Notify served user

Inform served user of result

Intrusion accepted YES conferenced NO

State of user C

isolated

CI IDLE Intrusion FE1

Isolation FE1

Figure 17 - SS-CI, SDL for functional entity FE1 (part 2 of 8)

- 48 -

During intrusion

Intrusion FE1

Served user requests isolation

Wait on busy requested

Served user requests forced release FORCED_REL req.ind

916, ra, FE2

Wait for response on forced release request. FORCED_REL resp.conf

917, ra, FE2

Inform user of result of forced release request

NO Intrusion FE1

Forced release accepted ? YES

CI IDLE

Figure 17 - SS-CI, SDL for functional entity FE1 (part 3 of 8)

- 49 -

Call intrusion in progress Isolation requested

ISOLATE req.ind

914, ra, FE2

Wait for response on isolate request

ISOLATE resp.conf

915, ra, FE2

Inform served user

Intrusion FE1

Isolation accepted

YES

Isolation FE1

Figure 17 - SS-CI, SDL for functional entity FE1 (part 4 of 8)

- 50 -

Intrusion in progress selections

REQUEST_WOB req.ind

919, ra, FE2

Wait for response on WOB request

REQUEST_WOB resp.conf

91A, ra, FE2

Inform user

NO Intrusion FE1

WOB accepted ? YES WOB FE1

Figure 17 - SS-CI, SDL for functional entity FE1 (part 5 of 8)

- 51 -

WOB FE1

Wait on Busy

Served user requests intrusion CI_INV req.ind

B_ALERTING req.ind

912, ra, FE2

Wait for reintrusion

WARNING req.ind

91B, ra, FE2

Notify user, B is alerting

User B alerting

91D, ra, FE2 B_ANSWER

91C, ra, FE2

Notify served user Notify user, B answer CI_INV resp.conf

913, ra, FE2 CI IDLE

Inform user of intrusion result

Re-intrusion accepted ?

YES

NO WOB FE1

State of user C

Isolated

Conferenced Intrusion FE1

Isolation FE1

Figure 17 - SS-CI, SDL for functional entity FE1 (part 6 of 8)

- 52 -

* CI IDLE, Wait for response on INFORM, WOB FE1, user B alerting

General processes occuring in several states of FE1

EST_TERM req.ind

918, ra, FE2

Inform served user that established 93B, ra, FE1 call has released.

CI IDLE

* CI IDLE

Call released (from colocated CCA)

CI IDLE

Figure 17 - SS-CI, SDL for functional entity FE1 (part 7 of 8)

- 53 -

During intrusion/isolation

Isolation FE1

Wait on busy requested

REQUEST_WOB req.ind

919, ra, FE2

Wait for response on WOB request

REQUEST_WOB resp.conf

91A, ra, FE2

Served user requests forced release FORCED_REL req.ind

916, ra, FE2

Inform user Wait for response on forced release request.

WOB accepted ? YES

Isolation FE1

FORCED_REL resp.conf

WOB FE1

917, ra, FE2

Inform user of result of forced release request

NO Isolation FE1

Forced release accepted ? YES

CI IDLE

Figure 17 - SS-CI, SDL for functional entity FE1 (part 8 of 8)

- 54 -

7.4.2

Behaviour of FE2 Figure 18 shows the normal behaviour of FE2. Input signals from the left and output signals to the left represent primitives from and to FE1. Input signals from and output signals to the right represent information flows from and to FE3 and input signals from the collocated CC.

CI IDLE

Intrusion setup

Call request 92I, 92G, ra, FE1 (w/o CI_INV req.ind) from colocated CC

CI_INV req.ind with SETUP req.ind

ImmediateNO invocation implemented ? YES

92E,921, ra, FE1

Consultation not implemented

Immediate NO invocation provided ?

Consultation provided? NO

YES

Nonretention

Consultation implemented

Path retention

CI_INV req.ind with Basic Call SETUP req.ind

YES

Basic Call to proceed

CI IDLE 92I, rb, FE3 CI_ACT req.ind with Basic Call SETUP req.ind

Pending Intrusion

92G, rb, FE3 Path retention

Pending immediate invocation, ret

CI_ACT req.ind with or Basic call SETUP req.ind

921, rb, FE3

Non-retentio Retain all information from Basic Call SETUP

Pending consultatio non-retention

Pending consultation retention

Figure 18 - SS-CI, SDL for functional entity FE2 (part 1 of 10)

- 55 -

Intrusion setup, consultation, path retention.

Pending consultation retention

CI_AVAIL req.ind

923,rb, FE3

Start timer T1 923

INFORM req.ind

Basic call alerting or answered

CI_IDLE

923, ra, FE1

Wait for response on INFORM request

Timer T1 expires

Basic call to release

CI IDLE

CI_INV req.ind

924, ra, FE1

Stop timer T1

CI_INV req.ind

924,rb, FE3

Pending Intrusion

Figure 18 - SS-CI, SDL for functional entity FE2 (part 2 of 10)

- 56 -

Intrusion setup consultation, non-path retention

Pending consultation non-retention

Basic call released for reasons other than busy (from colocated CC)

Basic call alerting or answered Call release due to busy (from colocated CC.)

92H, rb, FE3 CI IDLE

Start timer T1 92H

CI IDLE

INFORM req.ind

92H, ra, FE1

Wait for CI_INV

Timer T1 expires

Basic call released towards CCA.

CI_INV req.ind

92F, rb, FE1

Stop timer T1

CI_INV req.ind

92F, rb, FE3

CI IDLE

Pending Intrusion

Figure 18 - SS-CI, SDL for functional entity FE2 (part 3 of 10)

- 57 -

Immediate invocation, path retention

Pending immediate invocation, ret

Basic call answered or alerting

CI_AVAIL req.ind

922, rb, FE3

CI IDLE

CI_INV req.ind

922, rb, FE3

Pending Intrusion

Figure 18 - SS-CI, SDL for functional entity FE2 (part 4 of 10)

- 58 -

Pending Intrusion

CI_INV resp.conf

925, rb, FE3

CI_INV resp.conf

925, ra, FE1

WARNING req.ind

92J, rb, FE2

92J, ra, FE1

Intrusion accepted YES NO CI IDLE

Conferenced State of user C

Intrusion FE2

Isolated

Isolation FE2

Figure 18 - SS-CI, SDL for functional entity FE2 (part 5 of 10)

- 59 -

Intrusion FE2

Intrusion in progress

REQUEST_WOB req.ind

EST_TERM req.ind

92C, ra, FE1

92B, rb, FE3

EST_TERM req.ind 92B, ra, FE1

CI IDLE FORCED_REL req.ind

929, ra, FE1 ISOLATE req.ind

FORCED_REL req.ind

929, rb, FE3

927, ra, FE1

ISOLATE req.ind

Wait for response on forced release request

927, rb, FE3

Wait for response on isolate request EST_TERM req.ind

92B, rb, FE3

EST_TERM req.ind 92B, ra, FE1

CI IDLE FORCED_REL resp.conf

FORCED_REL resp.conf

YES

92A, rb, FE3

Intrusion FE2

928, rb, FE3

ISOLATE resp.conf

92A, ra, FE1

Forced releaseNO accepted

CI IDLE

ISOLATE resp.conf

Isolation accepted

928, ra, FE1

YES

Isolation FE2

Figure 18 - SS-CI, SDL for functional entity FE2 (part 6 of 10)

- 60 -

Intrusion/isolation in progress

Isolation FE2

FORCED_REL req.ind

REQUEST_WOB req.ind

929, ra, FE1

92C, ra, FE1

REQUEST_WOB req.ind

929, rb, FE3

Wait for response on forced release request

92C, rb, FE3

Wait on response on WOB request

EST_TERM req.ind

92B, rb, FE3

EST_TERM req.ind 92B, ra, FE1

CI IDLE

FORCED_REL resp.conf

Forced releaseNO accepted

REQUEST_WOB resp.conf

92A, rb, FE3

REQUEST_WOB 92D, ra, FE1 resp.conf

92A, ra, FE1

WOB accepted YES

YES CI IDLE

92D, rb, FE3

Isolation FE2

WOB FE2

Figure 18 - SS-CI, SDL for functional entity FE2 (part 7 of 10)

- 61 -

Intrusion in progress Wait on busy requested

REQUEST_WOB req.ind

92C, rb, FE3

Wait for response on WOB request

REQUEST_WOB resp.conf

92D, rb, FE3

REQUEST_WOB 92D, ra, FE1 resp.conf

EST_TERM req.ind

92B, rb, FE3

EST_TERM req.ind 92B, ra, FE1

CI IDLE YES

WOB accepted

WOB FE2

Intrusion FE2

Figure 18 - SS-CI, SDL for functional entity FE2 (part 8 of 10)

- 62 -

WOB FE2

WOB in progress

B_ALERTING req.ind

92K, rb, Fe3

B_ALERTING req.ind

92K, ra, FE1

wait for further action

CI _INV req.ind

B_ANSWER req.ind

92L, rb, FE3

B_ANSWER req.ind

92L, ra, FE1

CI IDLE

926, ra, FE1

Pending reintrusion WARNING req.ind CI_INV resp.conf

925, rb, FE3 WARNING req.ind

CI_INV resp.conf

Reintrusion accepted ? NO WOB FE2

92J, rb, FE2

92J,ra, FE1

925, ra, FE1

YES Conferenced

Intrusion FE2

State of user C

Isolated

Isolation FE2

Figure 18 - SS-CI, SDL for functional entity FE2 (part 9 of 10)

- 63 -

General processes occuring in several states of FE2

* CI IDLE, pending consultation non retention

Call released (from colocated CC)

CI IDLE

Figure 18 - SS-CI, SDL for functional entity FE2 (part 10 of 10)

- 64 -

7.4.3

Behaviour of FE3 Figure 19 shows the normal behaviour of FE3. Input signals from the left and output signals to the left represent primitives from and to FE2. Input signals from and output signals to the right represent information flows from and to FE4 and input signals from the collocated CCA.

Call intrusion immediate requested

CI IDLE

with Basic Call CI_INV SETUP req.ind 936, rb, FE2 req.ind

931, rb, FE2

wait CI_ACT

wait CI_INV

destination free

CI_ACT req.ind with Basic Call SETUP

destination busy

User B's CIPL < CICL? WOB YES

Basic call to proceed

INFO_REQ req.ind

932, rc, FE4

CI IDLE Wait for information Established call released INFO_REQ resp.conf (from colocated CC)

Waiting on busy?

933, rc, FE4

YES 12

NO Basic call to proceed normally WOB FE3

CI IDLE

Figure 19 - SS-CI, SDL for functional entity FE3 (part 1 of 8)

- 65 -

wait CI_ACT

Call intrusion capability check

destination free

destination busy

User B's CIPL < CICL? YES

Basic call to proceed normally

CI_AVAIL req.ind CI IDLE

935, rb, FE2

Path retention with Basic Call CI_INV SETUP req.ind 936, rb, FE2 req.ind

Call released (from colocated CC)

wait CI_INV2

CI IDLE

destination free

destination busy User B's NO CIPL < CICL? YES INFO_REQ req.ind

932, rc, FE4

Wait for information 2

Basic call to proceed normally

CI IDLE

Established call released (from colocated CC) Basic call to proceed normally CI IDLE

INFO_REQ resp.conf

933, rc, FE4

Figure 19 - SS-CI, SDL for functional entity FE3 (part 2 of 8)

- 66 -

Intrusion requested, warning tone provided

NO CI_INV resp.conf

Intrusion allowed ? 934

93B, rb, FE2

YES

Warning tone toNO user B and C ?

Is served user in WOB state NO YES WOB FE3

The FE shall compare the CIC with the CIPL values of user B user C. If the CICL is higher tha both CIPL´s, intrusion is permit

No tone

YES WARNING req.ind

CI IDLE

937, rc, FE4

Warning to user B

Warning tone to served user? YES WARNING req.ind

937, rb, FE2

Start timer T2

Wait for timer T2

Figure 19 - SS-CI, SDL for functional entity FE3 (part 3 of 8)

- 67 -

Intrusion requested, no warning tone provided

Wait for timer T2 Established call released (from colocated CC)

CI_INV resp.conf

93B, Rb, FE2

Intrusion is rejected. Basic call to proceed.

CI IDLE

Timer T2 elapsed No tone CI_INV resp.conf

93B, rb, FE2

Inform user B about the intrusion User C to be autoYES matically isolatedNO ?

C_ISOLATED req.ind

Isolation FE3

939, rc, FE4

C_INTR req.ind

Intrusion FE3

938, 93H, rc, Fe4

Figure 18 (part 2) SS-CI, SDL for FE3

Figure 19 - SS-CI, SDL for functional entity FE3 (part 4 of 8)

- 68 -

Intrusion in progress

Intrusion FE3

Established call released (from colocated CC)

REQUEST_WOB req.ind

EST_TERM req.ind 93G, rb, FE2

CI IDLE

FORCED_REL req.ind

93E, rb, FE2

93F, rb, FE2

FORCED_REL 93F, RB, FE2 resp.conf

Forced release accepted NO ISOLATE req.ind

93D, rb, FE2 YES

ISOLATE resp.conf

Intrusion FE3

93D, rb, FE2 Inform user B

Isolate accepted

NO C_FORCED_REL req.ind

YES C_ISOLATED req.ind

93F, rc, FE4

93D, rc, FE4 CI IDLE

Inform user B

Isolation FE3

Intrusion FE3

Figure 19 - SS-CI, SDL for functional entity FE3 (part 5 of 8)

- 69 -

Intrusion/isolation in progress

REQUEST_WOB req.ind

Isolation FE3

93E, rb, FE2

FORCED_REL req.ind

93F, rb, FE2

FORCED_REL 93F, RB, FE2 resp.conf

Forced release accepted NO Established call released (from colocated CC)

EST_TERM req.ind 93G, rb, FE2

YES

Isolation FE3

Inform user B

CI IDLE C_FORCED_REL req.ind

93F, rc, FE4

CI IDLE

Figure 19 - SS-CI, SDL for functional entity FE3 (part 6 of 8)

- 70 -

Intrusion in progress, Wait on busy requested.

REQUEST_WOB 93E, rb, FE2 resp.conf

YES

INTR_TERM req.ind

Has WOB NO been accepted ?

93E, rc, FE4 Conference

Previous state

Isolation

WOB FE3 Intrusion FE3

CI_INV req.ind

WOB

936, rb, FE2

Isolation FE3

User B starts alerting

B_ALERTING req.ind

93I, rb, FE2

Wait for further user B action

User B answers

B_ANSWER req.ind93J, rb, FE2

CI IDLE

Figure 19 - SS-CI, SDL for functional entity FE3 (part 7 of 8)

- 71 -

* CI IDLE

General processes occuring in several states of FE3

Intruding call released (from colocated CC) INTR_TERM req.ind

93C, rc, FE4

Inform user B about the termination of SS-CI

CI IDLE

Figure 19 - SS-CI, SDL for functional entity FE3 (part 8 of 8)

- 72 -

7.4.4

Behaviour of FE4 Figure 20 shows the normal behaviour of FE4. Input signals from the left and output signals to the left represent primitives from and to FE3. Input signals from and output signals to the right represent information flows from and to FE5 and input signals from the collocated CC.

Intrusion

CI IDLE

INFO_REQ req.ind

INFO_REQ resp conf

941, rc, FE3

C_INTR req.ind

943, rc, FE3

943, rd, FE5

942, rd, FE5

C_ISOLATED req.ind

944, rc, FE3

944, rd, FE5

CI IDLE

C_FORCED_REL req.ind

WARNING req.ind

942, rc, FE3

CI IDLE

C_INTR req.ind

WARNING req.ind

945, rc, FE3

INTR_TERM req.ind

C_FORCED_REL 945, rd, FE5 req.ind

INTR_TERM req.ind

CI IDLE

946, rc, FE3

946, rd, FE5

Figure 20 - SS-CI, SDL for functional entity FE4

- 73 -

7.4.5

Behaviour of FE5 Figure 21 shows the normal behaviour of FE5. Input signals from the left and output signals to the left represent primitives from and to FE4. Input signals from and output signals to the right represent primitives from and to the user and input signals from the collocated CCA.

Intrusion

CI IDLE

WARNING req.ind C_INTR req.ind

952, rd, FE4

Inform user that intrusion has begun

951, rd, FE4

Warn the served user of the impending intrusion

CI IDLE

C_FORCED_REL req.ind

954, rc, FE3

C_ISOLATED req.ind

Inform user C of the force release. Intrusion end.

Inform user about isolation. Intrusion in progress.

CI IDLE

INTR_TERM req.ind

955, rd, FE4

Inform user intrusion terminated. Established call remains.

CI IDLE

Figure 21 - SS-CI, SDL for functional entity FE5

953, rd, FE4

- 74 -

7.5

Allocation of functional entities to physical equipment The allocation of FEs to physical locations as shown in table 12 shall apply. "TE" represents a TE attached to a PISN. Where a terminal is stimulus with respect to SS-CI, any FE shown as residing in the TE shall reside instead in the TE's local PINX. Table 12 - Scenarios for the allocation of FEs to physical equipment

Scenario 1

7.6

FE1

FE2

FE3

FE4

FE5

served user TE

served user PINX

user B PINX/TE

user C PINX

user C TE

Interworking considerations On an incoming call from another network: If the other network supports SS-CI, then FE1 and FE2 shall be in the other network (table 13, scenario 2). On an outgoing call to another network: i) If the other network fully supports SS-CI, then FE3 shall be in the other network (table 13, scenario 4). ii) If the other network does not support SS-CI, then FE3 shall be in the gateway PINX (table 13, scenario 7) and: a) shall supply a response/confirmation with Result = "long term denial" to a CI_INV request/indication; b) shall ignore receipt of a CI_ACT request/indication. iii) If the other network supports SS-CI only without path retention, then FE3 shall be distributed between the gateway PINX and the other network (table 13, scenario 8). The gateway PINX: a) shall forward any CI_INV request/indication to the other network; b) on receipt of CI_ACT request/indication, shall send a request for call establishment without SS-CI to the other network. If the call fails due to busy called user, the Gateway PINX may optionally retain all call set up information and send a CI_AVAIL request/indication to FE2. On receipt of a CI_INV request/indication, the Gateway PINX shall send a request for call establishment with SS- CI to the other network. Depending on the result of the request for call establishment, FE2 shall send a CI_INV response/confirmation specifying appropriate value for element Result. The actions performed may depend on the requirements of the other network. If user B is in the PISN, user C is in another network, and the other network is able to supply FE4 functionality, FE4 and FE5 shall be in the other network (table 13, scenario 5). If user B is in the PISN, user C is in another network, and the other network is unable to provide FE4 functionality, FE4 shall be in the Gateway PINX and FE5 shall be in the other network (table 13, scenario 3). If user C is in the PISN and user B is in another network, FE1, FE2 and FE3 shall be in the other network (table 13, scenario 6).

- 75 -

Table 13 - Scenarios for allocation of FEs to physical equipment for normal operation in case of interworking with another network FE1

FE2

FE3

FE4

FE5

Scenario 2

other N/W

user B PINX/TE

user C PINX

user C TE

Scenario 3

served user TE

served user PINX

user B PINX/TE

gateway PINX

other N/W

Scenario 4

served user TE

served user PINX

other N/W

Scenario 5

served user TE

user B PINX/TE

other N/W

Scenario 6

other N/W

user C PINX

user C TE

Scenario 7

served user TE

served user PINX

gateway PINX

other N/W

Scenario 8

served user TE

served user PINX

gateway PINX + other N/W

other N/W

Printed copies can be ordered from: ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland Fax: Internet:

+41 22 849.60.01 [email protected]

Files can be downloaded from our FTP site, ftp.ecma.ch, logging in as anonymous and giving your E-mail address as password. This Standard is available from library ECMA-ST as a compacted, self-expanding file in MSWord 6.0 format (file E202-DOC.EXE) and as an Acrobat PDF file (file E202-PDF.PDF). File E202-EXP.TXT gives a short presentation of the Standard. Our web site, http://www.ecma.ch, gives full information on ECMA, ECMA activities, ECMA Standards and Technical Reports.

ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland This Standard ECMA-202 is available free of charge in printed form and as a file. See inside cover page for instructions

ECMA-202 — Private Integrated Services Network (PISN) - Specification, functional model and information flows - Call intrusion supplementary service (CISD) (June 1997)

Related documents