Conceptio › Archive › ECMA International

ECMA Internationalopen access

ECMA-174 — Private Integrated Services Network (PISN) - Inter-exchange signalling protocol - Call diversion supplementary services (QSIG-CF) (December 2001)

ECMA International · ECMA International

ECMA International · Standards · License: Open Access

ecma ecmainternational exchange integrated inter network pisn private

ecma, standard, ecma international, specification, ecma-174, ecma 174, 174, private, integrated, services, network, pisn, inter-exchange, signalling, protocol, call, diversion, supplementary, qsig-cf

S tandard ECMA-174

3rd Edition - December 2001

Standardizing Information

and

Communication

Systems

Private Integrated Services Network (PISN) Inter-Exchange Signalling Protocol Call Diversion Supplementary Services

Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http://www.ecma.ch - Internet: [email protected]

S tandard ECMA-174

3rd Edition - December 2001

Standardizing

Information

and

Communication

Systems

Private Integrated Services Network (PISN) Inter-Exchange Signalling Protocol Call Diversion Supplementary Services (QSIG-CF)

Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http://www.ecma.ch - Internet: [email protected] IW

Ecma-174.doc

14-01-02 09,30

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. This particular Standard specifies the signalling protocol for use at the Q reference point in support of the Call Diversion supplementary services: • Call Forwarding Unconditional (SS-CFU) • Call Forwarding Busy (SS-CFB) • Call Forwarding No Reply (SS-CFNR) • Call Deflection (SS-CD) The protocol defined in this Standard forms part of the PSS1 protocol (informally known as QSIG). 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-174 (published by ECMA in June 1992), the 2nd Edition was extended to include the Call Deflection supplementary service (SS-CD) and changes were incorporated in order to achieve alignment with International Standard ISO/IEC 13873:1995(E) published by ISO/IEC in December 1995. Compared to the 2nd Edition of Standard ECMA-174 (published by ECMA in June 1997), this 3rd Edition incorporates editorial errata and removes all differences with International Standard ISO/IEC 13873:1995. The 3rd edition also incorporates migration to ASN.1 version 1997 and clarifies normative text to explicitly align SS-CFNR forward switching procedures with SS-CFNR re-route procedures.

Adopted as 3rd Edition of Standard ECMA-174 by the General Assembly of December 2001.

- i -

Table of contents 1

Scope

Conformance

References (normative)

5 6

Definitions 4 . 1 E x te r n a l d e f in itio n s 4 . 2 O th e r d e f in itio n s 4.2.1 Activating PINX 4.2.2 Bu sy 4.2.3 Co n n e c te d n u mb e r 4.2.4 Deactivating PINX 4.2.5 D iv e r s io n 4.2.6 D iv e r te d - to n u mb e r 4.2.7 Diverted-to PINX 4.2.8 D iv e r te d - to u s e r 4.2.9 D iv e r tin g c a u s e 4.2.10 D iv e r tin g n u mb e r 4.2.11 F o r w a r d in g 4.2.12 F o r w a r d s w itc h in g 4.2.13 I n te r r o g a tin g P I N X 4.2.14 L a s t d iv e r tin g u s e r 4.2.15 O r i g i n a l c a l l e d n u mb e r 4.2.16 Original called user 4.2.17 P a r tia l r e r o u te in g 4.2.18 P r e s e n ta tio n in d ic a to r 4.2.19 Re r o u te in g 4.2.20 Re r o u te in g P I N X 4.2.21 Served user 4.2.22 User A 4.2.23 User B 4.2.24 User B1, user B2, user B3, etc. 4.2.25 User C Acronyms Signalling protocol for the support of SS-DIV 6 . 1 S S - D I V d e s c r ip tio n 6 . 2 S S - D I V o p e r a tio n a l r e q u ir e me n ts 6.2.1 P r o v is io n /w ith d r a w a l 6.2.2 Re q u ir e me n ts o n th e O r ig in a tin g P I N X 6.2.3 Re q u ir e me n ts o n th e S e r v e d U s e r P I N X

2 2 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 5 5 5 5 6 6

- ii -

6.2.4 Re q u ir e me n ts o n th e D iv e r te d - to P I N X 6.2.5 Re q u ir e me n ts o n th e Re r o u te in g P I N X 6.2.6 Re q u ir e me n ts o n a T r a n s it P I N X 6.2.7 Re q u ir e me n ts o n th e A c tiv a tin g P I N X 6.2.8 Re q u ir e me n ts o n th e D e a c tiv a tin g P I N X 6.2.9 Re q u ir e me n ts o n th e I n te r r o g a tin g P I N X 6 . 3 S S - D I V c o d in g r e q u ir e me n ts 6.3.1 Operations 6.3.2 I n f o r ma t i o n e l e me n t s 6.3.3 Messages 6 . 4 S S - D I V s ta te d e f in itio n s 6.4.1 States at the Originating PINX 6.4.2 States at the Served User PINX 6.4.3 States at the Diverted-to PINX 6.4.4 States at the Rerouteing PINX 6.4.5 States at the Activating PINX 6.4.6 States at the Deactivating PINX 6.4.7 States at the Interrogating PINX 6 . 5 S S - D I V S ig n a llin g p r o c e d u r e s 6.5.1 Actions at the Originating PINX 6.5.2 Actions at a Transit PINX 6.5.3 Actions at the Served User PINX 6.5.4 A c tio n s a t th e Re r o u te in g P I N X 6.5.5 A c tio n s a t th e D iv e r te d - to P I N X 6.5.6 Actions at the Activating PINX 6.5.7 Actions at the Deactivating PINX 6.5.8 A c tio n s a t th e I n te r r o g a tin g P I N X 6 . 6 S S - D I V I mp a c t o f in te r w o r k in g w ith p u b lic I S D N s 6.6.1 I mp a c t o f in te r w o r k in g o n in c o min g c a lls 6.6.2 I mp a c t o f in te r w o r k in g o n o u tg o in g c a lls 6 . 7 S S - D I V I mp a c t o f in te r w o r k in g w ith n o n - I S D N s 6.7.1 I mp a c t o f in te r w o r k in g o n in c o min g c a lls 6.7.2 I mp a c t o f in te r w o r k in g o n o u tg o in g c a lls 6 . 8 P r o to c o l in te r a c tio n s b e tw e e n S S - D I V a n d o th e r S S s a n d A N F s 6.8.1 P r o to c o l in te r a c tio n s o f Ca ll F o r w a r d in g U n c o n d itio n a l ( S S - CF U ) 6.8.2 P r o to c o l in te r a c tio n s o f Ca ll F o r w a r d in g Bu s y ( S S - CF B) 6.8.3 P r o to c o l in te r a c tio n s o f Ca ll F o r w a r d in g N o Re p ly ( S S - CF N R) 6.8.4 P r o to c o l in te r a c tio n s o f Ca ll D e f le c tio n ( S S - CD ) 6 . 9 S S - D I V p a r a me t e r v a l u e s ( t i me r s ) 6.9.1 T i me r T 1 6.9.2 T i me r T 2 6.9.3 T i me r T 3 6.9.4 T i me r T 4 6.9.5 T i me r T 5

6 6 6 7 7 7 7 7 14 14 14 14 14 15 15 15 15 15 16 16 17 17 20 22 22 23 23 24 24 25 25 25 25 25 26 28 29 30 30 30 31 31 31 31

A n n e x A - P r o t o c o l I m p l e m e n t a t i o n C o n fo r m a n c e S t a t e m e n t ( P I C S ) p r o f o r m a

- iii -

Annex B - Imported ASN.1 definitions

A n n e x C - S p e c i f i c a t i o n a n d D e s c r i p t i o n L a n gu a g e ( S D L ) r e p r e s e n t a t i o n o f p r o c e d u r e s

A n n e x D - Ex a m p le s o f m e s s a g e s e q u e n c e s

Annex E - Bibliography

A n n e x F - A S N . 1 d e f in it io n s a c c o r d in g t o I TU - T R e c s . X . 2 0 8 / X . 2 0 9

Scope This Standard specifies the signalling protocol for the support of Call Diversion supplementary services (SS-DIV) at the Q reference point between Private Integrated services Network eXchanges (PINXs) connected together within a Private Integrated Services Network (PISN). The Call Diversion supplementary services are Call Forwarding Unconditional (SS-CFU), Call Forwarding Busy (SS-CFB), Call Forwarding No Reply (SS-CFNR) and Call Deflection (SS-CD). SS-CFU, SS-CFB, SS-CFNR and SS-CD are supplementary services which permit a served user to have the PISN send all or specific incoming calls addressed to the served user's PISN number to another number. The Q reference point is defined in ECMA-133. Service specifications are produced in three stages and according to the method specified in ETS 300 387. This Standard contains the stage 3 specification for the Q reference point and satisfies the requirements identified by the stage 1 and stage 2 specifications in ECMA-173. The signalling protocol for SS-DIV operates on top of the signalling protocol for basic circuit switched call control, as specified in ECMA-143 and uses certain aspects of the generic procedures for the control of supplementary services specified in ECMA-165. This Standard also specifies additional signalling protocol requirements for the support of interactions at the Q reference point between SS-DIV and other supplementary services and ANFs. This Standard is applicable to PINXs which can be interconnected to form a PISN.

Conformance In order to conform to this Standard, a PINX shall satisfy the requirements identified in the Protocol Implementation Conformance Statement (PICS) proforma in annex A.

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-133

Private Integrated Services Network (PISN) - Reference Configuration for PISN Exchanges (PINX) (International Standard ISO/IEC 11579-1)

ECMA-142

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

ECMA-143

Private Integrated Services Network (PISN) - Circuit-mode Bearer Services - InterExchange Signalling Procedures and Protocol (International Standard ISO/IEC 11572)

ECMA-164

Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Name Identification Supplementary Services (International Standard ISO/IEC 13868)

ECMA-165

Private Integrated Services Network (PISN) - Generic Functional Protocol for the Support of Supplementary Services - Inter-Exchange Signalling Procedures and Protocol (International Standard ISO/IEC 11582)

ECMA-173

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

ECMA-178

Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Call Transfer Supplementary Services (International Standard ISO/IEC 13869)

- 2 -

ECMA-186

Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Call Completion Supplementary Services (International Standard ISO/IEC 13870)

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. Q.950

Supplementary services protocols, structure and general principles (2000)

ITU-T Rec. Q.952

Stage 3 service description for call offering supplementary services using DSS 1 Diversion supplementary services (1993)

ITU-T Rec. Z.100

Specification and description language (1999)

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: – Application Protocol Data Unit (APDU)

(ECMA-165)

– Basic Service

(ITU-T Rec. I.210)

– Call, Basic Call

(ECMA-165)

– Coordination Function

(ECMA-165)

– End PINX

(ECMA-143)

– Incoming Gateway PINX

(ECMA-143)

– Interpretation APDU

(ECMA-165)

– Network determined user busy

(ITU-T Rec. I.221)

– Notification

(ECMA-165)

– Originating PINX

(ECMA-143)

– Outgoing Gateway PINX

(ECMA-143)

– Primary PINX

(ECMA-178)

– Private Integrated Services Network (PISN)

(ECMA-133)

– Private Integrated services Network eXchange (PINX)

(ECMA-133)

– Secondary PINX

(ECMA-178)

– Signalling

(ITU-T Rec. I.112)

– Supplementary Service

(ITU-T Rec. I.210)

– Supplementary Service Control Entity

(ECMA-165)

– Terminating PINX

(ECMA-143)

– Transferring PINX

(ECMA-178)

– Transit PINX

(ECMA-143)

– User

(ECMA-142)

– User determined user busy

(ITU-T Rec. I.221)

- 3 -

4.2

Other definitions

4.2.1

A c t iv a t in g P I N X The Activating PINX is the PINX serving the activating user.

4.2.2

Bu s y An ISDN destination is considered to be busy if either a "network determined user busy" or a "user determined user busy" condition exists.

4.2.3

Connected number The number of the user that answers (user C).

4.2.4

D e a c t iv a t in g P I N X The Deactivating PINX is the PINX serving the deactivating user.

4.2.5

D iv e r s io n Diversion is the redirection of a call, on request of a called user and prior to answer, to a number different from the number of that called user.

4.2.6

Diverted-to number The diverted-to number is the number to which a call is diverted.

4.2.7

D iv e r t e d - t o P I N X The Diverted-to PINX is the PINX serving the diverted-to user.

4.2.8

Diverted-to user The diverted-to user is the user to which a call is diverted.

4.2.9

D iv e r t in g c a u s e The diverting cause is a parameter which contains the reason for the diversion, e.g. CFU, CFB, CFNR.

4.2.10

D iv e r t in g n u m b e r The diverting number is the number of the served user.

4.2.11

F o r wa r d in g Forwarding is the type of diversion invoked automatically by the network in accordance with information previously registered in the network against the called number.

4.2.12

F o r wa r d s wit c h in g A network routeing algorithm which performs the diversion by joining together the first connection from user A's node to user B's node and a second, new connection from user B's node to user C's node.

4.2.13

I n t e r r o g a t in g P I N X The Interrogating PINX is the PINX serving the interrogating user.

4.2.14

La s t d iv e r t in g u s e r The last diverting user is the served user from the point of view of the diverted-to user for a particular stage of call diversion. In the case of a call subject to a single stage of call diversion, user B is the last diverting user from the point of view of user C. In the case of a call subject to multiple stages of call diversion, user B1 is the last diverting user from the point of view of user B2, user B2 is the last diverting user from the point of view of user B3, etc. The served user for the final stage of call diversion is the last diverting user from the point of view of user C.

4.2.15

O r ig in a l c a lle d n u m b e r The original called number is the number of user B (in case of multiple call diversion user B1).

4.2.16

O r ig in a l c a lle d u s e r The original called user is the first served user of a call which is subject to one or more stages of call diversion, i.e. user B or B1.

- 4 -

4.2.17

Partial rerouteing A network routeing algorithm which performs the call diversion by replacing a particular part of the connection from user A's node (located in the public ISDN) to user B's node (located in a PISN) by another connection from user A's node to user C's node (located in the public ISDN). The new connection is established completely within the public ISDN by joining together the original connection from user A's node to the public ISDN gateway node and a second, new connection from the public ISDN gateway node to user C's node.

4.2.18

P r e s e n t a t io n in d ic a t o r The presentation indicator is the indicator showing whether the diverted-to number should be presented to the calling user, as derived from user C's Calling/connected Line Identification Restriction (CLIR) supplementary service.

4.2.19

R e r o u t e in g A network routeing algorithm which performs the call diversion by replacing the connection from user A's node to user B's node by another connection from user A's node to user C's node.

4.2.20

R e r o u t e in g P I N X A Rerouteing PINX is the PINX which executes call diversion. NOTE In case of rerouteing, the Rerouteing PINX is either the Originating PINX or the Incoming Gateway PINX. In case of forward switching, the Rerouteing PINX is the Terminating PINX.

4.2.21

Served user The served user is the user of a particular PISN number who is requesting that calls to his/her number be diverted. This user may also be referred to as the diverting user or the called user.

4.2.22

User A User A is the calling user of a call which is subject to call diversion.

4.2.23

User B User B is the served (diverting) user of a call which is subject to call diversion.

4.2.24

User B1, user B2, user B3, etc. These are the served (diverting) users of a call which are subject to multiple stages of diversion. B1 is the first served user, B2 is the second served user, B3 is the third served user, etc. NOTE B2 is also the diverted-to user with respect to the first stage of call diversion, B3 is also the diverted-to user with respect to the second stage of call diversion, etc.

4.2.25

User C User C is the diverted-to user with respect to the final stage of call diversion.

Acronyms ANF

Additional Network Feature

APDU

Application Protocol Data Unit

ASN.1

Abstract Syntax Notation One

CLIR

Calling/connected Line Identification Restriction

DTN

Diverted-to Number

ISDN

Integrated Services Digital Network

NDUB

Network Determined User Busy

NFE

Network Facility Extension

NSO

Notification Subscription Option

- 5 -

PICS

Protocol Implementation Conformance Statement

PINX

Private Integrated services Network eXchange

PISN

Private Integrated Services Network

SDL

Specification and Description Language

Supplementary Service

SS-CDA

Call Deflection from Alert supplementary service

SS-CDI

Call Deflection Immediate supplementary service

SS-CF

Call Forwarding supplementary service

SS-CFB

Call Forwarding Busy supplementary service

SS-CFNR

Call Forwarding No Reply supplementary service

SS-CFU

Call Forwarding Unconditional supplementary service

SS-CLIR

Calling/Connected Line Identification Restriction supplementary service

SS-CNIP

Calling Name Identification Presentation supplementary service

SS-CNIR

Calling/Connected Name Identification Restriction supplementary service

SS-DIV

Call Diversion supplementary services

Terminal Equipment

UDUB

User Determined User Busy

Signalling protocol for the support of SS-DIV

6.1

SS-DIV description SS-CFU enables a served user to have the PISN redirect to another user, calls which are addressed to the served user's PISN number. SS-CFU may operate on all calls or just those associated with specified basic services. The served user's ability to originate calls is unaffected by SS-CFU. After CFU has been activated calls are forwarded independently of the status of the served user. SS-CFB enables a served user to have the PISN redirect to another user, calls which are addressed to the served user's PISN number and meet busy. SS-CFB may operate on all calls or just those associated with specified basic services. The served user's ability to originate calls is unaffected by SS-CFB. SS-CFNR enables a served user to have the PISN redirect to another user, calls which are addressed to the served user's PISN number, and for which the connection is not established within a predefined period of time. SS-CFNR may operate on all calls or just those associated with specified basic services. The served user's ability to originate calls is unaffected by SS-CFNR. The Call Deflection supplementary service (SS-CD) has no explicit impact on this Standard. Support for the two versions of CD, as defined in ECMA-173, is achieved as follows: – Call Deflection from Alert (CDA) is covered by the signalling protocol of SS-CFNR, – Call Deflection Immediate (CDI) is covered by the signalling protocol of SS-CFU. The maximum number of diversions to a single call is an implementation option. When counting the number of diversions, all types of diversions shall be included. These supplementary services are applicable to all basic services defined in ECMA-142.

6.2 6.2.1

SS-DIV operational requirements P r o v is io n /wit h d r a wa l Provision and withdrawal shall be in accordance with the related classes of subscription options that have an impact on the signalling protocol at the Q reference point as summarized in table 1.

- 6 -

Table 1 - Subscription options Subscription Parameter

Value

Calling user receives notification that call has been diverted

- No - Yes without diverted-to number/name - Yes with diverted-to number/name - No - Yes

Served user releases his/her number/name to diverted to user

The service will be withdrawn by the service provider at the subscriber request or for administration reasons. The subscription parameters and values offered by a PINX are an implementation matter. A PISN may offer more or less parameters and values than those specified in this clause. 6.2.2

Requirements on the Originating PINX Call establishment procedures for the outgoing side of an inter-PINX link and call release procedures, as specified in ECMA-143, shall apply. Generic procedures for the call related control of supplementary services, as specified in ECMA-165 for an End PINX, shall apply. In addition, the generic procedures for notification, as specified in ECMA165 for an End PINX, shall apply.

6.2.3

Requirements on the Served User PINX Call establishment for the incoming side of an inter-PINX link and call release procedures, as specified in ECMA-143, shall apply. Generic procedures for the call related control of supplementary services, as specified in ECMA-165 for an End PINX, shall apply. Generic procedures for the call independent control (connection orientated) of supplementary services, as specified in ECMA-165 for a Terminating PINX, shall apply if the remote activation, deactivation or interrogation procedure is supported. Generic procedures for the call independent control (connection orientated) of supplementary services, as specified in ECMA-165 for an Originating PINX, shall apply if the procedure for verification of the diverted-to number is supported.

6.2.4

Requirements on the Diverted-to PINX Call establishment for the incoming side of an inter-PINX link and call release procedures, as specified in ECMA-143, shall apply. Generic procedures for the call related control of supplementary services, as specified in ECMA-165 for an End PINX, shall apply. Generic procedures for the call independent control (connection orientated) of supplementary services, as specified in ECMA-165 for a Terminating PINX, shall apply if the procedure for verification of the diverted-to number is supported.

6.2.5

Requirements on the Rerouteing PINX Call establishment for the outgoing and incoming side of an inter-PINX link and call release procedures, as specified in ECMA-143, shall apply. Generic procedures for the call related control of supplementary services, as specified in ECMA-165 for an End PINX, shall apply.

6.2.6

Requirements on a Transit PINX Basic call procedures for call establishment and call clearing at a Transit PINX, as specified in ECMA-143, shall apply.

- 7 -

Generic procedures for the call related control and call independent control (connection orientated) of supplementary services, as specified in ECMA-165 for a Transit PINX, shall apply. In addition, the generic procedures for notification, as specified in ECMA-165 for a Transit PINX, shall apply. 6.2.7

Requirements on the Activating PINX Generic procedures for the call independent control (connection orientated) of supplementary services, as specified in ECMA-165 for an Originating PINX, shall apply.

6.2.8

Requirements on the Deactivating PINX Generic procedures for the call independent control (connection orientated) of supplementary services, as specified in ECMA-165 for an Originating PINX, shall apply.

6.2.9

Requirements on the Interrogating PINX Generic procedures for the call independent control (connection orientated) of supplementary services, as specified in ECMA-165 for an Originating PINX, shall apply.

6.3 6.3.1

SS-DIV coding requirements O p e r a t io n s The operations defined in Abstract Syntax Notation number 1 (ASN.1) in table 2 shall apply. The notation is in accordance with ITU-T Rec. X.680 and X.690. The ITU-T Rec. X.208 and X.209 superseded version is in annex F.

- 8 -

Table 2 - Operations in Support of SS-DIV Call-Diversion-Operations-asn1-97 { iso (1) standard (0) pss1-call-diversion (13873) call-diversion-operations-asn1-97 (1) } DEFINITIONS EXPLICIT TAGS

::=

BEGIN IMPORTS

OPERATION, ERROR FROM Remote-Operations-Information-Objects { joint-iso-itu-t remote-operations (4) informationObjects(5) version1(0)} EXTENSION, Extension{} FROM Manufacturer-specific-service-extension-class-asn1-97 { iso (1) standard (0) pss1-generic-procedures (11582) msi-class-asn1-97 (11) } PSS1InformationElement FROM PSS1-generic-parameters-definition-asn1-97 { iso (1) standard (0) pss1-generic-procedures (11582) pss1-generic-parameters-asn1-97 (17)

} Address, PartyNumber, PartySubaddress, PresentedNumberScreened, PresentedNumberUnscreened, PresentationAllowedIndicator FROM Addressing-Data-Elements-asn1-97 { iso (1) standard (0) pss1-generic-procedures (11582) addressing-data-elements-asn1-97 (20) } Name FROM Name-Operations-asn1-97 { iso (1) standard (0) pss1-name (13868) name-operations-asn1-97 (1) } userNotSubscribed, notAvailable, invalidServedUserNr, basicServiceNotProvided, resourceUnavailable, supplementaryServiceInteractionNotAllowed FROM General-Error-List { ccitt recommendation q 950 general-error-list (1) };

Call-Diversion-Operations OPERATION ::= {activateDiversionQ | deactivateDiversionQ | interrogateDiversionQ | checkRestriction | callRerouteing | divertingLegInformation1 | divertingLegInformation2 | divertingLegInformation3 | cfnrDivertedLegFailed}

- 9 -

Table 2 - Operations in Support of SS-DIV (continued) activateDiversionQ OPERATION ::={ -- Sent from the Activating PINX to the Served User PINX ARGUMENT SEQUENCE { procedure Procedure, basicService BasicService, divertedToAddress Address, servedUserNr PartyNumber, activatingUserNr PartyNumber, extension CHOICE { single [1] IMPLICIT Extension{{DiversionExtensionSet}} , multiple[2] IMPLICIT SEQUENCE OF Extension{{DiversionExtensionSet}} } OPTIONAL } RESULT

CHOICE { null NULL, single [1] IMPLICIT Extension{{DiversionExtensionSet}}, multiple[2] IMPLICIT SEQUENCE OF Extension{{DiversionExtensionSet}} } userNotSubscribed | notAvailable | invalidServedUserNr | basicServiceNotProvided | resourceUnavailable | invalidDivertedToNr | specialServiceNr | diversionToServedUserNr | temporarilyUnavailable | notAuthorized | unspecified }

ERRORS

{

CODE

local: 15}

deactivateDiversionQ OPERATION ::={ -- Sent from the Deactivating PINX to the Served User PINX ARGUMENT SEQUENCE { procedure Procedure, basicService BasicService, servedUserNr PartyNumber, deactivatingUserNr PartyNumber, extension CHOICE { single [1] IMPLICIT Extension{{DiversionExtensionSet}} , multiple[2] IMPLICIT SEQUENCE OF Extension{{DiversionExtensionSet}} } OPTIONAL } RESULT CHOICE { null NULL, single [1] IMPLICIT Extension{{DiversionExtensionSet}} , multiple[2] IMPLICIT SEQUENCE OF Extension{{DiversionExtensionSet}} } ERRORS {userNotSubscribed | notAvailable| invalidServedUserNr | temporarilyUnavailable | notAuthorized | unspecified } CODE

local: 16}

- 10 -

Table 2 - Operations in Support of SS-DIV (continued) interrogateDiversionQ OPERATION ::={ -- Sent from the Interrogating PINX to the Served User PINX ARGUMENT SEQUENCE { procedure Procedure, basicService BasicService DEFAULT allServices, servedUserNr PartyNumber, interrogatingUserNr PartyNumber, extension CHOICE { single [1] IMPLICIT Extension{{DiversionExtensionSet}} , multiple[2] IMPLICIT SEQUENCE OF Extension{{DiversionExtensionSet}} } OPTIONAL } RESULT ERRORS

IntResultList

CODE

local: 17}

{userNotSubscribed | notAvailable | invalidServedUserNr | temporarilyUnavailable | notAuthorized | unspecified }

checkRestriction OPERATION ::={ -- Sent from the Served User PINX to the Diverted-to PINX ARGUMENT SEQUENCE { servedUserNr PartyNumber, basicService BasicService, divertedToNr PartyNumber, extension CHOICE { single [1] IMPLICIT Extension{{DiversionExtensionSet}} , multiple[2] IMPLICIT SEQUENCE OF Extension{{DiversionExtensionSet}} } OPTIONAL } RESULT CHOICE { null NULL, single [1] IMPLICIT Extension{{DiversionExtensionSet}}, multiple[2] IMPLICIT SEQUENCE OF Extension{{DiversionExtensionSet}} } ERRORS {notAvailable | invalidServedUserNr | invalidDivertedToNr | specialServiceNr | unspecified } CODE

local: 18}

- 11 -

Table 2 - Operations in Support of SS-DIV (continued) callRerouteing OPERATION ::={ -- Sent from the Served User PINX to the Rerouteing PINX ARGUMENT SEQUENCE { rerouteingReason DiversionReason, originalRerouteingReason [0] IMPLICIT DiversionReason OPTIONAL, calledAddress Address, diversionCounter INTEGER (1..15), pSS1InfoElement PSS1InformationElement, -- The basic call information elements Bearer capability, High layer compatibility, Low -- layer compatibity and Progress indicator can be embedded in the -- pSS1InfoElement in accordance with 6.5.3.1.5. lastRerouteingNr [1] PresentedNumberUnscreened, subscriptionOption [2] IMPLICIT SubscriptionOption, callingPartySubaddress [3] PartySubaddress OPTIONAL, callingNumber [4] PresentedNumberScreened, callingName [5] Name OPTIONAL, originalCalledNr [6] PresentedNumberUnscreened OPTIONAL, redirectingName [7] Name OPTIONAL, originalCalledName [8] Name OPTIONAL, extension CHOICE { single [9] IMPLICIT Extension{{DiversionExtensionSet}}, multiple[10] IMPLICIT SEQUENCE OF Extension{{DiversionExtensionSet}} } OPTIONAL } RESULT

CHOICE {

null NULL, single [1] IMPLICIT Extension{{DiversionExtensionSet}} , multiple[2] IMPLICIT SEQUENCE OF Extension{{DiversionExtensionSet}} } ERRORS {userNotSubscribed | notAvailable | resourceUnavailable | invalidDivertedToNr | specialServiceNr | diversionToServedUserNr | numberOfDiversionsExceeded | supplementaryServiceInteractionNotAllowed | unspecified } -- The error value numberOfDiversionsExceeded applies only in case of partial rerouteing. CODE

local: 19}

divertingLegInformation1 OPERATION ::={ -- Sent from the Rerouteing PINX to the Originating PINX ARGUMENT SEQUENCE { diversionReason DiversionReason, subscriptionOption SubscriptionOption, nominatedNr PartyNumber, extension CHOICE { single [9] IMPLICIT Extension{{DiversionExtensionSet}} , multiple [10] IMPLICIT SEQUENCE OF Extension{{DiversionExtensionSet}} } OPTIONAL } RETURN RESULT

FALSE

ALWAYS RESPONDS

FALSE

CODE

local: 20}

- 12 -

Table 2 - Operations in Support of SS-DIV (continued) divertingLegInformation2 OPERATION ::={ -- Sent from the Rerouteing PINX to the Diverted-to PINX ARGUMENT SEQUENCE { diversionCounter INTEGER (1..15), diversionReason DiversionReason, originalDiversionReason [0] IMPLICIT DiversionReason OPTIONAL, divertingNr [1] PresentedNumberUnscreened OPTIONAL, originalCalledNr [2] PresentedNumberUnscreened OPTIONAL, redirectingName [3] Name OPTIONAL, originalCalledName [4] Name OPTIONAL, extension CHOICE { single [5] IMPLICIT Extension{{DiversionExtensionSet}} , multiple[6] IMPLICIT SEQUENCE OF Extension{{DiversionExtensionSet}} } OPTIONAL } -- The divertingNr element is mandatory except in the case of interworking. RETURN RESULT

FALSE

ALWAYS RESPONDS

FALSE

CODE

local: 21}

divertingLegInformation3 OPERATION ::={ -- Sent from the Diverted-to PINX to the Originating PINX ARGUMENT SEQUENCE { presentationAllowedIndicator PresentationAllowedIndicator, redirectionName [0] Name OPTIONAL, extension CHOICE { single [1] IMPLICIT Extension{{DiversionExtensionSet}} , multiple[2] IMPLICIT SEQUENCE OF Extension{{DiversionExtensionSet}} } OPTIONAL } RETURN RESULT

FALSE

ALWAYS RESPONDS

FALSE

CODE

local: 22}

cfnrDivertedLegFailed OPERATION ::={ -- Sent from the Rerouteing PINX to the Served User PINX -- This indicates that the diverted-to leg has been cleared during SS-CFNR execution. ARGUMENT CHOICE { null NULL, single [1] IMPLICIT Extension{{DiversionExtensionSet}} , multiple[2] IMPLICIT SEQUENCE OF Extension{{DiversionExtensionSet}} } RETURN RESULT

FALSE

ALWAYS RESPONDS

FALSE

CODE

local: 23}

- 13 -

Table 2 - Operations in Support of SS-DIV (concluded) -- Definitions of general used data types: DiversionReason ::= ENUMERATED { unknown (0), cfu (1), cfb (2), cfnr (3)} -- The value unknown is only used if received from another network when interworking. IntResultList IntResult

::= SET SIZE (0..29) OF IntResult ::= SEQUENCE { servedUserNr PartyNumber, basicService BasicService, procedure Procedure, divertedToAddress Address, remoteEnabled BOOLEAN DEFAULT FALSE, extension CHOICE { single [1] IMPLICIT Extension{{DiversionExtensionSet}} , multiple[2] IMPLICIT SEQUENCE OF Extension{{DiversionExtensionSet}} } OPTIONAL }

Procedure SubscriptionOption

::= ENUMERATED { cfu (0), cfb (1), cfnr (2) } ::= ENUMERATED { noNotification (0), notificationWithoutDivertedToNr (1), notificationWithDivertedToNr (2) }

BasicService

::= ENUMERATED { allServices (0), speech (1), unrestrictedDigitalInformation (2), audio3100Hz (3), telephony (32), teletex (33), telefaxGroup4Class1 (34), videotexSyntaxBased (35), videotelephony (36) }

DiversionExtensionSet

EXTENSION ::= {…}

invalidDivertedToNr specialServiceNr diversionToServedUserNr numberOfDiversionsExceeded temporarilyUnavailable notAuthorized unspecified

END -- of Call-Diversion-Operations-asn1-97

ERROR ::= {CODE local: 12} ERROR ::= {CODE local: 14} ERROR ::= {CODE local: 15} ERROR ::= {CODE local: 24} ERROR ::= {CODE local: 1000} ERROR ::= {CODE local: 1007} ERROR ::= {PARAMETER Extension{{DiversionExtensionSet}} CODE local:1008}

- 14 -

6.3.2 Information elements 6.3.2.1 Facility information element The operations defined in 6.3.1 shall be coded in the Facility information element in accordance with ECMA-165. When conveying the invoke APDU of the operations defined in 6.3.1, the destinationEntity data element of the NFE shall contain value endPINX. When conveying the invoke APDU of the operations divertingLegInformation 1, divertingLegInformation 2, divertingLegInformation 3 and/or cfnrDivertedLegFailed the interpretation APDU shall be included and shall contain the value discardAnyUnrecognisedInvoke APDU. When conveying the invoke APDU of the callRerouting operation, the Interpretation APDU may be omitted, or may be included with the value "rejectAnyUnrecognizedInvokePDU". In all other cases, the Interpretation APDU may be omitted or may be included, with either the value "rejectAnyUnrecognizedPDU" or "clearCallIfAnyInvokePDUNotRecognzed". 6.3.2.2

N o t i f i c a t i o n i n d ic a t o r i n f o r m a t i o n e l e m e n t The general structure and coding of the Notification indicator information element is specified in ECMA-165, 11.3.4. The following specific Notification Description value shall be used for the diversion notification from the Outgoing Gateway PINX to the Originating PINX as received from the public ISDN: – call is diverting:

"111 1011" (Bits 765 4321).

The Redirection number information element received from the public ISDN and sent by the Outgoing Gateway PINX to the Originating PINX shall be included in the argument of notification pss1IeNotification (as defined in ECMA-165, annex B) within a second Notification indicator information element. The following Notification Description value shall be used for this purpose: – discriminator for extension to ISO defined ASN.1 encoded notification data structure: "100 0000" (Bits 765 4321). The Redirection number information element shall be encoded as specified in ITU-T Rec. Q.952. 6.3.3

6.4 6.4.1

Messages The Facility information element and the Notification indicator information element shall be conveyed in the messages as specified in ECMA-165, clause 10. The basic call messages shall be used for call establishment and release as specified in ECMA-143.

SS-DIV state definitions S t a t e s a t t h e O r ig in a t in g P I N X The procedures for the Originating PINX are written in terms of the following conceptual states existing within the SS-DIV Supplementary Service Control entity in that PINX in association with a particular call: ∗ CDO-Idle: No divertingLegInformation1 invoke APDU has been received. ∗ CDO-Divert: The divertingLegInformation1 invoke APDU has been received and the subscription option of the served user and the diverted-to number have been stored.

6.4.2

States at the Served User PINX The procedures for the Served User PINX are written in terms of the following conceptual states existing within the SS-DIV Supplementary Service Control entity. There are different state machines for activation, deactivation, interrogation and invocation of call diversion: Activation states (in association with a particular request for activation): ∗ CDS-Act-Idle: No processing of an activateDiversionQ invoke APDU. ∗ CDS-Act-Wait: The Served User PINX has received an activation request and has sent a checkRestriction invoke APDU to the Diverted-to PINX.

- 15 -

Deactivation state (in association with a particular request for deactivation): ∗ CDS-Deact-Idle: No processing of a deactivateDiversionQ invoke APDU. Interrogation state (in association with a particular request for interrogation): ∗ CDS-Inter-Idle: No processing of an interrogateDiversionQ invoke APDU. Invocation states (in association with a particular call): ∗ CDS-Inv-Idle: Diversion invocation not in progress. ∗ CDS-Requested: The Served User PINX has sent a callRerouteing invoke APDU to the Rerouteing PINX and is waiting for receipt of an return result, return error or reject APDU. 6.4.3

S t a t e s a t t h e D iv e r t e d - t o P I N X The procedures for the Diverted-to PINX are written in terms of the following conceptual states existing within the SS-DIV Supplementary Service Control entity in that PINX. There are different state machines for the invocation of call diversion and restriction checking: Invocation states (in association with a particular call): ∗ CDF-Inv-Idle: No processing of a divertingLegInformation2 invoke APDU. ∗ CDF-Inv-Wait: A divertingLegInformation2 invoke APDU has been received and the Diverted-to PINX is waiting for valid presentation restriction information. Check restriction state (in association with a particular request for validating a diverted-to number): ∗ CDF-Res-Idle: No processing of a checkRestriction invoke APDU.

6.4.4

S t a t e s a t t h e R e r o u t e in g P I N X The procedures for the Rerouteing PINX are written in terms of the following conceptual states existing within the SS-DIV Supplementary Service Control entity in that PINX in association with a particular call: ∗ CDR-Idle: Rerouteing not in progress. ∗ CDR-Invoked: The CFNR rerouteing procedure has been successfully performed and the Rerouteing PINX is waiting for completion of establishment of the call to the diverted-to user.

6.4.5

S t a t e s a t t h e A c t iv a t in g P I N X The procedures for the Activating PINX are written in terms of the following conceptual states existing within the SS-DIV Supplementary Service Control entity in that PINX: ∗ CDA-Idle: Activation not in progress. ∗ CDA-Wait: An activateDiversionQ invoke APDU has been sent. The Activating PINX is waiting for the response.

6.4.6

S t a t e s a t t h e D e a c t iv a t in g P I N X The procedures for the Deactivating PINX are written in terms of the following conceptual states existing within the SS-DIV Supplementary Service Control entity in that PINX: ∗ CDD-Idle: Deactivation not in progress. ∗ CDD-Wait: A deactivateDiversionQ invoke APDU has been sent. The Deactivating PINX is waiting for the response.

6.4.7

S t a t e s a t t h e I n t e r r o g a t in g P I N X The procedures for the Interrogating PINX are written in terms of the following conceptual states existing within the SS-DIV Supplementary Service Control entity in that PINX: ∗ CDI-Idle: Interrogation not in progress. ∗ CDI-Wait: An interogateDiversionQ invoke APDU has been sent. The Interrogating PINX is waiting for the response.

- 16 -

6.5

SS-DIV Signalling procedures Annex D shows some examples of message sequences of the signalling procedures.

6.5.1

A c t io n s a t t h e O r ig in a t in g P I N X When an Originating PINX also provides Rerouteing PINX functionality, in support of call diversion by rerouteing, the joint requirements of 6.5.1 (for an Originating PINX) and 6.5.4 (for a Rerouteing PINX) shall apply, with the exception that any communication between the Originating PINX functionality and the Rerouteing PINX functionality will be an intra-PINX matter. The messages specified for sending from the Originating PINX towards the Rerouteing PINX or vice versa will not appear on any interPINX link. NOTE The Originating PINX can act also as Rerouteing PINX in all cases where call diversion by rerouteing is appropriate.

6.5.1.1

Normal Procedure On receipt of a divertingLegInformation1 invoke APDU in a FACILITY or CONNECT message while in basic call protocol control state Overlap Sending, Outgoing Call Proceeding or Call Delivered and in state CDO-Idle, the Originating PINX shall take account of the information therein and enter state CDO-Divert. In determining whether to notify the calling user, the Originating PINX shall take account of the value of element subscriptionOption. If the value noNotification has been received, no notification of diversion shall be given to the calling user. Otherwise a notification of diversion shall be given to the calling user if the capability exists. The diverted-to number and subaddress shall not be presented to the calling user at this stage. When the divertingLegInformation1 invoke APDU has been received in a CONNECT message, a divertingLegInformation3 invoke APDU in the same message shall be handled as specified below. On receipt of a divertingLegInformation1 invoke APDU in a FACILITY or CONNECT message while in state CDO-Divert, the Originating PINX shall take account of the information therein and remain in the same state. If the value of element diversionReason is cfu or cfb, no notification of this further diversion shall be given to the calling user. If the value of element diversionReason is cfnr, account shall be taken of the value of element subscriptionOption in this APDU and in all previously received divertingLegInformation1 invoke APDUs for this call. If this or any previous value is noNotification, no notification shall be given to the calling user. Otherwise a notification of further diversion shall be given to the calling user if the capability exists. The diverted-to number and subaddress shall not be presented to the calling user at this stage. When the divertingLegInformation1 invoke APDU has been received in a CONNECT message, a divertingLegInformation3 invoke APDU in the same message shall be handled as specified below. On receipt of a divertingLegInformation3 invoke APDU in an ALERTING, CONNECT or FACILITY message while in state CDO-Divert, the Originating PINX shall take account of the information therein, shall remain in the same state if received in an ALERTING or FACILITY message, and shall enter state CDO-Idle if received in a CONNECT message. The diverted-to number (as received in element nominatedNr of the last received diversionLegInformation1 invoke APDU) shall be presented to the calling user, if the capability exists, only if all of the following conditions are true: – all previously received divertingLegInformation1 invoke notificationWith-DivertedToNr in element subscriptionOption; and

APDUs

contained

value

– this and any previously received divertingLegInformation3 invoke APDUs contained value TRUE in element of type PresentationAllowedIndicator; and – no previous notification of a diverted-to number has been given to the calling user unless, since then, a divertingLegInformation1 invoke APDU with value cfnr in element diversionReason has been received. The diverted-to name (as received in element redirectionName of the divertingLegInformation3 invoke APDU) may be presented to the calling user, if the capability exists, only if all of the three conditions above for the presentation of the diverted-to number are true and if not marked, within the element redirectionName, as presentation restricted. On receipt of a CONNECT message, the Originating PINX shall enter state CDO-Idle.

- 17 -

NOTE In case of where a call enters another network from the PISN and call diversion occurs in that other network, no divertingLegInformation1 or divertingLegInformation3 invoke APDUs will be received by the Originating PINX. Instead, notification(s) of the diversion in accordance with 6.3.2.2 may be received form the Outgoing Gateway PINX. Such notifications will be handled in accordance with ECMA-165, 7.4.3.3. 6.5.1.2

Ex c e p t io n a l P r o c e d u r e s On call clearing during state CDO-Divert, the Originating PINX shall enter state CDO-Idle.

6.5.2

A c t io n s a t a Tr a n s it P I N X No special actions are recognized.

6.5.3

A c t io n s a t t h e S e r v e d U s e r P I N X In the context of invocation, when a Served User PINX also provides Rerouteing PINX functionality, in support of call diversion by forward switching, the joint requirements of 6.5.3 (for a Served User PINX) and 6.5.4 (for a Rerouteing PINX) shall apply, with the exception that any communication between the Served User PINX functionality and the Rerouteing PINX functionality will be an intra-PINX matter. The messages specified for sending from the Served User PINX towards the Rerouteing PINX or vice versa will not appear on any inter-PINX link. NOTE The Served User PINX can act also as Rerouteing PINX e.g. in cases where call diversion by rerouteing has been rejected or where forward switching is appropriate according to implementation specific reasons (e.g. the diverted-to user is located in the Served User PINX).

6.5.3.1 Normal Procedure 6 . 5 . 3 . 1 . 1 A c t iv a t io n On receipt of an activateDiversionQ invoke APDU using the call reference of a call independent signalling connection (as specified in ECMA-165, 7.3), the Served User PINX shall check the received basic service (element basicService) for the served user (element servedUserNr) and verify that remote activation is supported and enabled. The address of the activating user (element activatingUserNr) may also be taken into account in determining whether activation is to be allowed to proceed. The Served User PINX may use the procedures specified in 6.5.3.1.4 and/or local techniques for verifying, as far as possible, that the diverted-to user's number is valid. If the activation request is acceptable, the Served User PINX shall activate diversion of the type indicated by the element procedure, answer the activateDiversionQ invoke APDU with a return result APDU, store the received diverted-to number and the subaddress, if provided, and optionally convey an appropriate notification to the served user. 6.5.3.1.2

D e a c t iv a t io n On receipt of a deactivateDiversionQ invoke APDU using the call reference of a call independent signalling connection (as specified in ECMA-165, 7.3), the Served User PINX shall check the consistency of the received basic service (element basicService) for the served user (element servedUserNr). The address of the deactivating user (element deactivatingUserNr) may also be taken into account in determining whether deactivation is to be allowed to proceed. If the deactivation request is valid, the Served User PINX shall deactivate diversion of the type indicated by the element procedure, answer the deactivateDiversion invoke APDU with a return result APDU and optionally convey an appropriate notification to the served user.

6.5.3.1.3

I n t e r r o g a t io n On receipt of an interrogateDiversionQ invoke APDU using the call reference of a call independent signalling connection (as specified in ECMA-165, 7.3), the Served User PINX shall check the interrogation request and answer the interrogateDiversionQ invoke APDU with a return result APDU if the interrogation request is valid and Call Forwarding is activated. The address of the interrogating user (element interrogatingUserNr) may also be taken into account in determining whether interrogation is to be allowed to proceed.

- 18 -

6.5.3.1.4

Verification of the diverted-to user's number The Served User PINX may use the procedure below to check with the Diverted-to PINX whether the diverted-to number exists and whether there are any restrictions which might prevent call diversion. The Served User PINX shall send a checkRestriction invoke APDU to the Diverted-to PINX using the call reference of a call independent signalling connection. The call independent signalling connection shall be established (or used, if an appropriate connection is already available) in accordance with the procedures specified in ECMA-165, 7.3. The CDS-Act-Wait state shall be entered and timer T5 shall be started. NOTE The number to be used in the Called party number information element when establishing the call independent signalling connection is outside the scope of this Standard. It can be, for example, the diverted-to number. On receipt of a return result APDU in reply to the checkRestriction invoke APDU, the Served User PINX shall treat the diverted-to user's number as a valid number, enter CDS-Act-Idle state and stop timer T5. The Served User PINX is responsible for clearing the call independent signalling connection towards the Diverted-to PINX. This may occur on receipt of a return result APDU. Alternatively, the signalling connection may be retained for other applications, if appropriate.

6.5.3.1.5

I n v o c a t io n The detection of a call diversion invoke request results from different local procedures in the Served User PINX. When SS-DIV is invoked, a callRerouteing invoke APDU shall be sent in a call related FACILITY message to the Rerouteing PINX and the CDS-Requested state shall be entered. Sending of the FACILITY message for SS-CFU(SS-CDI) and SS-CFB shall be applicable in the basic call protocol control states Incoming Call Proceeding and Overlap Receiving. Sending of the FACILITY message for SS-CFNR(SS-CDA) shall be applicable in the basic call protocol control state Call Received. The timer T1 shall be started by the Served User PINX on entering the CDS-Requested state. The timer shall be stopped on receipt of a return result APDU of the callRerouteing operation. The following data elements and information elements shall be included in the argument of the callRerouteing invoke APDU: – element rerouteingReason containing the reason for the last diversion, indicating a value other than unknown, – element originalRerouteingReason, only in case of multiple diversions, containing the reason for the original diversion, – element calledAddress as stored in the Served User PINX as diverted-to number and, possibly, subaddress, NOTE The number should have significance throughout the PISN. If it is a number from a Private Numbering Plan (PNP), it should be a Complete Number. If it is an E.164 number, then a subscriber number can be insufficient, and in some networks, a national number can be insufficient. – element diversionCounter containing the number of diversions undergone by the call (value one if this is the first diversion), – element pSS1InfoElement containing an embedded Bearer capability information element, as received in the incoming SETUP message, and any of the following information elements which were received in the incoming SETUP message: High layer compatibility, Low layer compatibility and Progress indicator.

- 19 -

– element lastRerouteingNr containing the number of the last diverting user, – element subscriptionOption containing the served user's requirements for notifying the calling user, – element callingPartySubaddress if a Calling party subaddress information element was received in the incoming SETUP message, – element callingNumber as received in the incoming SETUP message in the Calling party number information element, – element callingName if a callingName invoke APDU was received in the incoming SETUP message as defined in ECMA-164 and recognised by the Served User PINX, – element originalCalledNr, only in case of multiple call diversion, containing the number of the original called user, – optionally element redirectingName, – optionally element originalCalledName. On receipt of the return result APDU of the callRerouteing operation, the Served User PINX shall enter CDS-Inv-Idle state and may send an appropriate notification to the served user. NOTE The call between Rerouteing PINX and Served User PINX is released by the Rerouteing PINX according to ECMA-143. 6.5.3.2 Ex c e p t io n a l P r o c e d u r e s 6 . 5 . 3 . 2 . 1 A c t iv a t io n If the diverted-to user's number is detected as an invalid number or if the activation request can not be accepted for other reasons, the Served User PINX shall send back a return error APDU with an appropriate error value. 6.5.3.2.2

D e a c t iv a t io n If the deactivation request is not valid, the Served User PINX shall answer the deactivateDiversion invoke APDU with a return error APDU containing an appropriate error value.

6.5.3.2.3

I n t e r r o g a t io n If the interrogation request is not valid or if the particular type of Call Forwarding is not activated, the Served User PINX shall answer the interrogateDiversionQ invoke APDU with a return error APDU containing an appropriate error value.

6.5.3.2.4

Verification of the diverted-to user's number On receipt of a return error APDU in reply to the checkRestriction invoke APDU, the Served User PINX shall treat the diverted-to user's number as an invalid number, enter the CDS-Act-Idle state and stop timer T5. If timer T5 expires (i.e. the checkRestriction invoke APDU is not answered by the Diverted-to PINX), if the call independent signalling connection cannot be established, or on receipt of a reject APDU (e.g. the checkRestriction operation is not supported by the Diverted-to PINX), the Served User PINX may treat the diverted-to number either as valid or invalid depending on the particular cause of the failure. The Served User PINX shall enter the CDS-Act-Idle state. Timer T5 shall be stopped on receipt of a reject APDU. The Served User PINX is responsible for clearing the call independent signalling connection towards the Diverted-to PINX. This may occur on receipt of a return error or reject APDU or expiry of timer T5. Alternatively, the signalling connection may be retained for other applications, if appropriate.

6.5.3.2.5

I n v o c a t io n When SS-DIV is invoked, but the callRerouteing invoke APDU cannot be sent to the Rerouteing PINX (e.g. if the number of diversions has exceeded the maximum value), then the Served User PINX shall maintain the incoming call for SS-CFNR(CDA) and perform an implementation specific

- 20 -

procedure for SS-CFU(CDI) and SS-CFB (e.g. release the call according to ECMA-143 or override call diversion). On receipt of the return error or reject APDU of the callRerouteing operation or on expiry of timer T1, the Served User PINX shall enter CDS-Inv-Idle state and shall perform an implementation specific procedure (e.g. maintain the incoming call for SS-CFNR(CDA), release the call according to ECMA-143 or try again using forward switching). Timer T1 shall be stopped on receipt of a return error or reject APDU of the callRerouteing operation. If a specific incoming call is received (e.g. from the diverted-to user to the served user), the Served User PINX may not invoke SS-DIV, but instead offer the call to the served user. Subsequent to receipt of a callRerouteing return result APDU, on receipt of a cfnrDivertedLegFailed invoke APDU (which indicates that SS-CFNR(CDA) has been abandoned), the Served User PINX shall remain in state CDS-Inv-Idle and may notify the served user. On call clearing during CDS-Requested state, the Served User PINX shall enter CDS-Inv-Idle state. 6.5.4

6.5.4.1

A c t io n s a t t h e R e r o u t e in g P I N X The Rerouteing PINX functionality may be incorporated either in the Originating PINX (in support of call diversion by rerouteing) or in the Served User PINX (in support of call diversion by forward switching). In the case of rerouteing, the communication between the Rerouteing PINX functionality and the Originating PINX functionality will be an intra-PINX matter. In the case of forward switching the communication between the Rerouteing PINX functionality and the Served User PINX functionality will be an intra-PINX matter. In both cases the related messages specified for sending from the Rerouteing PINX to either the Originating PINX or the Served User PINX and vice versa will not appear on any inter-PINX link. Normal Procedure On receipt of a callRerouteing invoke APDU in a FACILITY message during basic call protocol control states Overlap Sending or Outgoing Call Proceeding for SS-CFU(CDI)/SS-CFB and Call Delivered for SS-CFNR(CDA), the Rerouteing PINX shall check if the diversion request is valid. If the diversion request can be performed, the Rerouteing PINX shall answer the callRerouteing invoke APDU with a return result APDU in a FACILITY message, shall initiate a new call establishment to the new destination (diverted-to user) and in the case of SS-CFU(CDI) or SS-CFB shall release the leg towards the Served User PINX by sending a DISCONNECT message. In the case of SS-CFU(CDI) or SS-CFB the return result APDU may instead be conveyed in the DISCONNECT message. The SETUP message for the new call establishment shall include a divertingLegInformation2 invoke APDU. A callingName invoke APDU (see ECMA-164) may be included in the SETUP message, if the element callingName was received in the callRerouteing invoke APDU and if the Name Identification supplementary service is supported by the Rerouteing PINX. The following specific basic call information elements shall be included: – the information received in the element calledAddress of the callRerouteing invoke APDU shall be included into the Called party number information element and, if subaddress information is present, into the Called party subaddress information element, – the information received in the element callingNumber of the callRerouteing invoke APDU shall be included into the Calling party number information element and, if subaddress information is present, into the Calling party subaddress information element, – the Bearer capability information element as received in embedded form within the callRerouteing invoke APDU, and any of the following information elements which were also received in embedded form in this APDU: High layer compatibility, Low layer compatibility and Progress indicator information elements, The following data elements shall be included in the argument of the divertingLegInformation2 invoke APDU: – element diversionCounter as received in the callRerouteing invoke APDU,

- 21 -

– element diversionReason as received in the element rerouteingReason of the callRerouteing invoke APDU, – element originalDiversionReason if received in the element originalRerouteingReason of the callRerouteing invoke APDU, – element divertingNr as received in the element lastRerouteingNr of the callRerouteing invoke APDU, – optionally element originalCalledNr if received in the callRerouteing invoke APDU, – optionally element redirectingName if received in the callRerouteing invoke APDU, – optionally element originalCalledName if received in the callRerouteing invoke APDU. NOTE As an implementation option, the Rerouteing PINX may have stored some of the information from the original SETUP message for inclusion in the new SETUP message to the diverted-to user. The parameter rerouteingReason received in the callRerouteing invoke APDU shall indicate to the Rerouteing PINX whether the SS-CFU/SS-CFB or the SS-CFNR procedure is to be performed. After the new SETUP message has been sent, the procedures of the Rerouteing PINX are split into two cases, SS-CFU(CDI)/SS-CFB and SS-CFNR(CDA): – For SS-CFU(CDI)/SS-CFB, the Rerouteing PINX shall send a call related FACILITY message with a divertingLegInformation1 invoke APDU to the Originating PINX. The two remaining legs of the call shall be joined together (Originating PINX - Diverted-to PINX). ∗ For SS-CFNR(CDA), the Rerouteing PINX shall either move to the CDR-Invoked state if in the CDR-Idle state or shall remain in the CDR-Invoked state and wait for further events as followsOn receipt of a FACILITY message containing a divertingLegInformation1 invoke APDU from the Diverted-to PINX, the Rerouteing PINX shall remain in state CDR-Invoked and take no further action. ∗ On receipt of a FACILITY message containing a callRerouteing invoke APDU, the Rerouting PINX shall remain in state CDR-Invoked and normal procedures for a Rerouting PINX shall apply as defined in this section for basic call protocol control state Call Delivered. ∗ On receipt of an ALERTING message from the Diverted-to PINX, the Rerouteing PINX shall initiate call clearing towards the Served User PINX according to ECMA-143, send a divertingLeg-Information1 invoke APDU in the FACILITY message to the Originating PINX and enter the CDR-Idle state. The two remaining legs of the call shall be joined together (Originating PINX - Diverted-to PINX). ∗ On receipt of an CONNECT message (if previously no ALERTING has been received) from the Diverted-to PINX, the Rerouteing PINX shall initiate call clearing towards the Served User PINX according to ECMA-143, send a divertingLegInformation1 invoke APDU in the CONNECT message to the Originating PINX and enter the CDR-Idle state. The two remaining legs of the call shall be joined together (Originating PINX - Diverted-to PINX). ∗ On receipt of a CONNECT message from the Served User PINX, the Rerouteing PINX shall initiate call clearing towards the Diverted-to PINX according to ECMA-143 and enter the CDR-Idle state. The CONNECT message shall be relayed to the Originating PINX according to ECMA-143. The original call shall remain (Originating PINX - Served User PINX). The argument of the divertingLegInformation1 invoke APDU shall include the elements diversionReason, subscriptionOption and nominatedNr as received in the argument of the callRerouteing invoke APDU in the elements rerouteingReason, subscriptionOption and calledAddress respectively. After the two legs of the call have been joined together the Rerouteing PINX shall return to state CDR-Idle and shall act as a Transit PINX for the resulting call. NOTE After the two legs of the call have been joined together, the Rerouteing PINX will pass on

- 22 -

transparently a divertingLegInformation3 invoke APDU. Where a divertingLegInformation1 invoke APDU is included in the CONNECT message, this will be in addition to the divertingLegInformation3 invoke APDU. 6.5.4.2

Ex c e p t io n a l P r o c e d u r e s If the diversion request cannot be performed on receipt of a callRerouteing invoke APDU, a return error APDU including the appropriate error value shall be sent back in a FACILITY message. For events received for SS-CFNR(CDA) in the CDR-Invoked state, the Rerouteing PINX shall perform the following actions: – On receipt of a DISCONNECT, RELEASE or RELEASE COMPLETE message from the Divertedto PINX, the Rerouteing PINX shall complete call clearing towards the Diverted-to PINX, send a cfnrDivertedLegFailed invoke APDU in a FACILITY message to the Served User PINX and enter the CDR-Idle state. The original call shall remain (Originating PINX - Served User PINX). – On receipt of a call clearing message from the Originating PINX or Served User PINX, the Rerouteing PINX shall continue call clearing according to ECMA-143, stimulate release of the remaining two legs of the call and enter the CDR-Idle state.

6.5.5 A c t io n s a t t h e D iv e r t e d - t o P I N X 6.5.5.1 Normal Procedure 6 . 5 . 5 . 1 . 1 I n v o c a t io n On receipt of a SETUP message with a divertingLegInformation2 invoke APDU, the Diverted-to PINX shall enter CDF-Inv-Wait state. A diversion notification, the redirecting number (and the original called number in case of multiple diversion) as received, and optionally the redirecting name (and the original called name in case of multiple diversion) shall be conveyed in an appropriate message together with the basic call establishment information to the called user if able and authorized to receive the notification. When it is known whether presentation restriction applies to the diverted-to number, the Divertedto PINX shall enter CDF-Inv-Idle state and send a divertingLegInformation3 invoke APDU in a FACILITY, ALERTING or CONNECT message to the Originating PINX. This information shall indicate whether the presentation of the diverted-to number is restricted and may also indicate the name of the diverted-to user in element redirectionName and whether its presentation is restricted. The Diverted-to PINX shall not send a FACILITY message with a divertingLegInformation3 invoke APDU unless an ALERTING message has already been sent in case of SS-CFNR(CDA). The APDU shall be sent in the CONNECT message if it has not already been sent in a FACILITY or ALERTING message. 6.5.5.1.2

Verification of the diverted-to user's number On receipt of a checkRestriction invoke APDU using the call reference of a call independent signalling connection (as specified in ECMA-165, 7.3), the Diverted-to PINX shall check if the address of the intended diverted-to user (element divertedToNr in the argument) exists and if there are any restrictions (e.g. basic service) which could prevent call diversion from the served user (element servedUserNr in the argument) to that user. A checkRestriction return result APDU shall be sent back to the Served User PINX if there are no restrictions.

6.5.5.2 Ex c e p t io n a l P r o c e d u r e s 6 . 5 . 5 . 2 . 1 I n v o c a t io n On call clearing during CDF-Inv-Wait state, the Diverted-to PINX shall enter CDF-Inv-Idle state. 6.5.5.2.2

Verification of the diverted-to user's number A return error APDU shall be sent back to the Served User PINX if there are any restrictions detected by the Diverted-to PINX.

6.5.6 A c t io n s a t t h e A c t iv a t in g P I N X 6.5.6.1 Normal Procedure On receipt of a remote activation request from the user, the Activating PINX shall send an activateDiversionQ invoke APDU to the Served User PINX using the call reference of a call

- 23 -

independent signalling connection. The call independent signalling connection shall be established (or used, if an appropriate connection is already available) in accordance with the procedures specified in ECMA-165, 7.3. The Activating PINX shall enter the CDA-Wait state and start timer T2. On receipt of the activateDiversionQ return result APDU, the Activating PINX shall stop timer T2, revert to the CDA-Idle state and convey the return result back to the activating user. NOTE The number to be used in the Called party number information element when establishing the call independent signalling connection is outside the scope of this Standard. The Activating PINX is responsible for clearing the call independent signalling connection towards the Served User PINX. This may occur on receipt of an activateDiversionQ return result APDU. Alternatively, the signalling connection may be retained for other applications, if appropriate. 6.5.6.2

Ex c e p t io n a l P r o c e d u r e s On receipt of the activateDiversionQ return error or reject APDU from the Served User PINX, the Activating PINX shall stop timer T2, revert to the CDA-Idle state and indicate rejection to the activating user. If timer T2 expires (i.e. the activateDiversionQ invoke APDU is not answered by the Served User PINX), the Activating PINX shall indicate rejection to the user and enter CDA-Idle state. The Activating PINX is responsible for clearing the call independent signalling connection towards the Served User PINX. This may occur on receipt of an activateDiversionQ return error or reject APDU or expiry of timer T2. Alternatively, the signalling connection may be retained for other applications, if appropriate.

6.5.7 A c t io n s a t t h e D e a c t iv a t in g P I N X 6.5.7.1 Normal Procedure On receipt of a remote deactivation request from the user, the Deactivating PINX shall send a deactivateDiversionQ invoke APDU to the Served User PINX using the call reference of a call independent signalling connection. The call independent signalling connection shall be established (or used, if an appropriate connection is already available) in accordance with the procedures specified in ECMA-165, 7.3. The Deactivating PINX shall enter the CDD-Wait state and start timer T3. On receipt of the deactivateDiversionQ return result APDU, the Deactivating PINX shall stop timer T3, revert to the CDD-Idle state and convey the return result back to the deactivating user. NOTE The number to be used in the Called party number information element when establishing the call independent signalling connection is outside the scope of this Standard. The Deactivating PINX is responsible for clearing the call independent signalling connection towards the Served User PINX. This may occur on receipt of a deactivateDiversionQ return result APDU. Alternatively, the signalling connection may be retained for other applications, if appropriate. 6.5.7.2

Ex c e p t io n a l P r o c e d u r e s On receipt of the deactivateDiversionQ return error or reject APDU from the Served User PINX, the Deactivating PINX shall stop timer T3, revert to the CDD-Idle state and indicate rejection to the deactivating user. If timer T3 expires (i.e. the deactivateDiversionQ invoke APDU is not answered by the Served User PINX), the Deactivating PINX shall indicate rejection to the user and enter CDD-Idle state. The Deactivating PINX is responsible for clearing the call independent signalling connection towards the Served User PINX. This may occur on receipt of a deactivateDiversionQ return error or reject APDU or expiry of timer T3. Alternatively, the signalling connection may be retained for other applications, if appropriate.

6.5.8 A c t io n s a t t h e I n t e r r o g a t in g P I N X 6.5.8.1 Normal Procedure On receipt of a remote interrogate request from the user, the Interrogating PINX shall send a interrogateDiversionQ invoke APDU to the Served User PINX using the call reference of a call

- 24 -

independent signalling connection. The call independent signalling connection shall be established (or used, if an appropriate connection is already available) in accordance with the procedures specified in ECMA-165, 7.3. The Interrogating PINX shall enter the CDI-Wait state and start timer T4. On receipt of the interrogateDiversionQ return result or return error APDU, the Interrogating PINX shall stop timer T4, revert to the CDI-Idle state and convey the return result or return error back to the interrogating user. NOTE The number to be used in the Called party number information element when establishing the call independent signalling connection is outside the scope of this Standard. The Interrogating PINX is responsible for clearing the call independent signalling connection towards the Served User PINX. This may occur on receipt of an interrogateDiversionQ return result APDU. Alternatively, the signalling connection may be retained for other applications, if appropriate. 6.5.8.2

Ex c e p t io n a l P r o c e d u r e s On receipt of the interrogateDiversionQ return error or reject APDU from the Served User PINX, the Interrogating PINX shall stop timer T4, revert to the CDI-Idle state and indicate rejection to the interrogating user. If timer T4 expires (i.e. the interrogateDiversionQ invoke APDU is not answered by the Served User PINX), the Interrogating PINX shall indicate rejection to the user and enter CDI-Idle state. The Interrogating PINX is responsible for clearing the call independent signalling connection towards the Served User PINX. This may occur on receipt of an interrogateDiversionQ return error or reject APDU or expiry of timer T4. Alternatively, the signalling connection may be retained for other applications, if appropriate.

6.6

SS-DIV Impact of interworking with public ISDNs When an Incoming Gateway PINX also provides Rerouteing PINX functionality, in support of call diversion by rerouteing, the joint requirements of 6.6.1 (for an Incoming Gateway PINX) and 6.5.4 (for a Rerouteing PINX) shall apply. NOTE There are no capabilities specified by the public ISDN for activation, deactivation and interrogation of Diversion by a PISN on behalf of a PISN user.

6.6.1 I m p a c t o f in t e r wo r k in g o n in c o m in g c a lls 6.6.1.1 D iv e r s io n wit h in t h e P I S N The Incoming Gateway PINX shall send appropriate notifications (redirection number and diversion notifications) to the calling user in the public ISDN according to the information presentation rules specified for the Originating PINX based on information from the divertingLegInformation1 invoke APDU received from the Rerouteing PINX and the divertingLegInformation3 invoke APDU received from the Diverted-to PINX. If the divertingLegInformation3 invoke APDU is not received prior to or in the CONNECT message from the Diverted-to PINX, the Incoming Gateway PINX shall indicate to the public ISDN that presentation is restricted. 6.6.1.2

D iv e r s io n wit h in t h e p u b lic I S D N If the Incoming Gateway PINX is informed that an incoming call from the public ISDN has already been diverted, it shall send a divertingLegInformation2 invoke APDU in the SETUP message towards the Diverted-to PINX. If the other network does not provide the redirecting and/or the original called user's name, but provides indication that the user's name is restricted, the Incoming Gateway PINX shall include the divertingLegInformation2 invoke APDU in the SETUP message sent to the terminating PINX. Within the argument, the redirectingName and/or originalCalledName elements shall be omitted or the namePresentationRestricted type indicating a NULL name value shall be chosen for the element of type name.

- 25 -

The Incoming Gateway PINX shall indicate to the public ISDN whether presentation of the divertedto number is allowed, based on information received from the diverted-to PINX in the divertingLegInformation3 invoke APDU. If the divertingLegInformation3 invoke APDU is not received prior to or in the CONNECT message from the diverted-to PINX, the Incoming Gateway PINX shall indicate to the public ISDN that presentation is restricted. 6.6.1.3

Partial rerouteing On receipt of a callRerouteing invoke APDU in a FACILITY message from the Served User PINX, the Incoming Gateway PINX may request the public ISDN to perform partial rerouteing, instead of itself providing Rerouteing PINX functionality. In case of interworking with the public ISDN and if the public ISDN accepts a partial rerouteing request, the Gateway PINX shall send the return result either in a DISCONNECT or in a FACILITY message to the Served User PINX. If sent in a FACILITY message, the Incoming Gateway PINX shall then send a DISCONNECT message to the Served User PINX. If the public ISDN rejects a partial rerouteing request, the Gateway PINX may either provide rerouteing functionality or send a return error APDU in a FACILITY message to the Served User PINX.

6.6.2 I m p a c t o f in t e r wo r k in g o n o u t g o in g c a lls 6.6.2.1 D iv e r s io n wit h in t h e P I S N The Outgoing Gateway PINX shall convert a received divertingLegInformation2 invoke APDU from the Rerouteing PINX to an appropriate indication to the public ISDN (diverted-to user); a divertingLegInformation3 invoke APDU shall be sent to the Originating PINX on receipt of number restriction information from the public ISDN. If no information is received from the public ISDN which can be used to generate the divertingLegInformation3 invoke APDU, the Outgoing Gateway PINX shall take no specific action, i.e. the normal basic call handling procedure applies. NOTE In the case that no such information is received, the presentation of the Diverted-to number at the calling PISN user is not allowed. 6.6.2.2

6.7

D iv e r s io n wit h in t h e p u b lic I S D N The Outgoing Gateway PINX shall pass the notifications received from the public ISDN (Redirection number and Notification indicator information elements) to the Originating PINX within Notification indicator information elements. The received Redirection number shall be enveloped into a Notification indicator element according to 6.3.2.2.

SS-DIV Impact of interworking with non-ISDNs When an Incoming Gateway PINX also provides Rerouteing PINX functionality, in support of call diversion by rerouteing, the joint requirements of 6.7.1 (for an Incoming Gateway PINX) and 6.5.4 (for a Rerouteing PINX) shall apply.

6.7.1

I m p a c t o f in t e r wo r k in g o n in c o m in g c a lls When interworking with another network which supports equivalent supplementary services, the Incoming Gateway PINX may provide conversion between the signalling specified in this Standard and the signalling protocol of the other network.

6.7.2

I m p a c t o f in t e r wo r k in g o n o u t g o in g c a lls When interworking with another network which supports equivalent supplementary services, the Outgoing Gateway PINX may provide conversion between the signalling specified in this Standard and the signalling protocol of the other network.

6.8

Protocol interactions between SS-DIV and other SSs and ANFs This clause specifies protocol interactions with other supplementary services and ANFs for which stage 3 standards had been published at the time of publication of this Standard. For interactions with supplementary services and ANFs for which stage 3 standards had been published subsequent to the publication of this Standard, see those other standards.

- 26 -

NOTE 1 Additional interactions that have no impact on the signalling protocol at the Q reference point can be found in the relevant stage 1 specifications. NOTE 2 Simultaneous conveyance of APDUs for SS-DIV and another supplementary service or ANF in the same message each in accordance with the requirements of its respective stage 3 standard, does not, on its own, constitute a protocol interaction. 6.8.1 P r o t o c o l in t e r a c t io n s o f C a ll F o r wa r d in g U n c o n d it io n a l ( S S - C F U ) 6.8.1.1 Interaction with Calling Name Identification Presentation (SS-CNIP) Protocol interactions are specified in 6.5. 6.8.1.2

Interaction with Connected Name Identification Presentation (SS-CONP) Protocol interactions are specified in 6.5.

6.8.1.3

Interaction with Completion of Call to Busy Subscriber (SS-CCBS) The following interaction shall apply if SS-CCBS is supported in accordance with ECMA-186.

6.8.1.3.1

O r ig in a t in g P I N X p r o c e d u r e s f o r in v o k in g C C BS a t a C F U d iv e r t e d - t o u s e r NOTE In this case the Originating PINX with regard to CCBS is also the Originating PINX with regard to CFU. If CCBS is to be invoked at a busy diverted-to user, the Originating PINX shall store the content of element nominatedNr, if received in the argument of operation divertingLegInformation1, and use it: – as element numberB in the argument of any CCBS operation which requires this element; – as Called party number information element in the SETUP message of any call independent signalling procedure; – as Called party number information element in the SETUP message of the CC Call. The address of the originally called user shall not be used for CCBS. If element nominatedNr is not available, a CCBS request received from User A shall be rejected.

6.8.1.3.2

O r ig in a t in g P I N X p r o c e d u r e s if C F U is a c t iv a t e d b y S S - C C BS U s e r A No protocol interaction. NOTE 1 In this case the Originating PINX with regard to CCBS is the Served User PINX with regard to CFU. NOTE 2 If SS-CCBS User A, having a CCBS request outstanding against User B, has activated CFU and the connection release option of CCBS applies, an arriving call independent signalling connection (conveying a ccExecPossible invoke APDU or a ccCancel invoke APDU) is not an incoming call and will therefore not be diverted.

6.8.1.3.3

6.8.1.4 6.8.1.4.1

T e r m i n a t i n g P I N X p r o c e d u r e s i f C FU i s a c t i v a t e d b y U s e r B a f t e r C C B S h a s b e e n in v o k e d No protocol interaction. I n t e r a c t i o n wit h C o m p l e t i o n o f C a l l s o n N o R e p l y ( S S - C C N R ) The following interaction shall apply if SS-CCNR is supported in accordance with ECMA-186. Originating PINX procedures for invoking CCNR at a CFU diverted-to user NOTE In this case the Originating PINX with regard to CCNR is also the Originating PINX with regard to CFU.

- 27 -

If CCNR is to be invoked at a diverted-to user who does not answer, the Originating PINX shall store the content of element nominatedNr, if received in the argument of operation divertingLegInformation1, and use it: – as element numberB in the argument of any CCNR operation which requires this element; – as Called party number information element in the SETUP message of any call independent signalling procedure; – as Called party number information element in the SETUP message of the CC Call. The address of the originally called user shall not be used for CCNR. If element nominatedNr is not available, a CCNR request received from User A shall be rejected. 6.8.1.4.2

Originating PINX procedures if CFU is activated by SS-CCNR User A No protocol interaction. NOTE 1 In this case the Originating PINX with regard to CCNR is the Served User PINX with regard to CFU. NOTE 2 If SS-CCNR User A, having a CCNR request outstanding against User B, has activated CFU and the connection release option of CCNR applies, an arriving call independent signalling connection (conveying a ccExecPossible invoke APDU or a ccCancel invoke APDU) is not an incoming call and will therefore not be diverted.

6.8.1.4.3

6.8.1.5 6.8.1.5.1

Terminating PINX procedures if CFU is activated by User B after CCNR has been invoked No protocol interaction. I n t e r a c t io n wit h C a ll Tr a n s f e r ( S S - C T) The following interaction shall apply if SS-CT is supported in accordance with ECMA-178. Actions at a Transferring PINX for join In state CT-Await-Answer-From-User-C the Transferring PINX shall convey any received divertingLegInformation1 invoke APDU or divertingLegInformation3 invoke APDU from the Secondary PINX to the Primary PINX. In state CT-Await-Answer-From-User-C, on receipt of a callRerouting invoke APDU from the Secondary PINX, the Transferring PINX shall act as the Rerouteing PINX. Any divertingLegInformation1 invoke APDUs or divertingLegInformation3 invoke APDUs generated in accordance with Rerouteing PINX procedures shall be sent to the Primary PINX. When the Transferring PINX enters state CT-Await-Answer-From-User-C, if the transferring PINX had previously received one or more divertingLegInformation1 invoke APDUs (i.e., the PINX was in state CDO-Divert) from the direction of the Secondary PINX or from the Rerouting PINX, the Transferring PINX shall send a divertingLegInformation1 invoke APDU to the Primary PINX together with the callTransferComplete invoke APDU, The divertingLegInformation1 invoke APDU shall be coded as follows: -

diversionReason (based on the diversion reason of the last divertingLegInformation1 invoke APDU received)

subscriptionOption (based on the most restrictive subscription option received in any of the divertingLegInformation1 invoke APDUs)

nominatedNr (based on the nominated number of the last divertingLegInformation1 invoke APDU received).

If the Transferring PINX receives a divertingLegInformation3 invoke APDU in an ALERTING message and the Transferring PINX has not yet sent a callTransferComplete invoke APDU to the Primary PINX, then the Transferring PINX shall first send a divertingLegInformation1 invoke

- 28 -

APDU to the Primary PINX together with the callTransferComplete invoke APDU and then relay the divertingLegInformation3 invoke APDU in a FACILITY message. 6.8.1.6

I n t e r a c t io n wit h C a ll F o r wa r d in g Bu s y ( S S - C F B) Protocol interactions are specified in 6.5.

6.8.1.7

I n t e r a c t io n wit h C a ll F o r wa r d in g N o R e p ly ( S S - C F N R ) Protocol interactions are specified in 6.5.

6.8.1.8

I n t e r a c t io n wit h C a ll D e f le c t io n ( S S - C D ) Protocol interactions are specified in 6.5.

6.8.1.9

Interaction with Path Replacement (ANF-PR) No protocol interaction.

6.8.2 P r o t o c o l in t e r a c t io n s o f C a ll F o r wa r d in g Bu s y ( S S - C F B) 6.8.2.1 Interaction with Calling Name Identification Presentation (SS-CNIP) Protocol interactions are specified in 6.5. 6.8.2.2

Interaction with Connected Name Identification Presentation (SS-CONP) Protocol interactions are specified in 6.5.

6.8.2.3

Interaction with Completion of Calls to Busy Subscriber (SS-CCBS) The following interaction shall apply if SS-CCBS is supported in accordance with ECMA-186.

6.8.2.3.1

O r ig in a t in g P I N X p r o c e d u r e s f o r in v o k in g C C BS a t a C F B d iv e r t e d - t o u s e r NOTE In this case the Originating PINX with regard to CCBS is also the Originating PINX with regard to CFB. The procedures of 6.8.1.3.1 shall apply.

6.8.2.3.2

O r ig in a t in g P I N X p r o c e d u r e s if C F B is a c t iv a t e d b y S S - C C BS U s e r A No protocol interaction.

6.8.2.3.3

T e r m i n a t i n g P I N X p r o c e d u r e s i f C FB i s a c t i v a t e d b y U s e r B a f t e r C C B S h a s b e e n in v o k e d No protocol interaction.

6.8.2.4 6.8.2.4.1

I n t e r a c t i o n wit h C o m p l e t i o n o f C a l l s o n N o R e p l y ( S S - C C N R ) The following interaction shall apply if SS-CCNR is supported in accordance with ECMA-186. Originating PINX procedures for invoking CCNR at a CFB diverted-to user NOTE In this case the Originating PINX with regard to CCNR is also the Originating PINX with regard to CFB. The procedures of 6.8.1.4.1 shall apply.

6.8.2.4.2

Originating PINX procedures if CFB is activated by SS-CCNR User A No protocol interaction.

6.8.2.4.3

Terminating PINX procedures if CFB is activated by User B after CCNR has been invoked No protocol interaction.

6.8.2.5 6.8.2.5.1

I n t e r a c t io n wit h C a ll Tr a n s f e r ( S S - C T) The following interaction shall apply if SS-CT is supported in accordance with ECMA-178. Actions at a Transferring PINX for join Protocol interactions are specified in 6.8.1.5.1.

- 29 -

6.8.2.6

I n t e r a c t io n wit h C a ll F o r wa r d in g U n c o n d it io n a l ( S S - C F U ) Protocol interactions are specified in 6.5.

6.8.2.7

I n t e r a c t io n wit h C a ll F o r wa r d in g N o R e p ly ( S S - C F N R ) Protocol interactions are specified in 6.5.

6.8.2.8

I n t e r a c t io n wit h C a ll D e f le c t io n ( S S - C D ) Protocol interactions are specified in 6.5.

6.8.2.9

Interaction with Path Replacement (ANF-PR) No protocol interaction.

6.8.3 P r o t o c o l in t e r a c t io n s o f C a ll F o r wa r d in g N o R e p ly ( S S - C F N R ) 6.8.3.1 Interaction with Calling Name Identification Presentation (SS-CNIP) Protocol interactions are specified in 6.5. 6.8.3.2

Interaction with Connected Name Identification Presentation (SS-CONP) Protocol interactions are specified in 6.5.

6.8.3.3

Interaction with Completion of Calls to Busy Subscriber (SS-CCBS) No protocol interaction.

6.8.3.4

I n t e r a c t i o n wit h C o m p l e t i o n o f C a l l s o n N o R e p l y ( S S - C C N R ) The following interaction shall apply if SS-CCNR is supported in accordance with ECMA-186.

6.8.3.4.1

Originating PINX procedures for invoking CCNR at a CFNR diverted-to user The procedures of 6.8.1.4.1 shall apply.

6.8.3.4.2

Originating PINX procedures if CFNR is activated by SS-CCNR User A No protocol interaction.

6.8.3.4.3

Terminating PINX procedures if CFNR is activated by User B after CCNR has been invoked No protocol interaction.

6.8.3.5

I n t e r a c t io n wit h C a ll Tr a n s f e r ( S S - C T) The following interaction shall apply if SS-CT is supported in accordance with ECMA-178. NOTE If SS-CFNR is invoked for an unanswered, transferred call, either the Transferring PINX acts as the Rerouteing PINX (call transfer by join and call forwarding by rerouteing) or the Primary PINX acts as the Rerouteing PINX (call transfer by rerouteing and call forwarding by rerouteing) or the Secondary PINX acts as the Rerouteing PINX (call forwarding by forward switching).

6.8.3.5.1

Actions at a Transferring PINX for rerouteing and SS-CFNR Originating PINX On receipt of a callRerouting invoke APDU after initiating call transfer by rerouteing, the Transferring PINX shall send a callRerouting return error APDU to the SS-CFNR Served User PINX, containing error value supplementaryServiceInteractionNotAllowed. The Transferring PINX shall not pass on a received divertingLegInformation1 invoke APDU and divertingLegInformation3 invoke APDU after initiating call transfer by rerouteing.

6.8.3.5.2

Actions at a Transferring PINX for join or rerouteing and SS-CFNR Originating PINX The Transferring PINX shall not initiate signalling for SS-CT while performing call forwarding by rerouteing and prior to clearing either the call to the diverting user or the call to the diverted-to user.

- 30 -

6.8.3.5.3

Actions at a Secondary PINX for rerouteing and SS-CFNR Served User PINX On receipt of a callTransferIdentify invoke APDU after initiating call forwarding by rerouteing, the SS-CFNR Served User PINX shall send a callTransferIdentify return error APDU containing error value supplementaryServiceInteractionNotAllowed to the Transferring PINX. SS-CFNR shall not be initiated while the Secondary PINX is involved in transfer by rerouteing.

6.8.3.5.4

Actions at a Secondary PINX for rerouteing and SS-CFNR Served User and Rerouteing PINX On receipt of a callTransferIdentify invoke APDU after initiating call forwarding by forward switching and before a divertingLegInformation1 invoke APDU has been sent, the SS-CFNR Rerouteing PINX shall send a callTransferIdentify return error APDU to the Transferring PINX, containing error value supplementaryServiceInteractionNotAllowed.

6.8.3.5.5

A c t io n s a t a S e c o n d a r y P I N X f o r j o i n a n d S S - C F N R S e r v e d U s e r a n d R e r o u t e i n g PINX On receipt of a callTransferComplete, callTransferUpdate or subaddressTransfer invoke APDU after initiating call forwarding by forward switching, the SS-CFNR Rerouteing PINX shall not pass on the APDU to the Diverted-to PINX while the SS-CFNR rerouteing procedure is in progress. After receipt of an ALERTING or CONNECT message from the Diverted-to PINX and if the diverting user has not already answered the call, the information received in callTransferComplete, callTransferUpdate or subaddressTransfer invoke APDUs shall be passed on to the Diverted-to PINX.

6.8.3.5.6

Actions at a Transferring PINX for join Protocol interactions are specified in 6.8.1.5.1.

6.8.3.5.7

A c t io n s a t a P r im a r y P I N X f o r j o in The actions at an Originating PINX in 6.5.1.1 and 6.5.1.2 of this Standard shall apply also to the Primary PINX with the following exceptions: – The basic call protocol control state in which a divertingLegInformation1 invoke APDU or a divertingLegInformation3 invoke APDU can be received is "Active". – On receipt of a callTransferActive invoke APDU, the Primary PINX shall enter state CFO-Idle.

6.8.3.6

I n t e r a c t io n wit h C a ll F o r wa r d in g U n c o n d it io n a l ( S S - C F U ) Protocol interactions are specified in 6.5.

6.8.3.7

I n t e r a c t io n wit h C a ll F o r wa r d in g Bu s y ( S S - C F B) Protocol interactions are specified in 6.5.

6.8.3.8

I n t e r a c t io n wit h C a ll D e f le c t io n ( S S - C D ) Protocol interactions are specified in 6.5.

6.8.3.9

Interaction with Path Replacement (ANF-PR) No protocol interaction.

6.8.4

P r o t o c o l in t e r a c t io n s o f C a ll D e f le c t io n ( S S - C D ) The protocol interactions with Call Deflection Immediate shall be as specified in 6.8.1 for interactions with CFU. The protocol interactions with Call Deflection from Alert shall be as specified in 6.8.3 for interactions with CFNR.

6.9 6.9.1

SS-DIV parameter values (timers) Timer T1 This timer shall be started by the Served User PINX when a callRerouteing invoke APDU is sent to the Rerouteing PINX. The timer shall be stopped on receipt of an return result, return error or reject APDU of the callRerouteing operation. The expiry of this timer shall be equivalent to the receipt of a reject APDU.

- 31 -

Timer T1 shall have a value not less than 10 seconds. 6.9.2

Timer T2 This timer shall be started by the Activating PINX when an activateDiversionQ invoke APDU is sent to the Served User PINX. The timer shall be stopped on receipt of an return result, return error or reject APDU of the activateDiversionQ operation. The expiry of this timer shall be equivalent to the receipt of a reject APDU. Timer T2 shall have a value not less than 30 seconds.

6.9.3

Timer T3 This timer shall be started by the Deactivating PINX when a deactivateDiversionQ invoke APDU is sent to the Served User PINX. The timer shall be stopped on receipt of an return result, return error or reject APDU of the deactivateDiversionQ operation. The expiry of this timer shall be equivalent to the receipt of a reject APDU. Timer T3 shall have a value not less than 15 seconds.

6.9.4

Timer T4 This timer shall be started by the Interrogating PINX when an interrogateDiversionQ invoke APDU is sent to the Served User PINX. The timer shall be stopped on receipt of an return result, return error or reject APDU of the interrogateDiversionQ operation. The expiry of this timer shall be equivalent to the receipt of a reject APDU. Timer T4 shall have a value not less than 15 seconds.

6.9.5

Timer T5 This timer shall be started by the Served User PINX when a checkRestriction invoke APDU is sent to the Diverted-to PINX. The timer shall be stopped on receipt of an return result, return error or reject APDU of the checkRestriction operation. The expiry of this timer shall be equivalent to the receipt of a reject APDU. Timer T5 shall have a value not less than 15 seconds.

- 32 -

- 33 -

Annex A ( n o r ma tiv e )

Protocol Implementation Conformance Statement (PICS) proforma

A.1

Introduction The supplier of a protocol implementation which is claimed to conform to this Standard shall complete the following Protocol Implementation Conformance Statement (PICS) proforma. A completed PICS proforma is the PICS for the implementation in question. The PICS is a statement of which capabilities and options of the protocol have been implemented. The PICS can have a number of uses, including use: – by a protocol implementor, as a check list to reduce the risk of failure to conform to the Standard through oversight; – by the supplier and acquirer (or potential acquirer) of the implementation, as a detailed indication of the capabilities of the implementation, stated relative to the common basis for understanding provided by the Standard PICS proforma; – by the user or potential user of the implementation, as a basis for initially checking the possibility of interworking with another implementation - while interworking can never be guaranteed, failure to interwork can often be predicted from incompatible PICS); – by a protocol tester, as the basis for selecting appropriate tests against which to assess the claim for conformance of the implementation.

A.2

Instructions for completing the PICS proforma

A.2.1

General structure of the PICS proforma The PICS proforma is a fixed format questionnaire divided into sub-clauses each containing a group of individual items. Each item is identified by an item number, the name of the item (question to be answered) and the reference(s) to the clause(s) that specifies (specify) the item in the main body of this Standard. The "Status" column indicates whether an item is applicable and if so whether support is mandatory or optional. The following terms are used: m

mandatory (the capability is required for conformance to the protocol);

optional (the capability is not required for conformance to the protocol, but if the capability is implemented, it is required to conform to the protocol specifications);

o.<n>

optional, but support of at least one of the group of options labelled by the same numeral <n> is required;

prohibited;

c.<cond>

conditional requirement, depending on support for the item or items listed in condition <cond>;

<item>:m

simple conditional requirement, the capability being mandatory if item number <item> is supported, otherwise not applicable;

<item>:o

simple conditional requirement, the capability being optional if item number <item> is supported, otherwise not applicable.

Answers to the questionnaire items are to be provided either in the "Support" column, by simply marking an answer to indicate a restricted choice (Yes or No) or in the "Not Applicable" column (N/A).

- 34 -

A.2.2

Additional Information Items of Additional Information allow a supplier to provide further information intended to assist the interpretation of the PICS. It is not intended or expected that a large quantity will be supplied, and a PICS can be considered complete without any such information. Examples might be an outline of the ways in which a (single) implementation can be set up to operate in a variety of environments and configurations. References to items of Additional Information may be entered next to any answer in the questionnaire, and may be included in items of Exception information.

A.2.3

Exception Information It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status (after any conditions have been applied) in a way that conflicts with the indicated requirements. No preprinted answer will be found in the Support column for this. Instead, the supplier is required to write into the support column an x.<i> reference to an item of Exception Information, and to provide the appropriate rationale in the Exception item itself. An implementation for which an Exception item is required in this way does not conform to this Standard. A possible reason for the situation described above is that a defect in the Standard has been reported, a correction for which is expected to change the requirement not met by the implementation.

- 35 -

A.3

PICS proforma for ECMA-174

A.3.1

Implementation Identification

Supplier Contact point for queries about the PICS Implementation Name(s) and Version(s) Other information necessary for full identification, e.g. name(s) and version(s) for machines and/or operating system name(s) Only the first three items are required for all implementations; other information may be completed as appropriate in meeting the requirement for full identification. The terms Name and Version should be interpreted appropriately to correspond with a suppliers terminology (e.g. Type, Series, Model).

A.3.2

Protocol Summary

Protocol version

1.0

Addenda implemented (if applicable) Amendmends implemented Have any exeption items been required (see A.2.3) ?

Date of Statement

No [ ] Yes [ ] (The answer "yes" means that the implementation does not confirm to this Standard)

- 36 -

A.3.3

General

Item

Name of Item

Support of SS-CFU

o.1

Yes [ ] No [ ]

Support of SS-CFB

o.1

Yes [ ] No [ ]

Support of SS-CFNR

o.1

Yes [ ] No [ ]

Support of SS-CDI

o.1

Yes [ ] No [ ]

Support of SS-CDA

o.1

Yes [ ] No [ ]

Behaviour as Originating PINX

o.2

Yes [ ] No [ ]

Behaviour as Terminatimg PINX

o.2

Yes [ ] No [ ]

Behaviour as Transit PINX

o.2

Yes [ ] No [ ]

Behaviour as Incoming Gateway PINX

o.2

Yes [ ] No [ ]

A10

Behaviour as Outgoing Gateway PINX

o.2

Yes [ ] No [ ]

A.3.4

Procedures

Item

Name of Item

Reference

Status

N/A

Support

Procedures at the Originating PINX

6.5.1

A6:m

[ ]

m: Yes [ ]

Procedures at the Transit PINX

6.5.2

A8:m

[ ]

m: Yes [ ]

Procedures at the Rerouteing PINX

6.5.4

c.1

[ ]

m: Yes [ ] o: Yes [ ] No [ ]

Procedures at the Served User PINX activation

6.5.3.1.1 6.5.3.2.1

A7:o

[ ]

o: Yes [ ] No [ ]

Procedures at the Served User PINX deactivation

6.5.3.1.2 6.5.3.2.2

A7:o

[ ]

o: Yes [ ] No [ ]

Reference

Status

N/A

Support

- 37 -

Item

Name of Item

Reference

Status

N/A

Support

Procedures at the Served User PINX interrogation

6.5.3.1.3 6.5.3.2.3

A7:o

[ ]

o: Yes [ ] No [ ]

Procedures at the Served User PINX verification of diverted-to number

6.5.3.1.4 6.5.3.2.4

A7:o

[ ]

o: Yes [ ] No [ ]

Procedures at the Served User PINX invocation

6.5.3.1.5 6.5.3.2.5

A7:m

[ ]

m: Yes [ ]

Procedures at the Diverted-to PINX invocation

6.5.5.1.1 6.5.5.2.1

A7:m

[ ]

m: Yes [ ]

B10

Procedures at the Diverted-to PINX verification of diverted-to number

6.5.5.1.2 6.5.5.2.2

A7:o

[ ]

o: Yes [ ] No [ ]

B11

Procedures at the Activating PINX

6.5.6

Yes [ ] No [ ]

B12

Procedures at the Deactivating PINX

6.5.7

Yes [ ] No [ ]

B13

Procedures at the Interrogation PINX

6.5.8

Yes [ ] No [ ]

B14

Procedures at the Incoming Gateway PINX to public ISDN, diverting within the PISN

6.6.1.1

A9:m

[ ]

m: Yes [ ]

B15

Procedures at the Incoming Gateway PINX, diverting within the public ISDN

6.6.1.2

A9:m

[ ]

m: Yes [ ]

B16

Procedures at the Incoming Gateway PINX to public ISDN, partial rerouteing

6.6.1.3

A9:o

[ ]

o: Yes [ ] No [ ]

B17

Procedures at the Outgoing Gateway PINX to public ISDN, diverting within the PISN

6.6.2.1

A10:m

[ ]

m: Yes [ ]

B18

Procedures at the Outgoing Gateway PINX. diverting within the public ISDN

6.6.2.2

A10:m

[ ]

m: Yes [ ]

B19

Procedures at the Incoming Gateway PINX to another network (Non-ISDN)

6.7.1

A9:o

[ ]

o: Yes [ ] No [ ]

B20

Procedures at the Outgoing Gateway PINX to another network (Non-ISDN)

6.7.2

A10:o

[ ]

o: Yes [ ] No [ ]

c.1:

if A6 or A9 then mandatory else if A7 then optional else N/A

- 38 -

A.3.5

Coding

Item

Name of Item

Reference

Status

N/A

Support

Sending of redirectionName element in divertingLegInformation3 APDU

6.3.1

B9:o

[ ]

o: Yes [ ] No [ ]

Receipt of redirectionName element in divertingLegInformation3 APDU

6.3.1

B1:o

[ ]

o: Yes [ ] No [ ]

Sending of redirectingName element in callRerouteing and divertingLegInformation2 APDUs

6.3.1

c.1

[ ]

o: Yes [ ] No [ ]

Receipt of redirectingName element in callRerouteing and divertingLegInformation2 APDUs

6.3.1

c.2

[ ]

o: Yes [ ] No [ ]

Sending of originalCalledName element in callRerouteing and divertingLegInformation2 APDUs

6.3.1

c.1

[ ]

o: Yes [ ] No [ ]

Receipt of originalCalledName element in callRerouteing and divertingLegInformation2 APDUs

6.3.1

c.2

[ ]

o: Yes [ ] No [ ]

Sending of activateDiversionQ invoke APDU and receipt of return result and return error APDUs

6.3.1

B11:m

[ ]

m: Yes [ ]

Receipt of activateDiversionQ invoke APDU and sending of return result and return error APDUs

6.3.1

B4:m

[ ]

m: Yes [ ]

Sending of deactivateDiversionQ invoke APDU and receipt of return result and return error APDUs

6.3.1

B12:m

[ ]

m: Yes [ ]

C10

Receipt of deactivateDiversionQ invoke APDU and sending of return result and return error APDUs

6.3.1

B5:m

[ ]

m: Yes [ ]

C11

Sending of interrogateDiversionQ invoke APDU and receipt of return result and return error APDUs

6.3.1

B13:m

[ ]

m: Yes [ ]

C12

Receipt of interrogateDiversionQ invoke APDU and sending of return result and return error APDUs

6.3.1

B6:m

[ ]

m: Yes [ ]

C13

Sending of checkRestriction invoke APDU and receipt of return result and return error APDUs

6.3.1

B7:m

[ ]

m: Yes [ ]

C14

Receipt of checkRestriction invoke APDU and sending of return result and return error APDUs

6.3.1

B10:m

[ ]

m: Yes [ ]

- 39 -

Item

Name of Item

Reference

Status

N/A

Support

C15

Sending of callRerouteing invoke APDU and receipt of return result and return error APDUs

6.3.1

B8:m

[ ]

m: Yes [ ]

C16

Receipt of callRerouteing invoke APDU and sending of return result and return error APDUs

6.3.1

B3:m

[ ]

m: Yes [ ]

C17

Sending of divertingLegInformation1 invoke APDU

6.3.1

B3:m

[ ]

m: Yes [ ]

C18

Receipt of divertingLegInformation1 invoke APDU

6.3.1

B1:m

[ ]

m: Yes [ ]

C19

Sending of divertingLegInformation2 invoke APDU

6.3.1

B3:m

[ ]

m: Yes [ ]

C20

Receipt of divertingLegInformation2 invoke APDU

6.3.1

B9:m

[ ]

m: Yes [ ]

C21

Sending of divertingLegInformation3 invoke APDU

6.3.1

B9:m

[ ]

m: Yes [ ]

C22

Receipt of divertingLegInformation3 invoke APDU

6.3.1

B1:m

[ ]

m: Yes [ ]

C23

Sending of cfnrDivertedLegFailed invoke APDU

6.3.1

c.3

[ ]

m: Yes [ ]

C24

Receipt of cfnrDivertedLegFailed invoke APDU

6.3.1

c.4

[ ]

m: Yes [ ]

C25

Sending of Notification indicator containing "call is diverted" or embedded Redirection number information element

6.3.2.2

c.5

[ ]

m: Yes [ ]

C26

Recognition of "call is diverted" notification and embedded Redirection number information element in received Notification information element

6.3.2.2

c.6

[ ]

o: Yes [ ] No [ ]

c.1:

if B3 or B8 then optional, else N/A

c.2:

if B3 or B9 then optional, else N/A

c.3:

if B3 and A3 then mandatory, else N/A

c.4:

if B8 and A3 then mandatory, else N/A

c.5:

if B18 or B20 then mandatory, else N/A

c.6:

if B1 or B14 or B19 then optional, else N/A

- 40 -

A.3.6

Timers

Item

Name of Item

Reference

Status

N/A

Support

Support of timer T1

6.8.1

B8:m

[ ]

m: Yes [ ]

Support of timer T2

6.8.2

B11:m

[ ]

m: Yes [ ]

Support of timer T3

6.8.3

B12:m

[ ]

m: Yes [ ]

Support of timer T4

6.8.4

B13:m

[ ]

m: Yes [ ]

Support of timer T5

6.8.5

B7:m

[ ]

m: Yes [ ]

A.3.7

Interactions between SS-CFU/SS-CDI and SS-CCBS

Item

Question/feature

Support of SS-CCBS (Originating PINX)

Originating PINX procedures for invoking SS-CCBS at an SS-CFU/SS-CDI diverted-to user

Reference

Status

N/A

o 6.8.1.3.1

Support Yes [ ] No [ ]

c.1

[]

Yes [ ] No [ ]

Status

N/A

Support

c.1: if E1 and (A1 or A4) and A6 then optional, else N/A

A.3.8 Item

Interactions between SS-CFU/SS-CDI and SS-CCNR Question/feature

Support of SS-CCNR (Originating PINX)

Originating PINX procedures for invoking SS-CCNR at an SS-CFU/SS-CDI diverted-to user

Reference

o 6.8.1.4.1

c.1: if F1 and (A1 or A4) and A6 then optional, else N/A

c.1

Yes [ ] No [ ] []

Yes [ ] No [ ]

- 41 -

A.3.9 Item

Interactions between SS-CFB and SS-CCBS Question/feature

Support of SS-CCBS (Originating PINX)

Originating PINX procedures for invoking SS-CCBS at an SS-CFB diverted-to user

Reference

Status

N/A

o 6.8.2.3.1

Support Yes [ ] No [ ]

c.1

[]

Yes [ ] No [ ]

Status

N/A

Support

c.1: if G1 and A2 and A6 then optional, else N/A

A.3.10 Interactions between SS-CFB and SS-CCNR Item

Question/feature

Support of SS-CCNR (Originating PINX)

Originating PINX procedures for invoking SS-CCNR at an SS-CFB diverted-to user

Reference

o 6.8.2.4.1

c.1

Yes [ ] No [ ] []

Yes [ ] No [ ]

N/A

Support

c.1: if H1 and A2 and A6 then optional, else N/A

A.3.11 Interactions between SS-CFNR/SS-CDA and SS-CCNR Item

Question/feature

Support of SS-CCNR (Originating PINX)

Originating PINX procedures for invoking SS-CCNR at an SS-CFNR/SS-CDA diverted-to user

Reference

Status o

6.8.3.4.1

c.1: if I1 and (A3 or A5) and A6 then optional, else N/A

c.1

Yes [ ] No [ ] []

Yes [ ] No [ ]

- 42 -

A.3.12 Interactions between SS-CFNR and SS-CT Item

Question/feature

Reference

Status

N/A

Support

Support of SS-CT (transfer by join)

Yes [ ] No [ ]

Support of SS-CT (transfer by rerouteing)

Yes [ ] No [ ]

Support of SS-CFNR or SS-CDA by forward switching at a Served User PINX

B8:o

[]

Yes [ ] No [ ]

Actions at a Transferring PINX for rerouteing and SS-CFNR/SS-CDA Originating PINX

6.8.3.5.1

c.1

[]

m: Yes [ ]

Actions at a Transferring PINX for join or rerouteing and SS-CFNR/SS-CDA Originating PINX

6.8.3.5.2

c.2

[]

m: Yes [ ]

Actions at a Secondary PINX for rerouteing and SS-CFNR/SS-CDA Served User PINX

6.8.3.5.3

c.3

[]

m: Yes [ ]

Actions at a Secondary PINX for rerouteing and SS-CFNR/SS-CDA Served User / Rerouteing PINX

6.8.3.5.4

c.4

[]

m: Yes [ ]

Actions at a Secondary PINX for join and SS-CFNR/SS-CDA Served User / Rerouteing PINX

6.8.3.5.5

c.5

[]

m: Yes [ ]

Actions at a Transferring PINX for join

6.8.3.5.6

c.6

[]

m: Yes [ ]

J10

Actions at a Primary PINX for join

6.8.3.5.7

c.6

[]

m: Yes [ ]

Status

N/A

Support

c.1: if J2 and (A3 or A5) and A6 then mandatory, else N/A c.2: if (J1 or J2) and (A3 or A5) and A6 then mandatory, else N/A c.3: if J2 and (A3 or A5) and B8 then mandatory, else N/A c.4: if J2 and (A3 or A5) and J3 then mandatory, else N/A c.5: if J1 and (A3 or A5) and J3 then mandatory, else N/A c.6: if J1 and (A3 or A5) then mandatory, else N/A

A.3.13 Interactions between SS-CFU/SS-CDI and SS-CT Item

Question/feature

Reference

Support of SS-CT (transfer by join)

Yes [ ] No [ ]

Support of SS-CT (transfer by rerouteing)

Yes [ ] No [ ]

Actions at a Transferring PINX for join

c.1: if K1 and A2 then mandatory, else N/A

6.8.1.5.1

c.1

[]

m: Yes [ ]

- 43 -

A.3.14 Interactions between SS-CFB and SS-CT Item

Question/feature

Reference

Status

N/A

Support

Support of SS-CT (transfer by join)

Yes [ ] No [ ]

Support of SS-CT (transfer by rerouteing)

Yes [ ] No [ ]

Actions at a Transferring PINX for join

c.1: if L1 and A2 then mandatory, else N/A

6.8.2.5.1

c.1

[]

m: Yes [ ]

- 44 -

- 45 -

Annex B ( in f o r ma tiv e )

Imported ASN.1 definitions

The content of this annex has been deleted to remove duplicate ASN.1 definitions defined elsewhere.

- 46 -

- 47 -

Annex C ( in f o r ma tiv e )

Specification and Description Language (SDL) representation of procedures

The diagrams in this annex use the Specification and Description Language defined in ITU-T Recommendation Z.100 (1999). Each diagram represents the behaviour of an SS-DIV Supplementary Service Control entity at a particular type of PINX. In accordance with the protocol model described in ECMA-165, the Supplementary Service Control entity uses, via the Coordination Function, the services of Generic Functional Transport Control and Basic Call Control. Where an output symbol represents a primitive to the Coordination Function, and that primitive results in a message being sent, the output bears the name of the message and any remote operations APDU(s) or notification(s) contained in that message. In case of a message specified in ECMA-143, basic call actions associated with the sending of that message are deemed to occur. Where an input symbol represents a primitive from the Coordination Function and that primitive is the result of a message being received, the input signal bears the name of the message and any remote operation APDU(s) or notification(s) contained in that message. In case of a message specified in ECMA-143, basic call actions associated with the receipt of that message are deemed to have occurred. The following abbreviations are used: inv.

invoke APDU

res.

return result APDU

err.

return error APDU

rej.

reject APDU

C.1

SDL Representation of SS-DIV at the Originating PINX Figure C-1 shows the behaviour of an SS-DIV Supplementary Service Control entity within the Originating PINX, • Input signals from the right represent messages received via Protocol Control or primitives from the Coordination Function. NOTE When the rerouteing functionality is incorporated in the Originating PINX (in case of Call Diversion by rerouteing), the input signals from the right represent primitives from the Rerouteing PINX functionality to the Origination PINX functionality within the Originating PINX. • Output signals to the left represent primitives to the calling user. States are marked with the letters "CDO" (Call Diversion, Originating).

- 48 -

CDO-Idle

FACILITY

CONNECT

divertingLegInformation1 inv.

save subscription option and DTN

notify ?

divertingLegInformation3 inv.

notify ?

notification indication

presentation of number ?

Y diverted-to number indication

presentation of name ?

Y diverted-to name indication

CDO-Divert

CDO-Idle

F ig u r e C - 1 - O r ig in a t in g P I N X S D L ( s h e e t 1 o f 2 )

- 49 -

message (*) may be ALERTING, CONNECT or FACILITY

CDO-Divert

FACILITY

message (*)

CONNECT

divertingLegInformation1 inv.

divertingLegInformation3 inv.

divertingLegInformation1 inv.

divertingLegInformation3 inv.

save more restrictive NSO and new DTN

presentation of number ?

Y CFNR (CDA) ?

diverted-to number indication

NSO = notify ?

save more restrictive NSO and new DTN

presentation of name ?

notification indication

diverted-to name indication

call cleared

notification indication

presentation of number ?

NSO = notify ?

Y diverted-to number indication

presentation of name ?

notification indication

Y diverted-to name indication

CDO-Divert

CONNECT received ?

CDO-Idle

F ig u r e C - 1 - O r ig in a t in g P I N X S D L ( s h e e t 2 o f 2 )

- 50 -

C.2

SDL Representation of SS-DIV at the Rerouteing PINX NOTE 1 In case of rerouteing, the Rerouteing PINX is either the Originating PINX or the Incoming Gateway PINX. In case of forward switching, the Rerouteing PINX is the Served User PINX. Figure C-2 shows the behaviour of an SS-DIV Supplementary Service Control entity within the Rerouteing PINX. •

Input signals from the right represent messages received via Protocol Control or primitives from the Coordination Function. NOTE 2 When the rerouteing functionality is incorporated in the Served User PINX, the input signals from the right represent primitives from the Served User PINX functionality to the Rerouteing PINX functionality within the Served User PINX.

•

Output signals to the left represent messages sent via the incoming side Protocol Control. NOTE 3 When the rerouteing functionality is incorporated in the Originating PINX, the output signals to the left represent primitives from the Rerouteing PINX functionality to the Origination PINX functionality within the Originating PINX.

•

Output signals to the right represent messages sent via outgoing side Protocol Control. NOTE 4 When the rerouteing functionality is incorporated in the Served User PINX, the output signals to the right represent primitives from the Rerouting PINX functionality to the Served User PINX functionality within the Served User PINX or to the Diverted to PINX respectively.

States are marked with the letters "CDR" (Call Diversion, Rerouteing).

- 51 -

CDR-Idle

FACILITY callRerouting inv.

validate diversion request

DIV request valid ?

FACILITY callRerouting err.

CFNR (CDA) ?

to Served User PINX

CDR-Idle

to Served User PINX

callRerouting res.

stimulate release to Served User PINX and join remaining legs

callRerouting res.

FACILITY

DISCONN.

stimulate establishment of basic call

SETUP divertingLegInformation2 inv.

FACILITY callRerouting res.

to Served User PINX

stimulate establishment of basic call

to Diverted-to PINX

SETUP

divertingLegInformation2 inv.

FACILITY divertingLegInformation1 inv.

CDR-Idle

to Served User PINX

CDR-Invoked

Figure C-2 - Rerouteing PINX SDL (sheet 1 of 2)

to Diverted-to PINX

- 52 -

CDR-Invoked

CONNECT from Served User PINX

call cleared by Originating or Served User PINX

call cleared by Diverted-to PINX

FACILITY cfnrDivertedLegFailed inv.

ALERTING

CONNECT

from Diverted-to PINX

FACILITY

CONNECT

divertingLegInformation1 inv.

NOTE

stimulate release to Diverted-to PINX

stimulate release to Served User PINX and join remaining legs

stimulate release of both remaining legs

stimulate release to Served User PINX and join remaining legs

CDR-Idle

NOTE If a divertingLegInformation3 invoke APDU is included in the incoming CONNECT message from the Diverted-to PINX, this APDU is inserted in addition to the divertingLegInformation1 invoke APDU in the outgoing CONNECT message. NOTE Multiple service invocations are not indicated (i.e., receipt of callRerouting.inv in a FACILITY message or divertingLegInformation1 in a FACILITY message). Figure C-2 - Rerouteing PINX SDL (sheet 2 of 2)

- 53 -

C.3

SDL Representation of SS-DIV at the Served User PINX Figure C-3 shows the behaviour of an SS-DIV Supplementary Service Control entity within the Served User PINX, •

Input signals from the left represent messages received via Protocol Control. NOTE When the rerouteing functionality is incorporated in the Served User PINX (in case of Call Diversion by forward switching), the input signals from the left represent primitives from the Rerouteing PINX functionality to the Served User PINX functionality within the Served User PINX.

•

Input signals from the right represent primitives from the Coordination Function.

•

Output signals to the left represent messages sent via the incoming side Protocol Control. NOTE When the rerouteing functionality is incorporated in the Served User PINX, the output signals to the left represent primitives from the Served User PINX functionality to the Rerouteing PINX functionality within the Served User PINX.

•

Output signals to the right represent primitives to the served user.

•

Protocol timer expiry is indicated by input signals from the right.

States are marked with the letters "CDS" (Call Diversion, Served User PINX). NOTE Figure C-3, sheet 1 does not show the interaction between multiple invocations of CFNR (CDA).

- 54 -

CDS-Inv-Idle

FACILITY

DIV request detected

cfnrDivertedLegFailed inv. indication to served user : "call remains"

increment diversion counter

DIV request valid ?

Y N FACILITY callRerouting inv.

CFNR (CDA) ?

implementation specific procedure start timer T1

CDS-Inv-Idle

CDS-Requested

callRerouting return result or return error or reject APDU

FACILITY

call rerouting response

call cleared

timer T1 expired

stop timer T1

DIV invocation positiv ?

notify served user ?

Y implementation specific procedure

call diversion indication to served user

implementation specific procedure

CDS-Inv-Idle

Figure C-3 - Served User PINX SDL (sheet 1 of 3)

- 55 -

CDS-Act-Idle

message with activateDiv.Q invoke APDU

activate request valid ?

message with checkRestriction inv.

message with activateDiv.Q err.

start timer T5

CDS-Act-Idle

CDS-Act-Wait

message with check response

checkRestriction return result or return error or reject APDU

Timer T5 expired

stop timer T5

DIV activation acceptable ?

activate DIV

message with activateDiv.Q res.

message with activateDiv.Q err.

activation indication to served user

CDS-Act-Idle

Figure C-3 - Served User PINX SDL (sheet 2 of 3)

- 56 -

CDS-Deact-Idle

CDS-Inter-Idle

message with deactivateDiv.Q invoke APDU

DIV deactivation acceptable ?

message with interrog.Div.Q invoke APDU

get DIV activation data

message with interrogate response

deactivate DIV

message with deactivateDiv.Q return result APDU

message with deactivateDiv.Q return error APDU

interrogateDiversionQ return result or return error APDU

deactivation indication to served user

CDS-Deact-Idle

CDS-Inter-Idle

NOTE ActivateDiversionQ, deactivateDiversionQ and interrogateDiversionQ operations are not visible at the Q reference point in case of local activation, deactivation and interrogation. Figure C-3 - Served User PINX SDL (sheet 3 of 3)

- 57 -

C.4

SDL Representation of SS-DIV at the Diverted-to PINX Figure C-4 shows the behaviour of an SS-DIV Supplementary Service Control entity within the Diverted-to PINX. •

Input signals from the left represent messages received via Protocol Control.

•

Input signals from the right represent primitives from the Coordination Function.

•

Output signals to the left represent messages sent via Protocol Control.

•

Output signals to the right represent primitives to the diverted-to user.

States are marked with the letters "CDF" (Call Diversion, Diverted-to PINX).

CDF-Inv-Idle

CDF-Res-Idle

SETUP with divertingLeginformation2 invoke APDU diversion indication to user

message with checkRestrict. invoke APDU check diverted-to number and basic service

at the same time as basic call

message with check response

CDF-Inv-Wait

call cleared

presentation restrictions of diverted-to user message with divertingLeginformation3 invoke APDU

checkRestriction return result or return error APDU

ALERTING, CONNECT, FACILITY to Rerouteing PINX

CDF-Inv-Idle

CDF-Res-Idle

Figure C-4 - Diverted-to PINX SDL

- 58 -

C.5

SDL Representation of SS-DIV at the Activating PINX Figure C-5 shows the behaviour of an SS-DIV Supplementary Service Control entity within the Activating PINX. •

Input signals from the left represent messages received via Protocol Control.

•

Input signals from the right represent primitives from the activating user or timer expiry.

•

Output signals to the left represent messages sent via Protocol Control.

•

Output signals to the right represent primitives to the activating user.

States are marked with the letters "CDA" (Call Diversion, Activating PINX).

CDA-Idle

activation request from user

start timer T2

message with activateDiv.Q invoke APDU

CDA-Wait

message with activate response

stop timer T2

activateDiversionQ return result or return error or reject APDU timer T2 expired

activation indication to user

CDA-Idle

NOTE ActivateDiversionQ operations are not visible at the Q reference point in case of local activation. F ig u r e C - 5 - A c t iv a t in g P I N X S D L

- 59 -

C.6

SDL Representation of SS-DIV at the Deactivating PINX Figure C-6 shows the behaviour of an SS-DIV Supplementary Service Control entity within the Deactivating PINX. •

Input signals from the left represent messages received via Protocol Control.

•

Input signals from the right represent primitives from the deactivating user or timer expiry.

•

Output signals to the left represent messages sent via Protocol Control.

•

Output signals to the right represent primitives to the deactivating user.

States are marked with the letters "CDD" (Call Diversion, Deactivating PINX).

CDD-Idle

deactivation request from user

start timer T3

message with deactivateDiv.Q invoke APDU

CDD-Wait

message with deactivate response

stop timer T3

deactivateDiversionQ return result or return error or reject APDU timer T3 expired

deactivation indication to user

CDD-Idle

NOTE DeactivateDiversionQ operations are not visible at the Q reference point in case of local deactivation. F ig u r e C - 6 - D e a c t iv a t in g P I N X S D L

- 60 -

C.7

SDL Representation of SS-DIV at the Interrogating PINX Figure C-7 shows the behaviour of an SS-DIV Supplementary Service Control entity within the Interrogating PINX. •

Input signals from the left represent messages received via Protocol Control.

•

Input signals from the right represent primitives from the interrogating user or timer expiry.

•

Output signals to the left represent messages sent via Protocol Control.

•

Output signals to the right represent primitives to the interrogating user.

States are marked with the letters "CDI" (Call Diversion, Interrogating PINX).

CDI-Idle

interrogation request from user

start timer T4

message with interrog.Div.Q invoke APDU

CDI-Wait

message with interrogate response

stop timer T4

interrogateDiversionQ return result or return error or reject APDU timer T4 expired

interrogation indication to user

CDI-Idle

NOTE InterrogateDiversionQ operations are not visible at the Q reference point in case of local interrogation. F ig u r e C - 7 - I n t e r r o g a t in g P I N X S D L

- 61 -

Annex D ( in f o r ma tiv e )

Examples of message sequences

This annex describes some typical message flows of SS-DIV. The following conventions are used in the figures of this annex. 1. The following notation is used: Message containing SS-DIV information Basic call message without SS-DIV information

xxx.inv xxx.rr xxx.re

Invoke APDU for operation xxx Return result APDU for operation xxx Return error APDU for operation xxx

2. The figures show messages exchanged via Protocol Control between PINXs involved in SS-DIV. Only messages relevant to SS-DIV are shown. 3. Only the relevant information content (i.e. remote operation APDUs) is listed below each message name. The Facility information elements containing remote operation APDUs are not explicitly shown. Information with no impact on SSDIV is not shown.

- 62 -

D.1

Example message sequences in case of rerouteing In case of call diversion by rerouteing, Rerouteing PINX functionality is provided in the Originating PINX.

D.1.1

Example message sequences for SS-CFU/SS-CFB invocation Figure D-1.1.1 shows an example of successful invocation of SS-CFU(CDI)/SS-CFB.

(Rerouteing)

Served User

PINX

Originating

Diverted-to PINX

SETUP FACILITY callRerouting.inv FACILITY callRerouting.rr DISCONNECT SETUP divertingLegInformation2.inv ALERTING CONNECT divertingLegInformation3.inv

F ig u r e D - 1 . 1 . 1 - M e s s a g e s e q u e n c e f o r s u c c e s s f u l in v o c a t io n o f S S - C F U ( C D I ) /S S - C F B

- 63 -

Figures D-1.1.2 and D-1.1.3 show examples of unsuccessful invocations of SS-CFU(CDI)/SS-CFB.

(Rerouteing)

Served User

PINX

Originating

Diverted-to PINX

SETUP FACILITY callRerouting.inv FACILITY callRerouting.rr DISCONNECT SETUP divertingLegInformation2.inv DISCONNECT

F ig u r e D - 1 . 1 . 2 - M e s s a g e s e q u e n c e f o r u n s u c c e s s f u l in v o c a t io n o f S S - C F U ( C D I ) /S S - C F B: F a ilu r e of diverted call

(Rerouteing)

Served User

PINX

Originating

SETUP FACILITY callRerouting.inv FACILITY callRerouting.re

F ig u r e D - 1 . 1 . 3 - M e s s a g e s e q u e n c e f o r u n s u c c e s s f u l in v o c a t io n o f S S - C F U ( C D I ) /S S - C F B: Rejection of rerouteing request

- 64 -

D.1.2

Message sequences for SS-CFNR(CDA) invocation Figure D-1.2.1 shows an example for successful invocation of SS-CFNR(CDA).

(Rerouteing)

Served User

PINX

Originating

Diverted-to PINX

SETUP ALERTING FACILITY callRerouting.inv FACILITY callRerouting.rr SETUP divertingLegInformation2.inv ALERTING DISCONNECT CONNECT divertingLegInformation3.inv

Figure D-1.2.1 - Message sequence for successful invocation of SS-CFNR(CDA)

- 65 -

Figures D-1.2.2 and D-1.2.3 show examples for unsuccessful invocations of SS-CFNR(CDA).

(Rerouteing)

Served User

PINX

Originating

Diverted-to PINX

SETUP ALERTING FACILITY callRerouting.inv FACILITY callRerouting.rr SETUP divertingLegInformation2.inv DISCONNECT FACILITY cfnrDivertingLegFailed.inv

F ig u r e D - 1 . 2 . 2 - M e s s a g e s e q u e n c e f o r u n s u c c e s s f u l in v o c a t io n o f S S - C F N R ( C D A ) : Diversion not completed

(Rerouteing)

Served User

PINX

Originating

SETUP ALERTING FACILITY callRerouting.inv FACILITY callRerouting.re

F ig u r e D - 1 . 2 . 3 - M e s s a g e s e q u e n c e f o r u n s u c c e s s f u l in v o c a t io n o f S S - C F N R ( C D A ) : Rerouteing rejected

- 66 -

Figure D-1.2.4 shows the case in SS-CFNR(CDA) when user B answers before alerting of user C.

(Rerouteing)

Served User

PINX

Originating

SETUP ALERTING FACILITY callRerouting.inv FACILITY callRerouting.rr SETUP divertingLegInformation2.inv CONNECT DISCONNECT

F ig u r e D - 1 . 2 . 4 - M e s s a g e s e q u e n c e f o r S S - C F N R ( C D A ) : User B answers before alerting of user C

Diverted-to PINX

- 67 -

D.2

Example message sequences in case of forward switching In case of call diversion by forward switching, Rerouteing PINX functionality is provided in the Served User PINX.

D.2.1

Example message sequences for SS-CFU/SS-CFB invocation Figure D-2.1.1 shows an example for successful invocation of SS-CFU(CDI)/SS-CFB.

Originating

Served User

Diverted-to

PINX

(Rerouteing) PINX

PINX

SETUP SETUP divertingLegInformation2.inv FACILITY divertingLegInformation1.inv ALERTING ALERTING CONNECT CONNECT

divertingLegInformation3.inv

F ig u r e D - 2 . 1 . 1 - M e s s a g e s e q u e n c e f o r s u c c e s s f u l in v o c a t io n o f S S - C F U ( C D I ) /S S - C F B

- 68 -

Figure D-2.1.2 shows an example for unsuccessful invocation of SS-CFU(CDI)/SS-CFB.

Originating

Served User

Diverted-to

PINX

(Rerouteing) PINX

PINX

SETUP SETUP FACILITY

divertingLegInformation2.inv

divertingLegInformation1.inv DISCONNECT DISCONNECT

F ig u r e D - 2 . 1 . 2 - M e s s a g e s e q u e n c e f o r u n s u c c e s s f u l in v o c a t io n o f S S - C F U ( C D I ) /S S - C F B: Failure of diverted call

- 69 -

D.2.2

Example message sequences for SS-CFNR(CDA) invocation Figure D-2.2.1 shows an example for successful invocation of SS-CFNR(CDA).

Originating

Served User

Diverted-to

PINX

(Rerouteing) PINX

PINX

SETUP ALERTING SETUP divertingLegInformation2.inv ALERTING FACILITY CONNECT

divertingLegInformation1.inv

divertingLegInformation3.inv CONNECT divertingLegInformation3.inv

Figure D-2.2.1 - Message sequence for successful invocation of SS-CFNR(CDA) Figure D-2.2.2 shows an example for unsuccessful invocation of SS-CFNR(CDA).

Originating

Served User

Diverted-to

PINX

(Rerouteing) PINX

PINX

SETUP ALERTING SETUP divertingLegInformation2.inv DISCONNECT

F ig u r e D - 2 . 2 . 2 - M e s s a g e s e q u e n c e f o r u n s u c c e s s f u l in v o c a t io n o f S S - C F N R ( C D A ) : Diversion not completed

- 70 -

Figure D-2.2.3 shows the case in SS-CFNR(CDA) when user B answers before alerting of user C.

Originating

Served User

Diverted-to

PINX

(Rerouteing) PINX

PINX

SETUP ALERTING SETUP divertingLegInformation2.inv (Answer of served user) CONNECT

DISCONNECT

F ig u r e D - 2 . 2 . 3 - M e s s a g e s e q u e n c e f o r S S - C F N R ( C D A ) : User B answers before alerting of user C

- 71 -

D.3

Example message sequences for activation, deactivation and interrogation Figure D-3.1 shows an example for the successful activation of SS-CF including verification of the divertedto number. This example shows the particular case of a Transit PINX between the Served User PINX and the Diverted-to PINX. In this example, the signalling connection for activation and the signalling connection for verification of the diverted-to number are each established for the purpose and released immediately afterwards.

Diverted-to

Transit

PINX

Served User PINX

Activating

PINX

SETUP

SETUP SETUP

activateDiversionQ.inv

checkRestriction.inv

CONNECT checkRestriction.rr

RELEASE

CONNECT activateDiversionQ.rr

REL COM RELEASE REL COM

RELEASE REL COM

F ig u r e D - 3 . 1 - M e s s a g e s e q u e n c e f o r a c t iv a t io n o f S S - C F

- 72 -

Figure D.3.2 shows an example for the successful deactivation of SS-CF. In this example, the signalling connection for deactivation is established for the purpose and released immediately afterwards.

Served User

Interrogat. PINX

PINX

SETUP deactivateDiversionQ.inv CONNECT deactivateDiversionQ.rr RELEASE RELEASE COMPLETE

F ig u r e D - 3 . 2 - M e s s a g e s e q u e n c e f o r d e a c t iv a t io n o f S S - C F Figure D-3.3 shows an example for the successful interrogation of SS-CF. In this example, the signalling connection for interrogation is established for the purpose and released immediately afterwards.

Served User

Interrogat. PINX

PINX

SETUP interrogateDiversionQ.inv CONNECT interrogateDiversionQ.rr RELEASE RELEASE COMPLETE

F ig u r e D - 3 . 3 - M e s s a g e s e q u e n c e f o r in t e r r o g a t io n o f S S - C F

- 73 -

Annex E ( in f o r ma tiv e )

Bibliography

ITU-T Rec. I.252.2

Integrated Services Digital Network (ISDN), Call Forwarding Busy (CFB) supplementary service, service description (1992)

ITU-T Rec. I.252.3

Integrated Services Digital Network (ISDN), Call Forwarding No Reply (CFNR) supplementary service, service description (1992)

ITU-T Rec. I.252.4

Integrated Services Digital Network (ISDN), Call Forwarding Unconditional (CFU) supplementary service, service description (1992)

ITU-T Rec. I.252.5

Integrated Services Digital Network (ISDN), Call Deflection (CD) supplementary service, service description (1992)

- 74 -

- 75 -

Annex F ( n o r ma tiv e )

ASN.1 definitions according to ITU-T Recs. X.208 / X.209

This annex lists all ASN.1 modules as they were defined in the second edition of ECMA-174, i.e. based on ITU-T Recommendations X.208 / X.209. Starting with the third edition the ASN.1 modules within ECMA-174 comply with ITU-T Recommendations X.680 / X.690. Please note that regardless of which version of these modules is used as a base of a QSIG implementation, the line encoding remains unchanged. Changes in future editions to modules based on X.680 / X.690 ASN.1 are not reflected in the modules in this annex. Ta b le F . 1 - C a ll- D iv e r s io n - O p e r a t io n s – b a s e d o n I TU - T R e c s . X . 2 0 8 / X . 2 0 9 Call-Diversion-Operations { iso (1) standard (0) pss1-call-diversion (13873) call-diversion-operations (0) } DEFINITIONS EXPLICIT TAGS

::=

BEGIN IMPORTS

OPERATION, ERROR FROM Remote-Operation-Notation { joint-iso-ccitt (2) remote-operations (4) notation (0) } Extension FROM Manufacturer-specific-service-extension-definition { iso standard pss1-generic-procedures (11582) msi-definition (0) } PSS1InformationElement FROM PSS1-generic-parameters-definition { iso standard pss1-generic-procedures (11582) pss1-generic-parameters (6) } Address, PartyNumber, PartySubaddress, PresentedNumberScreened, PresentedNumberUnscreened, PresentationAllowedIndicator FROM Addressing-Data-Elements { iso standard pss1-generic-procedures (11582) addressing-data-elements (9)} Name FROM Name-Operations { iso standard pss1-name (13868) name-operations (0) } userNotSubscribed, notAvailable, invalidServedUserNr, basicServiceNotProvided, resourceUnavailable, supplementaryServiceInteractionNotAllowed FROM General-Error-List { ccitt recommendation q 950 general-error-list (1) };

- 76 -

Ta b le F . 1 - C a ll- D iv e r s io n - O p e r a t io n s – b a s e d o n I TU - T R e c s . X . 2 0 8 / X . 2 0 9 ( c o n t in u e d ) ActivateDiversionQ ::= OPERATION -- Sent from the Activating PINX to the Served User PINX ARGUMENT SEQUENCE { procedure Procedure, basicService BasicService, divertedToAddress Address, servedUserNr PartyNumber, activatingUserNr PartyNumber, extension CHOICE { [1] IMPLICIT Extension , [2] IMPLICIT SEQUENCE OF Extension } OPTIONAL } RESULT CHOICE { NULL, [1] IMPLICIT Extension , [2] IMPLICIT SEQUENCE OF Extension } ERRORS { userNotSubscribed, notAvailable, invalidServedUserNr, basicServiceNotProvided, resourceUnavailable, invalidDivertedToNr, specialServiceNr, diversionToServedUserNr, temporarilyUnavailable, notAuthorized, unspecified } DeactivateDiversionQ ::= OPERATION -- Sent from the Deactivating PINX to the Served User PINX ARGUMENT SEQUENCE { procedure Procedure, basicService BasicService, servedUserNr PartyNumber, deactivatingUserNr PartyNumber, extension CHOICE { [1] IMPLICIT Extension , [2] IMPLICIT SEQUENCE OF Extension } OPTIONAL } RESULT CHOICE { NULL, [1] IMPLICIT Extension , [2] IMPLICIT SEQUENCE OF Extension } ERRORS {userNotSubscribed, notAvailable, invalidServedUserNr, temporarilyUnavailable, notAuthorized, unspecified } InterrogateDiversionQ ::= OPERATION -- Sent from the Interrogating PINX to the Served User PINX ARGUMENT SEQUENCE { procedure Procedure, basicService BasicService DEFAULT allServices, servedUserNr PartyNumber, interrogatingUserNr PartyNumber, extension CHOICE { [1] IMPLICIT Extension , [2] IMPLICIT SEQUENCE OF Extension } OPTIONAL } RESULT IntResultList ERRORS {userNotSubscribed, notAvailable, invalidServedUserNr, temporarilyUnavailable, notAuthorized, unspecified }

- 77 -

Ta b le F . 1 - C a ll- D iv e r s io n - O p e r a t io n s – b a s e d o n I TU - T R e c s . X . 2 0 8 / X . 2 0 9 ( c o n t in u e d ) CheckRestriction ::= OPERATION -- Sent from the Served User PINX to the Diverted-to PINX ARGUMENT SEQUENCE { servedUserNr PartyNumber, basicService BasicService, divertedToNr PartyNumber, extension CHOICE { [1] IMPLICIT Extension , [2] IMPLICIT SEQUENCE OF Extension } OPTIONAL } RESULT CHOICE { NULL, [1] IMPLICIT Extension, [2] IMPLICIT SEQUENCE OF Extension } ERRORS {notAvailable, invalidServedUserNr, invalidDivertedToNr, specialServiceNr, unspecified } CallRerouteing ::= OPERATION -- Sent from the Served User PINX to the Rerouteing PINX ARGUMENT SEQUENCE { rerouteingReason DiversionReason, originalRerouteingReason [0] IMPLICIT DiversionReason OPTIONAL, calledAddress Address, diversionCounter INTEGER (1..15), pSS1InfoElement PSS1InformationElement, -- The basic call information elements Bearer capability, High layer compatibility, Low -- layer compatibity and Progress indicator can be embedded in the -- pSS1InfoElement in accordance with 6.5.3.1.5. lastRerouteingNr [1] PresentedNumberUnscreened, subscriptionOption [2] IMPLICIT SubscriptionOption, callingPartySubaddress [3] PartySubaddress OPTIONAL, callingNumber [4] PresentedNumberScreened, callingName [5] Name OPTIONAL, originalCalledNr [6] PresentedNumberUnscreened OPTIONAL, redirectingName [7] Name OPTIONAL, originalCalledName [8] Name OPTIONAL, extension CHOICE { [9] IMPLICIT Extension , [10] IMPLICIT SEQUENCE OF Extension } OPTIONAL } RESULT CHOICE { NULL, [1] IMPLICIT Extension , [2] IMPLICIT SEQUENCE OF Extension } ERRORS

{userNotSubscribed, notAvailable, resourceUnavailable, invalidDivertedToNr, specialServiceNr, diversionToServedUserNr, numberOfDiversionsExceeded, supplementaryServiceInteractionNotAllowed, unspecified } -- The error value numberOfDiversionsExceeded applies only in case of partial rerouteing.

- 78 -

Ta b le F . 1 - C a ll- D iv e r s io n - O p e r a t io n s – b a s e d o n I TU - T R e c s . X . 2 0 8 / X . 2 0 9 ( c o n t in u e d ) DivertingLegInformation1 ::= OPERATION -- Sent from the Rerouteing PINX to the Originating PINX ARGUMENT SEQUENCE { diversionReason DiversionReason, subscriptionOption SubscriptionOption, nominatedNr PartyNumber, extension CHOICE { [9] IMPLICIT Extension , [10] IMPLICIT SEQUENCE OF Extension } OPTIONAL } DivertingLegInformation2 ::= OPERATION -- Sent from the Rerouteing PINX to the Diverted-to PINX ARGUMENT SEQUENCE { diversionCounter INTEGER (1..15), diversionReason DiversionReason, originalDiversionReason [0] IMPLICIT DiversionReason OPTIONAL, divertingNr [1] PresentedNumberUnscreened OPTIONAL, originalCalledNr [2] PresentedNumberUnscreened OPTIONAL, redirectingName [3] Name OPTIONAL, originalCalledName [4] Name OPTIONAL, extension CHOICE { [5] IMPLICIT Extension , [6] IMPLICIT SEQUENCE OF Extension } OPTIONAL } -- The divertingNr element is mandatory except in the case of interworking. DivertingLegInformation3 ::= OPERATION -- Sent from the Diverted-to PINX to the Originating PINX ARGUMENT SEQUENCE { presentationAllowedIndicator PresentationAllowedIndicator, redirectionName [0] Name OPTIONAL, extension CHOICE { [1] IMPLICIT Extension , [2] IMPLICIT SEQUENCE OF Extension } OPTIONAL } CfnrDivertedLegFailed ::= OPERATION -- Sent from the Rerouteing PINX to the Served User PINX ARGUMENT CHOICE { NULL, [1] IMPLICIT Extension , [2] IMPLICIT SEQUENCE OF Extension } -- This indicates that the diverted-to leg has been cleared during SS-CFNR execution. -- Definitions of general used data types: DiversionReason ::= ENUMERATED { unknown (0), cfu (1), cfb (2), cfnr (3)} -- The value unknown is only used if received from another network when interworking.

- 79 -

Ta b le F . 1 - C a ll- D iv e r s io n - O p e r a t io n s – b a s e d o n I TU - T R e c s . X . 2 0 8 / X . 2 0 9 ( c o n c lu d e d ) IntResultList IntResult

::= SET SIZE (0..29) OF IntResult ::= SEQUENCE { servedUserNr PartyNumber, basicService BasicService, procedure Procedure, divertedToAddress Address, remoteEnabled BOOLEAN DEFAULT FALSE, extension CHOICE { [1] IMPLICIT Extension , [2] IMPLICIT SEQUENCE OF Extension} OPTIONAL }

Procedure

::= ENUMERATED { cfu (0), cfb (1), cfnr (2) }

SubscriptionOption

::= ENUMERATED { noNotification (0), notificationWithoutDivertedToNr (1), notificationWithDivertedToNr (2) }

Unspecified

invalidDivertedToNr ERROR ::= localValue 12 specialServiceNr ERROR ::= localValue 14 diversionToServedUserNr ERROR ::= localValue 15 numberOfDiversionsExceeded ERROR ::= localValue 24 temporarilyUnavailable ERROR ::= localValue 1000 notAuthorized ERROR ::= localValue 1007 unspecified Unspecified ::= localValue 1008 ::= ERROR PARAMETER Extension

BasicService

activateDiversionQ deactivateDiversionQ interrogateDiversionQ checkRestriction callRerouteing divertingLegInformation1 divertingLegInformation2 divertingLegInformation3 cfnrDivertedLegFailed

ActivateDiversionQ DeactivateDiversionQ InterrogateDiversionQ CheckRestriction CallRerouteing DivertingLegInformation1 DivertingLegInformation2 DivertingLegInformation3 CfnrDivertedLegFailed

END -- of Call-Diversion-Operations

::= localValue 15 ::= localValue 16 ::= localValue 17 ::= localValue 18 ::= localValue 19 ::= localValue 20 ::= localValue 21 ::= localValue 22 ::= localValue 23

Free printed copies can be ordered from: ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland Fax: Email:

+41 22 849.60.01 [email protected]

Files of this Standard can be freely downloaded from the ECMA web site (www.ecma.ch). This site gives full information on ECMA, ECMA activities, ECMA Standards and Technical Reports.

ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland See inside cover page for obtaining further soft or hard copies.

ECMA-174 — Private Integrated Services Network (PISN) - Inter-exchange signalling protocol - Call diversion supplementary services (QSIG-CF) (December 2001)

Related documents