Conceptio › Archive › ECMA International

ECMA Internationalopen access

ECMA-300 — Private Integrated Services Network (PISN) - Inter-exchange signalling protocol - Single step call transfer supplementary service (QSIG-SSCT) (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-300, ecma 300, 300, private, integrated, services, network, pisn, inter-exchange, signalling, protocol, single, step, call, transfer, supplementary, service, qsig-ssct

S tandard ECMA-300

2nd Edition - December 2001

Standardizing Information

and

Communication

Systems

Private Integrated Services Network (PISN) Inter-Exchange Signalling Protocol Single Step Call Transfer Supplementary Service

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

S tandard ECMA-300

2nd Edition - December 2001

Standardizing

Information

and

Communication

Systems

Private Integrated Services Network (PISN) Inter-Exchange Signalling Protocol Single Step Call Transfer Supplementary Service (QSIG-SSCT)

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

Ecma-300.doc

15-01-02 08,38

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 Transfer supplementary service. 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-300 (published by ECMA in February 2000), this 2nd Edition incorporates migration to ASN.1 version 1997 as well as changes in order to achieve complete alignment with International Standard ISO/IEC 19460:2001(E) published by ISO/IEC in May 2001.

Adopted as 2nd Edition of Standard ECMA-300 by the General Assembly in December 2001.

- i -

Table of contents 1

Scope

Conformance

References (normative)

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 Re r o u tin g n u mb e r 4.2.2 Re r o u tin g P I N X 4.2.3 Transferred PINX 4.2.4 Transferred-To PINX 4.2.5 Transferring PINX

2 2 3 3 3 3 3 3

5 6

Acronyms Signalling protocol for the support of SS-SSCT 6.1 SS-SSCT description 6 . 2 S S - S S CT 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 a T r a n s f e r r in g P I N X 6.2.3 Re q u ir e me n ts o n a Re r o u tin g P I N X 6.2.4 Re q u ir e me n ts o n a T r a n s f e r r e d P I N X 6.2.5 Re q u ir e me n ts o n a T r a n s f e r r e d - T o 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 . 3 S S - S S CT 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 SS-SSCT state definitions 6.4.1 States at a Transferring PINX 6.4.2 States at a Rerouting PINX 6.4.3 States at a Transferred PINX 6.4.4 States at a Transferred-To PINX 6 . 5 S S - S S CT s ig n a llin g p r o c e d u r e s 6.5.1 Actions at a Transferring PINX 6.5.2 P r o c e d u r e s a t th e Re r o u tin g P I N X 6.5.3 Actions at a Transferred PINX 6.5.4 Actions at a Transferred-To PINX 6.5.5 Actions at a Transit PINX 6.5.6 S u b s e q u e n t a c tio n s a t T r a n s f er r e d a n d T r a n s f e r r e d - T o P I N X 6 . 6 S S - S S CT imp 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

3 4 4 4 4 4 4 4 4 4 5 5 7 7 8 8 8 8 8 8 9 9 12 12 12 12 12

- ii -

6.6.1 Actions at a Gateway PINX 6 . 7 S S - S S CT imp 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 Actions at a Gateway PINX 6 . 8 P r o to c o l I n te r a c tio n s b e tw e e n S S - S S CT a n d o th e r s u p p le me n ta r y s e r v ic e s a n d A N F s 6.8.1 C a l l i n g N a me I d e n t i f i c a t i o n P r e s e n t a t i o n ( S S - C N I P ) 6.8.2 C o n n e c t e d N a me I d e n t i f i c a t io n P r e s e n ta tio n ( S S - CO N P ) 6.8.3 C o mp l e t i o n o f C a l l s t o B u s y S u b s c r i b e r s ( S S - C C B S ) 6.8.4 Co mp le tio n o f Ca lls o n N o Re p ly ( S S - CCN R) 6.8.5 Ca llF o r w a r d in g U n c o n d itio n a l ( S S - CF U ) 6.8.6 C a l l F o r w a r d in g B u s y ( S S - C F B ) 6.8.7 Ca ll F o r w a r d in g N o Re p ly ( S S - CF N R) 6.8.8 Call Deflection (SS-CD) 6.8.9 Call Transfer (SS-CT) 6.8.10 P a t h R e p l a c e me n t ( A N F - P R ) 6.8.11 A d v ic e O f Ch a r g e ( S S - A O C) 6.8.12 Call Offer (SS-CO) 6.8.13 Do Not Disturb (SS-DND) 6.8.14 Do Not Disturb Override (SS-DNDO) 6.8.15 Recall (SS-RE) 6.8.16 Ca ll I n tr u s io n ( S S - CI ) 6.8.17 Call Interception (ANF-CINT) 6.8.18 T r a n s it Co u n te r ( S S - T C) 6.8.19 R o u te R e s t r i c t i o n C l a s s ( A N F - R R C ) 6.8.20 Authentication of the PISN (SS-WTAN) 6.8.21 A u th e n tic a tio n o f a W T M u s e r ( S S - W T A T ) 6.8.22 W ir e l e s s T e r mi n a l L o c a t i o n Re g is tr a tio n ( S S - W T L R) 6.8.23 W ir e l e s s T e r mi n a l M o b i l i t y I n c o min g C a l l ( A N F - W T M I ) 6.8.24 W ir e l e s s T e r mi n a l M o b i l i t y O u t g o in g C a l l ( A N F - W T M O ) 6.8.25 Me s s a g e W a itin g I n d ic a tio n ( S S - MW I ) 6.8.26 U s e r M o b i l i t y I n c o min g C a l l ( A N F - P U M I ) 6.8.27 U s e r M o b i l i t y O u t g o in g C a l l ( A N F - P U M O ) 6.8.28 P r i v a t e U s e r M o b i l i t y - R e g is t r a t i o n ( S S - P U M R ) 6.8.29 C o mmo n I n f o r ma t i o n ( A N F - C MN ) 6.8.30 Call Priority Interruption (Protection) (SS-CPI(P)) 6 . 9 S S - S S C T 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

12 13 13 13 13 13 14 14 14 14 14 15 15 15 16 17 17 17 17 17 17 18 18 18 18 18 18 18 18 18 18 18 18 18 19 19 19 19

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

Annex B - Imported ASN.1 definitions

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

A n n e x D - 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

- iii -

Annex E - Additional feature identifier in module Common-Information-Operations

A n n e x F - D i f f e r e n c e b e t w e e n S i n g l e S t e p C al l T r a n s f e r a n d C a l l T r a n s f e r b y R e r o u t i n g 5 1 A n n e x G - 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

- iv -

Scope This Standard specifies the signalling protocol for the support of the Single Step Call Transfer supplementary service (SS-SSCT) at the Q reference point between Private Integrated Network services eXchanges (PINXs) connected together within a Private Integrated Services Network (PISN). SS-SSCT is a supplementary service which enables a user, user A, to transform an existing call between user A and user B into a new call between user B and a user C whereby user A does not have a call established with user C prior to call transfer. 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-299. The signalling protocol for SS-SSCT 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 Single Step Call Transfer and other supplementary services and ANFs. This Standard is applicable to PINXs which can interconnect 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. Conformance to this Standard includes conforming to those clauses that specify protocol interactions between SS-SSCT and other supplementary services and ANFs for which signalling protocols at the Q reference point are supported in accordance with the stage 3 standards concerned.

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 64kbit/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-155

Private Integrated ISO/IEC 11571)

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)

Services

Networks

Addressing

(International

Standard

- 2 -

ECMA-174

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

ECMA-176

Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Path Replacement Additional Network Feature (International Standard ISO/IEC 13874)

ECMA-178

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

ECMA-212

Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Advice of Charge Supplementary Services (International Standard ISO/IEC 15050)

ECMA-221

Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Call Interception Additional Network Feature (International Standard ISO/IEC 15054)

ECMA-225

Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Transit Counter Additional Network Feature (International Standard ISO/IEC 15056)

ECMA-251

Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol Common Information Additional Network Feature (International Standard ISO/IEC 15772)

ECMA-264

Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Call Priority Interruption and Call Priority Interruption Protection Supplementary Services (International Standard ISO/IEC 15992)

ECMA-299

Private Integrated Services Network (PISN) - Specification, Functional Model and Information Flows - Single Step Call Transfer Supplementary Service

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. Q.950 Supplementary services protocols, structure and general principles (2000) 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)

−

Gateway PINX

(ECMA-143)

−

Complete Number

(ECMA-155)

−

Interpretation APDU

(ECMA-165)

−

Network Facility Extension (NFE)

(ECMA-165)

−

New Call, New Connection

(ECMA-299)

−

Original Call, Original Connection

(ECMA-299)

−

Originating PINX

(ECMA-165)

−

Private Integrated Services Network (PISN)

(ECMA-133)

−

Private Integrated services Network eXchange (PINX)

(ECMA-133)

- 3 -

4.2

−

Subsequent PINX

(ECMA-165)

−

Signalling

(ITU-T Rec. I.112)

−

Supplementary Service

(ITU-T Rec. I.210)

−

Supplementary Service Control Entity

(ECMA-165)

−

Terminating PINX

(ECMA-165)

−

Transit PINX

(ECMA-165)

−

User

(ECMA-142)

−

User A, Transferring user

(ECMA-299)

−

User B, Transferred user

(ECMA-299)

−

User C, Transferred-to user

(ECMA-299)

Other definitions

4.2.1

R e r o u t in g n u m b e r The number of the Transferred-to user.

4.2.2

R e r o u t in g P I N X A PINX on the call path of the original call, that reroutes that call to user C. This can either be the Transferring, the Transferred or a Transit PINX being capable of performing the rerouting function.

4.2.3

Transferred PINX The End PINX which is on the end of the original call nearest to user B.

4.2.4

Transferred-To PINX The End PINX which is on the end of the new call nearest to user C.

4.2.5

Transferring PINX The End PINX which initiates single step call transfer procedures on behalf of user A.

Acronyms APDU

Application Protocol Data Unit

ASN.1

Abstract Syntax Notation no. 1

ISDN

Integrated Services Digital Network

NFE

Network Facility Extension

PICS

Protocol Implementation Conformance Statement

PINX

Private Integrated services Network eXchange

PISN

Private Integrated Services Network

SDL

Specification and Description Language

SS-SSCT

Supplementary Service Single Step Call Transfer

- 4 -

Signalling protocol for the support of SS-SSCT

6.1

SS-SSCT description SS-SSCT is a supplementary service which enables a user, user A, to transform an existing call between user A and user B into a new call between user B and a user C whereby user A does not have a call established with user C prior to call transfer. This supplementary service is applicable to all basic services defined in ECMA-142.

6.2

SS-SSCT operational requirements

6.2.1

P r o v is io n /W it h d r a wa l Provision and withdrawal shall be in accordance with 6.2.1 of ECMA-299.

6.2.2

Requirements on a Transferring PINX The basic call procedures specified in ECMA-143 shall be supported. Generic procedures for the call-related control of supplementary services, as specified in ECMA-165 for an End PINX, shall apply.

6.2.3

Requirements on a Rerouting PINX The basic call procedures specified in ECMA-143 shall be supported. Generic procedures for the call-related control of supplementary services, as specified in ECMA-165 for an End PINX, shall apply.

6.2.4

Requirements on a Transferred PINX The basic call procedures specified in ECMA-143 shall be supported. Generic procedures for the call-related control of supplementary services, as specified in ECMA-165 for an End PINX, shall apply.

6.2.5

Requirements on a Transferred-To PINX The basic call procedures specified in ECMA-143 shall be supported. 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 The basic call procedures specified in ECMA-143 shall be supported. Generic procedures for the call-related control of supplementary services, as specified in ECMA-165 for a Transit PINX, shall apply.

- 5 -

6.3 6.3.1

SS-SSCT coding requirements O p e r a t io n s The operations defined in Abstract Syntax Notation number 1 (ASN.1) in table 1 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 G. Table 1 - Operations in support of SS-SSCT Single-Step-Call-Transfer-Operations-asn1-97 { iso(1) standard (0) pss1-single-step-call-transfer (19460) single-step-call-transfer-operations-asn1-97 (1)} DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS OPERATION, ERROR FROM Remote-Operations-Information-Objects { joint-iso-itu-t (2) 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) } Name FROM Name-Operations-asn1-97 {iso(1) standard(0) pss1-name (13868) name-operations-asn1-97 (1)} supplementaryServiceInteractionNotAllowed, notAvailable, invalidCallState FROM General-Error-List { ccitt recommendation q 950 general-error-list (1) } PresentedAddressScreened, PartyNumber FROM Addressing-Data-Elements-asn1-97 {iso(1) standard (0) pss1-generic-procedures (11582) addressing-data-elements-asn1-97 (20)} PSS1InformationElement FROM PSS1-generic-parameters-definition-asn1-97 {iso(1) standard (0) pss1-generic-procedures (11582) pss1-generic-parameters-asn1-97 (17)} callTransferUpdate, callTransferComplete, callTransferActive, subaddressTransfer, invalidRerouteingNumber, establishmentFailure FROM Call-Transfer-Operations-asn1-97 {iso(1) standard (0) pss1-call-transfer (13869) call-transfer-operations-asn1-97 (1)}; Single-Step-Call-Transfer-Operations OPERATION ::= { ssctInitiate | ssctSetup | ssctPostDial | ssctDigitInfo } ssctInitiate

OPERATION ::= { -- sent from the Transferring PINX to the Rerouting PINX ARGUMENT SSCTInitiateArg RESULT DummyRes ERRORS { notAvailable | invalidCallState | invalidRerouteingNumber | establishmentFailure | unspecified | supplementaryServiceInteractionNotAllowed } CODE local: 99}

- 6 -

Table 1 - Operations in support of SS-SSCT (continued) ssctSetup

OPERATION ::= { -- sent from the Rerouting PINX to the Transferred-To PINX ARGUMENT SSCTSetupArg RETURN RESULT FALSE ALWAYS RESPONDS FALSE CODE local: 100}

ssctPostDial

OPERATION ::= { -- sent from the Rerouting PINX to the Transferred PINX ARGUMENT DummyArg RETURN RESULT FALSE ALWAYS RESPONDS FALSE CODE local: 101}

ssctDigitInfo

OPERATION ::= { -- sent from the Transferred PINX to the Rerouting PINX ARGUMENT SSCTDigitInfoArg RETURN RESULT FALSE ALWAYS RESPONDS FALSE CODE local: 102}

DummyArg ::=

CHOICE { null single multiple

NULL, [1] IMPLICIT Extension{{SSCTExtSet}}, [2] IMPLICIT SEQUENCE OF Extension{{SSCTExtSet}}}

CHOICE { null single multiple

NULL, [1] IMPLICIT Extension{{SSCTExtSet}}, [2] IMPLICIT SEQUENCE OF Extension{{SSCTExtSet}}}

DummyRes ::=

SSCTInitiateArg ::= SEQUENCE { rerouteingNumber PartyNumber, -- Transferred-To Number transferredAddress PresentedAddressScreened, awaitConnect AwaitConnect, transferredName [1] Name OPTIONAL, transferringAddress [2] PresentedAddressScreened OPTIONAL, transferringName [3] Name OPTIONAL, argumentExtension CHOICE { single [4] IMPLICIT Extension{{SSCTExtSet}}, multiple [5] IMPLICIT SEQUENCE OF Extension{{SSCTExtSet}} } OPTIONAL } AwaitConnect ::=

BOOLEAN -- FALSE = release the original call upon ALERTING received -- TRUE = release the original call upon CONNECT received

- 7 -

Table 1 - Operations in support of SS-SSCT (concluded) SSCTSetupArg ::= SEQUENCE { transferringAddress transferringName argumentExtension single multiple

[1] PresentedAddressScreened OPTIONAL, [2] Name OPTIONAL, CHOICE { [3] IMPLICIT Extension{{SSCTExtSet}}, [4] IMPLICIT SEQUENCE OF Extension{{SSCTExtSet}} } OPTIONAL

} SSCTDigitInfoArg ::= SEQUENCE { reroutingNumber sendingComplete argumentExtension single multiple

[1] PartyNumber OPTIONAL, -- remaining digits of the Transferred-To Number [2] IMPLICIT NULL OPTIONAL, CHOICE { [3] IMPLICIT Extension{{SSCTExtSet}}, [4] IMPLICIT SEQUENCE OF Extension{{SSCTExtSet}} } OPTIONAL

} SSCTExtSet EXTENSION ::= {…} unspecified ERROR ::= { PARAMETER CODE END

Extension{{SSCTExtSet}} local: 1008}

-- of SSCT Operations-asn1-97

6.3.2 Information elements 6.3.2.1 Facility information element APDUs of 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 operation ssctSetup, the Interpretation APDU shall contain value discardAnyUnrecognisedInvokePdu. When conveying the invoke APDU of operations ssctInitiate, ssctPostDial or ssctDigitInfo the Interpretation APDU shall be included with the value rejectAnyUnrecognisedInvokePdu or omitted. 6.3.2.2

Information elements embedded in the Facility information element APDUs of the operations defined in 6.3.1 may contain information elements defined in and coded according to ECMA-143. These shall be embedded in data elements of type PSS1InformationElement as specified in annex B of ECMA-165.

6.3.2.3

Other information elements Information elements used during the establishment of the new connection shall be coded as specified in ECMA-143.

6.3.3

Messages Except for cases where a basic call message is to be conveyed at the same time, the Facility information element shall be conveyed in a FACILITY message as specified in ECMA-165.

- 8 -

Messages used during the establishment of the new connection and release of the original connection shall be as specified in ECMA-143 and, where applicable, augmented in ECMA-165.

6.4

SS-SSCT state definitions

6.4.1

States at a Transferring PINX The procedures at the Transferring PINX are written in terms of the following conceptual states existing within the SS-SSCT control entity in that PINX in association with a particular SS-SSCT request from the transferring user.

6.4.1.1

S S C T- I d le SS-SSCT is not operating.

6.4.1.2

S S C T- A wa it - I n it ia t e - R e s p o n s e A ssctInitiate invoke APDU has been sent to the Rerouting PINX.

6.4.2

S t a t e s a t a R e r o u t in g P I N X The procedures at the Rerouting PINX are written in terms of the following conceptual states existing within the SS-SSCT control entity in that PINX.

6.4.2.1

S S C T- I d le SS-SSCT is not operating.

6.4.2.2

S S C T- A wa it - S e t u p - R e s p o n s e - A le r t A ssctInitiate invoke APDU has been received with element waitConnect set to FALSE. A ssctSetup invoke APDU has been sent to the Transferred-To PINX.

6.4.2.3

S S C T- A wa it - S e t u p - R e s p o n s e - C o n n e c t A ssctInitiate invoke APDU has been received with element waitConnect set to TRUE. A ssctSetup invoke APDU has been sent to the Transferred-To PINX.

6.4.2.4

S S C T- A wa it - I n f o A ssctPostDial invoke APDU has been sent to the Transferred PINX and further address information can be received in overlap mode.

6.4.3

States at a Transferred PINX The procedures at the Transferred PINX are written in terms of the following conceptual states existing within the SS-SSCT control entity in that PINX in association with the original call, i.e. a particular call of the transferred user.

6.4.3.1

C T- I d le SS-SSCT is not operating. NOTE 1 As the Transferred PINX acts in the same way as a SS-CT Primary PINX in case of SS-CT by join subclause 6.4.2.1 (States at a Primary PINX - CT-Idle) of ECMA-178 applies accordingly.

6.4.4

States at a Transferred-To PINX The procedures at the Transferred-To PINX are written in terms of the following conceptual states existing within the SS-SSCT control entity in that PINX.

6.4.4.1

6.5

S S C T- I d le SS-SSCT is not operating.

SS-SSCT signalling procedures References in this clause to protocol control states refer to basic call protocol control states defined in ECMA-143. NOTE 2 The specification in this section is based on each of the End PINXs being a different PINX, but this section is also applicable to scenarios where two or more of the four PINXs are the same. In those scenarios some

- 9 -

of the signalling procedures and message flows described in this section are internal to the PINX implementation and therefore outside the scope of this Standard. Annex C contains some examples of message sequences. 6.5.1 6.5.1.1

Actions at a Transferring PINX The SDL representation of procedures at a Transferring PINX is shown in D.1 of annex D. Normal Procedures On receipt of a valid request for SS-SSCT from user A while in state SSCT-Idle for a call between user B and user A which is in protocol control state Active (the original call), the Transferring PINX shall -

send a ssctInitiate invoke APDU in a FACILITY message towards the Transferred PINX using the call reference of the original call. The ssctInitiate invoke APDU shall include the following elements: ·

awaitConnect set to TRUE if the original call shall be released after a CONNECT message from the Transferred-To PINX and set to FALSE if it shall be released on receipt of an ALERTING message from the Transferred-To PINX;

rerouteingNumber set to the party number of the transferred-to user (i.e., user C), as far as available;

transferredAddress set to the address of the transferred user, i.e. user B;

optionally transferredName set to the name of the transferred user, i.e. user B;

optionally elements transferringAddress and transferringName set to the address and name of the transferring user, i.e. user A;

start Timer T1;

enter state SSCT-Await-Initiate-Response.

On receipt in state SSCT-Await-Initiate-Response of a DISCONNECT message with a ssctInitiate return result APDU from the Rerouting PINX, using the call reference of the original call, the Transferring PINX shall continue call clearing of the original call according to basic call procedures, stop timer T1, and enter state SSCT-Idle. 6.5.1.2

Ex c e p t io n a l P r o c e d u r e s On receipt in state SSCT-Await-Initiate-Response of a message using the call reference of the original call, and conveying a ssctInitiate reject or return error APDU, the Transferring PINX shall stop timer T1, abort the procedure for single step call transfer and enter state SSCT-Idle. The original call shall continue. On expiry of timer T1, the Transferring PINX shall abort the procedure for single step call transfer and enter state SSCT-Idle. The original call shall continue. Upon receiving in state SSCT-Await-Initiate-Response an indication from basic call control that the original call has been cleared, the Transferring PINX shall stop Timer T1 and enter state SSCT-Idle.

6.5.2 6.5.2.1

P r o c e d u r e s a t t h e R e r o u t in g P I N X The SDL representation of procedures at a Rerouting PINX is shown in D.2 of annex D. Normal procedures On receipt in state SSCT-Idle of a FACILITY message containing a ssctInitiate invoke APDU while in protocol control state Active, the Rerouting PINX shall determine whether it can perform the SSCT rerouting request. If so, it shall attempt to establish a new connection by selecting a route determined by the contents of rerouteingNumber (i.e. to the Transferred-To PINX) received within the argument of ssctInitiate. If a B-channel is available and if enough digits of the reroutingNumber are present, a SETUP message shall be sent using a new call reference in accordance with the procedures of ECMA-143. The SETUP message shall contain the following information elements: -

Bearer capability, containing the Bearer Capability information of the original call;

- 10 -

Called party number, containing the number received in rerouteingNumber within the received ssctInitiate invoke APDU;

Calling party number, containing the number received in transferredAddress within the received ssctInitiate invoke APDU;

Facility, conveying a ssctSetup invoke APDU with optional elements transferringAddress and transferring Name set as within the received ssctInitiate invoke APDU and optionally conveying a callingName invoke APDU indicating the Name data as received within data element transferredName of the ssctInitiate invoke APDU;

optionally Calling party subaddress, containing the subaddress information from element transferredAddress within the received ssctInitiate invoke APDU.

If the element awaitConnect within the received ssctInitiate invoke APDU was set to TRUE, state SSCT-Await-Setup-Response-Connect shall be entered. If the element was set to FALSE, state SSCTAwait-Setup-Response-Alert shall be entered. The protocol procedures of ECMA-143 shall apply during the establishment of the new connection. If the reroutingNumber received within the argument of ssctInitiate invoke APDU is not complete, a ssctPostDial invoke APDU shall be sent to the Transferred PINX, the Rerouting PINX shall enter state SSCT-Await-Info and start timer T3. While in state SSCT-Await-Info, additional information received in the element reroutingNumber of a ssctDigitInfo invoke APDU in a FACILITY message shall be used to select a route for call extension or, if the call has already been extended, passed on to the Subsequent PINX in accordance with ECMA-143. If the Rerouting PINX regards the number information as complete, or if a sendingComplete element contained in ssctDigitInfo invoke APDU is received, the Rerouting PINX shall process any number information present in the argument, stop timer T3 and initiate call establishment towards the Transferred-To PINX in accordance with ECMA-143 if not already done and, depending on the element awaitConnect received within the ssctInitiate invoke APDU (see above), enter state SSCT-Await-Setup-Response-Connect or state SSCT-Await-Setup-Response-Alert. Otherwise it shall restart timer T3 and remain in state SSCTAwait-Info. On receipt in state SSCT-Await-Info of a CALL PROCEEDING message. Timer T3 shall be stopped and, depending on the element awaitConnect received within the ssctInitiate invoke APDU (see above), enter state SSCT-Await-Setup-Response-Connect or state SSCT-Await-Setup-ResponseAlert. On receipt in state SSCT-Await-Info of an ALERTING message. Timer T3 shall be stopped and, if the element awaitConnect received within the ssctInitiate invoke APDU is set to TRUE optionally start T2 and enter SSCT-Await-Setup-Response-Connect; otherwise if element awaitConnect is set to FALSE proceed as described below for receiving an ALERTING message in state SSCT-Await-SetupResponse-Alert. On receipt in state SSCT-Await-Info of a CONNECT message timer, T3 shall be stopped and proceed as described below for receiving a CONNECT message in state SSCT-Await-Setup-ResponseConnect. On receipt in state SSCT-Await-Setup-Response-Alert of an ALERTING or a CONNECT message, using the call reference of the new connection the Rerouting PINX shall -

disconnect the B-channel of the original call and connect the Transferred PINX to the B-channel of the new connection;

send a DISCONNECT message containing a ssctInitiate return result APDU on the call reference of the original call to the Transferring PINX (completion of the release of the old connection shall be in accordance with the protocol procedures of ECMA-143);

send a callTransferComplete invoke APDU within a FACILITY message on the call reference of the original call to the Transferred PINX, element callStatus set to alerting (on receipt of an ALERTING message) or to answered (on receipt of a CONNECT message);

enter state SSCT-Idle.

- 11 -

On receipt in state SSCT-Idle of a CONNECT message using the call reference of the new connection, the Rerouting PINX shall send a callTransferActive invoke APDU within a FACILITY message on the call reference of the original call to the Transferred PINX. On receipt in state SSCT-Await-Setup-Response-Connect of an ALERTING message (using the call reference of the new connection), the Rerouting PINX shall -

remain in state SSCT-Await-Setup-Response-Connect;

optionally start Timer T2.

On receipt in state SSCT-Await-Setup-Response-Connect of a CONNECT message on the call reference of the new connection, indicating call acceptance by user C, the Rerouting PINX shall -

stop Timer T2 (if started);

disconnect the B-channel of the original call and connect the Transferred PINX to the B-channel of the new connection;

send a callTransferComplete invoke APDU within a FACILITY message on the call reference of the original call to the Transferred PINX, element callStatus set to answered;

send a DISCONNECT message containing a ssctInitiate return result APDU on the call reference of the original call to the Transferring PINX. Completion of the release of the old connection shall be in accordance with the protocol procedures of ECMA-143;

enter state SSCT-Idle.

The above mentioned callTransferComplete and callTransferActive invoke APDU's shall contain information as specified in ECMA-178. If the received ALERTING or CONNECT messages also contain a callTransferUpdate invoke APDU with, in the argument, optional elements redirectionNumber, redirectionName and/or basicCallInfoElements, the callTransferUpdate invoke APDU shall be sent to the Transferred PINX within a FACILITY message. 6.5.2.2

Ex c e p t io n a l p r o c e d u r e s If on receipt in state SSCT-Idle of a FACILITY message containing a ssctInitiate invoke APDU and the SSCT rerouting request can not be performed,, the Rerouting PINX shall send a ssctInitiate return error APDU containing error value "notAvailable" to the Transferring PINX in a FACILITY message on the call reference on which the invoke was received. On expiry of timer T2, or on expiry of T3 if the number information received is not sufficient to proceed or on receipt in state SSCT-Await-Setup-Response-Alert or SSCT-Await-Setup-ResponseConnect or SSCT-Await-Info of a call clearing message on the call reference of the new connection, the Rerouting PINX shall -

proceed with call clearing of the new connection in accordance with the procedures of ECMA-143;

send a FACILITY message on the call reference of the original call to the Transferring PINX, conveying a ssctInitiate return error APDU, indicating error value establishmentFailure;

stop Timer T2 (if started);

stop Timer T3 (if started);

enter state SSCT-Idle.

On receipt in state SSCT-Await-Setup-Response-Alert, SSCT-Await-Setup-Response-Connect or SSCT-Await-Info of a call clearing message on the call reference of the original call, the Rerouting PINX shall -

proceed with call clearing of the original call in accordance with the procedures of ECMA-143 (acting as a Transit PINX);

initiate call clearing of the new call using the procedures of ECMA-143;

- 12 -

stop Timer T2 (if started);

stop Timer T3 (if started);

enter state SSCT-Idle.

If timer T3 expires and if the number information received so far is considered sufficient, initiate call establishment towards the Transferred-To PINX in accordance with ECMA-143, if not already done, and depending on the element awaitConnect received within ssctInitiate invoke APDU (see above), enter state SSCT-Await-Setup-Response-Connect or state SSCT-Await-Setup-Response-Alert. A ssctDigitInfo invoke APDU received in any other state than SSCT-Await-Info shall be ignored. 6.5.3

Actions at a Transferred PINX The SDL representation of procedures at a Primary PINX is shown in D.3 of annex D.

6.5.3.1

Normal procedures As the Transferred PINX acts in the same way as a SS-CT Primary PINX in case of SS-CT by join, sub-clause 6.5.2.1 of ECMA-178 shall apply accordingly. On receipt in state SSCT-Idle of a FACILITY message from the Rerouting PINX containing a ssctPostDial invoke APDU, additional address information from the transferred user B shall be included in the element reroutingNumber of ssctDigitInfo invoke APDUs and sent in FACILITY messages to the Rerouting PINX. The end of number information transmission may be indicated to the Rerouting PINX by means of a sendingComplete element within the ssctDigitInfo invoke APDU.

6.5.3.2

6.5.4

Ex c e p t io n a l p r o c e d u r e s As the Transferred PINX acts in the same way as a SS-CT Primary PINX in case of SS-CT by join, sub-clause 6.5.2.2 of ECMA-178 shall apply accordingly. Actions at a Transferred-To PINX The SDL representation of procedures at a Transferred-To PINX is shown in D.4 of annex D.

6.5.4.1

Normal procedures Having agreed the B-channel and sent back a SETUP ACKNOWLEDGE or a CALL PROCEEDING message in response to an incoming SETUP message, in accordance with the procedures of ECMA-143, if the SETUP contains a ssctSetup invoke APDU, the Transferred-To PINX shall proceed as follows. The Transferred-To PINX may record details of the transfer, may notify the transferred user, and may solicit a subaddress for sending to user B. The call establishment shall proceed according to the procedures of ECMA-143.

6.5.4.2

Ex c e p t io n a l p r o c e d u r e s Not applicable.

6.5.5

A c t io n s a t a Tr a n s it P I N X No special actions are required in support of SS-SSCT.

6.5.6

Subsequent actions at Transferred and Transferred-To PINX As the Transferred PINX acts in the same way as a SS-CT Primary PINX in case of SS-CT by join, and the Transferred-To PINX acts for the subsequent actions as a SS-CT Secondary PINX in case of SS-CT by join, sub-clause 6.5.5 of ECMA-178 shall apply accordingly.

6.6 6.6.1

SS-SSCT impact of interworking with public ISDNs A c t io n s a t a G a t e wa y P I N X As no similar service is available within a public ISDN, SS-SSCT has to be invoked by a PISN user A and also the Rerouting PINX has to be placed within the PISN. Interworking aspects are different depending on the type of interworking situation, the two relevant types are: -

User B is in the public ISDN,

User C is in the public ISDN,

- 13 -

these two scenarios can be combined, i.e. both users (B and C) can be within the public ISDN. 6.6.1.1

I m p a c t o f in t e r wo r k in g if U s e r B is in t h e p u b lic I S D N Single Step Call Transfer is performed within the PISN and the Gateway PINX shall act as Transferred PINX. If the signalling protocol at the access allows, the Gateway PINX shall indicate that transfer has occurred, together with relevant information e.g. transferringNumber, and the number and/or subaddress of the Transferred-to user in appropriate notifications or operations to the public ISDN. If subaddress information is subsequently received from the public ISDN it shall be forwarded to the Transferred-To PINX as data element connectedSubaddress in a subaddressTransfer invoke APDU within a FACILITY message. For this scenario only complete numbers are allowed.

6.6.1.2

I m p a c t o f in t e r wo r k in g if U s e r C is in t h e p u b lic I S D N Single Step Call Transfer is performed within the PISN and the Gateway PINX shall act as Transferred-To PINX. If the signalling protocol at the access allows, the Gateway PINX shall indicate that transfer has occurred, together with relevant information e.g. transferringNumber, and the number and/or subaddress of the transferred user in appropriate notifications or operations to the public ISDN. If subaddress information is subsequently received from the public ISDN it shall be forwarded to the Transferred PINX as data element connectedSubaddress in a subaddressTransfer invoke APDU within a FACILITY message.

6.7 6.7.1

SS-SSCT impact of interworking with non-ISDNs A c t io n s a t a G a t e wa y P I N X If no similar service is available within a non-ISDN, SS-SSCT has to be invoked by a PISN user A and also the Rerouting PINX has to be placed within the PISN. When user A is in the PISN, and user B (user C) is in the non-ISDN, single step call transfer shall be performed within the PISN, and the gateway PINX shall act as Transferred (Transferred-To) PINX. For this scenario only complete numbers are allowed. The gateway shall perform for single step call transfer a signalling mapping between the signalling system specified in this Standard and that of the non-ISDN.

6.8

Protocol Interactions between SS-SSCT and other supplementary services 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 are published subsequent to the publication of this Standard, see those other stage 3 standards. NOTE 3 Simultaneous conveyance of APDUs for SS-SSCT 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. NOTE 4 Additional interactions that have no impact on the signalling protocol at the Q reference point can be found in the relevant stage 1 specifications.

6.8.1

Calling Name Identification Presentation (SS-CNIP) Protocol interactions are specified in 6.5.

6.8.2

Connected Name Identification Presentation (SS-CONP) Protocol interactions are specified in 6.5. NOTE 5 For details see also ECMA-178.

- 14 -

6.8.3

Completion of Calls to Busy Subscribers (SS-CCBS) No protocol interaction.

6.8.4

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

6.8.5 C a llF 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.5.1 A c t io n s a t a R e r o u t in g P I N X a n d S S - C F U O r ig in a t in g P I N X In state SSCT-Await-Setup-Response-Alert or SSCT-Await-Setup-Response-Connect the Rerouting PINX shall convey any received divertingLegInformation1 invoke APDU or divertingLegInformation3 invoke APDU from the Transferred-To PINX together with the callTransferComplete invoke APDU to the Transferred PINX. In state SSCT-Idle the Rerouting PINX shall pass any received divertingLegInformation1 invoke APDU or divertingLegInformation3 invoke APDU from the Transferred-To PINX to the Transferred PINX. 6.8.5.2

A c t io n s a t a R e r o u t in g P I N X a n d a S S - C F U R e r o u t in g P I N X In state SSCT-Await-Setup-Response-Alert or SSCT-Await-Setup-Response-Connect, on receipt of a callRerouting invoke APDU from the Transferred-To PINX, the Rerouting PINX shall act as the SSCFU Rerouting PINX. Any divertingLegInformation1 invoke APDUs or divertingLegInformation3 invoke APDUs generated in accordance with SS-CFU Rerouteing PINX procedures shall be stored in the Rerouting PINX and sent together with the callTransferComplete invoke APDU to the Transferred PINX. In state SSCT-Idle the Rerouting PINX shall pass any received divertingLegInformation1 invoke APDU or divertingLegInformation3 invoke APDU from the Transferred-To PINX to the Transferred PINX.

6.8.5.3

Actions at a Transferred-To PINX The ssctSetup invoke APDU shall be forwarded with the new call to the SS-CFU Diverted-To PINX, which shall act as the new SS-SSCT Transferred-To PINX.

6.8.6 C a ll F o r wa r d in g Bu s y ( S S - C F B) 6.8.6.1 A c t io n s a t a R e r o u t in g P I N X a n d S S - C F B O r ig in a t in g P I N X Protocol interactions as specified in 6.8.5.1, the term SS-CFU Rerouting PINX shall be replaced by SS-CFB Rerouting PINX. 6.8.6.2

A c t io n s a t a R e r o u t in g P I N X a n d a S S - C F B R e r o u t in g P I N X Protocol interactions as specified in 6.8.5.2, the term SS-CFU Rerouting PINX shall be replaced by SS-CFB Rerouting PINX.

6.8.6.3

Actions at a Transferred-To PINX Protocol interactions as specified in 6.8.5.3, the term SS-CFU Rerouting PINX shall be replaced by SS-CFB Rerouting PINX.

6.8.7 C a l l F o r wa r d i n g N o R e p l y ( S S - C F N R ) 6.8.7.1 A c t io n s a t a R e r o u t in g P I N X a n d S S - C F N R O r ig in a t in g P I N X In state SSCT-Await-Setup-Response-Connect the Rerouting PINX shall convey any received divertingLegInformation1 invoke APDU or divertingLegInformation3 invoke APDU from the Transferred-To PINX to the Transferred PINX. 6.8.7.2

A c t io n s a t a R e r o u t in g P I N X a n d a S S - C F N R R e r o u t in g P I N X In state SSCT-Await-Setup-Response-Connect, on receipt of a callRerouting invoke APDU from the Transferred-To PINX, the Rerouting PINX shall act as the SS-CFNR Rerouting PINX. Any divertingLegInformation1 invoke APDUs or divertingLegInformation3 invoke APDUs generated in accordance with SS-CFNR Rerouting PINX procedures shall be sent to the Transferred PINX.

- 15 -

6.8.7.3

6.8.8

Actions at a Transferred-To PINX The ssctSetup invoke APDU shall be forwarded with the new call to the SS-CFNR Diverted-To PINX, which shall act as the new SS-SSCT Transferred-To PINX. Call Deflection (SS-CD) The protocol interactions with Call Deflection Immediate (SS-CDI) shall be as specified in 6.8.5. for interaction with SS-CFU. The protocol interactions with Call Deflection from Alert (SS-CDA) shall be as specified in 6.8.7 for interaction with SS-CFNR.

6.8.9

C a ll Tr a n s f e r ( S S - C T) A SS-CT request by the local user will be rejected by a SS-SSCT PINX when in any other SS-SSCT state than SSCT-Idle. A SS-SSCT request by the local user will be rejected by a SS-CT PINX when in any other SS-CT state than CT-Idle.

6.8.9.1

Actions at a Transferring PINX and Rerouting PINX While in any other SS-SSCT state than SSCT-Idle, any incoming callTransferIdentify or callTransferInitiate invoke APDU shall be answered with the according return error APDU, indicating supplementaryServiceInteractionNotAllowed by the Transferring PINX as well as by the Rerouting PINX.

6.8.9.2

Actions at a SS-CT Transferring PINX If the SS-CT Transferring PINX had previously sent a callTransferComplete invoke APDU, an incoming ssctInitiate invoke APDU shall be answered with a return error APDU, indicating supplementaryServiceInteractionNotAllowed.

6.8.10

Path Replacement (ANF-PR) ANF-PR may be invoked as a direct consequence of performing SS-SSCT. The following protocol interaction shall apply for the SS-SSCT original call to the Transferring and the Transferred PINX.

6 . 8 . 1 0 . 1 A c t io n s a t a A N F - P R R e q u e s t in g P I N X 6 . 8 . 1 0 . 1 . 1 I n v o c a t io n o f S in g le S t e p C a ll Tr a n s f e r For the purpose of the requirements below, these events shall be considered as invocation SSSSCT: -

receipt of ssctInitiate invoke APDU,

invocation of SS-SSCT by the local user (SS-SSCT user A).

SS-SSCT shall be allowed to proceed normally if invoked while the PINX is acting as a Requesting PINX for ANF-PR. If SS-SSCT is invoked while in ANF-PR state PR-Req-Initiating or PR-ReqRejecting, all signalling for SS-SSCT shall occur on the ANF-PR old path. If SS-SSCT is invoked while in ANF-PR state PR-Req-Completing, all subsequent signalling for SS-SSCT shall be sent on the ANF-PR new path and received SS-SSCT signals shall be accepted from either paths. 6 . 8 . 1 0 . 1 . 2 I n it ia t io n o f A N F - P R d u r in g S in g le S t e p C a ll Tr a n s f e r ANF-PR shall not be initiated during SS-SSCT. 6 . 8 . 1 0 . 2 A c t io n s a t a n A N F - P R C o o p e r a t in g P I N X 6 . 8 . 1 0 . 2 . 1 I n v o c a t io n o f C a ll Tr a n s f e r On receipt of a ssctInitiate invoke APDU while acting as an ANF-PR Cooperating PINX in ANF-PR state PR-Coop-Establishment or PR-Coop-Retain, SS-SSCT shall be allowed to proceed normally using the ANF-PR old path for further signalling. As an exceptional procedure, if after receipt of a ssctInitiate invoke APDU while acting as an ANF-PR Cooperating PINX in ANF-PR state PR-Coop-Establishment or PR-Coop-Retain, the old

- 16 -

path is released as a result of successful ANF-PR before SS-SSCT signalling is complete, SS-SSCT shall be allowed to proceed normally using the ANF-PR new path for further signalling. While acting as an ANF-PR Cooperating PINX in ANF-PR state PR-Coop-Establishment, an SS-SSCT invocation request from the local user shall be treated in one of the following ways: -

reject the request for SS-SSCT; or

wait until ANF-PR is completed before processing the request for SS-SSCT; or

abort ANF-PR and proceed with SS-SSCT.

To abort ANF-PR while in state PR-Coop-Establishment, the Cooperating PINX shall send a DISCONNECT message using the call reference of the new connection, thereby initiating the clearing procedures of ECMA-143 for the new connection, send a pathReplacePropose return error APDU with error value supplementaryServiceInteractionNotAllowed using the call reference of the old connection, and enter state PR-Coop-Idle. While acting as an ANF-PR Cooperating PINX in ANF-PR state PR-Coop-Retain, an SS-SSCT invocation request from the local user shall be treated in one of the following ways: -

reject the request for SS-SSCT; or

wait until ANF-PR is completed before processing the request for SS-SSCT.

6 . 8 . 1 0 . 2 . 2 I n it ia t io n o f A N F - P R d u r in g S in g le S t e p C a ll Tr a n s f e r On receipt of a pathReplacePropose invoke APDU while acting as a SS-SSCT Transferring or SS-SSCT Transferred PINX during SS-SSCT, a pathReplacePropose return error APDU shall be sent. The error shall be temporarilyUnavailable. 6.8.11 A d v ic e O f C h a r g e ( S S - A O C ) 6 . 8 . 1 1 . 1 A c t io n s a t a n S S - A O C O r ig in a t in g P I N X The following interactions apply when the Transferring PINX acts as SS-AOC Originating PINX. 6.8.11.1.1 Normal procedures In state Aoc-Orig-Active, on a Single Step Call Transfer request, the SS-AOC Originating PINX shall delay SS-SSCT procedures, send an aocComplete invoke APDU in a FACILITY message to the Outgoing Gateway PINX, start SS-AOC timer T1 and enter state Aoc-Orig-Wait-Completion. The number of user A shall be included in element chargedUser. If charging association chargingAssociation.

information

available,

shall

included

element

In state Aoc-Orig-Wait-Completion, on receipt of an aocComplete return result APDU in a FACILITY message coded aocFreeOfCharge, i.e. user A is not charged for the call before or after the single step call transfer, the SS-AOC Originating PINX shall stop SS-AOC timer T1, start the Single Step Call Transfer procedures as described in this Standard and enter state Aoc-Orig-Idle. NOTE 6 The SS-AOC Originating PINX should send to user A the indication that the call is free of charge in accordance with the particular AOC supplementary services invoked. In state Aoc-Orig-Wait-Completion, on receipt of an aocComplete return result APDU in a FACILITY message coded aocContinueCharging, i.e. user A continues to be charged, the SS-AOC Originating PINX shall stop SS-AOC timer T1, start the Single Step Call Transfer procedures as described in this Standard and enter state Aoc-Orig-Idle. NOTE 7 In the case of AOC-D, the SS-AOC Originating PINX should send the subtotal charge to user A. In state Aoc-Orig-Wait-Completion, on receipt of an aocComplete return result APDU in a FACILITY message coded aocStopCharging, i.e. user A is charged only for the call prior to transfer, the SS-AOC Originating PINX shall stop SS-AOC timer T1, start the Single Step Call Transfer procedures described in this Standard and enter state Aoc-Orig-Idle.

- 17 -

In state Aoc-Orig-Idle, on receipt of an aocFinal invoke APDU in a SETUP message using the call reference of a call-independent signalling connection, the SS-AOC Originating PINX shall stay in state Aoc-Orig-Idle and clear the call-independent signalling connection. NOTE 8 The final charging information received should be indicated to the user as identified by the content of the Called party number information element in the SETUP message. If element chargingAssociation is present in the invoke APDU, it should also be indicated to the user. 6 . 8 . 1 1 . 1 . 2 Ex c e p t io n a l p r o c e d u r e s In state Aoc-Orig-Wait-Completion, on expiry of SS-AOC timer T1, the SS-AOC Originating PINX shall start the Single Step Call Transfer procedures as described in this Standard and enter state Aoc-Orig-Idle. In state Aoc-Orig-Wait-Completion, on receipt of an aocComplete return error or reject APDU the SS-AOC Originating PINX shall stop SS-AOC timer T1, start the Single Step Call Transfer procedures as described in this Standard and enter state Aoc-Orig-Idle. In state Aoc-Orig-Wait-Completion, on receipt of a call clearing message relating to the original call to be transferred, the SS-AOC Originating PINX shall allow the clearing of that call. 6.8.11.2

Actions at the Transferred PINX In state Aoc-Orig-Idle, after receipt of a callTransferComplete invoke APDU the Transferred PINX may act as an SS-AOC Originating PINX for SS-AOC in accordance with the procedures of clause 6.6.1 in ECMA-212, using the procedures of clause 6.6.1.1.2 in ECMA-212 to invoke SS-AOC.

6.8.12

C a ll O f f e r ( S S - C O ) No protocol interaction.

6.8.13

Do Not Disturb (SS-DND) No protocol interaction.

6.8.14

Do Not Disturb Override (SS-DNDO) No protocol interaction.

6.8.15

R e c a ll ( S S - R E) No protocol interaction.

6.8.16

C a ll I n t r u s io n ( S S - C I ) No protocol interaction.

6.8.17

Call Interception (ANF-CINT) If interception delayed is invoked for an unanswered, transferred call (waiting on busy or alerting), the Rerouting PINX can act as the Intercepting PINX.

6.8.17.1

A c t io n s a t a R e r o u t in g P I N X a n d A N F - C I N T O r ig in a t in g P I N X In state SSCT-Await-Setup-Response-Alert or SSCT-Await-Setup-Response-Connect the Rerouting PINX shall not pass on any received cintLegInformation1, divertingLegInformation3, cintEnable or cintDisable invoke APDUs from the Transferred-To PINX. In state SSCT-Idle if interception is invoked for the new call, the Rerouting PINX shall convey any received cintLegInformation1, divertingLegInformation3, cintEnable or cintDisable invoke APDUs from the Transferred-To PINX to the Transferred PINX.

6.8.17.2

Actions at a Transferred PINX The actions at an Originating PINX specified in clause 6.6.3 of ECMA-221 for receipt of a cintLegInformation1, divertingLegInformation3, cintEnable or cintDisable invoke APDU and for invocation of interception delayed shall apply also to a Transferred PINX that has received a callTransferComplete invoke APDU with element call Status having the value “alerting” and has not received a callTransferActive invoke APDU. If interception delayed is invoked the procedures of clause 6.6.5 of ECMA-221 shall apply.

- 18 -

NOTE 9 The basic call protocol control state in which the actions concerned apply is “active”. 6.8.18

Tr a n s it C o u n t e r ( S S - TC ) When using Single Step Call Transfer the Rerouting PINX may include a Transit counter information element in the SETUP message sent to establish the new connection to the Transferred-To PINX. The transit count field of the Transit counter information element shall be set to zero. The Transferred-To PINX shall ignore the Transit counter information element if it is contained in the received SETUP message.

6.8.19

Route Restriction Class (ANF-RRC) No protocol interaction.

6.8.20

A u t h e n t ic a t io n o f t h e P I S N ( S S - W TA N ) No protocol interaction.

6.8.21

A u t h e n t ic a t io n o f a W TM u s e r ( S S - W TA T) No protocol interaction.

6.8.22

W i r e l e s s T e r m i n a l L o c a t io n R e g i s t r a t i o n ( S S - W T L R ) No protocol interaction.

6.8.23

Wireless Terminal Mobility Incoming Call (ANF-WTMI) No protocol interaction.

6.8.24

Wireless Terminal Mobility Outgoing Call (ANF-WTMO) No protocol interaction.

6.8.25

M e s s a g e W a it in g I n d ic a t io n ( S S - M W I ) No protocol interaction.

6.8.26

User Mobility Incoming Call (ANF-PUMI) No protocol interaction.

6.8.27

U s e r M o b i l i t y O u t g o in g C a l l ( A N F - P U M O ) No protocol interaction.

6.8.28

P r i v a t e U s e r M o b i l i t y - R e g is t r a t i o n ( S S - P U M R ) No protocol interaction.

6.8.29

Common Information (ANF-CMN) No protocol interaction. NOTE 10 Common Information may be exchanged between Transferred PINX and Transferred-To PINX subsequent to single step call transfer. In this case the Transferred PINX is considered to be the ANFCMN originating PINX and the Transferred-To PINX to be the ANF-CMN terminating PINX.

6.8.30 C a ll P r io r it y I n t e r r u p t io n ( P r o t e c t i o n ) ( S S - C P I ( P ) ) 6.8.30.1 Actions at the Transferring PINX If the call to be transferred was established as a protected call, the Transferring PINX shall include a callProtectionRequest invoke APDU with the ssctInitiate invoke APDU in the FACILITY message sent to the Rerouting PINX. The argument to the callProtectionRequest invoke operation shall convey the higher of the CPIPL values of the original call. 6.8.30.2

A c t io n s a t t h e R e r o u t in g P I N X If a callProtectionRequest invoke APDU is received together with the ssctInitiate invoke APDU from the Transferring PINX, SS-CPIP shall also be invoked for the establishment of the new connection. If SS-CPIP was invoked for the original call it shall be invoked again with the current CPIPL value.

- 19 -

6.9 6.9.1

SS-SSCT Parameter values (Timers) Timer T1 Timer T1 shall operate at the Transferring PINX during state SSCT-Await-Initiate-Response. Its purpose is to protect against the absence of a response to the ssctInitiate invoke APDU. Timer T1 shall have a value not less than 50 seconds.

6.9.2

Timer T2 Timer T2 may optionally operate at the Rerouting PINX during state SSCT-Await-Setup-ResponseConnect. Its purpose is to protect against failure to establish the new connection. NOTE 11 Alternatively an implementation can rely on basic call timers for this protection. Timer T2 shall have a value not less than 40 seconds.

6.9.3

Timer T3 Timer T3 shall operate at the Rerouting PINX during state SSCT-Await-Info. This timer is started on sending of the ssctPostDial invoke APDU, restarted on receipt of a ssctDigitInfo invoke APDU with incomplete number information, and stopped when a ssctDigitInfo invoke APDU containing final number information or an element sendingComplete is received. On expiry of timer T3 the new call is either cleared or allowed to proceed, depending on the amount of digits received. The value of timer T3 should be in the range 14 - 16 seconds.

- 20 -

- 21 -

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:

A.2

by the 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's PICS proforma;

by the user or potential user of an 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 PICSs;

by a protocol tester, as the basis for selecting appropriate tests against which to assess the claim for conformance of the implementation.

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 subclauses 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 for conformance 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 restricted choice (Yes) or (No), or in the "Not Applicable" column (N/A).

- 22 -

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 that a large quantity will be supplied, and a PICS can be considered complete without 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

Exceptional 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 requirement. 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.

- 23 -

A.3

PICS proforma for SS-SSCT

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 systems; system name(s)

Only the first three items are required for all implementations; other information may be completed as appropriate in meeting requirements 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) Amendments implemented Have any exception items been required (see A.2.3)?

Date of statement

No [ ]

Yes [ ]

(The answer Yes means that the implementation does not conform to this Standard)

- 24 -

A.3.3

General Item

A.3.4

Question/feature

Reference

Status

N/A

Support

Behaviour as a Transferring PINX

o.1

Yes [ ] No [ ]

Behaviour as a Rerouting PINX

o.1

Yes [ ] No [ ]

Behaviour as a Transferred PINX

o.1

Yes [ ] No [ ]

Behaviour as a Transferred-To PINX

o.1

Yes [ ] No [ ]

Behaviour as Gateway PINX to a public ISDN for SS-SSCT

Yes [ ] No [ ]

Behaviour as Gateway PINX to a non-ISDN for SS-SSCT

Yes [ ] No [ ]

Procedures Item

Question/feature

Reference

Status

N/A

Support

Support of relevant ECMA-143 and ECMA-165 procedures

6.2

Yes [ ]

Signalling procedures at a Transferring PINX

6.5.1

A1:m

[]

Yes [ ]

Signalling procedures at a Rerouting PINX

6.5.2

A2:m

[]

Yes [ ]

Signalling procedures at a Transferred PINX

6.5.3, 6.5.5

A3:m

[]

Yes [ ]

Signalling procedures at a Transferred-To PINX

6.5.4, 6.5.5

A4:m

[]

Yes [ ]

Interworking procedures to a public ISDN at a Transferred PINX

6.6.1.1

A5:o.2

[]

Yes [ ] No [ ]

Interworking procedures to a public ISDN at a Transferred-To PINX

6.6.1.2

A5:o.2

[]

Yes [ ] No [ ]

Interworking procedures to a non-ISDN at a Transferred PINX

6.7.1.1

A6:o.3

[]

Yes [ ] No [ ]

Interworking procedures to a non-ISDN at a Transferred-To PINX

6.7.1.2

A6:o.3

[]

Yes [ ] No [ ]

B10

Transfer occurs on alerting new call

6.5.1.1

A1:o.4

[]

Yes [ ] No [ ]

B11

Transfer occurs on active new call

6.5.1.1

A1:o.4

[]

Yes [ ] No [ ]

- 25 -

A.3.5

Coding Item

Name of Item

Reference

Status

N/A

Support

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

6.3

A1:m

[]

m: Yes [ ]

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

6.3

A2:m

[]

m: Yes [ ]

Sending of ssctSetup invoke APDU

6.3

A2:m

[]

m: Yes [ ]

Receipt of ssctSetup invoke APDU

6.3

A4:m

[]

m: Yes [ ]

Sending of ssctPostDial invoke APDU

6.3

A2:o

[]

o: Yes [ ] No [ ]

Receipt of ssctPostDial invoke APDU

6.3

A3:m

[]

m: Yes [ ]

Sending of ssctDigitInfo invoke APDU

6.3

A3:m

[]

m: Yes [ ]

Receipt of ssctDigitInfo invoke APDU

6.3

A2:m

[]

m: Yes [ ]

Sending of callTransferComplete invoke APDU

6.3

A2:m

[]

m: Yes [ ]

C10

Receipt of callTransferComplete invoke APDU

6.3

A3:m

[]

m: Yes [ ]

C11

Sending of callTransferActive invoke APDU

6.3

A2:m

[]

m: Yes [ ]

C12

Receipt of callTransferActive invoke APDU

6.3

A3:m

[]

m: Yes [ ]

C13

Sending of callTransferUpdate invoke APDU

6.3

c.1

[]

o: Yes [ ] No [ ]

C14

Receipt of callTransferUpdate invoke APDU

6.3

c.2

[]

m: Yes [ ]

C15

Sending of subaddressTransfer invoke APDU

6.3

c.1

[]

o: Yes [ ] No [ ]

C16

Receipt of subaddressTransfer invoke APDU

6.3

c.2

[]

m: Yes [ ]

Reference

Status

N/A

Support m: Yes [ ] Value [...] o: Yes [ ] No [ ] Value [...] m: Yes [ ] Value [...]

c.1: If (A3 or A4) then optional, else N/A c.2: If (A3 or A4) then mandatory, else N/A

A.3.6

Timers Item

Question/feature

Timer T1

6.9.1

A1:m

[]

Timer T2

6.9.2

A2:o

[]

Timer T3

6.9.3

A2:m

[]

- 26 -

A.3.7

Interactions between SS-SSCT and SS-CFU / SS-CDI Item

Question/feature

Reference

Status

N/A

Support

Support of SS-CFU or SS-CDI by forward switching at an SS-SSCT Rerouting PINX

ECMA-174

Yes [ ] No [ ]

Support of SS-CFU or SS-CDI by rerouting at an SS-SSCT Rerouting PINX

ECMA-174

Yes [ ] No [ ]

Support of SS-CFU or SS-CDI at a Transferred-To PINX

ECMA-174

Yes [ ] No [ ]

Interactions at an SS-SSCT Rerouting PINX and an SS-CFU / SS-CDI Originating PINX

6.8.5.1

c.3

[]

m: Yes [ ]

Interactions at an SS-SSCT Rerouting PINX and an SS-CFU / SS-CDI Rerouting PINX

6.8.5.2

c.4

[]

m: Yes [ ]

Interactions at an SS-SSCT Transferred-To PINX

6.8.5.3

c.5

[]

m: Yes [ ]

Reference

Status

N/A

Support

c.3: If (A2 and E1) then m, else N/A c.4: If (A2 and E2) then m, else N/A c.5: If (A4 and E3) then m, else N/A

A.3.8

Interactions between SS-SSCT and SS-CFB Item

Question/feature

Support of SS-CFB by forward switching at an SS-SSCT Rerouting PINX

ECMA-174

Yes [ ] No [ ]

Support of SS-CFB by rerouting at an SS-SSCT Rerouting PINX

ECMA-174

Yes [ ] No [ ]

Support of SS-CFB at a Transferred-To PINX

ECMA-174

Yes [ ] No [ ]

Interactions at an SS-SSCT Rerouting PINX and an SS-CFB Originating PINX

6.8.6.1

c.6

[]

m: Yes [ ]

Interactions at an SS-SSCT Rerouting PINX and an SS-CFB Rerouting PINX

6.8.6.2

c.7

[]

m: Yes [ ]

Interactions at an SS-SSCT Transferred-To PINX

6.8.6.3

c.8

[]

m: Yes [ ]

c.6: If (A2 and F1) then m, else N/A c.7: If (A2 and F2) then m, else N/A c.8: If (A4 and F3) then m, else N/A

- 27 -

A.3.9

Interactions between SS-SSCT and SS-CFNR / SS-CDA Item

Question/feature

Reference

Status

N/A

Support

Support of SS-CFNR or SS-CDA by forward switching at an SS-SSCT Rerouting PINX

ECMA-174

Yes [ ] No [ ]

Support of SS-CFNR or SS-CDA by rerouting at an SS-SSCT Rerouting PINX

ECMA-174

Yes [ ] No [ ]

Support of SS-CFNR or SS-CDA at a Transferred-To PINX

ECMA-174

Yes [ ] No [ ]

Interactions at an SS-SSCT Rerouting PINX and an SS-CNR / SS-CDA Originating PINX

6.8.7.1

c.9

[]

m: Yes [ ]

Interactions at an SS-SSCT Rerouting PINX and an SS-CCNR / SS-CDA Rerouting PINX

6.8.7.2

c.10

[]

m: Yes [ ]

Interactions at an SS-SSCT Transferred-To PINX

6.8.7.3

c.11

[]

m: Yes [ ]

Reference

Status

N/A

Support

ECMA-178

c.9: If (A2 and G1) then m, else N/A c.10: If (A2 and G2) then m, else N/A c.11: If (A4 and G3) then m, else N/A

A.3.10 Interactions between SS-SSCT and SS-CT Item

Question/feature

Support of SS-CT

Interactions at a Transferring PINX and a Rerouting PINX

6.8.9.1

c.12

[]

m: Yes [ ]

Interactions at a SS-CT Transferring PINX

6.8.9.2

c.13

[]

m: Yes [ ]

c.12: If (A1 or A2 and H1) then m, else N/A c.13: If (A1 and H1) then m, else N/A

Yes [ ] No [ ]

- 28 -

A.3.11 Interactions between SS-SSCT and ANF-PR Item

Question/feature

Reference

Status

N/A

Support

Support of ANF-PR at a ANF-PR Requesting PINX

ECMA-176

Yes [ ] No [ ]

Support of ANF-PR at a ANF-PR Cooperating PINX

ECMA-176

Yes [ ] No [ ]

Interactions at an ANF-PR Requesting PINX

6.8.10.1

I1:m

[]

m: Yes [ ] No [ ]

Interactions at an ANF-PR Cooperating PINX

6.8.10.2

I2:m

[]

m: Yes [ ] No [ ]

Reference

Status

N/A

Support

A.3.12 Interactions between SS-SSCT and SS-AOC Item

Question/feature

Support of SS-AOC in an SS-AOC Originating PINX

ECMA-212

Yes [ ] No [ ]

Support of SS-AOC in Transferred PINX

ECMA-212

Yes [ ] No [ ]

Interactions at an SS-AOC Originating PINX

6.8.11.1

J1:m

[]

m: Yes [ ] No [ ]

Interactions at a Transferred PINX

6.8.11.2

c.14

[]

m: Yes [ ]

Reference

Status

N/A

Support

ECMA-221

c.14: If (A3 and J2) then m, else N/A

A.3.13 Interactions between SS-SSCT and ANF-CINT Item

Question/feature

Support of ANF-CINT

Yes [ ] No [ ]

Interactions at a Rerouting PINX and an ANF-CINT Originating PINX

6.8.17.1

c.15

[]

m: Yes [ ]

Interactions at a Transferred PINX

6.8.17.2

c.16

[]

m: Yes [ ]

Reference

Status

N/A

Support

ECMA-225

6.8.18

L1:m

c.15 If (A2 and K1) then m, else N/A c.16: If (A3 and K1) then m, else N/A

A.3.14 Interactions between SS-SSCT and ANF-TC Item

Question/feature

Support of ANF-TC

Interactions with ANF-TC

Yes [ ] No [ ] []

m: Yes [ ]

- 29 -

A.3.15 Interactions between SS-SSCT and SS-CPI(P) Item

Question/feature

Reference

Status

ECMA-264

N/A

Support

Support of SS-CPIP

Interactions at a Transferring PINX

6.8.29.1

c.17

[]

m: Yes [ ]

Interactions at a Rerouting PINX

6.8.29.2

c.18

[]

m: Yes [ ]

c.17: If (A1 and M1) then m, else N/A. c.18: If (A2 and M1) then m, else N/A.

Yes [ ] No [ ]

- 30 -

- 31 -

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.

- 32 -

- 33 -

Annex C ( in f o r ma tiv e )

Examples of message sequences

This annex describes some typical message flows for SS-SSCT. The following conventions are used in the figures of this annex: 1

The following notation is used:

Message transporting SS-SSCT specific operation Message without SS-SSCT specific operation xxx.inv

Invoke APDU for operation xxx

xxx.rr

Return result APDU for operation xxx

xxx.re

Return error APDU for operation xxx

The figures show messages exchanged via Protocol Control between PINXs involved in SS-SSCT. Only messages relevant to SS-SSCT are shown.

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 SSSSCT is not shown.

The following abbreviations are used: ctActive

callTransferActive

ctComplete

callTransferComplete

ctUpdate

callTransferUpdate

- 34 -

C.1

Example message sequence for normal operation of single step call transfer, transfer occurs on alerting new call Figure C.1 shows an example of a normal operation of single step call transfer when transfer occurs on alerting new call. Transferred PINX

Transferring PINX

Transferred-To PINX

Rerouting PINX

Active Basic Call (original connection) between Transferring & Transferred PINX (Rerouting PINX is a Transit PINX between them) FACILITY (1) ssctInitiate.inv awaitConnect=FALSE

SETUP (2) ssctSetup.inv CALL PROCEEDING (2) ALERTING (2) FACILITY (1)

DISCONNECT (1)

ctComplete.inv callStatus=“alerting“

ssctInitiate.rr RELEASE (1) CONNECT (2) RELEASE COMPLETE (1)

FACILITY (1) ctActive.inv Active basic call (new connection) FACILITY (optional) ctUpdate/subaddressTransfer.inv FACILITY (optional) ctUpdate/subaddressTransfer.inv

Figure C.1 - Message sequence for normal operation of single step call transfer, transfer occurs on alerting new call

- 35 -

C.2

Example message sequence for normal operation of single step call transfer, transfer occurs on active new call Figure C.2 shows an example of a normal operation of single step call transfer when transfer occurs on active new call. Transferring PINX

Rerouting PINX

Transferred PINX

Transferred-To PINX

Active Basic Call (original connection) between Transferring & Transferred PINX (Rerouting PINX is a Transit PINX between them) FACILITY (1) ssctInitiate.inv awaitConnect=TRUE

SETUP (2) ssctSetup.inv CALL PROCEEDING (2) ALERTING (2) FACILITY (1)

CONNECT (2)

ctComplete.inv callStatus=“answered“ DISCONNECT (1) ssctInitiate.rr RELEASE (1) RELEASE COMPLETE (1) Active basic call (new connection) FACILITY (optional) ctUpdate/subaddressTransfer.inv FACILITY (optional) ctUpdate/subaddressTransfer.inv

Figure C.2 - Message sequence for normal operation of single step call transfer, transfer occurs on active new call

- 36 -

C.3

Example message sequence for normal operation of single step call transfer, transfer occurs after the transferred-to number is complete Figure C.3 shows an example of a normal operation of single step call transfer when post dialing is required to establish the new call and the destination number is sent in pieces. Transferring PINX

Rerouting PINX

Transferred PINX

Transferred-To PINX

Active Basic Call (original connection) between Transferring & Transferred PINX (Rerouting PINX is a Transit PINX between them) FACILITY (1) ssctInitiate.inv FACILITY (1) ssctPostDial.inv FACILITY (1)

enough digits received to route on

ssctDigitInfo.inv

SETUP (2)

FACILITY (1)

SETUP ACK (2)

ssctSetup.inv ssctDigitInfo.inv

INFO (2)

FACILITY (1) ssctDigitInfo.inv

INFO (2) CALL PROCEEDING (2)

Continue the SSCT procedure as shown in Figure C1 or Figure C2, depending if the SSCT occurs on alerting new call or active new call.

Figure C.3 - Message sequence for normal operation of single step call transfer, transfer occurs after the transferred-to number is complete

- 37 -

C.4

Example message sequence for unsuccessful operation of single step call transfer, new call fails Figure C.4 shows an example of a unsuccessful operation of single step call transfer when the new call fails. Transferring PINX

Transferred PINX

Rerouting PINX

Transferred-To PINX

Active Basic call (original connection) between Transferring & Transferred (Rerouting PINX is a Transit PINX between them) FACILITY (1) ssctInitiate.inv SETUP (2) ssctSetup.inv CALL PROCEEDING (2) FACILITY (1)

DISCONNECT (2)

ssctInitiate.re RELEASE (2) RELEASE COMPLETE (2)

Active Basic Call (original connection) between Transferring and Transferred (Rerouting PINX is a Transit PINX between them)

Figure C.4 - Message Sequence for unsuccessful operation of single step call transfer, new call fails

- 38 -

- 39 -

Annex D ( 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 Rec. Z.100. Each diagram represents the behaviour of a SS-SSCT 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 PSS1 message being sent, the output symbol bears the name of the message and any remote operation APDU(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 results from a PSS1 message being received, the input symbol bears the name of the message and any remote operation APDU(s) contained in that message. In case of a message specified in ECMA-143, basic call actions associated with the receiving of that message are deemed to occur. The following abbreviations are used: err.

return error APDU

ind.

indication

inv.

invoke APDU

new

new call

ori

original call

opt.

optionally

rej.

reject APDU

res.

return result APDU

awaitConnect element

- 40 -

D.1

SDL Representation of SS-SSCT at a Transferring PINX Figure D.1 shows the behaviour of a SS-SSCT Supplementary Service Control entity within a Transferring PINX. Input signals from the right and output signals to the right represent primitives to and from the Coordination Function in respect of the messages being sent and received to an from the Rerouting PINX. Input signals from the left and output signals to the left represent stimuli between the SS-SSCT Supplementary Service Control entity and user A. SSCT-Idle

SS-SSCT invoke from User A

SSCT invoke rej. to User A

SSCT allowed? Yes

determine aC

SSCT-Idle

FACILITY ssctInitiate inv. on ori

start T1

SSCT-AwaitInitiateResponse

DISCONNECT ssctInitiate res. on ori

FACILITY ssctInitiate err. / rej.

stop T1

clear ori

T1 expiry

proceed with ori

SSCT successful to User A

SSCT unsuccessful to User A

SSCT-Idle

Figure D.1 - Transferring PINX SDL

call clearing on ori

stop T1

- 41 -

D.2

SDL Representation of SS-SSCT at a Rerouting PINX Figure D.2 shows the behaviour of a SS-SSCT Supplementary Service Control entity within a Rerouting PINX. Input signals from the right and output signals to the right represent primitives to and from the Coordination Function in respect of the messages being sent and received to and from the Transferred PINX, the Transferring PINX and the Transferred-To PINX.

SSCT-Idle

FACILITY ssctInitiate inv. from Transferring PINX

FACILITY ssctDigitInfo inv. from Transferred PINX

CONNECT from Transferred-To PINX

FACILITY ctActive inv. to Transferred PINX

SS-SSCT possible? Yes

route on?

Yes

SSCT-Idle SETUP ssctSetup inv. to Transferred-To PINX

FACILITY ssctInitiate err. to Transferring PINX

number complete?

Yes

FACILITY ssctPostDial inv. to Transferred PINX

aC set?

Yes

start T3

SSCT-Idle

SSCT-AwaitInfo

SSCT-AwaitSetup-ResponseConnect

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

SSCT-AwaitSetup-ResponseAlert

- 42 -

SSCTAwait-Info A FACILITY ssctDigitInfo inv. from Transferred PINX

T3 expiry

Yes

SETUP already sent?

number complete?

INFORMATION to Transferred-To PINX

Yes

route on?

call extended?

SETUP ssctSetup inv. to Transferred-To PINX

Yes

SETUP ssctSetup inv. to Transferred-To PINX

clear new

FACILITY ssctInitiate err. to Transferring PINX

Yes

number complete? No

stop T3

re-start T3

aC set? Yes

SSCTAwait-Info

SSCTAwait-SetupResponse-Connect

SSCTAwait-SetupResponse-Alert

F ig u r e D . 2 ( s h e e t 2 o f 5 ) - R e r o u t in g P I N X S D L

SSCT-Idle

- 43 -

CALL PROCEEDING from Transferred-To PINX

ALERTING from Transferred-To PINX

stop T3

aC set?

CONNECT from Transferred-To PINX

call clearing message (new)

call clearing message (ori)

stop T3

Yes

aC set?

original call remains connected

Yes No

cear new

opt. start T2

C SSCTAwait-SetupResponse-Alert

clear ori

SSCTAwait-SetupResponse-Connect

FACILITY ssctInitiate err. to Transferring PINX

SSCT-Idle

F ig u r e D . 2 ( s h e e t 3 o f 5 ) - R e r o u t in g P I N X S D L

- 44 -

SSCT-AwaitSetup-ResponseConnect

CONNECT from Transferred-To PINX

ALERTING from Transferred-To PINX

stop T2 if running

T2 expired

opt. start T2

FACILITY ctComplete inv. (answered) to Transferred PINX

FACILITY ssctDigitInfo inv. from Transferred PINX

stop T2 if running

SSCT-AwaitSetup-ResponseConnect

call clearing message (new)

original call remains connected clear new

FACILITY ssctInitiate err. to Transferring PINX

call clearing message (ori)

stop T2 if running

clear ori

clear new

switch B-Channels

DISCONNECT ssctInitiate res. to Transferring PINX

SSCT-Idle

F ig u r e D . 2 ( s h e e t 4 o f 5 ) - R e r o u t in g P I N X S D L

SSCT-AwaitSetup-ResponseConnect

- 45 -

SSCT-AwaitSetupResponse-Alert

ALERTING from Transferred-To PINX

CONNECT from Transferred-To PINX

call clearing message (new)

original call remains connected

switch B-Channels

call clearing message (ori)

FACILITY ssctDigitInfo inv. from Transferred PINX

clear ori

clear new

FACILITY ctcomplete inv. (alerting) to Transferred PINX

DISCONNECT ssctInitiate res. to Transferring PINX

FACILITY ssctInitiate err. to Transferring PINX

SSCT-Idle

F ig u r e D . 2 ( s h e e t 5 o f 5 ) - R e r o u t in g P I N X S D L

SSCT-AwaitSetupResponse-Alert

- 46 -

D.3

SDL Representation of SS-SSCT at a Transferred PINX Figure D.3 shows the behaviour of a SS-SSCT Supplementary Service Control entity within a Transferred PINX. Input signals from the right and output signals to the right represent primitives to and from the Coordination Function in respect of the messages being sent and received to and from the Rerouting PINX. Input signals from the left and output signals to the left represent stimuli between the SS-SSCT Supplementary Service Control entity and the Transferred user B.

SSCT-Idle

FACILITY ssctPostDial inv. from Rerouting PINX

FACILITY ctComplete inv. from Rerouting PINX

Notify User B

Digits received from User B

FACILITY ctUpdate inv. from Rerouting PINX

FACILITY ssctDigitInfo inv. to Rerouting PINX Notify User B

FACILITY ctActive inv. from Rerouting PINX

Notify User B

FACILITY subAdrTfr inv. from Rerouting PINX

Notify subaddress to User B

number complete Yes

SSCT-Idle

Figure D.3 - Transferred PINX SDL

Subaddress from User B

FACILITY subAdrTfr inv. to Rerouting PINX

- 47 -

D.4

SDL Representation of SS-SSCT at a Transferred-To PINX Figure D.4 shows the behaviour of a SS-SSCT Supplementary Service Control entity within a Transferred-To PINX. Input signals from the right and output signals to the right represent primitives to and from the Coordination Function in respect of messages sent and received. Input signals from the left and output signals to the left represent stimuli between the SS-SSCT Supplementary Service Control entity and the Transferred-to user C.

SSCT-Idle

SETUP ssctSetup inv. from Rerouting PINX

able to proceed with SSCT?

Yes

inform User C about SS-SSCT

continue basic call

reject call

SSCT-Idle

Figure D.4 - Transferred-To PINX SDL

- 48 -

- 49 -

Annex E ( n o r ma tiv e )

Additional feature identifier in module Common-Information-Operations

In ASN.1 module Common-Information-Operations {iso (1) standard (0) pss1-common-information (15772) operations (0)}, specified in 6.3.1 of ECMA-251, bit number 17 of type FeatureIdList shall be interpreted in the following way: ssSSCTreRoutingSupported

(17)

-- Single Step Call Transfer rerouting supported -- meaningful both in forward and backward -- direction during call establishment

- 50 -

- 51 -

Annex F ( in f o r ma tiv e )

Difference between Single Step Call Transfer and Call Transfer by Rerouting

The Single Step Call Transfer supplementary service is a service which enables a transferring user to replace an existing call with a transferred user by a new call between transferred user and transferred-to user whereby the transferring user does not have a call established with the transferred-to user prior to that single step call transfer. The PINX (Rerouting PINX) which reroutes the transferred user to the transferred-to user may be any PINX in the call path between the Transferring PINX and the Transferred PINX. In many cases the Rerouting PINX will be the Transferred PINX or, if this is not possible, a Transit PINX "near" the Transferred PINX. The Call Transfer by Rerouting supplementary service (ECMA-178) is a service which enables a transferring user to transform two of that users calls into a new call between the transferred user and the transferred-to user. The PINX which reroutes the transferred user to the transferred-to user is prescribed to be the Primary PINX (i.e. the Transferred PINX) which is the PINX nearest to the transferred user.

- 52 -

- 53 -

Annex G (normative) 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 first edition of ECMA-300, i.e. based on ITU-T Recommendations X.208 / X.209. Starting with the second edition the ASN.1 modules within ECMA-300 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 G . 1 - S in g le - S t e p - C a ll- Tr a n s f e r - 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 Single-Step-Call-Transfer-Operations { iso(1) standard (0) pss1-single-step-call-transfer (19460) single-step-call-transfer-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-extension-definition { iso (1) standard (0) pss1-generic-procedures (11582) msi-definition (0) } Name FROM Name-Operations {iso(1) standard(0) pss1-name (13868) name-operations (0)} supplementaryServiceInteractionNotAllowed, notAvailable, invalidCallState FROM General-Error-List { ccitt recommendation q 950 general-error-list (1) } PresentedAddressScreened, PartyNumber FROM Addressing-Data-Elements {iso(1) standard (0) pss1-generic-procedures (11582) addressing-data-elements (9)} PSS1InformationElement FROM PSS1-generic-parameters-definition {iso(1) standard (0) pss1-generic-procedures (11582) pss1-generic-parameters (6)} callTransferUpdate, callTransferComplete, callTransferActive, subaddressTransfer, invalidRerouteingNumber, establishmentFailure FROM Call-Transfer-Operations {iso(1) standard (0) pss1-call-transfer (13869) call-transfer-operations(0)}; SsctInitiate

::=

OPERATION -- sent from the Transferring PINX to the Rerouting PINX ARGUMENT SSCTInitiateArg RESULT DummyRes ERRORS { notAvailable, invalidCallState, invalidRerouteingNumber, establishmentFailure, unspecified, supplementaryServiceInteractionNotAllowed }

- 54 -

Ta b le G . 1 - S in g le - S t e p - C a ll- Tr a n s f e r - 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 (continued) SsctSetup

::=

SsctPostDial ::=

OPERATION -- sent from the Rerouting PINX to the Transferred PINX ARGUMENT DummyArg

SsctDigitInfo ::=

OPERATION -- sent from the Transferred PINX to the Rerouting PINX ARGUMENT SSCTDigitInfoArg

DummyArg

::=

DummyRes

::=

OPERATION -- sent from the Rerouting PINX to the Transferred-To PINX ARGUMENT SSCTSetupArg

CHOICE { null single multiple

NULL, [1] IMPLICIT Extension, [2] IMPLICIT SEQUENCE OF Extension }

CHOICE { null single multiple

NULL, [1] IMPLICIT Extension, [2] IMPLICIT SEQUENCE OF Extension }

SSCTInitiateArg ::= SEQUENCE { rerouteingNumber transferredAddress awaitConnect transferredName transferringAddress transferringName argumentExtension

PartyNumber, -- Transferred-To Number PresentedAddressScreened, AwaitConnect, [1] Name OPTIONAL, [2] PresentedAddressScreened OPTIONAL, [3] Name OPTIONAL, CHOICE { single [4] IMPLICIT Extension, multiple [5] IMPLICIT SEQUENCE OF Extension } OPTIONAL

} AwaitConnect ::=

BOOLEAN -- FALSE = release the original call upon ALERTING received -- TRUE = release the original call upon CONNECT received

SSCTSetupArg ::= SEQUENCE { transferringAddress transferringName argumentExtension

}

[1] PresentedAddressScreened OPTIONAL, [2] Name OPTIONAL, CHOICE { single [3] IMPLICIT Extension, multiple [4] IMPLICIT SEQUENCE OF Extension } OPTIONAL

- 55 -

Ta b le G . 1 - S in g le - S t e p - C a ll- Tr a n s f e r - 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 (concluded) SSCTDigitInfoArg ::= SEQUENCE { reroutingNumber sendingComplete argumentExtension

[1] PartyNumber OPTIONAL, -- remaining digits of the Transferred-To Number [2] IMPLICIT NULL OPTIONAL, CHOICE { single [3] IMPLICIT Extension, multiple [4] IMPLICIT SEQUENCE OF Extension } OPTIONAL

}

Unspecified ::=

ERROR PARAMETER Extension

unspecified

Unspecified

:: = localValue 1008

ssctInitiate

SsctInitiate

:: = localValue 99

ssctSetup

SsctSetup

:: = localValue 100

ssctPostDial

SsctPostDial

:: = localValue 101

ssctDigitInfo

SsctDigitInfo

:: = localValue 102

END

-- of SSCT Operations

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-300 — Private Integrated Services Network (PISN) - Inter-exchange signalling protocol - Single step call transfer supplementary service (QSIG-SSCT) (December 2001)

Related documents