Conceptio › Archive › ECMA International

ECMA Internationalopen access

ECMA-186 — Private Integrated Services Network (PISN) - Inter-exchange signalling protocol - Call completion supplementary services (QSIG-CC) (December 2001)

ECMA International · ECMA International

ECMA International · Standards · License: Open Access

completion ecma ecmainternational exchange integrated inter network pisn

ecma, standard, ecma international, specification, ecma-186, ecma 186, 186, private, integrated, services, network, pisn, inter-exchange, signalling, protocol, call, completion, supplementary, qsig-cc

S tandard ECMA-186

4th Edition - December 2001

Standardizing Information

and

Communication

Systems

Private Integrated Services Network (PISN) Inter-Exchange Signalling Protocol Call Completion 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-186

4th Edition - December 2001

Standardizing

Information

and

Communication

Systems

Private Integrated Services Network (PISN) Inter-Exchange Signalling Protocol Call Completion Supplementary Services (QSIG-CC)

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

Ecma-186.doc

14-01-02 14,40

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 Completion supplementary services: • Call Completion to Busy Subscriber (SS-CCBS) • Call Completion on No Reply (SS-CCNR). 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-186 (published by ECMA in December 1992), the 2nd Edition incorporated changes in order to achieve complete alignment with International Standard ISO/IEC 13870:1995(E) published by ISO/IEC in November 1995. The 2nd Edition of Standard ECMA-186 was adopted by the General Assembly of June 1997. The 3rd Edition introduced the following changes compared to the 2nd Edition: •

Binding between non-reservation and connection retention has been removed.

•

Indicate value definitions for operations as "localValue".

•

Changes in Annex A (PICS).

•

Editorial corrections.

Compared to the 3rd Edition of Standard ECMA-186 (published by ECMA in February 2000), this 4th Edition incorporates migration to ASN.1 version 1997 as well as changes in order to achieve complete alignment with International Standard ISO/IEC 13870:2001(E) published by ISO/IEC in July 2001.

Adopted as 4th Edition of Standard ECMA-186 by the General Assembly of 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 CC Call 4.2.2 CC Request 4.2.3 Connection release 4.2.4 Co n n e c tio n r e te n tio n 4.2.5 Path reservation 4.2.6 Service retention

2 2 2 2 2 2 3 3 3

5 6

Acronyms Signalling protocol for the support of SS-CCBS and SS-CCNR 6.1 SS-CCBS/CCNR description 6 . 2 S S - CC o p e r a tio n a l r e q u ir e me n ts 6.2.1 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.2 Re q u ir e me n ts o n th e T e r min a tin g P I N X 6.2.3 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 - CC 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 - CC S ta te d e f in itio n s 6.4.1 States at the Originating PINX 6.4.2 S t a t e s a t t h e T e r mi n a t i n g P I N X 6 . 5 S S - CC s ig n a llin g p r o c e d u r e s 6.5.1 Ma j o r o p tio n s 6.5.2 Actions at the Originating PINX 6.5.3 A c t i o n s a t t h e T e r mi n a t i n g P I N X 6.5.4 Actions at the Transit PINX 6 . 6 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 n c o min g G a t e w a y P I N X p r o c e d u r e s : S S - C C B S r e q u e s t f r o m a p u b l i c I S D N 6.6.2 Outgoing Gateway PINX procedures: SS-CCBS request to a public ISDN 6 . 7 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 n c o min g G a te w a y P I N X p r o c e d u r e s 6.7.2 O u tg o in g G a te w a y P I N X p r o c e d u r e s 6 . 8 P r o t o c o l i n t e r a c t i o n b e t w e e n S S - C C B S a n d O t h e r S u p p l e me n t a r y S e r v i c e s a n d A N F s

3 3 3 4 4 4 4 5 5 9 9 9 9 10 10 10 11 17 21 21 21 22 23 23 23 23

- ii -

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 Co mp le tio n o f Ca lls o n N o Re p ly ( S S - CCN R) 6.8.4 Call Transfer 6.8.5 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.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 P a t h R e p l a c e me n t ( A N F - P R ) 6 . 9 P r o to c o l in te r a c tio n b e tw e e n S S - CCN R 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.9.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.9.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.9.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.9.4 Call Transfer 6.9.5 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.9.6 C a l l F o r w a r d in g B u s y ( S S - C F B ) 6.9.7 Ca ll F o r w a r d in g N o Re p ly ( S S - CF N R) 6.9.8 Call Deflection (SS-CD) 6.9.9 P a t h R e p l a c e me n t ( A N F - P R ) 6.10 P a r a me t e r v a l u e s ( t i me r s ) 6.10.1 T i me r s a t t h e O r i g i n a t i n g P I N X 6.10.2 T i me r s a t t h e T e r mi n a t i n g P I N X

24 24 24 24 24 24 25 25 25 25 25 25 25 25 25 26 26 26 26 27 27 27

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 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 g ua 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

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 the Call Completion supplementary services at the Q reference point between Private Integrated services Network eXchanges (PINXs) connected together within a Private Integrated Services Network (PISN). The Call Completion supplementary services are Completion of Calls to Busy Subscribers (SS-CCBS) and Completion of Calls on No Reply (SS-CCNR). SS-CCBS enables a calling User A, encountering a busy destination User B, to have the call completed when User B becomes not busy, without having to make a new call attempt. SS-CCNR enables a calling User A, encountering a destination User B that, though alerted, does not answer, to have the call completed when User B becomes not busy again after a period of activity, without having to make a new call attempt. 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-185. The signalling protocols for SS-CCBS and SS-CCNR operate 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-CC 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.

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 Inter-Exchange Signalling Procedures and Protocol (International Standard ISO/IEC 11572)

ECMA-155

Private Integrated Services Networks - Addressing (International Standard ISO/IEC 11571)

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

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

- 2 -

ECMA-185

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

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:

4.2

– Application Protocol Data Unit (APDU)

(ECMA-165)

– Basic Service

(ITU-T Rec. I.210)

– Complete Number

(ECMA-155)

– Incoming Gateway PINX

(ECMA-143)

– Interpretation APDU

(ECMA-165)

– Network Facility Extension (NFE)

(ECMA-165)

– Originating PINX

(ECMA-165)

– Outgoing Gateway PINX

(ECMA-143)

– Private Integrated Services Network (PISN)

(ECMA-133)

– Private Integrated services Network eXchange (PINX)

(ECMA-133)

– 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)

Other definitions

4.2.1

C C C a ll The re-initiation, in the course of executing a CC Request, of the previously unsuccessful call from User A to User B on behalf of User A, with or without Path Reservation.

4.2.2

CC Request An instance of SS-CCBS or SS-CCNR.

4.2.3

Connection release The release of the call independent signalling connection as soon as a SS-CC has been initiated and the establishment of further call independent signalling connections for subsequent phases of the service.

- 3 -

4.2.4

Connection retention The use of a single call independent signalling connection throughout the lifetime of a particular instance of SS-CC.

4.2.5

P a t h r e s e r v a t io n The reservation of resources prior to the SS-CC Recall, by means of a basic call set up from the Originating to the Terminating PINX, in order to have a bearer connection through the PISN available when User A accepts the SS-CC Recall.

4.2.6

Service retention The optional capability to continue with a CC Request after the CC Call failed due to User B being busy again.

6 6.1

Acronyms APDU

Application Protocol Data Unit

ASN.1

Abstract Syntax Notation no. 1

Call Completion

ISDN

Integrated Services Digital Network

MSI

Manufacturer Specific Information

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

Supplementary Service Completion of Calls (i.e. SS-CCBS or SS-CCNR)

SS-CCBS

Supplementary Service Completion of Calls to Busy Subscribers

SS-CCNR

Supplementary Service Completion of Calls on No Reply

Terminal Equipment

Signalling protocol for the support of SS-CCBS and SS-CCNR SS-CCBS/CCNR description Completion of Calls to Busy Subscribers (SS-CCBS) is a supplementary service which allows a calling User A, on encountering a busy called User B, to request that the PISN monitors User B and indicates to User A when User B becomes not busy. On response by User A to that indication the PISN will attempt to complete the call to User B. Completion of Calls on No Reply (SS-CCNR) is a supplementary service which allows a calling User A, when the called User B does not respond to the call request, to request that the PISN monitors User B and indicates to User A when User B becomes not busy after a subsequent period of activity at User B's TE. On response by User A to that indication the PISN will attempt to complete the call to User B. NOTE Which activities at User B's TE would result in a 'B not busy' indication to User A is outside the scope of this Standard. These supplementary services are applicable to all basic services defined in ECMA-142.

- 4 -

6.2 6.2.1

SS-CC operational requirements 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. Additionally generic procedures for the call independent control (connection oriented) of supplementary services, as specified in ECMA-165 for an Originating and a Terminating PINX, shall apply.

6.2.2

Requirements on the Terminating PINX Call establishment procedures 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. Additionally generic procedures for the call independent control (connection oriented) of supplementary services, as specified in ECMA-165 for an Originating and a Terminating PINX, shall apply.

6.2.3

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. NOTE The use of basic call timer T310 at a Transit PINX can cause premature clearing of a reserved path if the timer value is too short. For this reason this Standard specifies the sending of CCITT progress description no. 8 "in-band information or appropriate pattern now available" by the Terminating PINX, in order to stop timer T310, even though in-band tones and announcements are not applicable in this situation. Generic procedures for the call related control and call independent control (connection oriented) of supplementary services, as specified in ECMA-165 for a Transit PINX, shall apply.

- 5 -

6.3 6.3.1

SS-CC 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 F. Table 1 - Operations in support of SS-CC

SS-CC-Operations-asn1-97 { iso (1) standard (0) pss1-call-completion (13870) 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-asn1-97 { iso standard pss1-generic-procedures (11582) pss1-generic-parameters-asn1-97(17)} PartyNumber, PartySubaddress, PresentedNumberUnscreened FROM Addressing-Data-Elements-asn1-97 {iso standard pss1-generic-procedures (11582) addressing-data-elements-asn1-97 (20)} supplementaryServiceInteractionNotAllowed FROM General-Error-List { ccitt (0) recommendation (0) q 950 general-error-list (1) } ; CC-Operations OPERATION ::= {ccbsRequest | ccnrRequest | ccCancel | ccExecPossible | ccPathReserve | ccRingout | ccSuspend | ccResume } ccbsRequest OPERATION ::= { ARGUMENT CcRequestArg RESULT CcRequestRes ERRORS{ shortTermRejection | longTermRejection | unspecified | supplementaryServiceInteractionNotAllowed } CODE local: 40 }

- 6 -

Table 1 - Operations in support of SS-CC (continued) ccnrRequest OPERATION ::= { ARGUMENT CcRequestArg RESULT CcRequestRes ERRORS{ shortTermRejection | longTermRejection | unspecified | supplementaryServiceInteractionNotAllowed } CODE local: 27 } ccCancel OPERATION ::= { ARGUMENT RETURN RESULT ALWAYS RESPONDS CODE }

CcOptionalArg FALSE FALSE local: 28

ccExecPossible OPERATION ::= { ARGUMENT RETURN RESULT ALWAYS RESPONDS CODE }

CcOptionalArg FALSE FALSE local: 29

ccPathReserve OPERATION ::= { ARGUMENT CcExtension RESULT CcExtension ERRORS { remoteUserBusyAgain | failureToMatch | failedDueToInterworking | unspecified } CODE local: 30 }

- 7 -

Table 1 - Operations in support of SS-CC (continued) ccRingout OPERATION ::= { ARGUMENT CcExtension RETURN RESULT FALSE ERRORS{ remoteUserBusyAgain | failureToMatch | unspecified } ALWAYS RESPONDS FALSE CODE local: 31 } ccSuspend OPERATION ::= { ARGUMENT CcExtension RETURN RESULT FALSE ALWAYS RESPONDS FALSE CODE local: 32 } ccResume OPERATION ::= { ARGUMENT RETURN RESULT ALWAYS RESPONDS CODE }

CcExtension FALSE FALSE local: 33

-- TYPE DEFINITIONS FOR CC DATA TYPES FOLLOW CcRequestArg ::= SEQUENCE { numberA PresentedNumberUnscreened, numberB PartyNumber, service PSS1InformationElement, -- permitted information elements are: -- Bearer capability; Low layer compatibility; High layer compatibility subaddrA [10] PartySubaddress OPTIONAL, subaddrB [11] PartySubaddress OPTIONAL, can-retain-service [12] IMPLICIT BOOLEAN DEFAULT FALSE, retain-sig-connection [13] IMPLICIT BOOLEAN OPTIONAL, -- TRUE: signalling connection to be retained; -- FALSE: signalling connection to be released; -- omission: release or retain signalling connection-extension CcExtension OPTIONAL }

- 8 -

Table 1 - Operations in support of SS-CC (concluded) CcRequestRes ::= SEQUENCE{ no-path-reservation retain-service extension

[0] IMPLICIT BOOLEAN DEFAULT FALSE, [1] IMPLICIT BOOLEAN DEFAULT FALSE, CcExtension OPTIONAL }

CcOptionalArg ::= CHOICE{ fullArg

[0] IMPLICIT SEQUENCE { numberA PartyNumber, numberB PartyNumber, service PSS1InformationElement, -- permitted information elements are: --Bearer capability; -- Low layer compatibility; -- High layer compatibility. subaddrA [10] PartySubaddress OPTIONAL, subaddrB [11] PartySubaddress OPTIONAL, extension CcExtension OPTIONAL }, CcExtension

extArg } CcExtension ::= CHOICE { none single multiple

NULL, [14] IMPLICIT Extension{{CCExtSet}}, [15] IMPLICIT SEQUENCE OF Extension{{CCExtSet}} }

CCExtSet

EXTENSION

::= {...}

-- DEFINITIONS FOR ERRORS FOLLOW unspecified ERROR ::= { PARAMETER CODE } shortTermRejection longTermRejection remoteUserBusyAgain failureToMatch failedDueToInterworking

END

ERROR ERROR ERROR ERROR ERROR

-- of SS-CC-Operations-asn1-97

Extension{{CCExtSet}} local: 1008

::= { CODE ::= { CODE ::= { CODE ::= { CODE ::= { CODE

local: 1010} local: 1011} local: 1012} local: 1013} local: 1014}

- 9 -

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 11.3.3 of ECMA-165. The Facility information element shall always contain an NFE. When the Facility information element is sent and conveys an invoke APDU the destinationEntity element of the NFE shall contain value endPINX. A Facility information element conveying a ccPathReserve invoke APDU shall also contain an Interpretation APDU with value clearCallIfAnyInvokePduNotRecognised. In all other cases the Interpretation APDU shall either be omitted or included with value rejectAnyUnrecognisedInvokePdu. Within elements of type PSS1InformationElement information elements (e.g. Bearer capability) shall be coded in accordance with ECMA-143. 6.3.2.2

6.3.3

6.4

Other information elements Any other information elements (e.g. Calling party number, Called party number) shall be coded in accordance with the rules of ECMA-143 and ECMA-165. Messages The Facility information element shall be conveyed in the messages as specified in clause 10 of ECMA-165.

SS-CC State definitions

6.4.1

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-CC Supplementary Service Control entity in that PINX in association with a particular CC Request.

6.4.1.1

C C - I d le This state exists if SS-CC is not active.

6.4.1.2

C C - I n v o k e d - U s e r - A - R ET This state exists for an active CC Request while waiting for the indication that User B is not busy, using the connection retention method.

6.4.1.3

C C - I n v o k e d - U s e r - A - R LS This state exists for an active CC Request while waiting for the indication that User B is not busy, using the connection release method.

6.4.1.4

CC-Path-Setup This state exists during Path Reservation.

6.4.1.5

C C - R in g o u t This state exists when User A has accepted the SS-CC Recall but completion of the call to User B is still pending.

6.4.1.6

CC-Suspended-User-A This state exists when a CC Call without Path Reservation has been postponed because User A is busy.

6.4.1.7

C C - W a it - A C K This state exists during SS-CC invocation.

6.4.1.8

C C - W a i t - U s e r - A - A n s we r - N This state exists while waiting for SS-CC Recall acceptance from User A if no path has been reserved.

6.4.1.9

C C - W a i t - U s e r - A - A n s we r - R This state exists while waiting for SS-CC Recall acceptance from User A after a path has been reserved.

- 10 -

6.4.1.10 6.4.2

CC-Wait-User-A-Free This state exists when Path Reservation is delayed because User A is busy.

States at the Terminating PINX The procedures for the Terminating PINX are written in terms of the following conceptual states existing within the SS-CC Supplementary Service Control entity in that PINX in association with a particular CC Request.

6.4.2.1

C C - I d le This state exists if SS-CC is not active.

6.4.2.2

C C - A wa it - C a ll- C o m p le t io n This state exists while waiting for the incoming CC Call after having indicated that User B is not busy.

6.4.2.3

CC-Invoked-User-B This state exists while User B is monitored as a result of a CC Request received.

6.4.2.4

C C - P a t h - C o m p le t e This state exists when a path has been successfully reserved and CC Call completion is pending.

6.4.2.5

CC-Suspended-User-B This state exists when a CC Call has been postponed because User A is busy.

6.4.2.6

C C - W a it - U s e r - B- A le r t This state exists after a CC Call has been extended to User B, while waiting for acceptance (alerting or connect).

6.5

SS-CC signalling procedures The following procedures are a combination of call related and call independent signalling. The latter uses the connection-oriented APDU transport mechanism specified in ECMA-165, which provides call independent signalling connections for supplementary service control. All SS-CC control information is exchanged between Originating PINX and Terminating PINX. Examples of message sequences are shown in annex C.

6.5.1

6.5.1.1

M a j o r o p t io n s The signalling protocol contains the following major options. These are negotiated between the Originating and Terminating PINXs at SS-CC invocation time, using specific elements in the argument and result of operations ccbsRequest and ccnrRequest. P a t h R e s e r v a t io n There are two methods of establishing the CC Call: path reservation method - a bearer connection between the Originating and Terminating PINXs is established before recalling User A, to avoid the possibility of encountering network congestion after User A responds to SS-CC Recall; non-reservation method - a bearer connection between the Originating and Terminating PINXs is established after User A responds to SS-CC Recall and the service is cancelled if network congestion is encountered. As described in 6.5.2, it is an option of the Originating PINX which of these methods is used. The procedures specified in 6.5.3 mandate from a Terminating PINX the support of non-reservation method and allows the path reservation method. In interworking situations, an Outgoing Gateway PINX can force the use of the non-reservation method if the other network cannot support path reservation; see 6.6 and 6.7.

- 11 -

6.5.1.2

Retention of signalling connection There are two ways in which SS-CC uses call independent signalling connections: connection retention method - the signalling connection is maintained until completion or cancellation of SS-CC; connection release method - the signalling connection is cleared after each phase of call independent signalling and a new signalling connection is established for each subsequent phase of call independent signalling. The procedures specified in 6.5.2 and 6.5.3 leave the decision on the method to the Terminating PINX, but permit the Originating PINX to ask for the use of the connection release method if possible, in order to avoid occupying network resources for the duration of the service. Similarly, 6.7 permits an Incoming Gateway PINX to ask for the use of the connection release method for compatibility with other networks. Clauses 6.6 and 6.7 provide a means by which an Incoming Gateway PINX or Outgoing Gateway PINX can force the use of the connection retention method for compatibility with public ISDNs and other networks that operate with a retained connection.

6.5.1.3

Service retention There are two possible behaviours when User B is found to be busy again after User A responds to SS-CC Recall. service retention method - the CC Request remains in force at the Originating and Terminating PINXs and the Terminating PINX commences the monitoring of User B again; service cancellation method - the CC Request is cancelled at the Originating and Terminating PINXs. Either PINX can force the use of the service cancellation method. The service retention method will be used if both PINXs agree.

6.5.2

A c t io n s a t t h e O r ig in a t in g P I N X The SDL representation of procedures at the Originating PINX is shown in D.1 to D.10 of annex D.

6.5.2.1 Normal procedures 6 . 5 . 2 . 1 . 1 C C BS in v o c a t io n If User A requests SS-CCBS and the request is acceptable to the Originating PINX, the Originating PINX shall send a ccbsRequest invoke APDU to the Terminating PINX according to 6.5.2.1.3. NOTE SS-CCBS can be requested after a call attempt has encountered a busy condition at User B. The release of the original call is beyond the scope of this Standard. Upon receipt of a ccbsRequest return result APDU the Originating PINX shall start the service duration timer T2 with a value appropriate for SS-CCBS, enter state CC-Invoked-User-A-RET (connection retention case) or CC-Invoked-User-A-RLS (connection release case), and wait for an indication that User B has become not busy. 6.5.2.1.2

CCNR invocation If User A requests SS-CCNR and the request is acceptable to the Originating PINX, the Originating PINX shall send a ccnrRequest invoke APDU to the Terminating PINX according to 6.5.2.1.3. NOTE SS-CCNR can be requested after a call to User B has remained unanswered. The release of the original call is beyond the scope of this Standard. Upon receipt of a ccnrRequest return result APDU the Originating PINX shall start the service duration timer T2 with a value appropriate for SS-CCNR, enter state CC-Invoked-User-A-RET (connection retention case) or CC-Invoked-User-A-RLS (connection release case), and wait for an indication that User B has become not busy after a subsequent period of activity.

- 12 -

6.5.2.1.3

S S - C C in v o c a t io n - d e t a ile d p r o c e d u r e The Facility information element containing the ccbsRequest or ccnrRequest invoke APDU shall be sent in a SETUP message which establishes a call independent signalling connection between the two end PINXs, according to 7.3 of ECMA-165. The SETUP message shall contain User B's number in information element Called party number, and optionally User A's number in information element Calling party number. The following information shall be included in the argument of the ccbsRequest or ccnrRequest invoke APDU: • basic call information from the original call: – the number of User A, or an indication that it is not available or restricted, in element numberA; – optionally and if available, the subaddress of User A, in element subaddrA; – the number of User B, in element numberB; – if available, the subaddress of User B, in element subaddrB; – the information elements Bearer capability, Low layer compatibility (if available) and High layer compatibility (if available), embedded in element service; • optionally element retain-sig-connection with value TRUE if the Originating PINX prefers the connection retention option, or value FALSE if the Originating PINX prefers the connection release option. Otherwise, the element shall be omitted. • optionally element can-retain-service with value TRUE if the Originating PINX is able to use the service retention method. Otherwise the element shall either be omitted or have the value FALSE. After sending the ccbsRequest/ccnrRequest invoke APDU the Originating PINX shall start timer T1 and enter state CC-Wait-Ack. Upon receipt of a ccbsRequest or ccnrRequest return result APDU the Originating PINX shall stop timer T1. If the result contains element retain-service with value TRUE and element can-retain-service was sent with value TRUE in the argument of the corresponding invoke APDU, the Originating PINX shall record the fact that the service retention method is to be used; otherwise it shall record the fact that the service cancellation method is to be used. If the result contains element no-path-reservation with value TRUE the Originating PINX shall record the fact that the non-reservation method is to be used. Otherwise it may select either the path reservation method or the non-reservation method. NOTE A Terminating PINX can force the use of the non-reservation method; see 6.5.3.1.3. In interworking situations, an Outgoing Gateway PINX can force the use of the non-reservation method if the other network cannot support path reservation; see 6.6 and 6.7. If the ccbsRequest/ccnrRequest return result APDU was received in a CONNECT message the Originating PINX shall continue according to the procedures specified for the connection retention method. If the return result APDU was received in a RELEASE message the Originating PINX shall complete the clearing of the signalling connection in accordance with 7.3 of ECMA-165 and continue according to the procedures specified for the connection release method.

6.5.2.1.4

I n d ic a t io n t h a t U s e r B is n o t b u s y a) Connection retention case: If a ccExecPossible invoke APDU is received in a FACILITY message (i.e. on the retained call independent signalling connection) while in state CC-Invoked-User-A-RET the Originating PINX shall proceed as described under c) below. Any basic call information, if present in the argument of the ccExecPossible invoke APDU, shall be ignored.

- 13 -

b) Connection release case: On receipt of a ccExecPossible invoke APDU in a SETUP message for a call independent signalling connection the Originating PINX shall process the SETUP message according to 7.3 of ECMA-165, attempt to associate the APDU with a CC Request that is in state CC-InvokedUser-A-RLS, and if successful proceed as described under c) below. The association shall be achieved by comparing all the basic call information received in the argument of the ccExecPossible invoke APDU with the information stored at the Originating PINX. If less information is received than what is stored, a match shall be deemed to occur if all the elements received match those stored and any missing element belongs to the following group: subaddress of User A; subaddress of User B; High layer compatibility information element; Low layer compatibility information element. NOTE 1 Information can be missing as a result of the Terminating PINX discarding part of the optional information at SS-CC invocation time. This need not cause ambiguity provided the Terminating PINX rejects CC Requests which are duplicates with regard to the remaining information. NOTE 2 The Originating PINX with regard to SS-CC is the Terminating PINX with regard to the call independent signalling connection. c) For both cases: In both cases a) and b) above the Originating PINX shall proceed in accordance with: 6.5.2.1.5, if User A is not busy and the non-reservation method is to be used; or 6.5.2.1.6, if User A is not busy and the path reservation method is to be used; or 6.5.2.1.7, if User A is busy and the non-reservation method is to be used; or 6.5.2.1.8, if User A is busy and the path reservation method is to be used. 6.5.2.1.5

C C C a ll wit h o u t P a t h R e s e r v a t io n If User A is not busy and the Originating PINX uses the non-reservation method for establishing the CC Call, the Originating PINX shall indicate the SS-CC Recall to User A, start the recall timer T3 and enter state CC-Wait-User-A-Answer-N. If the SS-CC Recall is accepted before timer T3 expires the Originating PINX shall initiate the CC Call in accordance with ECMA-143 by sending a SETUP message towards the Terminating PINX, stop timer T3 and enter state CC-Ringout. The SETUP message shall contain a Facility information element with a ccRingout invoke APDU. If in state CC-Ringout an ALERTING or a CONNECT message is received the Originating PINX shall stop the service duration timer T2, delete the CC Request and return to state CC-Idle. If a call independent signalling connection for SS-CC still exists it may be released according to 7.3 of ECMA-165. The CC Call shall continue in accordance with ECMA-143.

6.5.2.1.6

C C C a ll wit h P a t h R e s e r v a t io n If User A is not busy and the Originating PINX uses the path-reservation method for establishing the CC Call, the Originating PINX shall: •

if the connection release method is used, return a RELEASE message with cause value number 16 "normal call clearing" to release the signalling connection; optionally the RELEASE message may also be sent in the connection retention case, if the service retention option does not apply and no further call independent signalling is expected;

•

initiate Path Reservation as a basic call request according to ECMA-143, sending a SETUP message towards the Terminating PINX; include in the SETUP message a ccPathReserve invoke APDU, as well as all the information stored from the original call;

•

start timer T4; and

•

enter state CC-Path-Setup.

- 14 -

Upon receipt of a ccPathReserve return result APDU in a call related PROGRESS message, while in state CC-Path-Setup the Originating PINX shall stop timer T4. If User A is busy the Originating PINX shall, if the capability exists, indicate to User A that User B is not busy. Either immediately or if the busy condition persists the Originating PINX shall continue according to 6.5.2.1.9. NOTE The means of determining whether the busy condition persists is implementation dependent. If User A is not busy the Originating PINX shall indicate the SS-CC Recall to User A, start the recall timer T3 and enter state CC-Wait-User-A-Answer-R. If the SS-CC Recall is accepted before timer T3 expires the Originating PINX shall stop timer T3, send a call related FACILITY message with a ccRingout invoke APDU to the Terminating PINX and enter state CC-Ringout. If in state CC-Ringout an ALERTING or CONNECT message is received, the Originating PINX shall stop the service duration timer T2, delete the CC Request and return to state CC-Idle. If a call independent signalling connection for SS-CC still exists it may be released according to 7.3 of ECMA-165. The CC Call shall continue in accordance with ECMA-143. 6.5.2.1.7

U s e r A b u s y , n o n - r e s e r v a t io n m e t h o d a) Suspend procedure: If User A is busy and the Originating PINX chooses the non-reservation method, the Originating PINX shall: •

if the connection retention method is used, send a ccSuspend invoke APDU to the Terminating PINX in a FACILITY message on the existing call independent signalling connection.

•

if the connection release method is used, send a ccSuspend invoke APDU to the Terminating PINX in a call independent signalling connection CONNECT message.

•

start monitoring User A and enter state CC-Suspended-User-A.

NOTE The second action above implies changing from connection release method to connection retention method. b) Resume procedure: If User A, for whom a CC Request in state CC-Suspended-User-A exists, becomes not busy the Originating PINX shall send a FACILITY message with a ccResume invoke APDU on the existing call independent signalling connection and enter state CC-Invoked-User-A-RET, waiting for another indication that User B is not busy. 6.5.2.1.8

U s e r A b u s y b e f o r e P a t h R e s e r v a t io n If User A is busy and the Originating PINX uses the path reservation method, the Originating PINX shall release the call independent signalling connection according to 7.3 of ECMA-165, unless the connection retention method applies, start monitoring User A, and enter state CC-Wait-User-A-Free. Cause number 16 "normal call clearing" shall be used when releasing the signalling connection. The Originating PINX may also send a ccSuspend invoke APDU to the Terminating PINX on the existing call independent signalling connection, either in the RELEASE message in case of connection release or in a FACILITY message in case of connection retention. If User A, for whom a CC Request in state CC-Wait-User-A-Free exists, becomes not busy the Originating PINX shall initiate a CC Call with Path Reservation according to 6.5.2.1.6.

6.5.2.1.9

U s e r A b u s y a f t e r P a t h R e s e r v a t io n If User A is busy on completion of Path Reservation the Originating PINX shall release the reserved path by sending a DISCONNECT message to the Terminating PINX, start monitoring

- 15 -

User A and enter state CC-Wait-User-A-Free. The DISCONNECT message shall contain a Facility information element with a ccSuspend invoke APDU. If User A, for whom a CC Request in state CC-Wait-User-A-Free exists, becomes not busy the Originating PINX shall initiate a CC Call with Path Reservation according to 6.5.2.1.6. 6.5.2.1.10 CCBS/CCNR cancellation a) Cancellation initiated by the Originating PINX: In order to cancel a CC Request, the Originating PINX shall send a ccCancel invoke APDU to the Terminating PINX, release any call independent signalling connection by sending a RELEASE message with cause number 16 "normal call clearing", release any CC Call by sending a DISCONNECT message with cause number 16 "normal call clearing", delete all data stored for that CC Request, stop any timer running, and return to state CC-Idle. Unless cancellation was initiated by user request or the Originating PINX automatically re-invokes SS-CC, User A shall, if the capability exists, be informed of failure of the service. If a call independent signalling connection exists the ccCancel invoke APDU shall be sent with argument extArg in the RELEASE message that initiates clearing of the connection. If no call independent signalling connection exists but a path has been reserved (i.e. after a ccPathReserve return result APDU was received) the ccCancel invoke APDU shall be sent with argument extArg in the DISCONNECT message that initiates clearing of the reserved path. In all other cases the ccCancel invoke APDU shall be sent in a SETUP message establishing a new signalling connection according to 7.3 of ECMA-165. The invoke APDU shall include argument fullArg with the same basic call information as previously sent in the ccbsRequest or ccnrRequest invoke APDU, i.e. • User A's number in element numberA; • User B's number in element numberB; • information elements Bearer capability and, if stored, High layer compatibility / Low layer compatibility in element service; • User A's subaddress, if stored, in element subaddrA - otherwise this element shall be omitted; • User B's subaddress, if stored, in element subaddrB - otherwise this element shall be omitted, in order to identify the CC Request to be cancelled. When subsequently receiving a RELEASE message, the signalling connection shall be cleared in accordance with ECMA-165. b) Cancellation initiated by the Terminating PINX: On receipt of a ccCancel invoke APDU from the Terminating PINX in the RELEASE message for an existing call independent signalling connection the Originating PINX shall delete all data stored for the associated CC Request, stop any timer still running, clear the CC Call - if already initiated - in accordance with ECMA-143, inform User A of the cancellation, if the capability exists, and return to state CC-Idle. Any basic call information, if present in the argument of the ccCancel invoke APDU, shall be ignored. On receipt of a ccCancel invoke APDU in the SETUP message for a new call independent signalling connection the Originating PINX shall attempt to associate the APDU with an active CC Request, by comparing the basic call information received in the argument of the invoke APDU with the information locally stored. If the information received is less than what is stored a match shall be deemed to occur if all the elements received match those stored and any missing element belongs to the following group: subaddress of User A; subaddress of User B; High layer compatibility information element; Low layer compatibility information element. If successfully associated, the Originating PINX shall delete all data stored for that CC Request, stop any timer still running, clear the CC Call - if already initiated - in accordance with ECMA-143, inform User A of the cancellation, if the capability exists, and return to state CC-Idle. The signalling connection shall be released according to 7.3 of ECMA-165.

- 16 -

6.5.2.2 Ex c e p t io n a l p r o c e d u r e s 6.5.2.2.1 CCBS/CCNR invocation If establishment of the call independent signalling connection fails, or if after sending a ccbsRequest or ccnrRequest invoke APDU no answer is received from the Terminating PINX before timer T1 expires, or if the answer is a return error APDU or a reject APDU, a failure indication shall be given to User A, and the Originating PINX shall return to state CC-Idle. The call independent signalling connection shall be released in accordance with ECMA-165, if it still exists. Timer T1 shall be stopped if still running. If a ccbsRequest or ccnrRequest return result APDU is received in a RELEASE message although the connection retention method is required (i.e. element retain-sig-connection was sent with value TRUE in the corresponding invoke APDU) the Originating PINX shall cancel the CC Request according to 6.5.2.1.10. If a ccbsRequest or ccnrRequest return result APDU is received in a CONNECT message although the connection release method is expected (i.e. element retain-sig-connection was sent with value FALSE in the corresponding invoke APDU) the Originating PINX shall either cancel the CC Request according to 6.5.2.1.10 or, if possible, proceed according to the rules specified for the connection retention method. 6.5.2.2.2

Unexpected APDUs If the Originating PINX receives a SETUP message for a call independent signalling connection with a ccExecPossible invoke APDU for which no matching CC Request in state CC-Invoked-UserA-RLS exists the PINX shall release the signalling connection according to 7.3 of ECMA-165. and include a ccCancel invoke APDU in the RELEASE message. A ccCancel invoke APDU for which no matching CC Request exists shall be ignored when received in a SETUP message for a call independent signalling connection, but the signalling connection shall be released according to 7.3 of ECMA-165.

6.5.2.2.3

Service duration timer expiry If the service duration timer T2 expires while in state CC-Invoked-User-A-RET, CC-Invoked-UserA-RLS, CC-Suspended-User-A, or CC-Wait-User-A-Free, the Originating PINX shall cancel the CC Request, using the procedure described in 6.5.2.1.10. In any other state, the Originating PINX may defer action until reaching one of the states above or may cancel the SS-CC request immediately.

6.5.2.2.4

SS-CC Recall timer expiry If User A does not accept the SS-CC Recall before the recall timer T3 expires the Originating PINX shall cancel the CC Request, using the procedure described in 6.5.2.1.10.

6.5.2.2.5

F a ilu r e o f P a t h R e s e r v a t io n If a DISCONNECT message with a reject APDU indicating 'unrecognisedOperation' or with a return error APDU indicating 'failedDueToInterworking' is received in response to a ccPathReserve invoke APDU the Originating PINX shall stop timer T4 and choose one of the following options: a) If the signalling connection has been retained, attempt a CC Call without Path Reservation according to 6.5.2.1.5. b) Retry Path Reservation on another route. c) Cancel the CC Request, using the procedure described in 6.5.2.1.10. The Originating PINX may then automatically re-invoke SS-CC, forcing the use of connection retention so that the non-reservation method can be used. If a call clearing message (according to ECMA-143) with a return error APDU indicating 'remoteUserBusyAgain' is received in response to a ccPathReserve invoke APDU, the Originating PINX shall stop timer T4 and return to state CC-Invoked-User-A-RET (connection retention case) or CC-Invoked-User-A-RLS (connection release case). If the error value in the ccPathReserve return error APDU is failureToMatch or unspecified, the Originating PINX shall delete the CC Request, stop any timer running, and return to state CC-Idle.

- 17 -

If a call independent signalling connection still exists the Originating PINX may release it in accordance with 7.3 of ECMA-165. If a Path Reservation attempt fails due to network congestion the Originating PINX may retry later to establish a path to the Terminating PINX or cancel the CC Request according to 6.5.2.1.10. If timer T4 expires, or if a Path Reservation attempt fails for any reason other than network congestion, without a ccPathReserve return error APDU being received, the Originating PINX shall cancel the CC Request according to 6.5.2.1.10. 6.5.2.2.6

F a ilu r e o f C C C a ll p r e s e n t a t io n If a call clearing message (according to ECMA-143) with a ccRingout return error APDU is received with an error value remoteUserBusyAgain the Originating PINX shall: − if the service retention option is effective for that CC Request, return to state CC-Invoked-UserA-RET (connection retention case) or CC-Invoked-User-A-RLS (connection release case); − else, delete the CC Request, stop timer T2, and return to state CC-Idle. If a call independent signalling connection still exists the Originating PINX may release it in accordance with 7.3 of ECMA-165. The Originating PINX shall either indicate the failure to User A or automatically (re-)invoke SS-CCBS according to 6.5.2.1.1. If the error indicated in the ccRingout return error APDU is 'failureToMatch' or 'unspecified' the Originating PINX shall delete the CC Request, stop timer T2, indicate the failure to User A, and return to state CC-Idle. If a call independent signalling connection still exists the Originating PINX may release it in accordance with 7.3 of ECMA-165. If the CC Call fails without a ccRingout return error APDU being received the Originating PINX shall cancel the CC Request according to 6.5.2.1.10.

6.5.3

Actions at the Terminating PINX The SDL representation of procedures at the Terminating PINX is shown in D.11 to D.16 of annex D.

6.5.3.1 Normal procedures 6 . 5 . 3 . 1 . 1 C C BS in v o c a t io n If a Facility information element with a ccbsRequest invoke APDU is received (in a SETUP message according to 7.3 of ECMA-165) the Terminating PINX shall process the request according to 6.5.3.1.3 and start monitoring User B for becoming not busy, if the CC Request is accepted. NOTE If User B is already not busy this will result in immediate initiation of the procedures of 6.5.3.1.4. 6.5.3.1.2

CCNR invocation If a Facility information element with a ccnrRequest invoke APDU is received (in a SETUP message according to 7.3 of ECMA-165) the Terminating PINX shall process the request according to 6.5.3.1.3 and start monitoring User B for becoming not busy after a subsequent period of activity, if the CC Request is accepted.

6.5.3.1.3

S S - C C in v o c a t io n - d e t a ile d p r o c e d u r e If a CC Request can be accepted the Terminating PINX shall store the basic call information contained in the argument of the ccbsRequest/ccnrRequest invoke APDU. The PINX may discard any of the following elements, if present: subaddress of User A; subaddress of User B; High layer compatibility information element; Low layer compatibility information element. NOTE Discarding part of the supplied information can lead to non-identical requests being treated as duplicates, see 6.5.3.2.1. As an acknowledgment a ccbsRequest/ccnrRequest return result APDU shall be returned to the Originating PINX. If element can-retain-service was present in the corresponding invoke APDU and had value TRUE and the Terminating PINX is able to use the service retention method an element retain-service with value TRUE shall be included in the result. In all other cases this element shall either be omitted or have the value FALSE. If the Terminating PINX does not support

- 18 -

the procedures for receiving a Call Completion call with Path Reservation according to 6.5.3.1.6, it shall force the use of non-reservation method by including an element no-path-reservation with value TRUE in the result. The Terminating PINX shall select either the connection retention or the connection release method in accordance with the following: • If element retain-sig-connection was present in the ccbsRequest/ccnrRequest invoke APDU and had value FALSE, and if the number of User A is available, the Terminating PINX shall use the connection release method. • If element retain-sig-connection was present in the ccbsRequest/ccnrRequest invoke APDU and had value TRUE, or if the number of User A is not available, the Terminating PINX shall use the connection retention method. • In other cases the Terminating PINX is free to select either method. If the connection retention method is to be used, the Terminating PINX shall send the ccbsRequest/ccnrRequest return result APDU in a CONNECT message on the call independent signalling connection. If the connection release method is to be used, the Terminating PINX shall send the ccbsRequest/ccnrRequest return result APDU in a RELEASE message on the call independent signalling connection and complete the release of the signalling connection in accordance with 7.3 of ECMA-165. Cause number 16 "normal call clearing" shall be used in the RELEASE message. In both cases the Terminating PINX shall enter state CC-Invoked-User-B. 6.5.3.1.4

I n d ic a t io n t h a t U s e r B is n o t b u s y As soon as User B becomes not busy (in the case of SS-CCNR, after a period of activity subsequent to SS-CC invocation) the Terminating PINX shall send a ccExecPossible invoke APDU to the Originating PINX, using call independent signalling, enter state CC-Await-Call-Completion and wait for the incoming CC Call. If the connection retention method is used the ccExecPossible invoke APDU with argument extArg shall be sent in a FACILITY message on the existing signalling connection. If the connection release method is used the ccExecPossible invoke APDU with argument fullArg shall be sent in a SETUP message, establishing a new call independent signalling connection according to 7.3 of ECMA-165. The argument shall contain the basic call information stored by the Terminating PINX in relation to that CC Request: • User A's number in element numberA; • User B's number in element numberB; • information elements Bearer capability and, if stored, High layer compatibility / Low layer compatibility in element service; • User A's subaddress, if stored, in element subaddrA - otherwise this element shall be omitted; • User B's subaddress, if stored, in element subaddrB - otherwise this element shall be omitted. NOTE 1 The terminating PINX should ensure that the sending of the ccExecPossible invoke APDU using a new call independent signalling connection does not occur so soon after the sending of the ccbsRequest or ccnrRequest return result APDU that it will arrive at the Originating PINX out of sequence. If subsequently a RELEASE message is received the signalling connection shall be released in accordance with 7.3 of ECMA-165, and the Terminating PINX shall remain in state CC-Await-Call-Completion. NOTE 2 It is the responsibility of the Terminating PINX to guard against non-receipt of a CC Call and, in the case of Path Reservation, of a subsequent ccRingout invoke APDU.

- 19 -

6.5.3.1.5

C C C a ll wit h o u t P a t h R e s e r v a t io n If a basic call SETUP message according to ECMA-143 is received with a ccRingout invoke APDU the terminating PINX shall attempt to associate the incoming CC Call with a CC Request in state CC-Await-Call-Completion and, if successful and User B is still not busy, extend the CC Call to User B and enter state CC-Wait-User-B-Alert. The association shall be achieved by comparing the basic call information locally stored with the information elements of the received SETUP message. A match shall be deemed to occur if all the elements stored locally match the corresponding information elements of the SETUP message; any information element in the SETUP message for which no corresponding element is stored shall be ignored during the comparison. If in state CC-Wait-User-B-Alert an ALERTING or a CONNECT message is sent to the Originating PINX according to ECMA-143, the Terminating PINX shall delete the respective CC Request and enter state CC-Idle. The associated signalling connection shall be released according to 7.3 of ECMA-165. The CC Call shall continue in accordance with ECMA-143.

6.5.3.1.6

C C C a ll wit h P a t h R e s e r v a t io n If a basic call SETUP message according to ECMA-143 is received with a ccPathReserve invoke APDU and the terminating PINX supports path reservation method, the terminating PINX shall attempt to associate the incoming CC Call (i.e. path reservation request) with a CC Request in state CC-Await-Call-Completion or CC-Suspended-User-B, by comparing the basic call information locally stored with the information elements of the received SETUP message. A match shall be deemed to occur if all the elements stored locally match the corresponding information elements of the SETUP message; any information element in the SETUP message for which no corresponding element is stored shall be ignored during the comparison. If the match is successful and User B is still not busy the Terminating PINX shall return a ccPathReserve return result APDU and enter state CC-Path-Complete. The return result APDU shall be sent in a call related PROGRESS message with CCITT progress description no. 8. The CC Call shall not be extended to User B yet. NOTE The function of this progress description is to stop basic call timer T310. Upon receipt of a ccRingout invoke APDU in a call related FACILITY message while in state CC-Path-Complete, and if User B is still not busy, the Terminating PINX shall enter state CC-Wait-User-B-Alert and extend the CC Call to User B. If in state CC-Wait-User-B-Alert an ALERTING or a CONNECT message is sent to the Originating PINX according to ECMA-143 the Terminating PINX shall delete the respective CC Request and enter state CC-Idle. If a signalling connection still exists it shall be released according to 7.3 of ECMA-165. The CC Call shall continue in accordance with ECMA-143.

6.5.3.1.7

CCBS/CCNR suspension / resumption If a ccSuspend invoke APDU is received in a call independent FACILITY, RELEASE or CONNECT message according to 7.3 of ECMA-165. while in state CC-Await-Call-Completion the Terminating PINX shall enter state CC-Suspended-User-B. If a ccSuspend invoke APDU is received in a call related DISCONNECT message while in state CC-Path-Complete the Terminating PINX shall release the reserved path in accordance with ECMA-143 and enter state CC-Await-Call-Completion, waiting for another path reservation attempt. If a ccResume invoke APDU is received in a FACILITY message on the existing call independent signalling connection while in state CC-Suspended-User-B the Terminating PINX shall enter state CC-Invoked-User-B and resume monitoring of User B. NOTE If User B is already not busy this will result in immediate initiation of the procedures of 6.5.3.1.4. If a ccPathReserve invoke APDU is received in a SETUP message while in state CC-SuspendedUser-B, 6.5.3.1.6 shall apply.

- 20 -

6.5.3.1.8

CCBS/CCNR cancellation a) Cancellation initiated by the Originating PINX: If a ccCancel invoke APDU is received in a call independent RELEASE message (connection retention case) the Terminating PINX shall delete the information stored for the associated CC Request and enter state CC-Idle. Any basic call information, if present in the argument of the ccCancel invoke APDU, shall be ignored. The signalling connection shall be released in accordance with 7.3 of ECMA-165. If a ccCancel invoke APDU is received in a call independent SETUP message (connection release case) the Terminating PINX shall attempt to associate the APDU with an active CC Request, by comparing the information contained in the argument of the ccCancel invoke APDU with the information locally stored. A match shall be deemed to occur if all the stored elements match the corresponding elements received; any received element for which no corresponding element is stored shall be ignored during the comparison. If successfully associated, the Terminating PINX shall delete the information stored for that CC Request, return a RELEASE message for the call independent signalling connection with Cause number 16 "normal call clearing", and enter state CC-Idle. If a ccCancel invoke APDU is received in a call related DISCONNECT message (after a path was reserved) the Terminating PINX shall release the CC Call (path) according to ECMA-143, delete the information stored for the associated CC Request and enter state CC-Idle.. Any basic call information, if present in the argument of the ccCancel invoke APDU, shall be ignored. If a signalling connection still exists it shall be released according to 7.3 of ECMA-165. b) Cancellation initiated by the Terminating PINX: In order to cancel a CC Request the Terminating PINX shall send a ccCancel invoke APDU to the Originating PINX using call independent signalling, delete the CC Request and enter state CC-Idle. If a signalling connection exists the ccCancel invoke APDU shall be sent with an argument extArg in a RELEASE message on the existing signalling connection. Cause number 16 "normal call clearing" shall be used. If no signalling connection exists the ccCancel invoke APDU shall be sent in a SETUP message establishing a new signalling connection according to 7.3 of ECMA-165. The invoke APDU shall contain in argument fullArg the basic call information stored by the Terminating PINX in relation to that CC Request, as listed in 6.5.3.1.4. If subsequently a RELEASE message is received the signalling connection shall be cleared in accordance with ECMA-165.

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 CCBS/CCNR invocation A CC Request may not be accepted if it is a duplicate of an already stored CC Request. Acceptance of duplicate CC Requests may be restricted to cases where the connection retention method can be used. NOTE Duplicate requests can also be caused by the Terminating PINX discarding part of the received basic call information. If a request for SS-CCBS or SS-CCNR cannot be accepted the Terminating PINX shall return a RELEASE message with a ccbsRequest or ccnrRequest return error APDU on the existing signalling connection. Cause number 16 "normal call clearing" shall be used. If the failure condition is persistent (e.g. service not provided for User B) error value longTermRejection shall be included. If the failure condition is transient (e.g. duplicate CC Request, allowed number of active CC Requests exceeded) error value shortTermRejection shall be included.

- 21 -

6.5.3.2.2

Unexpected APDUs If a call independent SETUP message is received with a ccCancel invoke APDU which cannot be associated with a CC Request the APDU shall be ignored, but the signalling connection shall be released according to 7.3 of ECMA-165. If a call related SETUP message is received with a ccRingout invoke APDU that cannot be associated with a CC Request in state CC-Await-Call-Completion, or with a ccPathReserve invoke APDU that cannot be associated with a CC Request in state CC-Await-Call-Completion or CC-Suspended-User-B, the Terminating PINX shall return a call clearing message, according to ECMA-143, with a ccRingout/ccPathReserve return error APDU with error value failureToMatch. NOTE If a call related SETUP message is received with a ccPathReserve invoke APDU and the receiving PINX does not support the Path Reservation method, the APDU shall be rejected as an unrecognised operation according to 8.1 of ECMA-165.

6.5.3.2.3

U s e r B b u s y a g a in o n P a t h R e s e r v a t io n a t t e m p t If the Terminating PINX supports the Path Reservation method and User B is busy again on arrival of a SETUP message with a ccPathReserve invoke APDU while in state CC-Await-Call-Completion or CC-Suspended-User-B, the Terminating PINX shall return a call clearing message, according to ECMA-143 using cause number 17 "user busy", with a ccPathReserve return error APDU with error value remoteUserBusyAgain, resume monitoring of User B and enter state CC-Invoked-User-B.

6.5.3.2.4

U s e r B b u s y a g a in o n C C C a ll p r e s e n t a t io n If User B is busy again when receiving a ccRingout invoke APDU, either in a FACILITY message while in state CC-Path-Complete or in a SETUP message while in state CC-Await-Call-Completion, the Terminating PINX shall return a call clearing message, according to ECMA-143 using cause number 17 "user busy", with a ccRingout return error APDU with error value remoteUserBusyAgain. If the service retention option is in use the CC Request shall be retained and monitoring of User B shall be resumed, returning to state CC-Invoked-User-B. If a signalling connection still exists and it is not in ACTIVE state, it shall be released according to 7.3 of ECMA-165. If the service retention option is not used the CC Request shall be deleted and state CC-Idle shall be entered. If a signalling connection still exists it shall be released according to 7.3 of ECMA-165.

6.5.3.2.5

6.5.4

6.6

I n t e r r u p t io n o f C C C a ll If a DISCONNECT message without any SS-CC invoke APDU is received for a CC Call in progress (e.g. after successful path reservation) the associated CC Request shall be deleted, and state CC-Idle shall be entered. If a signalling connection still exists it shall be released according to 7.3 of ECMA-165.

A c t io n s a t t h e Tr a n s it P I N X No special actions are required for SS-CC.

Impact of interworking with public ISDNs The SS-CCBS procedures specified in this Standard are compatible with the public ISDN procedures for the T reference point. When interworking with the public ISDN, a Gateway PINX shall perform the procedures specified below.

6.6.1

I n c o m in g G a t e wa y P I N X p r o c e d u r e s : S S - C C B S r e q u e s t f r o m a p u b l i c I S D N If a call from the public ISDN encounters a busy User B in the PISN and if the public ISDN requires to be informed if SS-CCBS is available, the Incoming Gateway PINX shall indicate to the public ISDN that SS-CCBS is available, unless it is known that SS-CCBS is not available. If a CCBS request is received from the public ISDN the Incoming Gateway PINX shall establish a call independent signalling connection towards the Terminating PINX, according to 7.3 of ECMA-165. The SETUP message shall include a ccbsRequest invoke APDU, which shall contain in its argument the data

- 22 -

received from the public ISDN, the element retain-sig-connection with value TRUE and optionally element can-retain-service, reflecting the corresponding indication from the public ISDN. The Incoming Gateway PINX shall translate the following APDUs received from the Terminating PINX into corresponding information and send it to the public ISDN: a ccbsRequest return result or return error APDU; a ccExecPossible invoke APDU; a ccCancel invoke APDU. ccCancel, ccSuspend or ccResume invoke APDUs shall be generated and sent to the Terminating PINX when the Incoming Gateway PINX receives corresponding indications from the public ISDN. All call independent signalling for a particular CC Request shall use the same call independent signalling connection, which shall remain active until that CC Request terminates. If a CCBS Call is received from the public ISDN it shall be extended by the Incoming Gateway PINX towards the Terminating PINX, including a ccRingout invoke APDU in the SETUP message. NOTE The CCBS Call need not enter the PISN at the same Gateway PINX as the corresponding call independent signalling connection. When the call independent signalling connection to the Terminating PINX is released the Incoming Gateway PINX shall release the call independent signalling association at the T reference point. 6.6.2

O u t g o in g G a t e wa y P I N X p r o c e d ur e s : S S - C C B S r e q u e s t t o a p u b l i c I S D N NOTE 1 The Outgoing Gateway PINX cannot pass on an indication that SS-CCBS is possible when received in a clearing message from the public ISDN. If a CCBS request is destined for the public ISDN the Outgoing Gateway PINX shall translate the ccbsRequest invoke APDU and send it to the public ISDN according to the procedures for the T reference point. When receiving a response the Outgoing Gateway PINX shall generate a ccbsRequest return result APDU (if the CCBS request was accepted) or a return error APDU (if the CCBS request was rejected) and send it to the Originating PINX in a CONNECT message (return result) or in a RELEASE message (return error). The return result APDU shall contain element no-path-reservation with value TRUE and optionally element retain-service, reflecting the corresponding indication from the public ISDN. NOTE 2 The sending of the return result APDU in a CONNECT message is in accordance with the connection retention method. This overrides the value FALSE in element retain-sig-connection, if present in the ccbsRequest invoke APDU. ccExecPossible or ccCancel invoke APDUs shall be generated and sent to the Originating PINX when the Outgoing Gateway PINX receives corresponding indications from the public ISDN. The Outgoing Gateway PINX shall translate the following APDUs received from the Originating PINX into corresponding information and send it to the public ISDN: A ccSuspend invoke APDU; a ccResume invoke APDU; a ccCancel invoke APDU. All call independent signalling for a particular CC Request shall use the same call independent signalling connection, which shall remain active until that CC Request terminates. A CCBS Call without Path Reservation shall be extended by the Outgoing Gateway PINX to the public ISDN. NOTE 3 The CCBS Call need not leave the PISN at the same Gateway PINX as the call independent signalling connection. When the call independent signalling connection to the Originating PINX is released the Outgoing Gateway PINX shall release the call independent signalling association at the T reference point. A Path Reservation attempt from the Originating PINX shall be abandoned by the Outgoing Gateway PINX by returning a DISCONNECT message with a ccPathReserve return error APDU indicating error value failedDueToInterworking.

- 23 -

6.7 6.7.1

Impact of interworking with non-ISDNs I n c o m in g G a t e wa y P I N X p r o c e d u r e s If a non-ISDN network offers an equivalent supplementary service, SS-CCBS or SS-CCNR can be invoked on request of that network if the SS-CC options supported by both the Incoming Gateway PINX and the Terminating PINX are compatible with the service offered by the non-ISDN network. When sending a ccbsRequest or ccnrRequest invoke APDU, the Incoming Gateway PINX shall include an element retain-sig-connection: • with value FALSE if, for compatibility with the other network or for other reasons, the Incoming Gateway PINX prefers the use of the connection release method; • with value TRUE if, for compatibility with the other network, it is necessary to use the connection retention method. Otherwise the element shall be omitted. The Incoming Gateway PINX may also include an element can-retain-service with value TRUE if the other network supports the service retention capability. If an element retain-sig-connection with value FALSE was sent but the Terminating PINX uses the connection retention method, sending the return result APDU in a CONNECT message, the Incoming Gateway PINX shall reject the service request from the other network and initiate cancellation procedures within the PISN if it is unable to interwork using the connection retention method.

6.7.2

O u t g o in g G a t e wa y P I N X p r o c e d u r e s If a non-ISDN network offers an equivalent supplementary service, SS-CCBS or SS-CCNR can be invoked in that network if the SS-CC options supported by both the Originating PINX and the Outgoing Gateway PINX are compatible with the service offered by the non-ISDN network. When sending a ccbsRequest or ccnrRequest return result APDU, the Outgoing Gateway PINX shall include an element no-path-reservation with value TRUE if the other network is unable to support the path reservation method. In all other cases this element shall either be omitted or have the value FALSE. The Outgoing Gateway PINX may also include an element retain-service with value TRUE if element can-retain-service was sent in the corresponding invoke APDU and the other network indicated support of service retention. In all other cases this element shall either be omitted or have the value FALSE. If in the invoke APDU element retain-sig-connection was sent with value TRUE, the Outgoing Gateway PINX shall not employ the connection release method. If unable to interwork using the connection retention method, the Outgoing Gateway PINX shall respond with a return error APDU. If in the invoke APDU no element retain-sig-connection was present, the Outgoing Gateway PINX shall select either the connection retention method or the connection release method, depending on the capabilities of the other network. If the element was present in the invoke APDU with value FALSE, the Outgoing Gateway PINX should, if possible, use the connection release method.

6.8

Protocol interaction between SS-CCBS and Other Supplementary Services and ANFs This clause specifies protocol interactions of SS-CCBS 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 1 Simultaneous conveyance of APDUs for SS-CCBS and another supplementary service or ANF in the same message, each in accordance with the requirements of its respective stage 3 standards, does not, on its own, constitute a protocol interaction. NOTE 2 Additional interactions that have no impact on the signalling protocol at the Q reference point can be found in the relevant stage 1 specifications.

- 24 -

6.8.1

Calling Name Identification Presentation (SS-CNIP) No protocol interaction.

6.8.2

Connected Name Identification Presentation (SS-CONP) No protocol interaction.

6.8.3

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

6.8.4

C a ll Tr a n s f e r No protocol interaction.

6.8.5

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 ) The following interactions shall apply if SS-CFU is supported in accordance with ECMA-174.

6.8.5.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 S S - C C BS a t a S S - 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 SS-CCBS is also the Originating PINX with regard to SS-CFU. If SS-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 SS-CCBS operation which requires this element; − Called party number information element in the SETUP message of any call independent signalling procedure; − 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 SS-CCBS request received from User A shall be rejected.

6.8.5.2

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

6.8.5.3

6.8.6 6.8.6.1

Terminating PINX procedures if SS-CFU is activated by User B after SS-CCBS has been invoked No protocol interaction. C a ll F o r wa r d in g Bu s y ( S S - C F B) The following interaction shall apply if SS-CFB is supported in accordance with ECMA-174. 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 S S - C C BS a t a S S - 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 SS-CCBS is also the Originating PINX with regard to SS-CFB. The procedures of 6.8.5.1 shall apply.

6.8.6.2

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

- 25 -

6.8.6.3

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

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 ) No protocol interaction.

6.8.8

Call Deflection (SS-CD) The protocol interactions with Call Deflection Immediate shall be as specified in 6.8.5 for interaction with SS-CFU. The protocol interactions with Call Deflection from Alert shall be as specified in 6.8.7 for interaction with SS-CFNR.

6.8.9

6.9

Path Replacement (ANF-PR) No protocol interaction

Protocol interaction between SS-CCNR and other supplementary Services and ANFs This clause specifies protocol interactions of SS-CCNR 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 1 Simultaneous conveyance of APDUs for SS-CCNR and another supplementary service or ANF in the same message, each in accordance with the requirements of its respective stage 3 standards, does not, on its own, constitute a protocol interaction. NOTE 2 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.9.1

Calling Name Identification Presentation (SS-CNIP) No protocol interaction.

6.9.2

Connected Name Identification Presentation (SS-CONP) No protocol interaction.

6.9.3

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

6.9.4

C a ll Tr a n s f e r No protocol interaction.

6.9.5

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 ) The following interactions shall apply if SS-CFU is supported in accordance with ECMA-174.

6.9.5.1

Originating PINX procedures for invoking SS-CCNR at a SS-CFU diverted-to user NOTE In this case the Originating PINX with regard to SS-CCNR is also the Originating PINX with regard to SS-CFU. If SS-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 SS-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.

- 26 -

The address of the originally called user shall not be used for CCNR. If element nominatedNr is not available, a SS-CCNR request received from User A shall be rejected. 6.9.5.2

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

6.9.5.3

6.9.6 6.9.6.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 S S -C F U i s a c t i v a t e d b y U s e r B a f t e r S S - C C N R h a s been invoked No protocol interaction. C a ll F o r wa r d in g Bu s y ( S S - C F B) The following interaction shall apply if SS-CFB is supported in accordance with ECMA-174. Originating PINX procedures for invoking SS-CCNR at a SS-CFB diverted-to user NOTE In this case the Originating PINX with regard to SS-CCBS is also the Originating PINX with regard to SS-CFB. The procedures of 6.9.5.1 shall apply.

6.9.6.2

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

6.9.6.3

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

6.9.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 ) The following interaction shall apply if SS-CFNR is supported in accordance with ECMA-174.

6.9.7.1

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

6.9.7.2

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

6.9.7.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 S S- C F N R i s a c t i v a t e d b y U s e r B a f t e r S S - C C N R has been invoked No protocol interaction.

6.9.8

Call Deflection (SS-CD) The protocol interactions with Call Deflection Immediate shall be as specified in 6.9.5 for interaction with SS-CFU. The protocol interactions with Call Deflection from Alert shall be as specified in 6.9.7 for interaction with SS-CFNR.

6.9.9

Path Replacement (ANF-PR) No protocol interaction.

- 27 -

6.10 6.10.1

Parameter values (timers) Timers at the Originating PINX The Originating PINX shall implement the following timers. Timer T1: Request Protection This timer is started when sending a ccbsRequest or ccnrRequest invoke APDU and stopped on receipt of a response. If timer T1 expires a failure indication is sent to User A. Timer T1 shall have a duration in the range 10 - 30 seconds. Timer T2: SS-CC Service Duration This timer is started on receipt of the ccbsRequest or ccnrRequest return result APDU and stopped on completion of the CC Call or if the CC Request is cancelled. If timer T2 expires the CC Request is cancelled. The duration of timer T2 is implementation dependent. Timer T3: Recall This timer is started when the SS-CC Recall is indicated to User A and stopped when User A responds. If timer T3 expires the CC Request is cancelled. Timer T3 shall have a duration in the range 10 - 30 seconds. Timer T4: Path Reservation Protection This timer is started when sending a ccPathReserve invoke APDU and stopped on receipt of a ccPathReserve return result or return error APDU. If timer T4 expires the CC Request is cancelled. Timer T4 shall have a duration in the range 30 - 40 seconds.

6.10.2

Timers at the Terminating PINX None.

- 28 -

- 29 -

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 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 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's. − 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 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) specifying 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).

- 30 -

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 requirement. No pre-printed 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.

- 31 -

A.3

PICS proforma for ECMA-186

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 the requirement for full identification. The terms Name and Version should be interpreted appropriately to correspond with a supplier's 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) ?

No [ ] Yes [ ] (The answer YES means that the implementation does not conform to this Standard)

Date of Statement

- 32 -

A.3.3

General Item

Question / feature

Reference

Status

N/A

Support

PINX can act as Originating PINX

o.1

Yes [ ] No [ ]

PINX can act as Terminating PINX

o.1

Yes [ ] No [ ]

Support of CCBS

o.2

Yes [ ] No [ ]

Support of CCNR

o.2

Yes [ ] No [ ]

Incoming Gateway Function

Yes [ ] No [ ]

Outgoing Gateway Function

Yes [ ] No [ ]

Support of (Path-) Non-reservation method

Yes [ ]

Support of Path Reservation method

Yes [ ] No [ ]

Support of Service Retention option

Yes [ ] No [ ]

A10

Support of relevant procedures of ECMA-143 and ECMA-165

Yes [ ]

6.2

- 33 -

A.3.4

Procedures at the Originating PINX This table shall apply only if item A1 is supported. Item

Question / feature

Reference

Status

N/A

Support

CCBS invocation

6.5.2.1.1 6.5.2.1.3

A3:m

[]

m:Yes [ ]

CCNR invocation

6.5.2.1.2 6.5.2.1.3

A4:m

[]

m:Yes [ ]

Procedures for connection retention method

6.5.2.1

Yes [ ]

Procedures for connection release method

6.5.2.1

Yes [ ] No [ ]

Procedures for receiving indication that User B is not busy

6.5.2.1.4

Yes [ ]

Set up CC Call without Path Reservation

6.5.2.1.5

Yes [ ]

Set up CC Call with Path Reservation

6.5.2.1.6

Procedures for User A busy, (path-) non-reservation method

6.5.2.1.7

Procedures for User A busy, path reservation method

6.5.2.1.8 6.5.2.1.9

B7:m

B10

Cancellation of a CC Request

6.5.2.1.10

Yes [ ]

B11

Exceptional procedures except failure of CC Call presentation

6.5.2.2.1 through 6.5.2.2.5

Yes [ ]

B12

Failure of CC Call presentation, service retention if User B is busy again

6.5.2.2.6

A9:m

B13

Failure of CC Call presentation, no service retention if User B is busy again, failure indication to User A

6.5.2.2.6

o.1

Yes [ ] No [ ]

B14

Failure of CC Call presentation, no service retention if User B is busy again, automatic re-invocation of SS-CCBS

6.5.2.2.6

o.1

Yes [ ] No [ ]

B15

Failure of Path Reservation due to "unrecognisedOperation" or "failedDueToInterworking": CC Call without Path Reservation

6.5.2.2.5

o.3

Yes [ ] No [ ]

B16

Failure of Path Reservation due to "unrecognisedOperation" or "failedDueToInterworking": retry Path Reservation on another route

6.5.2.2.5

o.3

Yes [ ] No [ ]

[]

o: Yes [ ] No [ ] Yes [ ]

[]

m:Yes [ ]

- 34 -

B17

Failure of Path Reservation due to "unrecognisedOperation" or "failedDueToInterworking": cancel the CC Request

6.5.2.2.5

o.3

Yes [ ] No [ ]

B18

Failure of Path Reservation due to network congestion: retry to establish a path

6.5.2.2.5

o.2

Yes [ ] No [ ]

B19

Failure of the Path Reservation due to network congestion: cancel the CC Request

6.5.2.2.5

o.2

Yes [ ] No [ ]

B20

Support of the suspend option before Path Reservation when user A is busy

6.5.2.1.8

A8:o

[]

o: Yes [ ] No [ ]

- 35 -

A.3.5

Procedures at the Terminating PINX This table shall apply only if item A2 is supported. Item

Question / feature

Reference

Status

N/A

Support

CCBS invocation

6.5.3.1.1 6.5.3.1.3

A3:m

[]

m:Yes [ ]

CCNR invocation

6.5.3.1.2 6.5.3.1.3

A4:m

[]

m:Yes [ ]

Procedures for connection retention method

6.5.3.1

Yes [ ]

Procedures for connection release method

6.5.3.1

Yes [ ]

Procedures for indicating that User B is not busy

6.5.3.1.4

Yes [ ]

Receive CC Call without Path Reservation

6.5.3.1.5

Yes [ ]

Receive CC Call with Path Reservation

6.5.3.1.6

c.1

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

CCBS/CCNR suspension / resumption

6.5.3.1.7

Yes [ ]

Cancellation of a CC Request

6.5.3.1.8

Yes [ ]

C10

Exceptional procedures except User B Busy again on CC Call presentation

6.5.3.2.1 6.5.3.2.2 6.5.3.2.3 6.5.3.2.5

Yes [ ]

C11

Service retention procedure if User B is busy again on CC Call presentation

6.5.3.2.4

A9:m

C12

Procedure without service retention if User B is busy again on CC Call presentation

6.5.3.2.4

Yes [ ]

C13

Force the use of non-reservation method

6.5.3.1.3 or 6.6.2 or 6.7.2

Yes [ ] No [ ]

c.1:

if C13 then o else m

[]

m:Yes [ ]

- 36 -

A.3.6

Procedures at a Gateway PINX This table shall apply only if item A5 or A6 is supported. Item

Question / feature

Reference

Status

N/A

Support

Interworking if CCBS Request comes from a public ISDN

6.6.1

A5:o.1

[]

o: Yes [ ] No [ ]

Interworking if CCBS/CCNR Request comes from a non-ISDN

6.7.1

A5:o.1

[]

o: Yes [ ] No [ ]

Interworking if CCBS Request goes to a public ISDN

6.6.2

A6:o.2

[]

o: Yes [ ] No [ ]

Interworking if CCBS/CCNR Request goes to a non-ISDN

6.7.2

A6:o.2

[]

o: Yes [ ] No [ ]

- 37 -

A.3.7

Coding Item

Question / feature

Reference

Status

N/A

Sending and receipt of ccbsRequest invoke APDUs

6.3.1

A3:m

[]

m:Yes [ ]

Sending and receipt of ccnrRequest invoke APDUs

6.3.1

A4:m

[]

m:Yes [ ]

Sending and receipt of ccCancel invoke APDU

6.3.1

Sending of ccExecPossible invoke APDU

6.3.1

c.1

[]

Receipt of ccExecPossible invoke APDU

6.3.1

c.2

[]

Sending of ccPathReserve invoke and receipt of return result and return error APDUs

6.3.1

c.3

[]

Receipt of ccPathReserve invoke and sending of return result or return error APDUs

6.3.1

Sending of ccRingout invoke and receipt of return error APDU

6.3.1

c.2

[]

m:Yes [ ]

Receipt of ccRingout invoke and sending of return error APDU

6.3.1

c.1

[]

m:Yes [ ]

E10

Sending of ccSuspend invoke APDU

6.3.1

c.2

[]

m:Yes [ ]

E11

Receipt of ccSuspend invoke APDU

6.3.1

c.1

[]

m:Yes [ ]

E12

Sending of ccResume invoke APDU

6.3.1

c.2

[]

m:Yes [ ]

E13

Receipt of ccResume invoke APDU

6.3.1

c.1

[]

m:Yes [ ]

c.1:

if (A2 or A6) then m else N/A

c.2:

if (A1 or A5) then m else N/A

c.3:

if (A1 and B7) then m else if D2 then o else N/A

c.4:

if (A2 and A8) then m else if D4 then o else N/A

Support

Yes [ ]

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

c.4

[]

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

- 38 -

A.3.8

A.3.9

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

Question/feature

Reference

Support of SS-CFU or SS-CDI

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

c.1:

if F1 and A1 and A3 then optional, else N/A

Status

N/A

o 6.8.5.1

Support Yes [ ] No [ ]

c.1

[]

Yes [ ] No [ ]

Status

N/A

Support

Interactions between SS-CCBS and SS-CFB Item

Question/feature

Reference

Support of SS-CFB

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

c.1:

if G1 and A1 and A3 then optional, else N/A

6.8.6.1

c.1

Yes [ ] No [ ] []

Yes [ ] No [ ]

N/A

Support

A.3.10 Interactions between SS-CCNR and SS-CFU/SS-CDI Item

Question/feature

Reference

Support of SS-CFU or SS-CDI

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

c.1:

if H1 and A1 and A4 then optional, else N/A

Status o

6.9.5.1

Yes [ ] No [ ]

c.1

[]

Yes [ ] No [ ]

Status

N/A

Support

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

Question/feature

Support of SS-CFB

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

c.1:

if I1 and A1 and A4 then optional, else N/A

Reference

o 6.9.6.1

c.1

Yes [ ] No [ ] []

Yes [ ] No [ ]

- 39 -

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

Question/feature

Support of SS-CFNR or SS-CDA

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

c.1:

if J1 and A1 and A4 then optional, else N/A

Reference

Status

N/A

Support Yes [ ] No [ ]

6.9.7.1

c.1

[]

Yes [ ] No [ ]

References

Status

N/A

Support

6.10.1

A1:m

[]

A.3.13 Timers Item K1

Question / feature Support of timer T1

m:Yes [ ] Value:

Support of timer T2

6.10.1

A1:m

[]

m:Yes [ ] Value:

Support of timer T3

6.10.1

A1:m

[]

m:Yes [ ] Value:

Support of timer T4

6.10.1

c.1

[]

m:Yes [ ] Value:

c.1:

if (A1 and B7) then m else N/A

- 40 -

- 41 -

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.

- 42 -

- 43 -

Annex C ( in f o r ma tiv e )

Examples of messages sequences

This annex describes some typical message flows for SS-CCBS and SS-CCNR. The following conventions are used in the figures of this annex. 1. The following notation is used: Call related protocol message Call independent protocol message between PINXs or a service primitive between a PINX and a user

SETUP

Message name

Number of connection x

xxx.inv

Invoke APDU for operation xxx

xxx.rr

Return result APDU for operation xxx

xxx.re

Return error APDU for operation xxx

2. The figures show messages exchanged via Protocol Control between the Originating PINX (PINX A) and a Transit PINX and between a Transit PINX and the Terminating PINX (PINX B). Only messages relevant to SS-CC are shown. NOTE Transit PINXs do not take an active part in the operation of SS-CC. 3. Only the relevant information content (SS-CC APDUs) is listed below each message name. The Facility information elements containing the SS-CC_APDUs are not explicitly shown. Information with no impact on SS-CC is not shown. 4. Some interactions with users are included in form of symbolic primitives. The actual protocol at the terminal interface is outside the scope of this Standard. 5. Each end-to-end signalling connection (call related or call independent) is assigned a number (Cx). Every message name is accompanied by the number of the respective signalling connection to which it relates.

- 44 -

C.1

Successful CCBS

C.1.1

With path reservation and connection release Figure C.1 shows an example message flow of a successful CCBS request and recall with path reservation. It is assumed that the signalling connection is released during the monitoring phase. User A

PINX A

CCBS request

CCBS Confirm

Transit PINX SETUP (C1) ccbsRequest.inv

PINX B

User B

SETUP (C1) ccbsRequest.inv

CALL PROCEEDING (C1)

RELEASE (C1) ccbsRequest.rr

RELEASE COMPLETE (C1)

Monitoring User B SETUP (C2) ccExecPossible.inv

SETUP (C2) ccExecPossible.inv

CALL PROCEEDING (C2)

RELEASE (C2)

RELEASE COMPLETE (C2)

SETUP (C3) ccPathReserve.inv

CALL PROCEEDING (C3)

Recall Indication

PROGRESS (C3) ccPathReserve.rr

Recall response

FACILITY (C3) ccRingout.inv

ALERT (C3)

Alerting Indication

User B not busy Indication

Setup request Alerting Indication

Normal Basic Call A-B

F ig u r e C . 1 - Ex a m p le M e s s a g e F lo w f o r S u c c e s s f u l C C B S w i t h p a t h r e s e r v a t i o n

- 45 -

C.1.2

Without path reservation Figure C.2 shows a successful CCBS request and recall without path reservation. The signalling connection is retained during the monitoring phase. User A

PINX A

CCBS request

CCBS Confirm

Transit PINX SETUP (C1) ccbsRequest.inv

PINX B SETUP (C1) ccbsRequest.inv

CALL PROCEEDING (C1)

CONNECT(C1) ccbsRequest.rr

CONNECT ACK (C1)

User B

CONNECT ACK (C1)

Monitoring User B Recal l Indication Recall response

Alerting Indication

FACILITY (C1) ccExecPossible.inv

SETUP (C2) ccRingout.inv

CALL PROCEEDING (C2)

ALERT (C2)

RELEASE (C1)

RELEASE COMPLETE (C1)

User B not busy Indication

Setup request

Alerting Indication

Normal Basic Call A-B

F ig u r e C . 2 - Ex a m p le m e s s a g e F lo w f o r s u c c e s s f u l C C B S w i t h o u t p a t h r e s e r v a t i o n

- 46 -

C.2

Successful CCNR Figure C.3 shows a successful CCNR request without connection retention. User A

PINX A

CCNR request

Transit PINX SETUP (C1) ccnrRequest.inv

CCNR Confirm

PINX B SETUP (C1) ccnrRequest.inv

CALL PROCEEDING (C1)

RELEASE (C1) ccnrRequest.rr

RELEASE COMPLETE (C1)

Monitoring User B-continue as for SS-CCBS, Fig. C.1

Figure C.3 - Example message flow for successful CCNR

User B

- 47 -

C.3

User A busy

C.3.1

Path reservation case Figure C.4 shows a CC Request which encounters User A busy when User B is not busy and a subsequent CC Call with path reservation when both users are not busy. It is assumed that the signalling connection has been retained. User A

PINX A

Transit PINX

PINX B

User B

Monitoring User B

User A busy Indication

FACILITY (C1) ccExecPossible.inv

optional:FACILITY (C1) ccSuspend.inv

User B not busy Indication

Monitoring User A User A not busy

SETUP (C2) ccPathReserve.inv

CALL PROCEEDING (C2)

Recall Indication

PROGRESS (C2) ccPathReserve.rr

Recall response

FACILITY (C2) ccRingout.inv

ALERT (C2)

RELEASE (C1)

Indication

Alerting Indication

RELEASE COMPLETE (C1)

Setup request Alerting Indication

RELEASE COMPLETE (C1)

Normal Basic Call A-B

F ig u r e C . 4 - Ex a m p le m e s s a g e f lo w f o r U s e r A B u s y , p a t h r e s e r v a t i o n c a s e

- 48 -

C.3.2

Non-reservation case Figure C.5 shows a CC Request which encounters User A busy when User B is not busy and a subsequent CC Call without path reservation when both users are not busy. User A

PINX A

Transit PINX

PINX B

User B

Monitoring User B

user A busy Indication

FACILITY (C1) ccExecPossible.inv

FACILITY (C1) ccSuspend.inv

User B not busy Indication

Monitoring User A user A not busy Indication

FACILITY (C1) ccResume.inv

Monitoring User B Recall Indication Recall response

Alerting Indication

FACILITY (C1) ccExecPossible.inv

User B not busy

SETUP (C2) ccRingout.inv

Setup request

CALL PROCEEDING (C2)

ALERT (C2)

RELEASE (C1)

RELEASE COMPLETE (C1)

Indication

Alerting Indication

Normal Basic Call A-B

F ig u r e C . 5 - Ex a m p le m e s s a g e f lo w f o r U s e r A B u s y , n o n - r e s e r v a t i o n c a s e

- 49 -

C.4

User B busy again

C.4.1

At path reservation Figure C.6 shows the case that a path reservation attempt encounters User B busy again. User A

PINX A

Transit PINX

PINX B

User B

Monitoring User B FACILITY (C1) ccExecPossible.inv

FACILITY (C1) ccExecPossible.inv

SETUP (C2) ccPathReserve.inv

CALL PROCEEDING (C2)

DISCONNECT(C2) ccPathReserve.re

RELEASE (C2)

RELEASE COMPLETE (C2)

User B not busy Indication

User B busy Indication

Monitoring User B

F ig u r e C . 6 - Ex a m p le m e s s a g e f lo w f o r U s e r B o n p a t h r e s e r v a t i o n

- 50 -

C.4.2

At CC Call presentation - without path reservation, without service retention Figure C.7 shows the case that a CC Call without path reservation encounters User B busy again and the service is not retained. User A

PINX A

Transit PINX

PINX B

User B

Monitoring User B Recall Indication Recall response

Failed Indication

FACILITY (C1) ccExecPossible.inv SETUP (C2) ccRingout.inv

CALL PROCEEDING (C2)

DISCONNECT(C2) ccRingout.re

RELEASE (C2)

RELEASE COMPLETE (C2)

RELEASE (C1)

RELEASE COMPLETE (C1)

User B not busy Indication

Setup request

Setup Reject (busy)

RELEASE COMPLETE (C1)

F ig u r e C . 7 - Ex a m p le M e s s a g e F lo w f o r U s e r B B u s y W i t h o u t S e r v i c e R e t e n t i o n

- 51 -

C.4.3

At CC Call presentation - without path reservation, with service retention Figure C.8 shows the case that a CC Call without path reservation encounters User B busy again and the service is retained. User A

PINX A

Transit PINX

PINX B

User B

Monitoring User B Recall Indication Recall response

Failed Indication

FACILITY (C1) ccExecPossible.inv

SETUP (C2) ccRingout.inv

CALL PROCEEDING (C2)

DISCONNECT (C2) ccRingout.inv

RELEASE (C2)

RELEASE COMPLETE (C2)

User B not busy Indication

Setup request

Setup Rject (busy)

Monitoring User B

F ig u r e C . 8 - Ex a m p le M e s s a g e F lo w f o r U s e r B B u s y w i t h S e r v i c e R e t e n t i o n

- 52 -

- 53 -

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 an SS-CC 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 Procedures 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 symbol bears the name of the message and any remote operations APDU(s) contained in that message. In the case of a message specified in ECMA-143, basic call actions associated with the sending of that message are deemed to occur. In the case of a call independent message, actions associated with the sending of that message according to 7.3 of ECMA-165 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 operations APDU(s) contained in that message. In the case of a message specified in ECMA-143, basic call actions associated with the receipt of that message are deemed to have occurred. In the case of a call independent message, actions associated with the receipt of that message according to 7.3 of ECMA-165 are deemed to have occurred. The following abbreviations are used: BC

Basic Call

conn

Connection

cfm

Confirmation

err

Return error APDU

ind

Indication

inv

Invoke APDU

res

Return result APDU

sig

Signalling

D.1

Behaviour of the Originating PINX Figures D.1 through D.10 show the behaviour of the Originating PINX. Input signals from the left and output signals to the left represent primitives − from or to the served user (user A); − from or to basic call control; these primitives are indicated by a prefix BC-; − internal signal, e.g. timer expiry. Input signals from the right and output signals to the right represent messages to the peer SS-Control entity (i.e. in the Terminating PINX) which carry SS-CC control information. Messages according to 7.3 of ECMA-165 (signalling connection) are indicated by 'sc'. Messages not marked 'sc' are call related.

- 54 -

CC-I dle

Not e C CBS reques t from Us er A

CCNR request f rom U ser A

SETU P (sc ) ccbs Reques t.inv

SET UP (s c) c cnrR eques t.inv

SETU P (sc ) cc Cancel.inv

R ELEASE (s c) ccC ancel. inv

RELEASE (sc)

C C-Idle

St art Timer T1

CC-Wait-AC K

RELEASE (sc)

C C-Idle

Note: This event c an only occur in error situations .

CONNEC T (sc ) cc bsR eques t. res/ cc nrRequ est .res

R ELEASE (sc) c cbs Request. res/ c cnrRequest .res

Stop T imer T 1

Stop T imer T1

Start Timer T 2

Start Tim er T 2

St ore CC reques t

N ote

SETUP (sc) cc Exec Possible. inv

RELEASE(sc) c cbs Request. err / c cnrRequest . err

sig. c onn. f ailed

Tim eout T1

Stop T imer T 1

St ore CC request

rey es inv ocation ?

reyes inv ocat ion ?

no " CC reques t accepted " t o U serA

no " C C request acc epted " t o Us erA

CC -InvokedUs er-A -R ET

CC-Inv oke d U ser-A-R LS

yes

CC failed indication to Us er A

F ig u r e D . 1 - O r ig in a t in g P I N X b e h a v io u r

reinv ocation ? no "C C-Request reject ed " t o U ser A

CC-I dle

- 55 -

CC-Invoked-User-A-RET

ye s

User A busy ?

CC cancelled indication to User A

no Path reservation ?

CC Cancel request from User A

Timeout T2

FACILITY (sc) ccExecPossible.inv

Stop Timer T2

ye s

RELEASE (sc) ccCancel.inv Path reservation ?

RELEASE (sc) ccCancel.inv

CC cancelled indication to User A

yes Delete CC request

ye s

Suspe nd op tion

Can sig. conn. be release d?

without

Can sig. conn. be release d?

REL EASE(sc)

ye s SETUP CC Recall ind. ccPathReserve.inv to User A

FACILITY (sc) ccSuspend.inv

RELEASE(sc)

with

CC-Idle Can sig. conn. be release d? yes

FACILITY (sc) ccSuspend.inv REL EASE (sc) ccSuspend.inv

S tart Timer T3

Start Timer T4

CC-Wait-UserA- Answer-N

CC-Path-Setu p

CC-Suspe nded-User-A

CC-Wait-User-A-Free

F ig u r e D . 2 - O r ig in a t in g P I N X b e h a v io u r ( c o n t in u e d )

- 56 -

CC-Invoked-User-A-RLS

SETUP (sc) ccExecPossible.inv

SETUP(sc) ccCancel.inv

CC cancel request from User A

Timeout T2

RELEASE (sc)

Stop Timer T2

CC cancelled indication to User A

Stop Timer T2

CC canceled indication to User A User A busy?

SETUP (sc) ccCancel.inv

yes

No Path Reservation ?

no no

Path Reservation ?

yes RELEASE (sc)

SETUP ccPathReserve.inv

Start Timer T4

Delete CC request

CC-Idle yes

CC Recall ind to User A

Start Timer T3

without

CC-Wait-User-AAnswer-N

RELEASE (sc)

Suspend option

with

CONNECT (sc) ccSuspend.inv

RELEASE (sc) ccSuspend.inv CC-SuspendedUser-A

CC-Path-Setup

CC-WaitUser-A-Free

F ig u r e D . 3 - O r ig in a t in g P I N X b e h a v io u r ( c o n t in u e d )

- 57 -

CC-Suspended-User-A

"User A not busy" indication

FACILITY (sc) ccResume.inv

RELEASE (sc) ccCancel.inv

CC cancel request from User A

Timeout T2

Stop Timer T2

CC cancelled indication to User A

RELEASE (sc) ccCancel.inv

Delete CC request

CC-Invoked-User-A-RET

CC-Idle

F ig u r e D . 4 - O r ig in a t in g P I N X b e h a v io u r ( c o n t in u e d )

- 58 -

CC-Wait-User-A-Free

"user A not busy" indication

RELEASE (sc) ccCancel.inv

SETUP (sc) ccCancel.inv

CC cancel request from User A

Timeout T2

SETUP ccPathReserve.inv

RELEASE (sc)

Stop Timer T2

CC cancelled indication to User A

Start Timer T4

Stop Timer T2

sig. conn. active ?

yes CC-Path-Setup

CC cancelled indication to User A

RELEASE (sc) ccCancel.inv

Delete CC request

CC-Idle

F ig u r e D . 5 - O r ig in a t in g P I N X b e h a v io u r ( c o n t in u e d )

SETUP (sc) ccCancel.inv

- 59 -

CC-Wait-User- AAnswer-N

CC recall accept from User A

RELEASE(sc) ccCancel.inv

Timeout T3

Timeout T2

RELEASE (sc) ccCancel.inv

Stop Timer T3

cancel

defer

Save T2

SETUP ccRingout.inv

Stop active Timers (T2, T3) CC-Wait-User- AAnswer-N

CC-Ringout

CC failed indication to User A

Delete CC request

CC-Idle

F ig u r e D . 6 - O r ig in a t in g P I N X b e h a v io u r ( c o n t in u e d )

- 60 -

CC-Path-Setup A Fig. D.8 PROGRESS ccPathReserve.res

CC failed ind. (congestion)

DISCONNECT ccPathReserve.err Fig. D.8

Stop Timer T4 User A busy? no

Stop Timer T4 yes

DISCONNECT ccSuspend .inv

User B busy?

yes sig. conn. active?

CC recall ind to User A

yes

Stop Timer T4

2 Stop Fig. D.8 Timer T2 sig. conn. yes active? no

quit

retry SETUP ccPathReserve.inv

Stop Timer T2

Start Timer T4

RELEASE (sc)

no CC-invokedUser-A-RET

CC-WaitUser-A-Free

Start Timer T3

Failed due to interw.?

CC cancelled ind. to User A CC-InvokedUser-A-RLS

Delete CC request

CC-Path- Setup no

sig. conn. active?

yes

SETUP(sc) ccCancel.inv

RELEASE(sc) ccCancel.inv

CC-Wait-User A-Answer-R CC-Idle

F ig u r e D . 7 - O r ig in a t in g P I N X b e h a v io u r ( c o n t in u e d )

- 61 -

A Fig D.7 Timeout T2

Timeout T4

CC cancel request from User A

CC cancelled indication to User A cancel

defer

Stop activeTimers (T2, T4)

Save T2

DISCONNECT CC-Path-Setup Delete CC request

1 (fig D.7) no

2 CC recall indicator to User A

SETUP ccPathReserve.inv

Start Timer T3

Start Timer T4

(fig D.7)

sig. conn. active?

SETUP(sc) ccCancel.inv

yes

RELEASE(sc) ccCancel .inv

CC-Idle CC-Wait-User- AAnswer-N

CC-Path-Setup

F ig u r e D . 8 - O r ig in a t in g P I N X b e h a v io u r ( c o n t in u e d )

- 62 -

CC-Wait-User-A-Answer-R

RELEASE (sc) ccCancel.inv

CC recall accept from User A

Stop Timer T3

SETUP(sc) ccCancel.inv

Timeout T3

RELEASE (sc)

Sig. conn. active ? no

FACILITY ccRingout.inv DISCONNECT

DISCONNECT ccCancel.inv

yes

RELEASE (sc) ccCancel.inv DISCONNECT

CC-Ringout Stop active Timers (T2, T3) Timeout T2

CC failed indication to User A Delete CC request

defer Save T2

cancel CC-Idle

CC-Wait-User- AAnswer-R

F ig u r e D . 9 - O r ig in a t in g P I N X b e h a v io u r ( c o n t in u e d )

- 63 -

CC-Ringout

ALERT or CONNECT

DISCONNECT ccRingout.err

BC Failed ind. (CC Call) no

Stop Timer T2

User B busy ?

Release Sig. conn.? yes

Stop Timer T2

no Stop Timer T2

Release Sig. conn .? Release yes Sig. conn.? yes RELEASE (sc)

RELEASE (sc)

yes

Sig. conn. active? no

RELEASE (sc)

Delete CC request

Service retention?

yes

Stop Timer T2

yes

CC-Invockeduser-A-RET

CC-InvockedUser-A-RLS

Sig. conn. active?

yes re-invocation

CC-Idle

Timeout T2

SETUP (sc) ccbsRequest.inv

Delete CC request

Start Timer T1

CC-Idle

CC-Wait-ACK

RELEASE (sc) ccCancel.inv

cancel

Save T2 sig. conn. active? CC-Ringout

yes

CC failed indication to User A

defer

DISCONNECT ccCancel.inv

yes DISCONNECT

F ig u r e D . 1 0 - O r ig in a t in g P I N X b e h a v io u r ( c o n t in u e d )

SETUP (sc) ccCancel.inv

- 64 -

D.2

Behaviour of the Terminating PINX Figures D.11 through D.16 show the behaviour of the Terminating PINX. Input signals from the left and output signals to the left represent messages from and to the peer SS-Control entity (i.e. in the Originating PINX) which carry SS-CC control information. Messages according to 7.3 of ECMA-165 (signalling connection) are indicated by 'sc'. Messages not marked 'sc' are call related. Input signals from the right and output signals to the right represent primitives: − from or to the called user (User B); − from or to basic call control; these primitives are indicated by a prefix BC.

- 65 -

CC-Idle

SETUP (sc) ccbsRequest.inv

SETUP (sc) ccnrRequest. inv

Request acceptable?

RELEASE (sc) ccbsRequest.err

yes

no RELEASE (sc) ccnrRequest.err

yes

Store CC request

Store CC request CC-Idle

Maintain sig. conn.?

CC-Idle Maintain sig. conn.?

yes

CONNECT (sc) ccbsRequest.res

CONNECT (sc) ccnrRequest.res

RELEASE (sc) ccbsRequest.res

Monitor User B for not busy

RELEASE (sc) ccnrRequest.res

Monitor User B for not busy after activity

CC-Invoked-User-B CC-Invoked-User-B NOTE

NOTE

SETUP (sc) ccCancel.inv

SETUP ccPathReserve.inv

SETUP ccRingout.inv

RELEASE (sc)

DISCONNECT ccPathReserve. err

DISCONNECT ccRingout.err

NOTE: This event can only occur in error situations. CC-Idle

Figure D.11 - Terminating PINX behaviour

- 66 -

CC- Invoked-User-B

SETUP (sc) ccCancel.inv

User B not busy indication

RELEASE (sc) ccCancel.inv

no Sig. conn. active ?

Cancel request

Sig. conn . active ? yes

yes FACILITY(sc) ccExecPossible.inv

CC-Await-CallCompletion

SETUP (sc) ccExecPossible.inv

SETUP (sc) ccCancel.inv

RELEASE (sc) ccCancel.inv

Delet CC request

Sig. conn. active ? no

yes

RELEASE (sc)

CC-Idle

F i g u r e D . 1 2 - T e r m i n a t i n g P IN X b e h a v i o u r ( c o n t i n u e d )

- 67 -

CC-Await-Call-Completion

FACILITY (sc) or RELEASE (sc) or CONNECT (sc) ccSuspend.inv

RELEASE (sc)

SETUP PathReserve.inv

CC-Await-CallCompletion User B busy again?

CC-Suspended-User-B

yes

no PROGRESS ccPathReserve.res

DISCONNECT ccPathReserve.err

CC-Path-Complete

CC-Invoked-User-B

RELEASE (sc) ccCancel.inv

Cancel request

RELEASE (sc)

SETUP ccRingout.inv User B busy again? yes

Sig. conn. active?

SETUP (sc) ccCancel.inv

DISCONNECT ccRingout.err

yes

Service retained?

Sig. conn. exist but not in active state? no

CC-InvokedUser-B

yes

BC setup ind. to User B

CC-Wait User -B-Alert

RELEASE (sc) ccCancel.inv

yes RELEASE (sc)

SETUP (sc) ccCancel.inv

RELEASE (sc) Delete CC request

CC-Idle

Delete CC request

CC-Idle

F i g u r e D . 1 3 - T e r m i n a t i n g P IN X b e h a v i o u r ( c o n t i n u e d )

- 68 -

CC-Path-Complete

FACILITY ccRingout.inv

User B still not busy?

DISCONNECT ccSuspend.inv

SETUP(sc) ccCancel.inv

CC-Await-CallCompletion

BC setup ind. to User B

C-Wait-User B-Alert

Service retained?

DISCONNECT ccCancel.inv

Delete CC request

DISCONNECT ccRingout.err

yes

RELEASE (sc) ccCancel.inv

sig. conn. active?

yes

RELEASE (sc)

yes CC-InvokedUser-B

CC-Idle

Cancel request

SETUP (sc) ccCancel.inv

Sig. conn. active? yes

RELEASE (sc) ccCancel.inv

Delete CC request

CC-Idle

F i g u r e D . 1 4 - T e r m i n a t i n g P IN X b e h a v i o u r ( c o n t i n u e d )

- 69 -

CC-Wait-User-B-Alert

BC alerting User B

BC setup cfm User B

ALERTING

CONNECT

BC cleared (CC call)

SETUP(sc) ccCancel.inv

RELEASE (sc) ccCancel.inv

Delete CC request

yes

Sig. conn. active? no

RELEASE (sc)

CC-Idle

F i g u r e D . 1 5 - T e r m i n a t i n g P IN X b e h a v i o u r ( c o n t i n u e d )

- 70 -

CC-Suspended-User-B

FACILITY (sc) ccResume.inv

SETUP ccPathReserve.inv

User B busy again? CC-Invoked-User-B

SETUP (sc) ccCancel.inv

RELEASE (sc) ccCancel.inv

RELEASE(sc)

yes

Cancel request

Sig. conn. active?

yes

RELEASE(sc) ccCancel.inv

DISCONNECT ccPathReserve.err

SETUP(sc) ccCancel.inv

PROGRESS ccPathReserve.res CC-Invoked-User-B CC-Path-Complete

Delete CC request

Sig. conn. active? no

yes RELEASE (sc)

CC-Idle

F i g u r e D . 1 6 - T e r m i n a t i n g P IN X b e h a v i o u r ( c o n t i n u e d )

- 71 -

Annex E ( in f o r ma tiv e )

Bibliography

ITU-T Rec. Q.953.3

Completion of Calls to Busy Subscribers (6/1997)

- 72 -

- 73 -

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 third edition of ECMA-186, i.e. based on ITU-T Recommendations X.208 / X.209. Starting with the fourth edition the ASN.1 modules within ECMA-186 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 - S S - C C - 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 SS-CC-Operations { iso (1) standard (0) pss1-call-completion (13870) 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(1)standard (0) pss1-generic-procedures (11582) msi-definition (0)} PSS1InformationElement FROM pss1-generic-parameters-definition { iso (1) standard (0) pss1-generic-procedures (11582) pss1-generic-parameters (6)} PartyNumber, PartySubaddress, PresentedNumberUnscreened FROM Addressing-Data-Elements {iso(1) standard (0) pss1-generic-procedures (11582) addressing-data-elements (9)} supplementaryServiceInteractionNotAllowed FROM General-Error-List { ccitt (0) recommendation (0) q 950 general-error-list (1) } ;

- 74 -

Ta b le F . 1 - S S - C C - 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 ) --TYPE DEFINITIONS FOR CC OPERATIONS AND ERRORS FOLLOW CcbsRequest ::= OPERATION ARGUMENT CcRequestArg RESULT CcRequestRes ERRORS{ shortTermRejection, longTermRejection, unspecified, supplementaryServiceInteractionNotAllowed } CcnrRequest ::= OPERATION ARGUMENT CcRequestArg RESULT CcRequestRes ERRORS{ shortTermRejection, longTermRejection, unspecified , supplementaryServiceInteractionNotAllowed } CcCancel ::= OPERATION ARGUMENT CcOptionalArg CcExecPossible ::= OPERATION ARGUMENT CcOptionalArg CcPathReserve ::= OPERATION ARGUMENT CcExtension RESULT CcExtension ERRORS { remoteUserBusyAgain, failureToMatch, failedDueToInterworking, unspecified }

- 75 -

Ta b le F . 1 - S S - C C - 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 ) (continued)CcRingout ::= OPERATION ARGUMENT CcExtension ERRORS{ remoteUserBusyAgain, failureToMatch, unspecified } CcSuspend ::= OPERATION ARGUMENT CcExtension CcResume ::= OPERATION ARGUMENT CcExtension Unspecified ::= ERROR PARAMETER Extension -- TYPE DEFINITIONS FOR CC DATA TYPES FOLLOW CcRequestArg ::= SEQUENCE { numberA numberB service

PresentedNumberUnscreened, PartyNumber, PSS1InformationElement, -- permitted information elements are: -- Bearer capability; -- Low layer compatibility; -- High layer compatibility -[10] PartySubaddress OPTIONAL, [11] PartySubaddress OPTIONAL, [12] IMPLICIT BOOLEAN DEFAULT FALSE, [13] IMPLICIT BOOLEAN OPTIONAL, -- TRUE: signalling connection to be retained; -- FALSE: signalling connection to be released; -- omission: release or retain signalling connection-CcExtension OPTIONAL }

subaddrA subaddrB can-retain-service retain-sig-connection

extension CcRequestRes ::= SEQUENCE{ no-path-reservation retain-service extension

[0] IMPLICIT BOOLEAN DEFAULT FALSE, [1] IMPLICIT BOOLEAN DEFAULT FALSE, CcExtension OPTIONAL }

- 76 -

Ta b le F . 1 - S S - C C - 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 ) CcOptionalArg ::= CHOICE{ fullArg

[0] IMPLICIT SEQUENCE { numberA PartyNumber, numberB PartyNumber, service PSS1InformationElement, -- permitted information elements are: -- Bearer capability; -- Low layer compatibility; -- High layer compatibility. subaddrA subaddrB extension

[10] PartySubaddress OPTIONAL, [11] PartySubaddress OPTIONAL, CcExtension OPTIONAL

}, CcExtension

extArg } CcExtension ::= CHOICE { none single multiple

NULL, [14] IMPLICIT Extension, [15] IMPLICIT SEQUENCE OF Extension

} --VALUE DEFINITIONS FOR OPERATIONS AND ERRORS FOLLOW ccbsRequest CcbsRequest ccnrRequest CcnrRequest ccCancel CcCancel ccExecPossible CcExecPossible ccPathReserve CcPathReserve ccRingout CcRingout ccSuspend CcSuspend ccResume CcResume shortTermRejection ERROR longTermRejection ERROR remoteUserBusyAgain ERROR failureToMatch ERROR failedDueToInterworking ERROR unspecified Unspecified END -- of SS-CC-Operations--

::= localValue 40 ::= localValue 27 ::= localValue 28 ::= localValue 29 ::= localValue 30 ::= localValue 31 ::= localValue 32 ::= localValue 33 ::= localValue 1010 ::= localValue 1011 ::= localValue 1012 ::= localValue 1013 ::= localValue 1014 ::= localValue 1008

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-186 — Private Integrated Services Network (PISN) - Inter-exchange signalling protocol - Call completion supplementary services (QSIG-CC) (December 2001)

Related documents