Conceptio › Archive › ECMA International

ECMA Internationalopen access

ECMA-192 — Private Integrated Services Network (PISN) - Inter-exchange signalling protocol - Call offer supplementary service (QSIG-CO) (December 2001)

ECMA International · ECMA International

ECMA International · Standards · License: Open Access

co ecma ecmainternational exchange integrated inter network pisn

ecma, standard, ecma international, specification, ecma-192, ecma 192, 192, private, integrated, services, network, pisn, inter-exchange, signalling, protocol, call, offer, supplementary, service, qsig-co

S tandard ECMA-192

4th Edition - December 2001

Standardizing Information

and

Communication

Systems

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

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

S tandard ECMA-192

4th Edition - December 2001

Standardizing

Information

and

Communication

Systems

Private Integrated Services Network (PISN) Inter-Exchange Signalling Protocol Call Offer Supplementary Service (QSIG-CO)

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

Ecma-192.doc

14-01-02 09,37

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 Offer supplementary service. The protocol defined in this Standard forms part of the PSS1 protocol (informally known as QSIG). This Standard is based upon the practical experience of ECMA member companies and the results of their active and continuous participation in the work of ISO/IEC JTC1, ITU-T, ETSI and other international and national standardization bodies. It represents a pragmatic and widely based consensus. Compared to the 1st and 2nd Editions of Standard ECMA-192 (published by ECMA in June 1993 and December 1994 respectively), the 3rd Edition incorporated changes in order to achieve complete alignment with International Standard ISO/IEC 14843:1996(E) published by ISO/IEC in September 1996. Compared to the 3rd Edition of Standard ECMA-192 (published by ECMA in June 1997), this 4th Edition incorporates migration to ASN.1 version 1997.

Adopted as 4th Edition of Standard ECMA-192 by the General Assembly of December 2001.

- i -

Table of contents 1

Scope

Conformance

References (normative)

5 6

Definitions 4 . 1 E x te r n a l d e f in itio n s 4 . 2 O th e r d e f in itio n s 4.2.1 Inter-PINX link 4.2.2 Path retention 4.2.3 Served User PINX Acronyms Signalling protocol for the support of SS-CO 6 . 1 S S - CO d e s c r ip tio n 6 . 2 S S - CO 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 a n O r ig in a tin g P I N X 6.2.2 Re q u ir e me n ts o n a 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 - CO c o d in g r e q u ir e me n ts 6.3.1 Operations 6.3.2 Notifications 6.3.3 I n f o r ma t i o n e l e me n t s 6.3.4 Messages 6 . 4 S S - CO 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 - CO s ig n a llin g p r o c e d u r e s f o r a c tiv atio n , d e a c tiv a tio n a n d r e g is tr a tio n 6 . 6 S S - CO s ig n a llin g p r o c e d u r e s f o r in v o c a tio n a n d o p e r a tio n 6.6.1 Actions at the Originating PINX 6.6.2 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.6.3 Actions at a Transit PINX 6 . 7 S S - CO imp a c t o f in te r w o r k in g w ith p u b lic I S D N s 6 . 8 S S - CO imp a c t o f in te r w o r k in g w ith n o n - I S D N s 6 . 9 P r o to c o l in te r a c tio n s b e tw e e n S S - CO 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 I n t e r a c t i o n w i t h 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 I n t e r a c t i o n w i t h C o n n e c t e d 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 O N P ) 6.9.3 I n t e r a c t i o n w i t h C a l l C o mp l e t i o n t o B u s y S u b s c r i b e r ( S S - C C B S ) 6.9.4 I n t e r a c t i o n w i t h C a l l C o mp l e t i o n o n N o R e p ly ( S S - C C N R ) 6.9.5 Interaction with Call Transfer (SS-CT) 6.9.6 I n te r a c tio n w ith 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 )

2 2 2 2 3 3 3 3 3 3 3 3 3 4 4 6 7 7 7 7 7 7 7 8 8 10 10 10 10 10 10 10 10 10 11

- ii -

6.9.7 I n t e r a c t i o n w i t h C a l l F o r w a r d in g B u s y ( S S - C F B ) 6.9.8 I n te r a c tio n w ith Ca ll F o r w a r d in g N o Re p ly ( S S - CF N R) 6.9.9 I n t e r a c t i o n w i t h P a t h R e p l a c e me n t ( A N F - P R ) 6.9.10 Interaction with Do Not Disturb (SS-DND) 6.9.11 I n t e r a c t i o n w i t h D o N o t D is t u r b O v e r r i d e ( S S - D N D O ) 6.9.12 Interaction with Call Intrusion (SS-CI) 6.10 S S - C O 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 T 1

12 12 12 12 12 13 13 13

Annex A - Signalling protocol for the support of Path Retention

Annex B - Protocol Implementation Conformance Statement (PICS) proforma

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

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

Annex E - Imported ASN.1 definitions

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 Offer supplementary service (SS-CO) at the Q reference point between Private Integrated services Network eXchanges (PINXs) connected together within a Private Integrated Services Network (PISN). SS-CO is a supplementary service which, on request from the calling user (or on that user's behalf), enables a call to be offered to a busy called user and to wait for that called user to accept this call. 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-191. The signalling protocol for SS-CO operates on top of the signalling protocol for basic circuit switched call control, as specified in ECMA-143, and uses certain aspects of the generic procedures for the control of supplementary services specified in ECMA-165. This Standard also specifies additional signalling protocol requirements for the support of interactions at the Q reference point between SS-CO and other supplementary services and ANFs. NOTE Additional interactions that have no impact on the signalling protocol at the Q reference point can be found in the relevant stage 1 specifications. 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 B.

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

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

ECMA-142

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

ECMA-143

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

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

ECMA-177

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

- 2 -

ECMA-178

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

ECMA-191

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

ECMA-194

Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Do Not Disturb and Do Not Disturb Override Supplementary Services (International Standard ISO/IEC 14844)

ECMA-203

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

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 4.2.1

Application Protocol Data Unit (APDU)

(ECMA-165)

Basic Service

(ITU-T Rec. I.210)

Call, Basic Call

(ECMA-165)

Coordination Function

(ECMA-165)

Diverted-to PINX

(ECMA-174)

Notification

(ECMA-165)

Originating PINX

(ECMA-143)

Private Integrated Services Network (PISN)

(ECMA-133)

Private Integrated services Network eXchange (PINX)

(ECMA-133)

Rerouteing PINX

(ECMA-174)

Served User

(ECMA-174)

Signalling

(ITU-T Rec. I.112)

Supplementary Service

(ITU-T Rec. I.210)

Supplementary Services Control Entity

(ECMA-165)

Terminating PINX

(ECMA-143)

Transit PINX

(ECMA-143)

User

(ECMA-142)

Other definitions I n t e r - P I N X lin k The totality of a signalling channel and a number of user information channels at the Q reference point.

- 3 -

4.2.2

P a t h r e t e n t io n The retaining of the network connection between the Originating PINX and the Terminating PINX so that a supplementary service (such as SS-CO) can be invoked without establishing a new connection.

4.2.3

Served User PINX The PINX serving the served user.

Acronyms

ANF

Additional Network Feature

APDU

Application Protocol Data Unit

ASN.1

Abstract Syntax Notation no. 1

ISDN

Integrated Services Digital Network

NFE

Network Facility Extension

PICS

Protocol Implementation Conformance Statement

PINX

Private Integrated services Network eXchange

PISN

Private Integrated Services Network

SDL

Specification and Description Language

SS-CO

Call Offer supplementary service

Signalling protocol for the support of SS-CO

6.1

SS-CO description Call Offer (SS-CO) is a supplementary service which, on request from the calling user (or on that user's behalf), enables a call to be offered to a busy called user and to wait for that called user to accept this call. SS-CO is applicable to all circuit mode basic services defined in ECMA-142.

6.2 6.2.1

SS-CO operational requirements Requirements on an 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.

6.2.2

Requirements on a 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.

6.2.3

Requirements on a Transit PINX Basic call procedures specified in ECMA-143 for a Transit PINX shall apply. Generic procedures for the call-related control of supplementary services, as specified in ECMA-165 for a Transit PINX, shall apply. For SS-CO the requirements are limited to the passing on of Facility information elements for which the destination, as indicated in the NFE, is not the Transit PINX.

- 4 -

6.3

SS-CO coding requirements

6.3.1

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

Call-Offer-Operations-asn1-97 {iso(1) standard(0) pss1-call-offer(14843) call-offer-operations-asn1-97 (2) } 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)} notAvailable, supplementaryServiceInteractionNotAllowed FROM General-Error-List {ccitt recommendation q 950 general-error-list (1)};

Call-Offer-Operations OPERATION ::= { callOfferRequest | pathRetain | serviceAvailable | cfbOverride } pathRetain

OPERATION ::= { ARGUMENT PathRetainArg RETURN RESULT FALSE ALWAYS RESPONDS FALSE CODE local: 41} -- this operation may be used by other supplementary services -- using other values of argument

serviceAvailable

OPERATION ::= { ARGUMENT ServiceAvailableArg RETURN RESULT FALSE ALWAYS RESPONDS FALSE CODE local: 42} -- this operation may be used by other supplementary services -- using other values of argument

- 5 -

Table 1 - Operations in support of SS-CO (continued) callOfferRequest

OPERATION ::= { ARGUMENT DummyArg RESULT DummyRes ERRORS { notAvailable | notBusy | temporarilyUnavailable | supplementaryServiceInteractionNotAllowed | unspecified} CODE local: 34}

PathRetainArg

::=

CHOICE

{serviceList extendedServiceList serviceList extension } }

ServiceList, SEQUENCE{ ServiceList, Extension{{COExtSet}}

ServiceAvailableArg

::=

CHOICE

{serviceList extendedServiceList serviceList extension } }

ServiceList, SEQUENCE{ ServiceList, Extension{{COExtSet}}

ServiceList

::= BIT STRING {callOffer(0)} (SIZE(1..32)) -- bits other than callOffer(0) are reserved for -- other supplementary services

DummyArg

::=

DummyRes

::=

CHOICE{ null extension sequenceOfExtn

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

CHOICE{ null extension sequenceOfExtn

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

- 6 -

Table 1 - Operations in support of SS-CO (concluded) cfbOverride

OPERATION ::= { ARGUMENT DummyArg RETURN RESULT FALSE ALWAYS RESPONDS FALSE CODE local: 49} -- used in the interaction with Call Forwarding Busy

COExtSet EXTENSION ::= {…} notBusy

ERROR ::= { CODE local: 1009} -- used when an SS-CO request is received in -- a Terminating PINX and the called user is not busy

temporarilyUnavailable

ERROR ::= { CODE local: 1000} -- used when conditions for invocation of SS-CO -- are momentarily not met

unspecified

ERROR ::= { PARAMETER CODE

END 6.3.2

Extension{{ COExtSet}} local: 1008}

-- of Call-Offer-Operations-asn1-97 N o t if ic a t io n s The notification defined in Abstract Syntax Notation number 1 (ASN.1) in table 2 shall apply. Table 2 - Notification in support of SS-CO

Call-Offer-Notifications-asn1-97 {iso(1) standard(0) pss1-call-offer(14843) call-offer-notifications-asn1-97 (3)} DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS

NOTIFICATION FROM Notification-class-asn1-97 {iso(1) standard(0) pss1-generic-procedures(11582) notification-class-asn1-97(21)};

remoteUserAlerting

NOTIFICATION ::= { ARGUMENT CODE

Call-Offer-Notifications NOTIFICATION ::= { remoteUserAlerting } END

--of Call-Offer-Notifications-asn1-97

NULL local: 2000 }

- 7 -

6.3.3 Information elements 6.3.3.1 Facility information element APDUs of the operations defined in 6.3.1 shall be coded in the Facility information element in accordance with ECMA-165. When conveying an APDU of operation callOfferRequest, the NFE shall be included. When conveying the invoke APDU of operation callOfferRequest, the destinationEntity data element of the NFE shall contain value endPINX. When conveying the invoke APDU of operation callOfferRequest, the Interpretation APDU shall be omitted. NOTE Additional requirements for the conveyance of APDUs of operations pathRetain and serviceAvailable are given in A.3.2 of annex A. 6.3.3.2

N o t i f i c a t i o n i n d ic a t o r i n f o r m a t i o n e l e m e n t The notification defined above shall be coded in the Notification indicator information element in accordance with ECMA-165.

6.3.3.3

Other information elements Any other information elements (e.g. Cause, Progress indicator) shall be coded in accordance with the rules of ECMA-143.

6.3.4

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

6.4

SS-CO 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-CO functional entity in that PINX in association with a particular call.

6.4.1.1

S t a t e C O - I d le SS-CO is not operating.

6.4.1.2

S t a t e C O - W a it - A c k The Originating PINX has requested SS-CO and is waiting for an acknowledgement from the Terminating PINX.

6.4.2

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

6.4.2.1

S t a t e C O - I d le SS-CO is not operating.

6.4.2.2

State CO-Dest-Invoked SS-CO has been invoked successfully.

6.5

SS-CO signalling procedures for activation, deactivation and registration Not applicable.

6.6

SS-CO signalling procedures for invocation and operation The following procedures are call-associated.

- 8 -

SS-CO may be invoked in two ways depending on whether the network connection is retained when a call encounters a busy called user. Retention of the network connection makes use of a generic path retention mechanism, which is specified in annex A. Annex C contains some examples of message sequences. 6.6.1

A c t io n s a t t h e O r ig in a t in g P I N X For a given call, the Originating PINX shall choose one of the following two methods for invocation of SS-CO: – invocation without path retention; – invocation with path retention. For invocation with path retention, the procedures specified below apply in conjunction with the procedures specified in A.5.1 of annex A. For each method, if the basic call clears in circumstances other than those covered below, SS-CO shall terminate, any SS-CO timer shall be stopped, and state CO-Idle shall be entered (e.g. on calling user release, call failure, etc.). The SDL representation of procedures at the Originating PINX is shown in D.1 of annex D.

6.6.1.1

Normal procedures To invoke SS-CO the Originating PINX shall send a callOfferRequest invoke APDU, start timer T1 and enter state CO-Wait-Ack. For invocation without path retention, the APDU shall be sent in the SETUP message that establishes the call. For invocation with path retention, the APDU shall be sent in a FACILITY message using the call reference of a call for which the network connection has been retained in accordance with A.5.1 of annex A (Path Retention state PRTO-Retained) and for which the received serviceAvailable invoke APDU indicated that SS-CO is invokable. In state CO-Wait-Ack, on receipt of a callOfferRequest return result APDU in a PROGRESS, a FACILITY or an ALERTING message, the Originating PINX shall stop timer T1 and shall enter state CO-Idle. NOTE 1 Successful invocation of SS-CO should be indicated to the calling user. NOTE 2 The completion of SS-CO will be indicated by release of the call, receipt of an ALERTING or a CONNECT message (handled in accordance with ECMA-143) or receipt of a NOTIFY message containing notification description value "remoteUserAlerting" (handled in accordance with ECMA-165).

6.6.1.2

Ex c e p t io n a l p r o c e d u r e s In state CO-Wait-Ack, on receipt of: – any message containing a callOfferRequest return error or reject APDU; or – an ALERTING, CONNECT or DISCONNECT message without a callOfferRequest return result, return error or reject APDU, the Originating PINX shall stop timer T1 and enter state CO-Idle, and the call shall continue in accordance with ECMA-143. On expiry of timer T1 the Originating PINX shall enter state CO-Idle and the call shall continue in accordance with ECMA-143. NOTE Failure of SS-CO should be indicated to the calling user.

6.6.2

Actions at the Terminating PINX The Terminating PINX shall support the two methods of invocation. For invocation with path retention, the procedures specified below apply in conjunction with the procedures specified in A.5.2 of annex A.

- 9 -

For each method, if the basic call clears in circumstances other than those covered below, SS-CO shall terminate and state CO-Idle shall be entered. The SDL representation of procedures at the Terminating PINX is shown in D.2 of annex D. 6.6.2.1

Normal procedures If, while processing an incoming SETUP message in accordance with the procedures of ECMA-143, the called user is found to be busy, and if the SETUP message contained a callOfferRequest invoke APDU, and if all conditions are met to allow SS-CO on the called user, the Terminating PINX shall not send a DISCONNECT message but shall instead send a callOfferRequest return result APDU. If, having retained a network connection in accordance with A.5.2 of annex A and having indicated in the serviceAvailable invoke APDU that SS-CO is invokable, a FACILITY message is received containing a callOfferRequest invoke APDU, the Terminating PINX shall check again whether the called user is busy, and if so, and if SS-CO is still invokable, shall send a callOfferRequest return result APDU. On sending a callOfferRequest return result APDU, the Terminating PINX shall enter state CO-DestInvoked. NOTE The Terminating PINX should, by appropriate means, inform the called user that a call is waiting and allow the user to accept the call or ignore the call. On entering the state CO-Dest-Invoked, the Terminating PINX shall either enter protocol control state Call Received with the consequent sending of an ALERTING message, or shall remain in protocol control state Incoming Call Proceeding while the call is being offered to the called user. If an ALERTING message is not sent, the Terminating PINX shall send a PROGRESS message containing a Progress indicator information element containing Progress description no. 8 "in-band information or appropriate pattern now available", if in-band tone or announcement is applied to the incoming B channel or if Progress description no. 8 has not been sent earlier in the call. NOTE The Terminating PINX can apply in-band tone or announcement to the incoming B-channel at this stage. However, even if no in-band tone or announcement is applied, the Progress description no. 8 is still required to be sent unless an ALERTING message is sent or Progress indicator no. 8 has been sent earlier in the call as a means of ensuring that basic call timer T310 is stopped at other PINXs. If an ALERTING message is sent, it can contain a Progress indicator information element containing progress description no. 8 to indicate the presence of in-band tone or announcement. The return result APDU may be sent in the ALERTING or PROGRESS message. Otherwise it shall be sent separately in a FACILITY message. In state CO-Dest-Invoked, if the called user becomes free and alerting commences, the Terminating PINX shall send an ALERTING message if an ALERTING message has not been sent earlier or a NOTIFY message containing notification description value "remoteUserAlerting" if an ALERTING message has been sent earlier and shall enter state CO-Idle. In state CO-Dest-Invoked, if the called user accepts the waiting call, the Terminating PINX shall send a CONNECT message and shall enter state CO-Idle. In state CO-Dest-Invoked, if the called user rejects the waiting call, the Terminating PINX shall send a DISCONNECT message and shall enter state CO-Idle.

6.6.2.2

Ex c e p t io n a l p r o c e d u r e s On receipt of a SETUP or FACILITY message containing a callOfferRequest invoke APDU, if the called user is not busy the call shall continue in accordance with ECMA-143. The Terminating PINX shall return a callOfferRequest return error APDU containing error notBusy in the resulting ALERTING or CONNECT message and shall remain in state CO-Idle. NOTE If supplementary service Call Waiting has been invoked on the called user, the ALERTING message can also include a Notification indicator information element containing a notification description value "call is a waiting call".

- 10 -

On receipt of a SETUP or FACILITY message containing a callOfferRequest invoke APDU, if the called user is busy but invocation of SS-CO is not possible the call shall be released in accordance with ECMA-143 or, if continued retention of the path is required, shall continue in accordance with A.5.2. The Terminating PINX shall return a callOfferRequest return error APDU containing an error other than notBusy in the resulting DISCONNECT or FACILITY message and shall remain in state CO-Idle. 6.6.3

6.7

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

SS-CO impact of interworking with public ISDNs On a call to a PISN from a public ISDN that does not support an equivalent service, SS-CO will not be requested. On a call from a PISN to a public ISDN that does not support an equivalent service, the Outgoing Gateway PINX shall reject any request to invoke call offer by returning a callOfferRequest return error ADPU containing error "notAvailable" in a FACILITY message and shall remain in state CO-Idle. NOTE At the time of publication of this Standard, no equivalent service was specified for public ISDNs.

6.8

SS-CO impact of interworking with non-ISDNs When interworking with a non-ISDN which does not support an equivalent service, the procedures defined in sub-clause 6.7 for interworking with a public ISDN that does not support an equivalent service shall apply. When interworking with a non-ISDN which supports an equivalent service, the two networks may cooperate in the operation of SS-CO. In this case, either the Originating PINX functionality or the Terminating PINX functionality will be provided in the non-ISDN. The Incoming or Outgoing Gateway PINX shall provide conversion between the signalling protocol specified in this Standard and the signalling protocol of the other network.

6.9

Protocol interactions between SS-CO and other supplementary services and ANFs This clause specifies protocol interactions with other supplementary services and ANFs for which stage 3 standards had been published at the time of publication of this Standard. For interactions with supplementary services and ANFs for which stage 3 standards are published subsequent to the publication of this Standard, see those other stage 3 standards. NOTE 1 Additional interactions that have no impact on the signalling protocol at the Q reference point can be found in the relevant stage 1 specifications. NOTE 2 Simultaneous conveyance of APDUs for SS-CO and another supplementary service or ANF in the same message, each in accordance with the requirements of its respective stage 3 standard, does not, on its own, constitute a protocol interaction.

6.9.1

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

6.9.2

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

6.9.3

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

6.9.4

I n t e r a c t i o n wit h C a l l C o m p l e t i o n o n N o R e p l y ( S S - C C N R ) No protocol interaction.

6.9.5

I n t e r a c t io n wit h C a ll Tr a n s f e r ( S S - C T) The following protocol interactions shall apply if SS-CT is supported in accordance with ECMA-178.

- 11 -

6.9.5.1

I n it ia t io n o f C a ll Tr a n s f e r d u r in g C a ll O f f e r NOTE SS-CT already allows call transfer during alerting, i.e. when the Transferring PINX is in protocol control state Call Delivered.

6.9.5.1.1

Actions at the Transferring PINX If user A requests call transfer for two calls in which that user is involved, one of the calls (primary call) being in protocol control state Active and the other call (secondary call) in protocol control state Outgoing Call Proceeding and for which SS-CO has been successfully invoked, the actions at the Transferring PINX of SS-CT for transfer during alerting (i.e. when the secondary call is in protocol control state Call Delivered) shall apply.

6.9.5.1.2

A c t io n s a t t h e S e c o n d a r y P I N X A PINX shall treat as valid an APDU indicating that it is the Secondary PINX for SS-CT also if the protocol state is Incoming Call Proceeding and SS-CO has been successfully invoked.

6.9.5.2 N o t if ic a t io n s t o U s e r B o f S S - C T 6 . 9 . 5 . 2 . 1 A c t io n s a t t h e S e c o n d a r y P I N X f o r t r a n s f e r b y j o in If call transfer by join is performed and the Secondary PINX is also a SS-CO Terminating PINX in state CO-Dest-Invoked, the Secondary PINX may send a "call is a waiting call" notification, as defined in ECMA-165, in a Notification indicator information element in a NOTIFY message to the Primary PINX using the call reference on which the callTransferComplete invoke APDU was received. If this notification is not sent, then when user C of SS-CT becomes not busy, no remoteUserAlerting notification shall be sent. 6.9.5.2.2

6.9.6 6.9.6.1

Actions at the Secondary PINX for transfer by rerouteing If call transfer by rerouteing is performed and the Secondary PINX is also a SS-CO Terminating PINX in state CO-Dest-Invoked, the Secondary PINX may send a "call is a waiting call" notification, as defined in ECMA-165, in a Notification indicator information element in addition to the callTransferSetup return result in the ALERTING message to the Primary PINX. If this notification has been sent, the Secondary PINX shall send a remoteUserAlerting notification in a Notification indicator information element in a NOTIFY message to the Primary PINX when User C of SS-CT becomes not busy.

I n t e r a c t io n wit h C a ll F o r wa r d in g U n c o n d it io n a l ( S S - C F U ) The following protocol interactions shall apply if SS-CFU is supported in accordance with ECMA-174. A c t io n s a t t h e R e r o u t e in g P I N X When executing call forwarding, the Rerouteing PINX shall act as follows: – Include a callOfferRequest invoke APDU in the SETUP message to the Diverted-to PINX if either: • this was included in the SETUP message to the Diverting PINX and a callOfferRequest return error APDU has not been sent by the Diverting PINX to the Originating PINX; or • SS-CO was invoked successfully at the diverting user following path retention. – Include a pathRetain invoke APDU with callOffer bit set to ONE in the SETUP message to the Diverted-to PINX if and only if this was included in the SETUP message to the Diverting PINX and neither a callOfferRequest return result APDU nor a callOfferRequest return error APDU has been sent by the Diverting PINX to the Originating PINX. – Discard a callOfferRequest return result APDU or callOfferRequest return error APDU received from the Diverted-to PINX if a callOfferRequest invoke APDU has been sent by the Rerouteing PINX to the Diverted-to PINX and either a callOfferRequest return result APDU or callOfferRequest return error APDU has been sent by the Diverting PINX to the Originating PINX. NOTE This interaction takes into account the possible use of SS-CFU signalling in support of Call Deflection Immediate, which can be invoked following SS-CO.

- 12 -

6.9.6.2

6.9.7

A c t io n s a t t h e O r ig in a t in g P I N X In order to invoke SS-CO without path retention after a call has encountered a busy diverted-to user, the Originating PINX shall include a callOfferRequest invoke APDU in addition to the divertingLegInformation2 invoke APDU in the SETUP message of the new call to the diverted-to user. I n t e r a c t io n wit h C a ll F o r wa r d in g Bu s y ( S S - C F B) The following protocol interactions shall apply if SS-CFB is supported in accordance with ECMA-174.

6.9.7.1

A c t io n s a t t h e R e r o u t e in g P I N X On receiving a callRerouting invoke APDU, the Rerouteing PINX shall include in the SETUP message to the Diverted-to PINX any callOfferRequest invoke APDU or pathRetain invoke APDU with bit callOffer set to ONE that has been sent in the original SETUP message.

6.9.7.2

A c t io n s a t t h e O r ig in a t in g P I N X In order to invoke SS-CO without path retention directly at the last busy diverted-to user after a call has encountered two or more busy users that have been reached as a result of one or more invocations of SS-CFB, the Originating PINX shall include a callOfferRequest invoke APDU in addition to the divertingLegInformation2 invoke APDU in the SETUP message of the new call to the busy divertedto user. If SS-CO is to be invoked at the first busy user after a call has encountered two or more busy users that have been reached as a result of one or more invocations of SS-CFB, the Originating PINX shall act in one of the following ways: – In order to invoke SS-CO without path retention at the first busy user, thereby overriding SS-CFB at that user, the Originating PINX shall include a callOfferRequest invoke APDU and a cfbOverride invoke APDU in a Facility information element in the SETUP message of the new call. When conveying the invoke APDU of operation cfbOverride, the NFE shall be included as defined for operation callOfferRequest and the Interpretation APDU shall be included with value discardAnyUnrecognisedInvokePdu. – In order to invoke SS-CO with path retention at the first busy user, thereby overriding SS-CFB at that user, the Originating PINX shall include a pathRetain invoke APDU with bit callOffer set to ONE and a cfbOverride invoke APDU in a Facility information element in the SETUP message of the new call. When conveying the invoke APDU of operation cfbOverride, the NFE shall be included as defined for operation pathRetain and the Interpretation APDU shall be included with value discardAnyUnrecognisedInvokePdu.

6.9.7.3

A c t io n s a t t h e S e r v e d ( C a lle d ) U s e r P I N X On receiving a SETUP message containing a callOfferRequest invoke APDU together with a cfbOverride invoke APDU, if the called user is busy, SS-CFB shall be overridden and the procedures of SS-CO shall apply. On receiving a SETUP message containing a pathRetain invoke APDU with bit callOffer set to ONE together with a cfbOverride invoke APDU, if the called user is busy, SS-CFB shall be overridden and the procedures of SS-CO shall apply.

6.9.8

I n t e r a c t i o n wit h 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.9.9

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

6.9.10

I n t e r a c t i o n wit h D o N o t D i s t u r b ( S S - D N D ) No protocol interaction.

6.9.11

Interaction with Do Not Disturb Override (SS-DNDO) The following protocol interactions shall apply if SS-DNDO is supported in accordance with ECMA-194.

- 13 -

6.9.11.1

6.9.12

Actions at the Terminating PINX On receiving a SETUP message containing a callOfferRequest invoke APDU together with a doNotDisturbOverrideQ invoke APDU, the procedures of SS-DNDO shall apply and, if SS-DND is not active or is successfully overridden, the procedures of SS-CO shall apply.

I n t e r a c t i o n wit h C a l l I n t r u s i o n ( S S - C I ) The following protocol interactions shall apply if SS-CI is supported in accordance with ECMA-203.

6.9.12.1

A c t io n s a t t h e O r ig in a t in g P I N X While SS-CO is in progress, the Originating PINX may request SS-CI by sending a callIntrusionRequest invoke APDU in a FACILITY message during basic call protocol state Outgoing Call Proceeding or Call Delivered, starting timer T1 of SS-CI and entering state CI-Wait-Ack. The procedures of SS-CI shall then apply.

6.9.12.2 Actions at the Terminating PINX 6.9.12.2.1 Normal Procedures After SS-CO has been successfully invoked and prior to completion of SS-CO, on receipt of a callIntrusionRequest invoke APDU in a FACILITY message, the Terminating PINX shall act in accordance with SS-CI. NOTE If SS-CI is successfully invoked, SS-CO returns to state CO-Idle, since a CONNECT message is sent. 6 . 9 . 1 2 . 2 . 2 Ex c e p t io n a l P r o c e d u r e s The procedures of SS-CI shall apply. If SS-CI is rejected, SS-CO shall continue.

6.10 6.10.1

SS-CO parameter values (timers) Timer T1 Timer T1 shall operate at the Originating PINX during state CO-Wait-Ack. Its purpose is to protect against an absence of response to SS-CO invocation. Timer T1 shall have a value not less than 30 s.

- 14 -

- 15 -

Annex A ( n o r ma tiv e )

Signalling protocol for the support of Path Retention

This annex is applicable to Originating PINXs that support SS-CO with path retention and to Terminating PINXs that support SS-CO. A similar annex will appear in other standards that make use of the generic mechanism for path retention.

A.1

Path Retention description Path retention is a generic mechanism which can be used by supplementary services during call establishment. Path retention is invoked by the Originating PINX either for one supplementary service or for several supplementary services at the same time. Invocation for a particular supplementary service means that the network connection is to be retained if the Terminating PINX encounters conditions in which it is appropriate to invoke that supplementary service. The Originating PINX is informed of the reason for retaining the connection so that it can decide (e.g. by consulting the calling user) whether to invoke the supplementary service. Under some circumstances in which the network connection is retained, more than one of the supplementary services for which path retention has been invoked may be applicable. Successive retentions of the network connection by the Terminating PINX following a single invocation of path retention by the Originating PINX are possible as a result of different conditions being encountered at the Terminating PINX. When an attempt is made to invoke a supplementary service for which the network connection has been retained, a further condition can be encountered that can cause the network connection to be retained again for the same supplementary service or a different supplementary service. Path retention is specified in terms of a Path Retention entity existing within the Coordination Function at the Originating PINX and at the Terminating PINX.

A.2

Path Retention operational requirements

A.2.1

Requirements on the Originating PINX Call establishment procedures for the outgoing side of an inter-PINX link, 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.

A.2.2

Requirements on the Terminating PINX Call establishment procedures for the incoming side of an inter-PINX link, 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.

A.2.3

Requirements on a Transit PINX Call establishment procedures, as specified in ECMA-143, shall apply. Generic procedures for the call-related control of supplementary services, as specified in ECMA-165 for a Transit PINX, shall apply.

A.3

Path Retention coding requirements

A.3.1

Operations The operations pathRetain and serviceAvailable as defined in sub-clause 6.3.1 shall apply. Within the ARGUMENT of operation pathRetain, the element of type ServiceList may contain bits other than those

- 16 -

named in sub-clause 6.3.1, in order to request path retention for other supplementary services. Within the ARGUMENT of operation serviceAvailable, the element of type ServiceList may contain bits other than those named in sub-clause 6.3.1, in order to indicate retention of the network connection for other supplementary services.

A.3.2

Information elements APDUs of the operations pathRetain and serviceAvailable shall be coded in the Facility information element in accordance with ECMA-165. When conveying an APDU of operation pathRetain or serviceAvailable, the NFE shall be included. In the case of an invoke APDU the destinationEntity data element of the NFE shall contain value endPINX. When conveying an invoke APDU of operation pathRetain or serviceAvailable, the Interpretation APDU shall contain value discardAnyUnrecognisedInvokePdu.

A.3.3

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

A.4

Path Retention state definitions

A.4.1

States at the Originating PINX The procedures at the Originating PINX are written in terms of the following conceptual states existing within the Path Retention entity in that PINX in association with a particular call.

A . 4 . 1 . 1 P R TO - I d le Path retention is not operating. A . 4 . 1 . 2 P R TO - R e q u e s t e d A pathRetain invoke APDU has been sent and the Originating PINX is waiting for a serviceAvailable invoke APDU from the Terminating PINX. A . 4 . 1 . 3 P R TO - R e t a in e d A serviceAvailable invoke APDU has been received and the network connection is retained. A . 4 . 1 . 4 P R TO - I n v o k in g Invocation of a supplementary service is being attempted using a retained network connection.

A.4.2

States at the Terminating PINX The procedures at the Terminating PINX are written in terms of the following conceptual states existing within the Path Retention entity in that PINX in association with a particular incoming call.

A . 4 . 2 . 1 P R TT- I d le Path retention is not operating. A . 4 . 2 . 2 P R TT- R e q u e s t e d A pathRetain invoke APDU has been received and the Terminating PINX is waiting until conditions for retaining the network connection are encountered. A . 4 . 2 . 3 P R TT- R e t a in e d A serviceAvailable invoke APDU has been sent and the network connection is retained. A . 4 . 2 . 4 P R TT- I n v o k in g Invocation of a supplementary service is being attempted using a retained network connection.

A.5

Path Retention signalling procedures for invocation and operation

A.5.1

Actions at the Originating PINX The SDL representation of procedures at the Originating PINX is shown in A.9.1.

- 17 -

On sending a SETUP message for call establishment, if path retention is required for allowing the possibility of invoking one or more supplementary services on encountering certain conditions at the Terminating PINX, the Originating PINX shall include a pathRetain invoke APDU in the SETUP message and shall enter state PRTO-Requested. In the element of type ServiceList in the ARGUMENT, any bit corresponding to a supplementary service for which path retention is required shall be set to ONE and all other bits shall be set to ZERO. On receipt of a serviceAvailable invoke APDU in a PROGRESS or a FACILITY message in state PRTORequested, the Originating PINX shall enter state PRTO-Retained. In state PRTO-Requested, if the Originating PINX determines that retention of the network connection can no longer occur (e.g. on receipt of a CONNECT message), it shall enter state PRTO-Idle. During state PRTO-Retained, invocation of any of the supplementary services indicated in the serviceAvailable invoke APDU may be requested. If invocation is requested (by sending the appropriate APDU in a FACILITY message), the Terminating PINX shall enter state PRTO-Invoking. In state PRTO-Invoking, if the supplementary service concerned is successfully invoked, the Originating PINX shall either: i) if there is a possibility of the network connection being retained again prior to completion of call establishment (e.g. to allow for the possibility of invoking another supplementary service or for the possibility of invoking the same supplementary service again), enter state PRTO-Requested again; or ii) enter state PRTO-Idle. In state PRTO-Invoking, if the supplementary service concerned fails to be invoked successfully, the Originating PINX shall either: i) if the network connection is still retained to allow the possibility of invoking another supplementary service, enter state PRTO-Retained again; or ii) enter state PRTO-Idle. If, in any state other than PRTO-Idle, the call is released, state PRTO-Idle shall be entered.

A.5.2

Actions at the Terminating PINX The SDL representation of procedures at the Terminating PINX is shown in A.9.2. On receipt of a pathRetain invoke APDU in a SETUP message, the Terminating PINX shall enter state PRTT-Requested and record the list of supplementary services for which path retention has been requested, as indicated by the element of type ServiceList. If, during state PRTT-Requested, a condition is encountered in which it is appropriate to invoke one or more of the supplementary services for which path retention has been requested, the Terminating PINX shall retain the network connection, send a serviceAvailable invoke APDU to the Originating PINX, start timer PRT1 and enter state PRTT-Retained. In the element of type ServiceList in the ARGUMENT, any bit corresponding to a supplementary service that can be invoked at this stage and for which path retention has been requested shall be set to ONE and all other bits shall be set to ZERO. This procedure replaces the normal procedure appropriate to the condition that has been encountered. The serviceAvailable invoke APDU shall be sent either in a FACILITY message or, if a PROGRESS message is to be sent at the same time, in the PROGRESS message. A PROGRESS message containing a Progress indicator information element with Progress description no. 8 "in-band information or appropriate pattern now available" shall be sent if this Progress description has not already been sent for this call. NOTE It is necessary that this Progress description be sent, as a means of ensuring that basic call timer T310 is stopped at other PINXs. However, if this Progress description has already been sent in conjunction with an earlier serviceAvailable invoke APDU for this call, it need not be repeated. In state PRTT-Requested, if the Terminating PINX determines that retention of the network connection can no longer occur (e.g. on sending a CONNECT message), it shall enter state PRTT-Idle.

- 18 -

In state PRTT-Retained, on receipt of an invocation request from the Originating PINX for any of the supplementary services for which the network connection has been retained, the Terminating PINX shall stop timer PRT1 and enter state PRTT-Invoking. In state PRTT-Invoking, if the supplementary service concerned is successfully invoked, the Terminating PINX shall either: i) if there is a possibility of the network connection being retained again prior to completion of call establishment (e.g. to allow for the possibility of invoking another supplementary service or for the possibility of invoking the same supplementary service again), enter state PRTT-Requested again; or ii) enter state PRTT-Idle. In state PRTT-Invoking, if the supplementary service concerned fails to be invoked successfully, the Terminating PINX shall either: i) continue to retain the network connection, return to state PRTT-Retained and start timer PRT1 if there are other supplementary services for which the network connection has been retained and that are still able to be invoked; or ii) enter state PRTT-Idle and allow the call to proceed as specified for failure of the supplementary service concerned (e.g. initiate release of the call). In case i), any APDU sent to the Originating PINX to indicate failure of the requested supplementary service shall be sent in a FACILITY message. On expiry of timer PRT1, the Terminating PINX shall enter state PRTT-Idle and initiate call clearing in accordance with ECMA-143. If, in any state other than PRTT-Idle, the call is released, state PRTT-Idle shall be entered and timer PRT1, if running, shall be stopped.

A.5.3

Actions at a Transit PINX No special actions are required in support of path retention.

A.6

Path Retention impact of interworking with public ISDNs On a call from a public ISDN that does not support an equivalent mechanism, path retention shall not be requested by the Incoming Gateway PINX. On a call from a PISN to a public ISDN that does not support an equivalent mechanism, the Outgoing Gateway PINX shall, on encountering a condition in the public ISDN in which it is appropriate to invoke one or more of the supplementary services for which path retention has been requested, either: i) proceed as if path retention had not been requested; or ii) retain the network connection and allow invocation of the supplementary services concerned in accordance with A.5.2. NOTE 1 If invocation of a supplementary service is requested while the network connection is retained, the Outgoing Gateway PINX is responsible for establishing a new network connection through the public ISDN in order to request invocation of the supplementary service. Failure to establish a new network connection (e.g. because of network congestion) can cause the Outgoing Gateway PINX to reject the supplementary service and release the call. NOTE 2 At the time of publication of this Standard, no equivalent mechanism was specified for public ISDNs.

A.7

Path Retention impact of interworking with non-ISDNs When interworking with a non-ISDN that does not support an equivalent mechanism, the procedures defined in A.6 for interworking with a public ISDN that does not support an equivalent mechanism shall apply.

- 19 -

When interworking with a non-ISDN that does support an equivalent mechanism, the two networks may cooperate in the operation of path retention. In this case, either the Originating PINX functionality or the Terminating PINX functionality will be provided in the non-ISDN. The Incoming or Outgoing Gateway PINX shall provide conversion between the signalling protocol specified in this Standard and the signalling protocol of the other network.

A.8

Path Retention parameter values (timers) Timer PRT1 operates at the Terminating PINX during state PRTT-Retained. Its purpose is to protect against absence of a supplementary service invocation request as a response to the serviceAvailable invoke APDU. Timer PRT1 shall have a value not less than 60 s.

A.9

Specification and Description Language (SDL) - Representation of procedures (informative) The diagrams in this annex use the Specification and Description Language defined in ITU-T Rec. Z.100 (1999). Each diagram represents the behaviour of a Path Retention entity at a particular type of PINX. In accordance with the protocol model described in ECMA-165, the Path Retention entity as a part of the Coordination Function uses the services of Generic Functional Procedures Control and Basic Call Control and provides services to the various SS Control entities. Where an output symbol represents a primitive to other parts of the Coordination Function, and that primitive results in a PSS1 message being sent, the output symbol bears the name of the message and any remote operations APDU contained in that message. In case of a message specified in ECMA-143, basic call actions associated with the sending of that message are deemed to occur. Where an input symbol represents a primitive from other parts of the Coordination Function, and that primitive results from receipt of a PSS1 message, the input symbol bears the name of the message and any remote operations APDU contained in that message. In case of a message specified in ECMA-143, basic call actions associated with the receipt of that message are deemed to occur. The following abbreviation is used: inv.

A.9.1

invoke APDU

SDL representation of Path Retention at the Originating PINX Figure A.1 shows the behaviour of a Path Retention entity within the Originating PINX. In figure A.1 output signals to the right represent messages sent via protocol control, input signals from the right represent messages received via protocol control, and input signals from the left represent internal primitives.

- 20 -

F ig u r e A . 1 ( s h e e t 1 o f 2 ) - S D L r e p r e s e n t a t io n o f P a t h R e t e n t io n a t t h e O r ig in a t in g P I N X

- 21 -

F ig u r e A . 1 ( s h e e t 2 o f 2 ) - S D L r e p r e s e n t a t io n o f P a t h R e t e n t io n a t t h e O r ig in a t in g P I N X

A.9.2

SDL representation of Path Retention at the Terminating PINX Figure A.2 shows the behaviour of a Path Retention entity within the Terminating PINX. In figure A.2 output signals to the left represent messages sent via protocol control, input signals from the left represent messages received via protocol control, and input signals from the right represent internal primitives.

- 22 -

Figure A.2 (sheet 1 of 2) - SDL representation of Path Retention at the Terminating PINX

- 23 -

Figure A.2 (sheet 2 of 2) - SDL representation of Path Retention at the Terminating PINX

- 24 -

- 25 -

Annex B ( n o r ma tiv e )

Protocol Implementation Conformance Statement (PICS) proforma

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

B.2 B.2.1

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

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

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

o.<n>

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

prohibited;

c.<cond>

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

<item>:m

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

<item>:o

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

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

- 26 -

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

B.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 preprinted answer will be found in the Support column for this. Instead, the supplier is required to write into the support column an x.<i> reference to an item of Exception Information, and to provide the appropriate rationale in the Exception item itself. An implementation for which an Exception item is required in this way does not conform to this Standard. A possible reason for the situation described above is that a defect in the Standard has been reported, a correction for which is expected to change the requirement not met by the implementation.

- 27 -

B.3 B.3.1

PICS proforma for ECMA-192 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 suppliers terminology (e.g. Type, Series, Model).

B.3.2

Protocol summary Protocol version

1.0

Addenda implemented (if applicable) Amendments implemented Have any exception items been required (see B.2.3)?

Date of statement

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

- 28 -

B.3.3

General

Item

Question/feature

References

Status

N/A

Support

Support of SS-CO in Originating PINX

6.6.1

o.1

Yes [ ]

No [ ]

Support of SS-CO in Terminating PINX

6.6.2

o.1

Yes [ ]

No [ ]

Behaviour as Gateway to support SS-CO from user in PINX to user in public ISDN

6.7

Yes [ ]

No [ ]

Behaviour as Gateway to support SS-CO from user in PINX to user in other network

6.8

Yes [ ]

No [ ]

Behaviour as Gateway to support SS-CO from user in other network to user in PINX

6.8

Yes [ ]

No [ ]

References

Status

6.2.1, 6.2.2, 6.2.3

B.3.4

Procedures

Item

Question/feature

N/A

Support

Support of relevant ECMA-143 and ECMA-165 procedures

SS-CO invocation without path retention in Originating PINX

6.6.1

A1:o.2

[]

Yes [ ]

No [ ]

SS-CO invocation with path retention in Originating PINX

6.6.1, A.2.1, A.5.1

A1:o.2

[]

Yes [ ]

No [ ]

SS-CO invocation without path retention in Terminating PINX

6.6.2

A2:m

[]

Yes [ ]

SS-CO invocation with path retention in Terminating PINX

6.6.2, A.2.2, A.5.2

A2:m

[]

Yes [ ]

B.3.5

Yes [ ]

Coding

Item

Question/feature

References

Status

N/A

Support

Sending of callOfferRequest invoke APDU and receipt of callOfferRequest return result and error APDU in Originating PINX

6.3.1, 6.3.3.1 6.3.4

A1:m

[]

Yes [ ]

Sending of pathRetain invoke APDU and receipt of serviceAvailable invoke APDU in Originating PINX

6.3.1, A.3

B3:m

[]

Yes [ ]

Receipt of callOfferRequest invoke APDU and sending of callOfferRequest return result and error APDU in Terminating PINX

6.3.1, 6.3.3.1 6.3.4

A2:m

[]

Yes [ ]

Receipt of pathRetain invoke APDU and sending of serviceAvailable invoke APDU in Terminating PINX

6.3.1, A.3

A2:m

[]

Yes [ ]

Sending of notification "remoteUserAlerting" in Terminating PINX

6.3.2, 6.3.3.2 6.3.4

A2:o

[]

Yes [ ]

No [ ]

- 29 -

B.3.6 Item D1 D2

B.3.7 Item

Timers Question/feature Support of timer T1 Support of timer PRT1

References

Status

N/A

6.10

A1:m

[]

A.8

A2:m

[]

Support Yes [ ] Value [

]

Yes [ ] Value [

]

Protocol interactions with Call Transfer (SS-CT) Question/feature

Reference

Status

N/A

Support

Support of SS-CT (transfer by join)

Yes [ ] No [ ]

Support of SS-CT (transfer by rerouteing)

Yes [ ] No [ ]

Interactions at Initiation of SS-CT during SS-CO at Transferring PINX

6.9.5.1.1

c.1

[]

m: Yes [ ]

Interactions at Initiation of SS-CT during SS-CO at Secondary PINX

6.9.5.1.2

c.2

[]

m: Yes [ ]

Interactions between SS-CT by join and SSCO for notifications at Secondary PINX

6.9.5.2.1

c.3

[]

m: Yes [ ]

Interactions between SS-CT by rerouteing and SS-CO for notification at Secondary PINX

6.9.5.2.2

c.4

[]

m: Yes [ ]

c.1: if (A1 and E1) or (A1 and E2) then mandatory, else N/A c.2: if (A2 and E1) or (A2 and E2) then mandatory, else N/A c.3: If (A2 and E1) then mandatory, else N/A c.4: if (A2 and E2) then mandatory, else N/A

B.3.8 Item

Protocol interactions with Call Forwarding Unconditional (SS-CFU) Question/feature

Reference

Status

N/A

Support

Support of SS-CFU (Rerouteing PINX)

Yes [ ] No [ ]

Support of SS-CFU (Originating PINX)

Yes [ ] No [ ]

Interactions at Rerouteing PINX

6.9.6.1

F1:m

[]

m: Yes [ ]

Interactions at Originating PINX

6.9.6.2

c.1

[]

m: Yes [ ]

c.1: if (A1 and F2) then mandatory, else N/A

- 30 -

B.3.9 Item

Protocol interactions with Call Forwarding Busy (SS-CFB) Question/feature

Reference

Status

N/A

Support

Support of SS-CFB (Originating PINX)

Yes [ ] No [ ]

Support of SS-CFB (Rerouteing PINX)

Yes [ ] No [ ]

Support of SS-CFB (Served User PINX)

Yes [ ] No [ ]

Interactions at Rerouteing PINX

6.9.7.1

c.1

[]

m: Yes [ ]

Interactions at Originating PINX

6.9.7.2

c.2

[]

m: Yes [ ]

Interactions at Served User PINX

6.9.7.3

c.3

[]

m: Yes [ ]

c.1: if (A1 or A2) and F2 then mandatory, else N/A c.2: If (A1 and G1) then mandatory, else N/A c.3: if (A2 and G3) then mandatory, else N/A

B.3.10 Protocol interactions with Do Not Disturb Override (SS-DNDO) Item

Question/feature

Support of SS-DNDO (Terminating PINX)

Interactions at the Terminating PINX

Reference

Status

N/A

o 6.9.11.1

Support Yes [ ] No [ ]

c.1

[]

m: Yes [ ]

Status

N/A

Support

c.1: if (A2 and H1) then mandatory, else N/A

B.3.11 Protocol interactions with Call Intrusion (SS-CI) Item

Question/feature

Reference

Support of SS-CI (Originating PINX)

Yes [ ] No [ ]

Support of SS-CI (Terminating PINX)

Yes [ ] No [ ]

Interactions at the Originating PINX

6.9.12.1

c.1

[]

Yes [ ] No [ ]

Interactions at the Terminating PINX

6.9.12.2

c.2

[]

Yes [ ] No [ ]

c.1: if (A1 and I1) then optional, else N/A c.2: if (A2 and I2) then optional, else N/A

- 31 -

Annex C ( in f o r ma tiv e )

Examples of message sequences

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

The following notation is used:

Basic call message containing SS-CO information. Basic call message without SS-CO information. Symbolic primitive carrying SS-CO information. Symbolic primitive without SS-CO information. xxx.inv xxx.res xxx.err

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

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

Only the relevant information content (i.e., remote operation APDUs) is listed below each message name. The Facility information elements containing remote operation APDUs are not explicitly shown. Information with no impact on SS-CO is not shown.

Some interactions with users are included in the form of symbolic primitives. The actual protocol at the terminal interface is outside the scope of this Standard.

RELEASE, RELEASE COMPLETE messages are not shown.

The examples assume en-bloc sending.

The following abbreviations are used: coRequest

callOfferRequest

co request

SS-CO request

co confirm

SS-CO confirmation

co reject

SS-CO rejection

co indication

SS-CO indication

- 32 -

C.1

Example message sequence for normal operation of SS-CO without Path Retention In this example the coRequest return result APDU is sent in an ALERTING message.

Calling user

Originating P I NX

co request

co confirm

Transit P I NX

Terminating P I NX

SETUP coRequest.inv

CALL PROCEEDING

ALERTING coRequest.res

called user

co indication

(called user free) setup indication

alerting condition

connect indication

NOTIFY remoteUserAlerting

CONNECT

alerting request

connect request

F i g u r e C . 1 - M e s s a g e s e q u e n c e f o r n o r m a l o p e r a t i o n o f S S - C O wit h o u t P a t h R e t e n t i o n

- 33 -

C.2

Example message sequence for normal operation of SS-CO with Path Retention In this example the coRequest return result APDU is sent in a FACILITY message and the service completes when the called user is alerting. Calling user

Originating P I NX

Transit P I NX

SETUP pathRetain.inv (indicating SS-CO)

busy indication

co request

co confirm

alerting indication connect indication

Terminating P I NX

called user

SETUP pathRetain.inv (indicating SS-CO)

CALL PROCEEDING

PROGRESS

Progress indicator no. 8 serviceAvailable.inv (indicating that SS-CO is invokable)

FACILITY coRequest.inv

FACILITY coRequest.res

co indication

(called user free) setup indication

ALERTING

alerting request

CONNECT

connect request

F i g u r e C . 2 - M e s s a g e s e q u e n c e f o r n o r m a l o p e r a t i o n o f S S - C O wit h P a t h R e t e n t i o n

- 34 -

C.3

Example of unsuccessful invocation of SS-CO without Path Retention In this example the request of SS-CO is rejected by the Terminating PINX even though the called user is busy.

Calling user

Originating P I NX

Transit P I NX

SETUP coRequest.inv

co request

co reject

Terminating P I NX

called user

SETUP coRequest.inv

DISCONNECT

cause = busy coRequest.err

Figure C.3 - Message sequence for unsuccessful invocation of SS-CO

C.4

Example of unsuccessful invocation of Path Retention for SS-CO In this example the request for path retention for SS-CO is rejected by the Terminating PINX and there is no other supplementary service for which the path is retainable. Calling user

Originating P I NX

Transit P I NX

SETUP pathRetain.inv (indicating that SS-CO is invokable) busy indication

Terminating P I NX

called user

SETUP pathRetain.inv (indicating that SS-CO is invokable)

DISCONNECT

cause = busy

Figure C.4 - Message sequence for unsuccessful invocation of Path Retention for SS-CO

- 35 -

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 Recommendation Z.100 (1999). Each diagram represents the behaviour of an SS-?? Supplementary Service Control entity at a particular type of PINX. In accordance with the protocol model described in ECMA-165, the Supplementary Service Control entity uses, via the Coordination Function, the services of Generic Functional Transport Control and Basic Call Control. Where an output symbol represents a primitive to the Coordination Function, and that primitive results in a message being sent, the output symbol bears the name of the message and any remote operations APDU(s) or notification(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. Where an input symbol represents a primitive from the Coordination Function, and that primitive is the result of a message being received, the input symbol bears the name of the message and any remote operations APDU(s) or notification(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. The following abbreviations are used: inv.

invoke APDU

res.

return result APDU

err.

return error APDU

rej.

reject APDU

coRequest

callOfferRequest.

D.1

SDL representation of SS-CO at the Originating PINX Figure D.1 shows the behaviour of an SS-CO Supplementary Service Control entity within the Originating PINX. Input signals from the left and output signals to the left represent primitives from and to the user or an entity acting on behalf of the user. Input signals from the right and output signals to the right represent primitives from and to the coordination function in respect of messages sent and received. Also protocol timer expiry is indicated by an input signal from the right.

- 36 -

Process originating_ptnx

Page 1 (1)

, -* %#

! " # $%

0 12 -* %#

./ 0 12 1 -* %

! -* % ( -* %

" $) $ * ! +,

& '!

( $ ( $

Figure D.1 - Originating PINX SDL

D.2

SDL representation of SS-CO at the Terminating PINX Figure D.2 shows the behaviour of an SS-CO Supplementary Service Control entity within the Terminating PINX. Input signals from the right and output signals to the right represent primitives from and to the user.

- 37 -

Input signals from the left and output signals to the left represent primitives from and to the coordination function in respect of messages sent and received. Process terminating_ptnx

Page 1 (1)

' 1

( $ %

/ 2

! " #

( )' * '(

$% % #

/ 2

'( ''

&''

&+ &+

, - %

&''

, %

, . $

Figure D.2 - Terminating PINX SDL

/ ! #

' '$ 0. /0

- 38 -

- 39 -

Annex E ( 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.

- 40 -

- 41 -

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-192, i.e. based on ITU-T Recommendations X.208 / X.209. Starting with the fourth edition the ASN.1 modules within ECMA-192 comply with ITU-T Recommendations X.680 / X.690. Please note that regardless of which version of these modules is used as a base of a QSIG implementation, the line encoding remains unchanged. Changes in future editions to modules based on X.680 / X.690 ASN.1 are not reflected in the modules in this annex. Ta b le F . 1 - C a ll- O f f e r - O p e r a t io n s – b a s e d o n I TU - T R e c s . X . 2 0 8 / X . 2 0 9 Call-Offer-Operations {iso(1) standard(0) pss1-call-offer(14843) call-offer-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)} notAvailable, supplementaryServiceInteractionNotAllowed FROM General-Error-List {ccitt recommendation q 950 general-error-list (1)};

PathRetain

::=

OPERATION ARGUMENT PathRetainArg -- this operation may be used by other supplementary services -- using other values of argument

ServiceAvailable

::=

OPERATION ARGUMENT ServiceAvailableArg -- this operation may be used by other supplementary services -- using other values of argument

CallOfferRequest

::=

OPERATION ARGUMENT DummyArg RESULT DummyRes ERRORS { notAvailable, notBusy, temporarilyUnavailable, supplementaryServiceInteractionNotAllowed, unspecified}

- 42 -

Ta b le F . 1 - C a ll- O f f e r - O p e r a t io n s – b a s e d o n I TU - T R e c s . X . 2 0 8 / X . 2 0 9 ( c o n t in u e d ) PathRetainArg

::=

CHOICE

{serviceList ServiceList, extendedServiceList SEQUENCE{ serviceList ServiceList, extension Extension } }

ServiceAvailableArg

::=

CHOICE

{serviceList ServiceList, extendedServiceList SEQUENCE{ serviceList ServiceList, extension Extension } }

ServiceList

::= BIT STRING {callOffer(0)} (SIZE(1..32)) -- bits other than callOffer(0) are reserved for -- other supplementary services

DummyArg

::=

DummyRes

::=

CHOICE{ null NULL, extension sequenceOfExtn

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

null NULL, extension sequenceOfExtn

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

CHOICE{

CfbOverride

::=

OPERATION ARGUMENT DummyArg -- used in the interaction with Call Forwarding Busy

callOfferRequest pathRetain serviceAvailable cfbOverride notBusy

CallOfferRequest ::= 34 PathRetain ::= 41 ServiceAvailable ::= 42 CfbOverride ::= 49 ERROR ::= 1009 -- used when an SS-CO request is received in -- a Terminating PINX and the called user is not busy

temporarilyUnavailable

ERROR ::= 1000 -- used when conditions for invocation of SS-CO -- are momentarily not met

- 43 -

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

::=

ERROR PARAMETER Extension

unspecified

Unspecified ::= 1008

END

-- of Call-Offer-Operations Ta b le F . 2 - C a ll- O f f e r - N o t if ic 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 )

Call-Offer-Notifications {iso(1) standard(0) pss1-call-offer(14843) call-offer-notifications(1)} DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS

RemoteUserAlerting

remoteUserAlerting END

NOTIFICATION FROM Notification-macro {iso(1) standard(0) pss1-generic-procedures(11582) notification-macro(10)}; ::=

NOTIFICATION ARGUMENT

RemoteUserAlerting

::= 2000

--of Call-Offer-Notifications

NULL

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-192 — Private Integrated Services Network (PISN) - Inter-exchange signalling protocol - Call offer supplementary service (QSIG-CO) (December 2001)

Related documents