Conceptio › Archive › ECMA International

ECMA Internationalopen access

ECMA-176 — Private Integrated Services Network (PISN) - Inter-exchange signalling protocol - Path replacement additional network feature (QSIG-PR) (December 2001)

ECMA International · ECMA International

ECMA International · Standards · License: Open Access

additional ecma ecmainternational exchange feature integrated inter network

ecma, standard, ecma international, specification, ecma-176, ecma 176, 176, private, integrated, services, network, pisn, inter-exchange, signalling, protocol, path, replacement, additional, feature, qsig-pr

S tandard ECMA-176

4th Edition - December 2001

Standardizing Information

and

Communication

Systems

Private Integrated Services Network (PISN) Inter-Exchange Signalling Protocol Path Replacement Additional Network Feature

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

S tandard ECMA-176

4th Edition - December 2001

Standardizing

Information

and

Communication

Systems

Private Integrated Services Network (PISN) Inter-Exchange Signalling Protocol Path Replacement Additional Network Feature (QSIG-PR)

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

Ecma-176.doc

14-01-02 14,23

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 Path Replacement additional network feature. 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. The 3rd edition of this ECMA Standard was technically aligned with the 2nd Edition International Standard ISO/IEC 13874 published by ISO/IEC in January 1999. Compared to the 3rd Edition of Standard ECMA-176 (published by ECMA in December 1998), this 4th Edition incorporates migration to ASN.1 version 1997.

Adopted as 4th Edition of Standard ECMA-176 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 Branching PINX 4.2.2 Co o p e r a tin g P I N X 4.2.3 End PINX 4.2.4 Preceding PINX 4.2.5 Replaced connection 4.2.6 Re q u e s tin g P I N X 4.2.7 Retained connection 4.2.8 Subsequent PINX 4.2.9 I n v itin g P I N X

2 2 2 2 3 3 3 3 3 3 3 3

List of acronyms

Signalling protocol for the support of ANF-PR 6 . 1 A N F - P R d e s c r ip tio n 6 . 2 A N F - P R 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 Co o p e r a tin g P I N X 6.2.2 Re q u ir e me n ts o n th e Re q u e s 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.2.4 Re q u ir e me n ts o n th e I n v itin g P I N X 6 . 3 A N F - P R 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 A N F - P R s ta te d e f in itio n s 6.4.1 States at the Requesting PINX 6.4.2 S ta te s a t th e Co o p e r a tin g P I N X 6.4.3 S t a t e s a t a T r a n s i t P I N X o n t h e r e t a i n e d p a th , in c lu d in g th e b r a n c h in g P I N X 6.4.4 States at the Inviting PINX 6 . 5 A N F - P R s ig n a llin g p r o c e d u r e s 6.5.1 A c tio n s a t th e Re q u e s tin g P I N X 6.5.2 A c tio n s a t th e Co o p e r a tin g P I N X 6.5.3 A c tio n s a t a Co o p e r a tin g /Re q u e s tin g P I N X in th e c a s e o f a tr o mb o n e c o n n e c tio n 6.5.4 Actions at a Transit PINX 6.5.5 A c tio n s a t I n v itin g P I N X

3 3 4 4 4 4 5 6 6 9 10 10 10 10 11 11 11 11 13 14 14 14

- ii -

6 . 6 A N F - P R o p tio n a l s ig n a llin g p r o c e d u r e s f o r r e ten tio n o f p a r t o f th e o ld c o n n e c tio n 6.6.1 A c tio n s a t th e Re q u e s tin g P I N X 6.6.2 A c tio n s a t th e Co o p e r a tin g P I N X 6.6.3 A c tio n s a t a T r a n s it P I N X o n th e r e ta in e d c o n n e c tio n 6.6.4 Actions at a Transit PINX on the new connection or replaced connection 6.6.5 A c tio n s a t I n v itin g P I N X o n th e r e ta in e d c o n n e c tio n 6 . 7 A N F - P R 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 A N F - P R 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 A N F - P 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 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 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 - C C B S ) 6.9.4 I n te r a c tio n w ith Co mp le tio n o f Ca lls o n N o Re p ly ( S S - CCN 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 ) 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 Interaction with Call Deflection (SS-CD) 6.10 A N F - P R 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 6.10.2 T i me r T 2 6.10.3 T i me r T 3 6.10.4 T i me r T 4

14 14 15 15 17 17 17 17 18 18 18 18 18 18 19 19 19 19 20 20 20 20 20

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

Annex B - Imported ASN.1 definitions

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

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

A n n e x E - 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 Path Replacement additional network feature (ANF-PR) at the Q reference point between Private Integrated services Network eXchanges (PINXs) connected together within a Private Integrated Services Network (PISN). ANF-PR is a feature which applies to an established call, allowing that call's connection between PINXs to be replaced by a new connection. 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-175. The signalling protocol for ANF-PR 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 ANF-PR 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 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-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-175

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

ECMA-178

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

- 2 -

ECMA-225

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

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

− ANF-PR user

(ECMA-175)

− Application Protocol Data Unit (APDU)

(ECMA-165)

− Basic Service

(ITU-T Rec. I.210)

− Call, Basic Call

(ECMA-165)

− Connection

(ECMA-175)

− Incoming Gateway PINX

(ECMA-143)

− Interpretation APDU

(ECMA-165)

− Network Facility Extension (NFE)

(ECMA-165)

− New Connection

(ECMA-175)

− Old Connection

(ECMA-175)

− Originating PINX

(ECMA-143)

− 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 Services Control Entity

(ECMA-165)

− Terminating PINX

(ECMA-143)

− Transit PINX

(ECMA-143)

− Trombone Connection

(ECMA-175)

− User (except in the context of ANF-PR user)

(ECMA-142)

Other definitions Br a n c h in g P I N X The Transit PINX at which the retained connection finishes and the new connection starts.

- 3 -

4.2.2

C o o p e r a t in g P I N X The end PINX which initiates the establishment of the new connection towards other end PINX involved in the call.

4.2.3

En d P I N X Within the context of a call, a PINX which is not acting as a Transit PINX, i.e., an Originating PINX, a Terminating PINX, an Incoming Gateway PINX or an Outgoing Gateway PINX.

4.2.4

Preceding PINX The adjacent PINX in the direction of the Cooperating PINX, relative to a particular PINX involved in the old connection. NOTE 1 This can be the Cooperating PINX itself or a Transit PINX.

4.2.5

Replaced connection That part of the old connection which is not retained and is replaced by the new connection.

4.2.6

R e q u e s t in g P I N X The end PINX which invokes ANF-PR and towards which the new connection is routed.

4.2.7

Retained connection That part of the old connection which is retained and not replaced by the new connection.

4.2.8

Subsequent PINX The adjacent PINX in the direction of the Requesting PINX, relative to a particular PINX involved in the old connection. NOTE 2 This can be the Requesting PINX itself or a Transit PINX.

4.2.9

6 6.1

I n v it in g P I N X Any PINX in the connection that is associated with the ANF-PR user and able to request either end PINX to invoke ANF-PR.

List of acronyms ANF

Additional Network Feature

ANF-PR

Path Replacement 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-CT

Call Transfer supplementary service

Signalling protocol for the support of ANF-PR ANF-PR description ANF-PR is invoked by an established call, allowing that call's connection through the PISN to be replaced by a new connection. Optionally, the direction of the new connection may be decided by the ANF-PR user.

- 4 -

If the new connection is required to satisfy certain criteria, ANF-PR should be used in conjunction with other supplementary services and/or ANFs. In the absence of specific criteria, the new connection should be established using the routeing rules which apply to basic call establishment. NOTE 3 Annex A of ECMA-175 gives examples of the circumstances under which ANF-PR can be used and criteria which can govern the selection of the new connection. ANF-PR may be initiated locally at the Requesting PINX or optionally from an Inviting PINX. The Requesting PINX shall request the Cooperating PINX to attempt the establishment of a new connection from the Cooperating PINX to the Requesting PINX. If successful, the new connection shall replace the old connection. NOTE 4 The Requesting PINX can be either end PINX involved in a call, i.e., the Originating PINX or the Terminating PINX or, in the case of interworking with another network, the Incoming Gateway PINX or Outgoing Gateway PINX. Optional procedures and coding are specified for allowing the retention of one or more elements of the old connection, starting from the Cooperating PINX and continuing as far as a Transit PINX, subject to any given criteria being achievable in that way. A new connection is established from the Transit PINX to the Requesting PINX instead of from the Cooperating PINX to the Requesting PINX.

6.2 6.2.1

ANF-PR operational requirements Requirements on the Cooperating PINX ANF-PR shall be applicable to a call whose protocol control state, as defined in ECMA-143, is Active. NOTE 5 State Active will have been reached as a result of ECMA-143 call establishment procedures, possibly in conjunction with supplementary service and/or ANF procedures. ECMA-143 protocol control procedures for call establishment at the outgoing side of an inter-PINX link shall apply to the establishment of the new connection. ECMA-143 protocol control procedures for call clearing shall apply to the release of the old connection in the event of successful switch over to the new connection. 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 the Requesting PINX ANF-PR shall be applicable to a call whose protocol control state, as defined in ECMA-143, is Active. NOTE 6 State Active will have been reached as a result of ECMA-143 call establishment procedures, possibly in conjunction with supplementary service and/or ANF procedures. ECMA-143 protocol control procedures for call establishment at the incoming side of an inter-PINX link shall apply to the establishment of the new connection. ECMA-143 protocol control procedures for call clearing shall apply to the release of the old connection in the event of successful switch over to the new connection. 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 6.2.3.1 Tr a n s it P I N X in v o lv e d in t h e r e p la c e d c o n n e c t io n ANF-PR shall be applicable to a call whose protocol control state, as defined in ECMA-143, on each of the two links (incoming and outgoing) is Active and whose call control state, as defined in ECMA-143 is TCC_Call_Active. NOTE 7 State Active will have been reached as a result of ECMA-143 call establishment procedures, possibly in conjunction with supplementary service and/or ANF procedures.

- 5 -

ECMA-143 protocol control and call control procedures for call clearing at a Transit PINX shall apply to the release of the old connection in the event of successful switch over to the new connection. Generic procedures for the call-related control of supplementary services, as specified in ECMA-165 for a Transit PINX, shall apply. For ANF-PR the requirements are limited to the passing on of Facility information elements for which the destination, as indicated in the Network Facility Extension (NFE), is not the Transit PINX. 6.2.3.2

Tr a n s it P I N X in v o lv e d in t h e n e w c o n n e c t io n ECMA-143 protocol control and call control procedures for call establishment at a Transit PINX shall apply to the establishment of the new connection. ECMA-143 protocol control and call control procedures for call clearing at a Transit PINX shall apply to the release of the new connection in the event of failure to complete ANF-PR successfully. Generic procedures for the call-related control of supplementary services, as specified in ECMA-165 for a Transit PINX, shall apply. For ANF-PR the requirements are limited to the passing on of Facility information elements for which the destination, as indicated in the Network Facility Extension (NFE), is not the Transit PINX.

6.2.3.3

Tr a n s it P I N X in v o lv e d in t h e r e t a in e d c o n n e c t io n The procedures below are applicable only if the optional procedures for retention of part of the old connection (55) are supported. ANF-PR shall be applicable to a call whose protocol control state, as defined in ECMA-143, on each of the two links (incoming and outgoing) is Active and whose call control state, as defined in ECMA-143 is TCC_Call_Active. NOTE 8 State Active will have been reached as a result of ECMA-143 call establishment procedures, possibly in conjunction with supplementary service and/or ANF procedures. Generic procedures for the call-related control of supplementary services, as specified in ECMA-165 for a Transit PINX, shall apply.

6.2.3.4

Br a n c h in g P I N X The procedures below are applicable only if the optional procedures for retention of part of the old connection (55) are supported. ANF-PR shall be applicable to a call whose protocol control state, as defined in ECMA-143, on each of the two links (incoming and outgoing) is Active and whose call control state, as defined in ECMA143 is TCC_Call_Active. NOTE 9 State Active will have been reached as a result of ECMA-143 call establishment procedures, possibly in conjunction with supplementary service and/or ANF procedures. ECMA-143 protocol control procedures for call establishment at the outgoing side of an inter-PINX link shall apply to the establishment of the new connection. ECMA-143 protocol control procedures for call clearing shall apply to the release of the replaced connection in the event of successful switch over to the new connection. Generic procedures for the call-related control of supplementary services, as specified in ECMA-165 for a Transit PINX, shall apply.

6.2.4

Requirements on the Inviting PINX ANF-PR shall be applicable to a call whose protocol control state, as defined in ECMA-143, is Active. Generic procedures for the call-related control of supplementary services, as specified in ECMA-165 for an end PINX, shall apply.

- 6 -

6.3

ANF-PR 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 E. Table 1 - Operations in support of ANF-PR

Path-Replacement-Operations-asn1-97 {iso standard pss1-path-replacement (13874) pr-operations-asn1-97(1)} DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS

OPERATION, ERROR FROM Remote-Operations-Information-Objects {joint-iso-itu-t (2) remote-operations(4) informationObjects(5) version1(0)} EXTENSION, Extension{} FROM Manufacturer-specific-service-extension-class-asn1-97 {iso standard pss1-generic-procedures (11582) msi-class-asn1-97 (11)} notAvailable, supplementaryServiceInteractionNotAllowed FROM General-Error-List {ccitt recommendation q 950 general-error-list (1)} PartyNumber FROM Addressing-Data-Elements-asn1-97 {iso(1) standard(0) pss1-generic-procedures(11582) addressing-data-elements-asn1-97 (20)};

Path-Replacement-Operations OPERATION ::={ pathReplacePropose | pathReplaceSetup | pathReplaceRetain | pathReplaceInvite} pathReplaceInvite

OPERATION ::= { ARGUMENT DummyArg RETURN RESULT FALSE ERRORS { notAvailable | temporarilyUnavailable | supplementaryServiceInteractionNotAllowed | criteriaPermanentlyUnachievable | criteriaTemporarilyUnachievable | invalidRerouteingNumber | unrecognizedCallIdentity | establishmentFailure | collision | unspecified } ALWAYS RESPONDS FALSE CODE local: 86 }

- 7 -

Table 1 - Operations in support of ANF-PR (continued) pathReplacePropose

OPERATION ::= { ARGUMENT PRProposeArg RETURN RESULT FALSE ERRORS { notAvailable | temporarilyUnavailable | supplementaryServiceInteractionNotAllowed | criteriaPermanentlyUnachievable | criteriaTemporarilyUnachievable | invalidRerouteingNumber | unrecognizedCallIdentity | establishmentFailure | collision | unspecified } ALWAYS RESPONDS FALSE CODE local: 4 }

pathReplaceSetup

OPERATION ::= { ARGUMENT PRSetupArg RESULT DummyResult ERRORS { criteriaPermanentlyUnachievable | criteriaTemporarilyUnachievable | invalidRerouteingNumber | unrecognizedCallIdentity | temporarilyUnavailable | unspecified } CODE local: 5 }

pathReplaceRetain

OPERATION ::= { ARGUMENT PRRetainArg RESULT DummyResult ERRORS { notAvailable | temporarilyUnavailable | supplementaryServiceInteractionNotAllowed | criteriaPermanentlyUnachievable | criteriaTemporarilyUnachievable | invalidRerouteingNumber | unrecognizedCallIdentity | establishmentFailure | unspecified } CODE local: 6 }

- 8 -

Table 1 - Operations in support of ANF-PR (continued) PRProposeArg

::=

SEQUENCE { callIdentity CallIdentity, rerouteingNumber PartyNumber, extension CHOICE { single [1] IMPLICIT Extension{{PRExtSet}}, multiple [2] IMPLICIT SEQUENCE OF Extension{{PRExtSet}} } OPTIONAL }

PRSetupArg

::=

SEQUENCE { callIdentity CallIdentity, extension CHOICE { single [1] IMPLICIT Extension{{PRExtSet}}, multiple [2] IMPLICIT SEQUENCE OF Extension{{PRExtSet}} } OPTIONAL }

PRRetainArg

::=

SEQUENCE { callIdentity CallIdentity, rerouteingNumber PartyNumber, extension CHOICE { single [1] IMPLICIT Extension{{PRExtSet}}, multiple [2] IMPLICIT SEQUENCE OF Extension{{PRExtSet}} } OPTIONAL }

DummyResult

::=

CHOICE { null single multiple }

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

CHOICE { null single multiple }

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

DummyArg

::=

PRExtSet EXTENSION ::= {…} CallIdentity

::=

NumericString (SIZE(1..4))

temporarilyUnavailable

ERROR ::= {CODE local: 1000} -- used when the operation is temporarily not available and none of -- the other errors applies - a later attempt could be successful

collision

ERROR ::= {CODE local: 1001} -- used when a pathReplacePropose invoke APDU is received by a PINX -- which has sent a pathReplacePropose invoke APDU

- 9 -

Table 1 - Operations in support of ANF-PR (concluded) criteriaPermanentlyUnachievable ERROR ::= {CODE local: 1002} -- used when the special criteria requested cannot be achieved -- because the necessary resources are permanently unavailable criteriaTemporarilyUnachievable ERROR ::= {CODE local: 1003} -- used when the special criteria requested cannot be achieved -- because the necessary resources are temporarily unavailable -- a later attempt could be successful invalidRerouteingNumber

ERROR ::= {CODE local: 1004} -- used when the establishment of the new connection fails because the -- Called party number information element is not a valid number for -- routeing the new connection to

unrecognizedCallIdentity

ERROR ::= {CODE local: 1005} -- used when establishment of the new connection fails because it could -- not be associated with the old connection at the Requesting PINX

establishmentFailure

ERROR ::= {CODE local: 1006} -- used when establishment of the new connection fails and no other error -- applies

unspecified

ERROR ::= { PARAMETER Extension{{PRExtSet}} CODE local: 1008} -- used to convey a manufacturer specific error, possibly with other information -- of Path-Replacement-Operations

END -- of Path-Replacement-Operations-asn1-97

6.3.2 Information elements 6.3.2.1 Facility information element APDUs of the operations defined in 6.3.1 shall be coded in the Facility information element in accordance with ECMA-165. When conveying the invoke APDU of operation pathReplaceInvite, the NFE shall be included and the destinationEntity data element of the NFE shall contain value endPINX. When conveying APDUs of operations pathReplacePropose and pathReplaceSetup, the NFE shall be included. When conveying the invoke APDU of operation pathReplacePropose, the destinationEntity data element of the NFE shall contain value endPINX. When conveying the invoke APDU of operation pathReplaceSetup, the destinationEntity data element of the NFE shall contain value endPINX. When conveying the invoke APDU of operation pathReplaceRetain, the NFE shall be omitted. When conveying the invoke APDU of operation pathReplaceSetup, the Interpretation APDU shall be included and shall have the value clearCallIfAnyInvokePduNotRecognised. When conveying any

- 10 -

other Remote Operations APDU, the Interpretation APDU shall either be omitted or have the value rejectAnyUnrecognisedInvokePdu. 6.3.2.2

Other information elements The following information elements used during establishment of the new connection and release of the old connection shall be coded as specified in ECMA-143: − Bearer capability − Called party number − Cause − Sending complete The following information element shall be coded as specified in ECMA-225: − Transit Counter

6.3.3

Messages Except for cases where a basic call message is to be conveyed at the same time, the Facility information shall be conveyed in a FACILITY message as specified in ECMA-165. The following messages used during establishment of the new connection and release of the old connection shall be as specified in ECMA-143: − CALL PROCEEDING − CONNECT − CONNECT ACKNOWLEDGE − DISCONNECT − RELEASE − RELEASE COMPLETE − SETUP

6.4

ANF-PR state definitions

6.4.1

S t a t e s a t t h e R e q u e s t in g P I N X The procedures for the Requesting PINX are written in terms of the following conceptual states existing within the ANF-PR functional entity in that PINX in association with a particular call.

6.4.1.1

S t a t e P R - R e q - I d le ANF-PR is not operating.

6.4.1.2

S t a t e P R - R e q - I n it ia t e d A pathReplacePropose invoke APDU has been sent to the Cooperating PINX.

6.4.1.3

S t a t e P R - R e q - C o m p le t in g The new connection has been established and a pathReplaceSetup return result APDU has been sent to the Cooperating PINX.

6.4.2

S t a t e s a t t h e C o o p e r a t in g P I N X The procedures for the Cooperating PINX are written in terms of the following conceptual states existing within the ANF-PR functional entity in that PINX in association with a particular call.

6.4.2.1

S t a t e P R - C o o p - I d le ANF-PR is not operating.

6.4.2.2

S t a t e P R - C o o p - Es t a b lis h m e n t A pathReplaceSetup invoke APDU has been sent in conjunction with the establishment of the new connection.

- 11 -

6.4.2.3 6.4.3

S t a t e P R - C o o p - R e t a in A pathReplaceRetain invoke APDU has been sent to the subsequent PINX. S t a t e s a t a Tr a n s it P I N X o n t h e r e t a in e d p a t h , in c lu d in g t h e b r a n c h in g P I N X The procedures for a Transit PINX on the retained path are written in terms of the following conceptual states existing within the ANF-PR functional entity in that PINX in association with a particular call.

6.4.3.1

S t a t e P R - Tr a n s it - I d le ANF-PR is not operating.

6.4.3.2

S t a t e P R - Tr a n s it - Es t a b lis h m e n t A pathReplaceSetup invoke APDU has been sent in conjunction with the establishment of the new connection.

6.4.3.3

S t a t e P R - Tr a n s it - R e t a in A pathReplaceRetain invoke APDU has been sent to the subsequent PINX.

6.4.4 S t a t e s a t t h e I n v it in g P I N X 6.4.4.1 S t a t e P R - in v it e - I d le ANF-PR is not operating.

6.5

ANF-PR signalling procedures The signalling procedures specified below are in support of replacement of the entire connection. Additional optional procedures for retention of part of the old connection are specified in 6.6. Examples of message sequences are shown in C.1 to C.4 of annex C.

6.5.1

A c t io n s a t t h e R e q u e s t in g P I N X The SDL representation of procedures at the Requesting PINX is shown in D.2 of annex D.

6.5.1.1

A N F P R in it ia t e d b y t h e R e q u e s t in g P I N X The procedures of 6.5.1.3 and 6.5.1.4 shall apply.

6.5.1.2

Optional support of a request from an Inviting PINX On receipt of a FACILITY message containing a pathReplaceInvite invoke APDU, the Requesting PINX shall apply the procedures of 6.5.1.3 and 6.5.1.4 with the following additions. If the Requesting PINX is unable to act on the pathReplaceInvite invoke APDU while in state PRReq-Idle, a FACILITY message containing pathReplaceInvite return error APDU may be returned. No state change shall occur. While in state PR-Req-Initiated or PR-Req-Completing, a FACILITY message containing a pathReplaceInvite invoke shall be ignored. On receipt of a FACILITY message containing a pathReplacePropose return error while in state PRReq-Initiated, a pathReplaceInvite return error APDU may be returned to the Inviting PINX.

6.5.1.3

Normal procedures Examples of message sequences are shown in C.1 and C.3 of annex C. The Requesting PINX shall send a pathReplacePropose invoke APDU in a FACILITY message to the Cooperating PINX and enter state PR-Req-Initiated. Within the argument, the rerouteingNumber data element shall contain a number from one of the native number plans of the PISN (see ECMA-155). The number, when used as the contents of information element Called party number in a SETUP message, shall be sufficient to cause routeing of the new connection to the Requesting PINX. The callIdentity data element shall contain a number which, in conjunction with the rerouteingNumber data element, identifies the particular ANF-PR entity, and therefore the call on which ANF-PR is being invoked. This number need not have significance outside the Requesting PINX.

- 12 -

NOTE 10 The number in the callIdentity data element should be sufficient to distinguish the call concerned from any other call for which the PINX is acting as an ANF-PR Requesting PINX at that time. Having agreed the B-channel and sent back a CALL PROCEEDING message in response to an incoming SETUP message, in accordance with the procedures of ECMA-143, if the SETUP contains a pathReplaceSetup invoke APDU the Requesting PINX shall proceed as follows. If the callIdentity data element in the argument of pathReplaceSetup, in conjunction with the number information in the Called party number information element, identifies an ANF-PR entity in state PR-Req-Initiated, the Requesting PINX shall associate the new connection (as requested by the SETUP message) with the call on whose behalf that ANF-PR entity is acting. The Requesting PINX shall connect the calling / called user to the B-channel of the new connection and terminate the B-channel of the old connection in a suitable manner (pending its release). NOTE 11 The method of terminating the old connection's B-channel is an implementation matter. Annex B of ECMA-175 contains more information on this. A pathReplaceSetup return result APDU shall be sent in a CONNECT message using the call reference of the new connection and state PR-Req-Completing shall be entered. NOTE 12 On sending CONNECT, the protocol control state for the new connection will become Active. While in state PR-Req-Completing, if a DISCONNECT message is received using the call reference of the old connection, the Requesting PINX shall complete the release of the old connection in accordance with the procedures of ECMA-143, and enter state PR-Req-Idle. The call shall continue as an active call using the new connection. 6.5.1.4

Ex c e p t io n a l p r o c e d u r e s Examples of message sequences are shown in C.2 and C.4 of annex C. Receipt of a FACILITY message containing a pathReplacePropose return error APDU or reject APDU during state PR-Req-Initiated shall cause entry to state PR-Req-Idle, thereby abandoning ANF-PR. The call shall continue to use the old connection. NOTE 13 Depending on the error, it may be appropriate to invoke ANF-PR again later. If the error is collision, steps should be taken to reduce the probability of a further collision, e.g., by using a random delay before invoking again. Failure to associate an incoming SETUP message containing a pathReplaceSetup invoke APDU with an ANF-PR entity in state PR-Req-Initiated shall result in the sending of a DISCONNECT message to initiate the clearing of the new connection. Depending on implementation, the DISCONNECT message shall contain either: − a suitable cause number in the Cause information element, e.g., 1 "unallocated (unassigned) number"; or − cause number 29 "facility rejected" in the Cause information element and a return error APDU containing error invalidRerouteingNumber; or − cause number 29 "facility rejected" in the Cause information element and a return error APDU containing error unrecognizedCallIdentity. If the incoming SETUP message containing a pathReplaceSetup invoke APDU is successfully associated with an ANF-PR entity in state PR-Req-Initiated but the new connection is unsuitable for some reason, e.g., criteria not satisfied, a DISCONNECT message shall be sent to initiate clearing of the new connection. The DISCONNECT message shall contain cause number 29 "facility rejected" in the Cause information element and a return error APDU containing an appropriate error. The ANF-PR entity shall remain in state PR-Req-Initiated.

- 13 -

NOTE 14 Receipt of a pathReplacePropose return error APDU can be expected. On receipt of a FACILITY message containing a pathReplacePropose invoke APDU while in state PR-Req-Initiated, a pathReplacePropose return error APDU containing error collision shall be returned. No state change shall occur. NOTE 15 Receipt of a pathReplacePropose return error APDU containing error collision can be expected. While in state PR-Req-Completing, if a DISCONNECT message is received using the call reference of the new connection, the Requesting PINX shall complete the release of the new connection in accordance with the procedures of ECMA-143, reconnect the calling / called user to the B-channel of the old connection, and enter state PR-Req-Idle. 6.5.2 6.5.2.1

A c t io n s a t t h e C o o p e r a t in g P I N X The SDL representation of procedures at the Cooperating PINX is shown in D.3 of annex D. Normal procedures On receipt of a FACILITY message containing a pathReplacePropose invoke APDU while in protocol control state Active and ANF-PR state PR-Coop-Idle, the Cooperating PINX shall determine whether it can proceed with ANF-PR. If so, it shall attempt to establish a new connection by selecting an outgoing B-channel on a route determined by the contents of the rerouteingNumber data element within the received argument. If a B-channel is available, a SETUP message shall be sent using a new call reference in accordance with the procedures of ECMA-143. The SETUP shall contain a new call reference and the following information elements. − Bearer capability, containing bearer capability information as for the old connection; − Called party number, containing the number received in the rerouteingNumber data element within the - received argument; − Sending complete; − Facility; − Optionally, Transit Counter with the transit count field set to zero. The Facility information element shall contain a pathReplaceSetup invoke APDU. Within the argument, data element callIdentity shall have the same contents as the corresponding data element in the argument of the received pathReplacePropose invoke APDU. The Cooperating PINX shall terminate the new connection's B-channel suitably. NOTE 16 The method of terminating the new connection's B-channel is an implementation matter. Annex B of ECMA-175 contains more information on this. State PR-Coop-Establishment shall be entered. The protocol control procedures of ECMA-143 shall apply during the establishment of the new connection. NOTE 17 Initially protocol control will enter state Call Initiated. On receipt of a CALL PROCEEDING message, state Outgoing Call Proceeding will be entered and on receipt of CONNECT, state Active will be entered. On receipt of a CONNECT message (using the call reference of the new connection) containing a pathReplaceSetup return result APDU, the Cooperating PINX shall disconnect the B-channel of the old connection and connect the calling / called user instead to the B-channel of the new connection. A DISCONNECT message shall be sent using the call reference of the old connection, thereby initiating the clearing procedures of ECMA-143 for the old connection. State PR-Coop-Idle shall be entered. The call shall continue as an active call using the new connection.

- 14 -

6.5.2.2

Ex c e p t io n a l p r o c e d u r e s If the Cooperating PINX is unable to comply with the pathReplacePropose invoke APDU, it shall send back a FACILITY message containing a pathReplacePropose return error APDU with a suitable error. If the new connection fails to be established for any reason, the Cooperating PINX shall send using the old connection a FACILITY message containing a pathReplacePropose return error APDU with a suitable error. Reasons can include: − unable to select a B-channel for the new connection; − receipt of a call clearing message using the new connection's call reference without a pathReplaceSetup return error APDU or reject APDU; − receipt of a call clearing message using the new connection's call reference with a pathReplaceSetup return error APDU or reject APDU; − timer expiry at the Cooperating PINX. In each case state PR-Coop-Idle shall be entered and the call shall continue as an active call using the old connection. On receipt of a FACILITY message containing a pathReplaceInvite invoke APDU while in state PRCoop-Retain or PR-Coop-Establishment, a FACILITY message containing a pathReplaceInvite return error APDU may be returned to the Inviting PINX. No state change should occur.

6.5.3

A c t io n s a t a C o o p e r a t in g /R e q u e s t in g P I N X in t h e c a s e o f a t r o m b o n e c o n n e c t io n On receipt of a FACILITY message containing a pathReplacePropose invoke APDU, the Cooperating PINX can determine from the rerouteingNumber data element in the argument whether the Requesting PINX is the same as the Cooperating PINX, i.e., whether a trombone connection exists. In the case of a trombone connection, establishment of the new connection and switching over to it will be intra-PINX matters. The only further signalling which will occur at the Q reference point will be the clearing of the old connection.

6.5.4

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 ANF-PR.

6.5.5

A c t io n s a t I n v it in g P I N X The SDL representation of procedures at the Inviting PINX is shown in D.1 of annex D.

6.5.5.1

Normal procedures On determining that ANF-PR is to be invoked during a call whose protocol control state is Active, the Inviting PINX shall send a pathReplaceInvite invoke APDU in a FACILITY message to the Requesting PINX. If the old connection is cleared it shall be interpreted as ANF-PR is successful.

6.5.5.2

Ex c e p t io n a l p r o c e d u r e s On receipt of a FACILITY message containing a pathReplaceInvite return error or reject APDU the action shall be implementation dependent. NOTE 18 Depending on the error, it may be appropriate to invoke ANF-PR again later or invoke ANF-PR in the other direction. If the error is collision, steps should be taken to reduce the probability of a further collision, e.g., by using a random delay before invoking again.

6.6

ANF-PR optional connection

signalling

procedures

for

retention

Examples of message sequences are shown in C.5 to C.7 of annex C. 6.6.1

A c t io n s a t t h e R e q u e s t in g P I N X The procedures of 6.5.1 shall apply, with the following addition.

part

the

old

- 15 -

If the Requesting PINX receives a FACILITY message containing a pathReplaceRetain invoke APDU from the preceding PINX, it shall send back a FACILITY message containing a pathReplaceRetain return result APDU and enter state PR-Req-Idle. 6.6.2

6.6.2.1

A c t io n s a t t h e C o o p e r a t in g P I N X The SDL representation of procedures at the Cooperating PINX, including optional retention of part of the old connection, is shown in D.3 of annex D. Normal procedures On receipt of a FACILITY message containing a pathReplacePropose invoke APDU while in protocol control state Active and ANF-PR state PR-Coop-Idle, the Cooperating PINX shall determine whether it can proceed with ANF-PR, and whether it can retain that part of the old connection as far as the subsequent PINX while still meeting any given criteria. If so, it shall send a FACILITY message containing a pathReplaceRetain invoke APDU to the subsequent PINX and enter state PR-CoopRetain. The rerouteingNumber and callIdentity data elements shall have the same contents as the corresponding data elements received in the pathReplacePropose invoke APDU. NOTE 19 The omission of the NFE from the Facility information element ensures that the APDU will be processed by the subsequent PINX. If the subsequent PINX does not support these optional procedures it will send back a reject APDU. If it cannot retain that part of the old connection as far as the subsequent PINX it shall proceed according to the provisions of 6.5.2. On receipt of a FACILITY message containing a pathReplaceRetain return result APDU from the subsequent PINX, the Cooperating PINX shall enter state PR-Coop-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 FACILITY message containing a pathReplaceRetain return error APDU or reject APDU from the subsequent PINX while in state PR-Coop-Retain, the Cooperating PINX shall either, depending on the reason for the error or reject APDU: − proceed according to the provisions of 6.5.2, as if there had been no attempt to retain part of the old connection; or − send back a FACILITY message containing a pathReplacePropose return error APDU with a suitable error to the Requesting PINX and enter state PR-Coop-Idle.

6.6.3

A c t io n s a t a Tr a n s it P I N X o n t h e r e t a in e d c o n n e c t io n The SDL representation of procedures at a Transit PINX on the retained Connection is shown in D.4 of annex D. On receipt of a FACILITY message containing a pathReplaceRetain invoke APDU from the preceding PINX while in protocol control state Active and ANF-PR state PR-Transit-Idle, the Transit PINX shall determine whether it can retain that part of the old connection as far as the subsequent PINX while still meeting any given criteria.

6.6.3.1 A b le t o r e t a in o ld c o n n e c t io n a s f a r a s s u b s e q u e n t P I N X 6.6.3.1.1 Normal procedures If the Transit PINX determines that it can retain that part of the old connection as far as the subsequent PINX, it shall send a FACILITY message containing a pathReplaceRetain invoke APDU to the subsequent PINX and enter state PR-Transit-Retain. The rerouteingNumber and callIdentity data elements shall have the same contents as the corresponding data elements in the received pathReplaceRetain invoke APDU.

- 16 -

NOTE 20 The omission of the NFE from the Facility information element ensures that the APDU will be processed by the subsequent PINX. If the subsequent PINX does not support these optional procedures it will send back a reject APDU. On receipt of a FACILITY message containing a pathReplaceRetain return result APDU from the subsequent PINX while in state PR-Transit-Retain, the Transit PINX shall send a pathReplaceRetain return result APDU to the preceding PINX and enter state PR-Transit-Idle. 6.6.3.1.2

Ex c e p t io n a l p r o c e d u r e s On receipt of a FACILITY message containing a pathReplaceRetain return error APDU or reject APDU from the subsequent PINX while in state PR-Transit-Retain, the Transit PINX shall either, depending on the reason for the error or reject APDU: − proceed according to the provisions 6.6.3.2, as if there had been no attempt to retain the old connection as far as the subsequent PINX; or − send a pathReplaceRetain return error APDU to the preceding PINX and enter state PR-TransitIdle.

6.6.3.2 U n a b le t o r e t a in o ld c o n n e c t io n a s f a r a s s u b s e q u e n t P I N X 6.6.3.2.1 Normal procedures If the Transit PINX determines that it is unable to retain that part of the old connection as far as the subsequent PINX, it shall attempt to establish a new connection by selecting an outgoing B-channel on a route determined by the contents of the rerouteingNumber data element within the received argument. If a B-channel is available, a SETUP message shall be sent using a new call reference in accordance with the procedures of ECMA-143. The SETUP shall contain a new call reference and the following information elements. − Bearer capability, containing bearer capability information as for the old connection; − Called party number, containing the number received in the rerouteingNumber data element within the received argument; − Sending complete; − Facility; − Optionally, Transit Counter with the transit count field set to zero. The Facility information element shall contain a pathReplaceSetup invoke APDU. Within the argument, data element callIdentity shall have the same contents as the corresponding data element in the argument of the received pathReplaceRetain invoke APDU. The Transit PINX shall terminate the new connection's B-channel suitably. NOTE 21 The method of terminating the new connection's B-channel is an implementation matter. Annex B of ECMA-175 contains more information on this. State PR-Transit-Establishment shall be entered. The protocol control procedures of ECMA-143 shall apply during the establishment of the new connection. NOTE 22 Initially protocol control will enter state Call Initiated. On receipt of a CALL PROCEEDING message, state Outgoing Call Proceeding will be entered and on receipt of CONNECT, state Active will be entered. On receipt of a CONNECT message (using the call reference of the new connection) containing a pathReplaceSetup return result APDU, the Transit PINX shall disconnect the B-channel of the replaced connection and connect the B-channel of the retained connection instead to the B-channel of the new connection. A DISCONNECT message shall be sent using the call reference of the replaced connection, thereby initiating the clearing procedures of ECMA-143 for the replaced

- 17 -

connection. The Transit PINX shall send a FACILITY message containing a pathReplaceRetain return result APDU to the preceding PINX and enter state PR-Transit-Idle. The call shall continue as an active call using the new connection. 6.6.3.2.2

Ex c e p t io n a l p r o c e d u r e s If the Transit PINX is unable to comply with the pathReplaceRetain invoke APDU, it shall send back to the preceding PINX a FACILITY message containing a pathReplaceRetain return error APDU with a suitable error. If the new connection fails to be established for any reason, the Transit PINX shall send back to the preceding PINX a FACILITY message containing a pathReplaceRetain return error APDU with a suitable error. Reasons can include: − unable to select a B-channel for the new connection; − receipt of a call clearing message using the new connection's call reference without a pathReplaceSetup return error APDU or reject APDU; − receipt of a call clearing message using the new connection's call reference with a pathReplaceSetup return error APDU or reject APDU; − timer expiry at the Transit PINX. In each case state PR-Transit-Idle shall be entered and the call shall continue as an active call using the old connection.

6.6.4

A c t io n s a t a Tr a n s it P I N X o n t h e n e w c o n n e c t io n o r r e p la c e d c o n n e c t io n No special actions are required in support of ANF-PR.

6.6.5

A c t io n s a t I n v it in g P I N X o n t h e r e t a in e d c o n n e c t io n The SDL representation of procedures at the Inviting PINX is shown in D.1 of annex D.

6.6.5.1

Normal procedures If the Inviting PINX is on the old part of the connection that is not retained 6.5.5.1 shall apply. If the Inviting PINX is on the retained part of the connection and receives a FACILITY message containing a pathReplaceRetain return result APDU that shall be interpreted by the Inviting PINX as ANF-PR is successful.

6.6.5.2

6.7

Ex c e p t io n a l p r o c e d u r e s 6.5.5.2 shall apply.

ANF-PR impact of interworking with public ISDNs When interworking with a public ISDN which does not support an equivalent feature, the incoming or outgoing gateway PINX can act as the Cooperating PINX, Requesting PINX or Inviting PINX in order to perform ANF-PR within the PISN. NOTE 23 At the time of publication of this Standard, no equivalent feature in public ISDNs was envisaged.

6.8

ANF-PR impact of interworking with non-ISDNs When interworking with a non-ISDN which does not support an equivalent feature, the incoming or outgoing gateway PINX can act as the Cooperating PINX, Requesting PINX or Inviting PINX in order to perform ANF-PR within the PISN. When interworking with a non-ISDN which supports an equivalent feature, the two networks may cooperate in the operation of ANF-PR. In this case, either Cooperating PINX functionality or Requesting PINX functionality will be provided in the non-ISDN. The incoming or outgoing gateway PINXs on the old and new paths shall provide conversion between the signalling specified in this Standard and the signalling protocol of the non-ISDN. When interworking with a non-ISDN which supports an equivalent feature, the Requesting PINX shall be able to limit the length of the value of element callIdentity in accordance with the capabilities of the non-ISDN.

- 18 -

6.9

Protocol interactions between ANF-PR 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 24 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 25 Simultaneous conveyance of APDUs for ANF-PR 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 Completion of Calls 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 o m p l e t i o n o f C a l l s o n N o R e p l y ( S S - C C N R ) 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 interaction shall apply if SS-CT is supported in accordance with ECMA-178.

6.9.5.1 A c t io n s a t a n A N F - P R R e q u e s t in g P I N X 6 . 9 . 5 . 1 . 1 I n v o c a t io n o f C a ll Tr a n s f e r For the purpose of the requirements below, the following events shall be considered as invocation of SS-CT: − receipt of callTransferComplete invoke APDU; − receipt of callTransferIdentify invoke APDU; − receipt of callTransferInitiate invoke APDU; − invocation of Call Transfer by the local user. SS-CT shall be allowed to proceed normally if invoked while the PINX is acting as a Requesting PINX for ANF-PR. If SS-CT is invoked while in ANF-PR state PR-Req-Initiating, all signalling for SS-CT shall occur on the old path. If SS-CT is invoked while in ANF-PR state PR-ReqCompleting, all subsequent signalling for SS-CT shall be sent on the new path and received SS-CT signals shall be accepted from either path. A pathReplaceSetup invoke APDU shall be responded to with a return error APDU containing error temporarilyUnavailable if, since sending the pathReplacePropose invoke APDU, SS-CT has been invoked. NOTE 26 This will prevent switching over to the new path, so that all signalling for SS-CT can take place on the old path without risk of loss during switch over. 6.9.5.1.2

I n it ia t io n o f A N F - P R d u r in g C a ll Tr a n s f e r ANF-PR shall not be initiated while the PINX is acting as a Transferring PINX, a Primary PINX or a Secondary PINX during SS-CT.

- 19 -

6.9.5.2 A c t io n s a t a n A N F - P R C o o p e r a t in g P I N X 6 . 9 . 5 . 2 . 1 I n v o c a t io n o f C a ll Tr a n s f e r On receipt of a callTransferComplete, callTransferIdentify or callTransferInitiate invoke APDU while acting as an ANF-PR Cooperating PINX in ANF-PR state PR-Coop-Establishment or PRCoop-Retain, SS-CT shall be allowed to proceed normally using the old path for further signalling. As an exceptional procedure, if after receipt of a callTransferComplete, callTransferIdentify or callTransferInitiate invoke APDU while acting as an ANF-PR Cooperating PINX in ANF-PR state PR-Coop-Establishment or PR-Coop-Retain, the old path is released as a result of successful ANFPR before SS-CT signalling is complete, SS-CT shall be allowed to proceed normally using the new path for further signalling. NOTE 27 The Requesting PINX will normally abandon ANF-PR by sending back a pathReplaceSetup return error APDU because SS-CT has been invoked. Therefore switch over to a new path will not normally occur. While acting as an ANF-PR Cooperating PINX in ANF-PR state PR-Coop-Establishment, an SSCT invocation request from the local user shall be treated in one of the following ways: − reject the request for SS-CT; or − wait until ANF-PR is complete before processing the request for SS-CT; or − abort ANF-PR and proceed with SS-CT. To abort ANF-PR while in state PR-Coop-Establishment, the Cooperating PINX shall send a DISCONNECT message using the call reference of the new connection, thereby initiating the clearing procedures of ECMA-143 for the new connection, send a pathReplacePropose return error APDU with error value supplementaryServiceInteractionNotAllowed using the call reference of the old connection, and enter state PR-Coop-Idle. While acting as an ANF-PR Cooperating PINX in ANF-PR state PR-Coop-Retain, an SS-CT invocation request from the local user shall be treated in one of the following ways: − reject the request for SS-CT; or − wait until ANF-PR is complete before processing the request for SS-CT. 6.9.5.2.2

I n it ia t io n o f A N F - P R d u r in g C a ll Tr a n s f e r On receipt of a pathReplacePropose invoke APDU while acting as a Transferring PINX, a Primary PINX or a Secondary PINX during SS-CT, a pathReplacePropose return error APDU shall be sent. The error shall be temporarilyUnavailable.

6.9.6

I n t e r a c t io n wit h C a ll F o r wa r d in g U n c o n d it io n a l ( S S - C F U ) No protocol interaction.

6.9.7

I n t e r a c t io n wit h C a ll F o r wa r d in g Bu s y ( S S - C F B) No protocol interaction.

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 Call Deflection (SS-CD) The protocol interaction with Call Deflection Immediate shall be as specified in 6.9.6 for interaction with SS-CFU. The protocol interaction with Call Deflection from Alert shall be as specified in 6.9.8 for interaction with SS-CFNR.

- 20 -

6.10 6.10.1

ANF-PR parameter values (timers) Timer T1 Timer T1 shall operate at the Requesting PINX during state PR-Req-Initiated. Its purpose is to protect against the absence of a response to the pathReplacePropose invoke APDU. A response can be either a pathReplacePropose return error APDU or a pathReplaceSetup invoke APDU. Timer T1 shall be started on entering state PR-Req-Initiated and stopped on leaving that state. On expiry of timer T1, the Requesting PINX shall return to state PR-Req-Idle. The call shall continue as an active call using the old connection. Timer T1 shall have a value not less than 30s.

6.10.2

Timer T2 Timer T2 shall operate at the Requesting PINX during state PR-Req-Completing. Its purpose is to protect against failure to release the old connection. Timer T2 shall be started on entering state PR-Req-Completing and stopped on leaving that state. On expiry of timer T2, the Requesting PINX shall initiate clearing of the old connection by sending a DISCONNECT message with cause number 31 "normal, unspecified" and return to state PR-Req-Idle. The call shall continue as an active call using the new connection. Timer T2 shall have a value not less than 15s.

6.10.3

Timer T3 Timer T3 may optionally operate at the Cooperating PINX or a Transit PINX during state PR-CoopEstablishment or PR-Transit-Establishment respectively. Its purpose is to protect against failure to establish the new connection. NOTE 28 Alternatively an implementation can rely on basic call timers for this protection. Timer T3 shall be started on entering state PR-Coop-Establishment or PR-Transit-Establishment and stopped on leaving that state. On expiry of timer T3, the PINX shall clear the new connection using the procedures of ECMA-143, and continue according to the procedures of 6.5.2.2 or 6.6.3.2.2 of this Standard respectively. Timer T3 shall have a value not less than protocol control timer T310.

6.10.4

Timer T4 Timer T4 shall operate at the Cooperating PINX or a Transit PINX during state PR-Coop-Retain or PRTransit-Retain respectively. Its purpose is to protect against the absence of a response to the pathReplaceRetain invoke APDU. Timer T4 shall be started on entering state PR-Coop-Retain or PR-Transit-Retain and stopped on leaving that state. On expiry of timer T4, the PINX shall continue according to the procedures of 6.6.2.2 or 6.6.3.1.2 of this Standard respectively. Timer T4 shall have a value not less than 30s.

- 21 -

Annex A ( n o r ma tiv e )

Protocol Implementation Conformance Statement (PICS) proforma

A.1

Introduction The supplier of a protocol implementation which is claimed to conform to this Standard shall complete the following Protocol Implementation Conformance Statement (PICS) proforma. A completed PICS proforma is the PICS for the implementation in question. The PICS is a statement of which capabilities and options of the protocol have been implemented. The PICS can have a number of uses, including use: − 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 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).

- 22 -

A.2.2

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

- 23 -

A.3

PICS proforma for ECMA-176

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 suppliers terminology (e.g., Type, Series, Model).

A.3.2

Protocol summary Protocol version

1.0

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

Date of statement

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

- 24 -

A.3.3

General

Item

Question/feature

References

Status

N/A

Support

Behaviour as Cooperating PINX for ANF-PR

o.1

Yes [ ] No [ ]

Behaviour as Requesting PINX for ANF-PR

o.1

Yes [ ] No [ ] Conditions for invoking ANF-PR should be given as Additional Information

Behaviour as Transit PINX for ANF-PR

Behaviour as gateway PINX to another network which provides Cooperating PINX functionality

Behaviour as gateway PINX to another network which provides Requesting PINX functionality

Procedures for retaining part or all of the old connection

Behaviour as Inviting PINX for ANF-PR

o.1

Yes [ ] No [ ]

6.8

o.1

Yes [ ] No [ ]

6.8

o.1

Yes [ ] No [ ]

Are methods of avoiding “loss of user information” (as described in annex B of ECMA-175) supported at the Requesting PINX?

Yes [ ] No [ ]

Are methods of avoiding “loss of user information” (as described in annex B of ECMA-175) supported at the Cooperating/Branching PINX?

6.5.5

Please provide information regarding which methods are supported and for which basic services these methods are applicable. Yes [ ] No [ ] Please provide information regarding which methods are supported and for which basic services these methods are applicable.

- 25 -

A.3.4

Procedures

Item

Question/feature

References

Status

Support

Support of relevant ECMA-143 and ECMA-165 procedures at a Cooperating PINX

6.2.1

A1:m

[]

m: Yes[ ]

Support of relevant ECMA-143 and ECMA-165 procedures at a Requesting PINX

6.2.2

A2:m

[]

m: Yes[ ]

Support of relevant ECMA-143 and ECMA-165 procedures at a Transit PINX

6.2.3.1, 6.2.3.2

A3:m

[]

m: Yes[ ]

Support of relevant ECMA-143 and ECMA-165 procedures at a Transit PINX on a retained connection

6.2.3.3, 6.2.3.4

c.1

[]

m: Yes[ ]

Signalling procedures at a Cooperating PINX

6.5.2

A1:m

[]

m: Yes[ ]

Signalling procedures at a Requesting PINX

6.5.1.3,

A2:m

[]

m: Yes[ ]

6.5.1.4 B7

Signalling procedures at a Cooperating/Requesting PINX in the case of a trombone connection

6.5.3

c.2

[]

m: Yes[ ]

Additional signalling procedures at a Requesting PINX when whole of old connection is retained

6.6.1

c.4

[]

m: Yes[ ]

Additional signalling procedures at a Cooperating PINX for retention of part or all of the old connection

6.6.2

c.3

[]

m: Yes[ ]

B10

Additional signalling procedures at a Transit PINX for retention of part or all of the old connection

6.6.3

c.1

[]

m: Yes[ ]

B11

Signalling procedures at Inviting PINX

6.5.5

A7:m

[]

m: Yes[ ]

B12

Additional procedure for support of request from an Inviting PINX

6.5.1.2

A2:o

B13

Additional signalling procedure at Inviting PINX on retained part of the old connection

6.6.5

A7:m

c.1 c.2: c.3 c.4

if A3 and A6 then m else N/A if A1 and A2 then m else N/A if A1 and A6 then m else N/A if A2 and A6 then m else N/A

o: Yes[ ], No [ ] []

m: Yes[ ]

- 26 -

A.3.5

Coding

Item

Question/feature

References

Status

N/A

Support

Sending of pathReplacePropose invoke APDU and receipt of return error APDU

6.3.1, 6.3.2.1

c.1

[]

m: Yes[ ]

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

6.3.1, 6.3.2.1

c.2

[]

m: Yes[ ]

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

6.3.1, 6.3.2.1

c.3

[]

m: Yes[ ]

Receipt of pathReplacePropose invoke APDU and sending of return error APDU

6.3.1, 6.3.2.1

c.2

[]

m: Yes[ ]

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

6.3.1, 6.3.2.1

c.1

[]

m: Yes[ ]

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

6.3.1, 6.3.2.1

c.4

[]

m: Yes[ ]

Receipt of pathReplaceInvite invoke APDU

6.3.1, 6.3.2.1

A2:o

o: Yes[ ], No [ ]

Sending of pathReplaceInvite return error

6.3.1, 6.3.2.1

C7:o

o: Yes[ ], No [ ]

Sending of pathReplaceInvite invoke APDU and receipt of errors

6.3.1, 6.3.2.1

A7:m

[]

m: Yes[ ]

A.3.6

c.1:

if A2 or A5 then m else N/A

c.2:

if A1 or A4 then m else N/A

c.3:

if (A1 or A3 or A4) and A6 then m else N/A

c.4:

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

Timers

Item

Question/feature

References

Status

N/A

Support

Support of timer T1

6.10.1

A2:m

[]

m: Yes[ ]

Support of timer T2

6.10.2

A2:m

[]

m: Yes[ ]

Support of timer T3

6.10.3

c.1

[]

o: Yes[ ] No [ ]

Support of timer T4

6.10.4

c.2

[]

m: Yes[ ]

c.1:

if A1 or (A3 and A6) then o else N/A

c.2:

if (A1 or A3) and A6 then m else N/A

- 27 -

A.3.7

Protocol interactions with SS-CT

Item

Question/feature

Support of SS-CT

Interactions between SS-CT and ANF-PR at an ANF-PR Requesting PINX

6.9.5.1

c.1

[]

m: Yes [ ]

Interactions between SS-CT and ANF-PR at an ANF-PR Cooperating PINX

6.9.5.2

c.2

[]

m: Yes [ ]

c.1:

if E1 and A2 then m, else N/A

c.2:

if E1 and A1 then m, else N/A

References

Status

N/A

Support Yes [ ] No [ ]

- 28 -

- 29 -

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.

- 30 -

- 31 -

Annex C ( in f o r ma tiv e )

Examples of message sequences

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

xxx.inv xxx.rr xxx.re

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

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

- 32 -

C.1

Example message sequence for normal operation - invocation by Requesting PINX Figure C.1 shows an example of normal operation of ANF-PR. The old connection and the new connection are each shown passing through two Transit PINXs.

Requesting PINX

Old Connection

Transit PINX

Old Connection

Transit PINX

Old Connection

Cooperating PINX

Basic call in ac tiv e s tate

FACILITY

pathReplacePropose.inv

FACILITY

pathReplacePropose.inv

Transit PINX

New Connection

Transit PINX

SETUP

New Connection

pathReplaceSetup.inv

CALL PROCEEDING

pathReplaceSetup.inv

CALL PROCEEDING CALL PROCEEDING CONNECT

CONNECT

pathReplaceSetup.rr

CONNECT

pathReplaceSetup.rr

CONNECT ACKNOWLEDGE

Old Connection

pathReplaceSetup.rr

CONNECT ACKNOWLEDGE Transit PINX

Old Connection

Transit PINX

DISCONNECT DISCONNECT RELEASE RELEASE

RELEASE RELEASE

COMPLETE

CONNECT ACKNOWLEDGE Old Connection

DISCONNECT RELEASE

RELEASE COMPLETE

COMPLETE Basic call in ac tiv e s tate

F ig 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 io n o f A N F - P R - in v o c a t io n b y Requesting PINX

- 33 -

C.2

Example message sequence for case of congestion encountered at Transit PINX - invocation by Requesting PINX Figure C.2 shows an example of the operation of ANF-PR for the case where a Transit PINX on the new connection is unable to proceed with connection establishment, e.g., because of congestion. Consequently ANF-PR fails.

Requesting PINX

Old Connection Transit

PINX

Old Connection

Transit PINX

Old Connection

Cooperating PINX

Basic call in ac tive state

FACILITY

pathReplacePropose.inv

FACILITY

pathReplacePropose.inv

Transit PINX

New Connection

SETUP pathReplaceSetup.inv

CALL PROCEEDING DISCONNECT RELEASE RELEASE COMPLETE Old Connection

Transit PINX

Old Connection

Transit PINX

FACILITY FACILITY

Old Connection

FACILITY pathReplacePropose.re

pathReplacePropose.re

Basic call in ac tive state

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 c o n g e s t i o n c a s e o f A N F - P R - in v o c a t io n b y R e q u e s t in g P I N X

- 34 -

C.3

Example message sequence for normal operation - invocation by Inviting PINX Figure C.3 shows an example of normal operation of ANF-PR when it is invoked by an Inviting PINX. The old connection and the new connection are each shown passing through two transit PINXs, in which one is also an Inviting PINX.

Requesting PINX

Transit PINX

Old Connection

Inviting Old Connection PINX

Old Connection

Cooperating PINX

Basic c all in ac tive s tate FACILITY pathReplaceInvite.inv

FACILITY pathReplaceInvite.inv

FACILITY

pathReplacePropose.inv

FACILITY

pathReplacePropose.inv

Transit PINX

New Connection

Transit PINX

SETUP

SETUP SETUP

New Connection

pathReplaceSetup.inv

CALL PROCEEDING

pathReplaceSetup.inv

CALL PROCEEDING CALL PROCEEDING CONNECT

CONNECT

pathReplaceSetup.rr

CONNECT

pathReplaceSetup.rr

CONNECT

pathReplaceSetup.rr

CONNECT

ACKNOWLEDGE

Old Connection

Transit PINX

Old Connection

Transit PINX

DISCONNECT DISCONNECT RELEASE RELEASE

RELEASE RELEASE

COMPLETE

CONNECT ACKNOWLEDGE Old Connection

DISCONNECT RELEASE

RELEASE COMPLETE

COMPLETE Basic call in ac tiv e state

F ig u r e C . 3 - 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 io n o f A N F - P R - in v o c a t io n b y I n v it in g P I N X

- 35 -

C.4

Example message sequence for case of congestion encountered at transit PINX - invocation by Inviting PINX Figure C.4 shows an example of the operation of ANF-PR when a transit PINX on the new connection is unable to proceed with connection establishment, e.g., because of congestion. Consequently ANF-PR fails.

Requesting PINX

Old Connection

Transit PINX

Inviting Old Connection PINX

Old Connection

Cooperating PINX

Basic call in active state FACILITY pathReplaceInvite.inv

FACILITY pathReplaceInvite.inv

FACILITY

pathReplacePropose.inv

FACILITY

pathReplacePropose.inv

Transit New Connection PINX SETUP pathReplaceSetup.inv

CALL PROCEEDING DISCONNECT RELEASE RELEASE COMPLETE Old Connection

Transit PINX

Old Connection

Transit PINX

FACILITY FACILITY

Old Connection

FACILITY pathReplacePropose.re

pathReplacePropose.re

FACILITY pathReplaceInvite.re

Basic call in active state

F i g u r e C . 4 - M e s s a g e s e q u e n c e f o r c o n g e s t i o n c a s e o f A N F - P R - in v o c a t io n b y I n v it in g P I N X

- 36 -

C.5

Example message sequence for normal operation, retaining part of the old connection Figure C.5 shows an example of normal operation of ANF-PR with elements of the old connection retained as far as the first Transit PINX. The old connection and the new connection are each shown passing through one Transit PINX.

R equesting PINX

Transit PINX

Old Connection (replaced)

Transit PINX

Old Connection (replaced)

Cooperating PINX

Basic call in act ive state

FACILITY

pathReplacePropose.inv

FACILITY pathReplacePropose.inv

New Connection

Transit PINX

New Connection

FACILITY

SETU P SETUP pathReplaceSetup.inv

pathReplaceRetain.inv

pathReplaceSetup.inv

CAL L PROC EEDING

CALL PRO CEEDING CO NNECT

CO NNECT

pathReplaceSetup.rr

CON NECT AC KN OWLEDGE

CON NEC T AC KNO WLEDGE

FACI LITY pathReplaceRetain.rr

Old Connection

Transit PINX

Old Connection

DISCON NECT DISCON NECT RELEASE R ELEASE

RELEASE RELEASE C OMPLETE

COMPLETE

Basic call in act ive state

F i g u r e C . 5 - 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 A N F - P R , r e t a in in g p a r t o f t h e o ld connection

- 37 -

C.6

Example message sequence for case of congestion encountered at Transit PINX, after attempting to retain part of the old connection Figure C.6 shows an example of the operation of ANF-PR with elements of the old connection retained as far as the first Transit PINX (branching PINX), but with failure to establish the new connection beyond the second Transit PINX, e.g., because of congestion. The Cooperating PINX does not re-attempt ANF-PR using a completely new connection, and therefore ANF-PR fails.

Requesting PINX

Old Connection Transit (replaced) PINX

Old Connection

Transit PINX

Old Connection (retained)

Cooperating PINX

Basic call in active s tate

FACILITY FACILITY

pathReplacePropose.inv

FACILITY pathReplacePropose.inv

Transit New Connection PINX FACILITY SETUP pathReplaceSetup.inv

pathReplaceRetain.inv

CALL PROCEEDING

DISCONNECT RELEASE

FACILITY pathReplacePropose.re

RELEASE COMPLETE Old Connection Transit

PINX

Old Connection

FACILITY FACILITY

FACILITY

pathReplacePropose.re

Basic call in active s tate

Figure C.6 - Message sequence for congestion case, retaining part of the old connection

- 38 -

C.7

Example message sequence for normal operation, retaining all of the old connection Figure C.7 shows an example of normal operation of ANF-PR with the whole of the old connection retained.

Requesting PINX

Old Connection Transit (retained) PINX

Old Connection (retained)

Transit PINX

Old Connection (retained)

Cooperating PINX

Basic call in active state FACILITY pathReplacePropose.inv

FACILITY pathReplaceP ropose.inv

FACILITY pathReplacePropose.inv

FACILITY FACILITY FACILITY

pathReplaceRetain.inv

FACILITY pathReplaceRetain.rr

Basic call in active state

F ig u r e C . 7 - 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 io n o f A N F - P R , r e t a in in g a ll o f t h e o ld connection

- 39 -

Annex D ( in f o r ma tiv e )

Specification and Description Language (SDL) representation of procedures

The diagrams in this annex use the Specification and Description Language defined in ITU-T Recommendation Z.100 (1999). Each diagram represents the behaviour of an ANF-PR 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

prPropose

pathReplacePropose

prSetup

pathReplaceSetup

prRetain

pathReplaceRetain

rerouteingNumber

callIdentity

- 40 -

D.1

SDL representation of ANF-PR at the Inviting PINX Figure D.1 shows the behaviour of an ANF-PR Supplementary Service Control entity within the Inviting PINX. Input signals from the right and output signals to the right represent primitives to and from the Coordination Function in respect of messages sent and received. Also protocol timer expiry and indications from basic call control are indicated by input signals from the right. Input signals from the left and output signals to the left represent stimuli between the ANF-PR Supplementary Service Control entity and the ANF-PR user.

PR-Invite-idle

Request for ANF-PR

FACILITY with prInvite err.

send FACILITY with prInvite inv.

ANF-PR unsuccessful

DISCONNECT old connection released (from local CC)

ANF-PR successful

To ANF-PR User

PR-Invite-idle

To ANF-PR User

PR-Invite-idle

F ig u r e D . 1 - I n v it in g P I N X S D L

- 41 -

D.2a SDL representation of ANF-PR at the Requesting PINX - invocation by Requesting PINX Figure D.2a shows the behaviour of an ANF-PR Supplementary Service Control entity within the Requesting PINX. Input signals from the right and output signals to the right represent primitives to and from the Coordination Function in respect of messages sent and received. Also protocol timer expiry and indications from basic call control are indicated by input signals from the right. Input signals from the left and output signals to the left represent stimuli between the ANF-PR Supplementary Service Control entity and the ANF-PR User. PR-Req-Idle

Initiate ANF-PR

Obt ain rN and cl Start T1

Send F ACILITY prPropose Inv.

PR-Req-Initiated

SETUP rcvd prSETUP Inv. matching rN/cl

Send DISCONNECT (new connection) prSetup err .

PR-Req-Initiated

FACILITY rcvd. prPropose err .

New connection acceptable?

T1 Expiry

Call Cleared

FACILITY rcvd. prRetain inv.

Send FACILITY prRetain rres.

Stop T 1

Y ANF-PR Unsuccessful

Stop T1

Switch to new B-channel Start T2

ANF-PR Unsuccessful

Stop T1

Send CONNECT (new connection) prSETUP res.

PR-ReqCompleting

DISCONNECT rcvd (old connection)

T2 Expiry

Stop T2

Send DISCONNECT (old connection)

Call Cleared

Stop T2

ANF-PR Successful

PR-Req-Idle

F ig u r e D . 2 a - R e q u e s t in g P I N X S D L

- 42 -

D.2b SDL representation of ANF-PR at the Requesting PINX - invocation by Inviting PINX Figure D.2b shows the behaviour of an ANF-PR Supplementary Service Control entity within the Requesting PINX being invoked by a Inviting PINX. Input signals from the right and output signals to the right represent primitives to and from the Coordination Function in respect of messages sent and received. Also protocol timer expiry and indications from basic call control are indicated by input signals from the right. Input signals from the left and output signals to the left represent messages between the ANF-PR Supplementary Service Control entity and the Inviting PINX. PR-Req-Idle

FACILITY rcvd prInvite inv.

ANF-PR available ?

Y Obtain rN and cl St art T1

send FACILITY prInvite err.

Send F ACILITY prPropose inv.

PR-Req-Idle

PR-Req-Initiated

SETUP rcvd prSETUP Inv. matching rN/cl

Send DISCONNECT (new connection) prSetup err .

PR-Req-Initiated

FACILITY rcvd. prPropose err.

New connection acceptable?

T1 Expiry

Call Cleared

FACILITY rcvd. prRetain inv.

Send FACILITY prRetain res.

Stop T1

Y send FACILITY prInvite err.

Stop T1

Switch t o new B-channel Start T2

send FACILITY prInvite err.

Stop T1

Send CONNECT (new connection) prSETUP res.

PR-ReqCompleting

DISCONNECT rcvd (old connection)

T2 Expiry

Stop T2

Send DISCONNECT (old connection)

Call Cleared

Stop T2

PR-Req-Idle

F ig u r e D . 2 b - R e q u e s t in g P I N X S D L

- 43 -

D.3

SDL representation of ANF-PR at the Cooperating PINX Figure D.3 shows the behaviour of an ANF-PR Supplementary Service Control entity within the Cooperating PINX. Input signals from the left and output signals to the left represent primitives to and from the Coordination Function in respect of messages sent and received. Input signals from the right represent protocol timer expiry and indications from basic call control. PR-Coop-Idle

FACILITY prPropose Inv . rcvd.

Able to proceed?

Y Y

Able to re-use old connection to next PINX ?

FACILITY rcvd. prRetain res.

T4 expiry

Send F ACILITY prRetain inv .

Send SETUP (new connection) prSetup inv .

Start T4

Start T3

PR-CoopRetain

PR-CoopEstablishment

FACILITY rcvd. prRetain err .

CONNECT rcvd. (new connection) prSetup res.

Failure to establish new connection

e.g. DISCONNECT , possibly containing prSetup err .

Stop T4 Switch to new B-chann el Sto p T3

Call cleared Able to establish new connection instead? Stop T4

Stop T3

T3 expiry

Send DISCONNECT (new connection)

Send DISCONNECT (old connection) Send F ACILITY (old connection) prPropose err .

Send F ACILITY prPropose err .

PR-Coop-Idle

F ig u r e D . 3 - C o o p e r a t in g P I N X S D L

Call cleared

Stop T3

- 44 -

D.4

SDL representation of ANF-PR at a Transit PINX on the retained connection Figure D.4 shows the behaviour of an ANF-PR Supplementary Service Control entity within a Transit PINX on the retained connection. Input signals from the left and output signals to the left represent primitives to and from the Coordination Function in respect of messages sent to and received from the subsequent PINX. Input signals from the right and output signals to the right represent primitives to and from the Coordination Function in respect of messages sent to and received from the preceding PINX. Also protocol timer expiry and indications from basic call control are indicated by input signals from the right. PR-T ransit-Idle

FACILITY prRetain Inv rcvd.

Able to proceed?

Y Y Send F ACILITY prRetain inv .

Able to re-use old connection to next PINX ?

N Send SETUP (new connection) prSetup inv .

St a r t T4

St a r t T3 PR-T ransitRetain

FACILITY rcvd. prRetain res.

Send F ACILITY prRetain res.

T4 expiry

N Send F ACILITY prPropose err .

St o p T4

CONNECT rcvd. (new connection) prSetup res.

St o p T4

Able to establish new connection instead? Call cleared

PR-TransitEstablishment

FACILITY rcvd. prRetain err .

Sw it ch t o n e w B- c ha n ne l St o p T3

Failure to establish new connection

T3 expiry

e.g. DISCONNECT , possibly containing prSetup err .

Y Send DISCONNECT (old connection)

St o p T3

Send F ACILITY prRetain res.

PR-T ransit-Idle

F ig u r e D . 4 - Tr a n s it P I N X S D L

Send DISCONNECT (new connection)

Send F ACILITY prRetain err .

Call cleared

St o p T3

- 45 -

Annex E ( 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-176, i.e. based on ITU-T Recommendations X.208 / X.209. Starting with the fourth edition the ASN.1 modules within ECMA-176 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. Table E.1 - Path-Replacement-Operations – based on ITU-T Recs. X.208 / X.209 Path-Replacement-Operations {iso standard pss1-path-replacement (13874) pr-operations (0)} DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS

OPERATION, ERROR FROM Remote-Operation-Notation {joint-iso-ccitt(2) remote-operations(4) notation (0)} Extension FROM Manufacturer-specific-service-extension-definition {iso standard pss1-generic-procedures (11582) msi-definition (0)} notAvailable, supplementaryServiceInteractionNotAllowed FROM General-Error-List {ccitt recommendation q 950 general-error-list (1)} PartyNumber FROM Addressing-Data-Elements {iso(1) standard(0) pss1-generic-procedures(11582) addressing-data-elements(9)};

PathReplaceInvite

::=

OPERATION ARGUMENT DummyArg ERRORS { notAvailable, temporarilyUnavailable, supplementaryServiceInteractionNotAllowed, criteriaPermanentlyUnachievable, criteriaTemporarilyUnachievable, invalidRerouteingNumber, unrecognizedCallIdentity, establishmentFailure, collision, unspecified }

- 46 -

T a b l e E . 1 - P a t h - R e p l a c e m e n t - O p e r a t i o n s – b a s ed o n I T U - T R e c s . X . 2 0 8 / X . 2 0 9 ( c o n t i n u e d ) PathReplacePropose

::=

OPERATION ARGUMENT PRProposeArg ERRORS { notAvailable, temporarilyUnavailable, supplementaryServiceInteractionNotAllowed, criteriaPermanentlyUnachievable, criteriaTemporarilyUnachievable, invalidRerouteingNumber, unrecognizedCallIdentity, establishmentFailure, collision, unspecified }

PathReplaceSetup

::=

OPERATION ARGUMENT PRSetupArg RESULT DummyResult ERRORS { criteriaPermanentlyUnachievable, criteriaTemporarilyUnachievable, invalidRerouteingNumber, unrecognizedCallIdentity, temporarilyUnavailable, unspecified }

PathReplaceRetain

::=

OPERATION ARGUMENT PRRetainArg RESULT DummyResult ERRORS { notAvailable, temporarilyUnavailable, supplementaryServiceInteractionNotAllowed, criteriaPermanentlyUnachievable, criteriaTemporarilyUnachievable, invalidRerouteingNumber, unrecognizedCallIdentity, establishmentFailure, unspecified }

- 47 -

T a b l e E . 1 - P a t h - R e p l a c e m e n t - O p e r a t i o n s – b a s ed o n I T U - T R e c s . X . 2 0 8 / X . 2 0 9 ( c o n t i n u e d ) PRProposeArg

::=

SEQUENCE { callIdentity CallIdentity, rerouteingNumber PartyNumber, extension CHOICE { [1] IMPLICIT Extension, [2] IMPLICIT SEQUENCE OF Extension } OPTIONAL }

PRSetupArg

::=

SEQUENCE { callIdentity CallIdentity, extension CHOICE { [1] IMPLICIT Extension, [2] IMPLICIT SEQUENCE OF Extension } OPTIONAL }

PRRetainArg

::=

SEQUENCE { callIdentity CallIdentity, rerouteingNumber PartyNumber, extension CHOICE { [1] IMPLICIT Extension, [2] IMPLICIT SEQUENCE OF Extension } OPTIONAL }

DummyResult

::=

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

DummyArg

::=

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

CallIdentity

::=

NumericString (SIZE(1..4))

pathReplacePropose pathReplaceSetup pathReplaceRetain pathReplaceInvite

PathReplacePropose ::= 4 PathReplaceSetup ::= 5 PathReplaceRetain ::= 6 PathReplaceInvite::= 86

- 48 -

Table E.1 - Path-Replacement-Operations – based on ITU-T Recs. X.208 / X.209 (concluded) temporarilyUnavailable ERROR ::= 1000 -- used when the operation is temporarily not available and none of -- the other errors applies - a later attempt could be successful collision

ERROR ::= 1001 -- used when a pathReplacePropose invoke APDU is received by a PINX -- which has sent a pathReplacePropose invoke APDU

criteriaPermanentlyUnachievable ERROR ::= 1002 -- used when the special criteria requested cannot be achieved -- because the necessary resources are permanently unavailable criteriaTemporarilyUnachievable ERROR ::= 1003 -- used when the special criteria requested cannot be achieved -- because the necessary resources are temporarily unavailable -- a later attempt could be successful invalidRerouteingNumber ERROR ::= 1004 -- used when the establishment of the new connection fails because the -- Called party number information element is not a valid number for -- routeing the new connection to unrecognizedCallIdentity ERROR ::= 1005 -- used when establishment of the new connection fails because it could -- not be associated with the old connection at the Requesting PINX establishmentFailure ERROR ::= 1006 -- used when establishment of the new connection fails and no other error -- applies Unspecified unspecified

END

::= ERROR PARAMETER Extension Unspecified ::= 1008 -- used to convey a manufacturer specific error, possibly with other information -- of Path-Replacement-Operations

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

+41 22 849.60.01 [email protected]

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

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

ECMA-176 — Private Integrated Services Network (PISN) - Inter-exchange signalling protocol - Path replacement additional network feature (QSIG-PR) (December 2001)

Related documents