Conceptio › Archive › ECMA International

ECMA Internationalopen access

ECMA-143 — Private Integrated Services Network (PISN) - Circuit mode bearer services - Inter-exchange signalling procedures and protocol (QSIG-BC) (December 2001)

ECMA International · ECMA International

ECMA International · Standards · License: Open Access

circuit ecma ecmainternational exchange integrated inter mode network

ecma, standard, ecma international, specification, ecma-143, ecma 143, 143, private, integrated, services, network, pisn, circuit, mode, bearer, inter-exchange, signalling, procedures, and, protocol, qsig-bc

S tandard ECMA-143

4th Edition - December 2001

Standardizing Information

and

Communication

Systems

Private Integrated Services Network (PISN) Circuit Mode Bearer Services Inter-Exchange Signalling Procedures and Protocol

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

S tandard ECMA-143

4th Edition - December 2001

Standardizing

Information

and

Communication

Systems

Private Integrated Services Network (PISN) Circuit Mode Bearer Services Inter-Exchange Signalling Procedures and Protocol (QSIG-BC)

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

Ecma-143.doc

14-01-02 13,52

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 defines the signalling protocol for use at the Q-reference point in support of bearer circuitswitched services. The protocol defined in this Standard forms part of the PSS1 protocol (informally known as QSIG). This Standard is based upon the practical experience of ECMA member companies and the results of their active and continuous participation in the work of ISO/IEC JTC1, ITU-T, ETSI and other international and national standardization bodies. It represents a pragmatic and widely based consensus. Compared to the 2nd Edition of Standard ECMA-143 (published by ECMA in December 1992), the 3rd Edition had been extended to include support for Multi-rate and changes had been incorporated in order to achieve complete alignment with International Standard ISO/IEC 11572:1996(E) published by ISO/IEC in December 1996, including amendment 1 and 2, and defect report 001. Compared to the 3rd Edition of Standard ECMA-143 (published by ECMA in June 1997), this 4th Edition is completely aligned with International Standard ISO/IEC 11572:2000(E) and corrigendum 001.

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

- i -

Table of contents 1

Scope

Conformance

References (normative)

Definitions Private Integrated Services Network (PISN) P r i v a t e I n t e g r a t e d s e r v i c e s N e tw o r k e X c h a n g e ( P I N X ) S id e , I n c o min g S id e a n d O u tg o in g S id e O u tg o in g Ca ll a n d I n c o min g Ca ll O r i g i n a t i n g P I N X , T e r mi n a t i n g P I N X a n d T r a n s i t P I N X G a t e w a y P I N X , I n c o min g G a t e w a y P I N X a n d O u t g o i n g G a t e w a y P I N X Preceding PINX and Subsequent PINX Inter-PINX link Ro u te Signalling Carriage Mechanism (SCM) U n r e c o g n is e d me s s a g e U n e x p e c t e d me s s a g e U n r e c o g n is e d in f o r ma tio n e le me n t I n f o r ma t i o n e l e me n t s w i t h i n v a l i d c o n te n t s

1 1 2 2 2 2 2 3 3 3 3 3 3 3 3

List of acronyms

General principles P r o to c o l mo d e l S e r v ic e s p r o v id e d to Ca ll Co n tr o l S e r v ic e s r e q u ir e d o f th e S ig n a l l i n g C a r r i a g e M e c h a n i s m

4 4 5 6

4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 5 6 6.1 6.2 6.3 7

Protocol Control states 7 . 1 S t a t e s f o r c i r c u i t - mo d e C a l l C o n t r o l 7.1.1 Null State (0) 7.1.2 Call Initiated (1) 7.1.3 O v e r la p S e n d in g ( 2 ) 7.1.4 Outgoing Call Proceeding (3) 7.1.5 Call Delivered (4) 7.1.6 Call Present (6) 7.1.7 Call Received (7) 7.1.8 Co n n e c t Re q u e s t ( 8 ) 7.1.9 I n c o min g C a l l P r o c e e d i n g ( 9 ) 7.1.10 Active (10) 7.1.11 D is c o n n e c t Re q u e s t ( 1 1 ) 7.1.12 D is c o n n e c t I n d ic a tio n ( 1 2 ) 7.1.13 Re le a s e Re q u e s t ( 1 9 )

6 6 6 6 6 6 6 6 6 7 7 7 7 7 7

- ii -

7.1.14 Overlap Receiving (25) 7 . 2 S t a t e s f o r l a ye r ma n a g e me n t 7.2.1 Null State (Rest 0) 7.2.2 Re s ta r t Re q u e s t ( Re s t 1 ) 7.2.3 Restart (Rest 2)

7 7 7 7 7

Call Control 8 . 1 S t a t e s f o r T r a n s i t P I N X C a l l C o n tr o l 8.1.1 TCC_Idle (0) 8.1.2 TCC_Await Digits (1) 8.1.3 TCC_Await Additional Digits (2) 8.1.4 TCC_Overlap (3) 8.1.5 T C C _ I n c o min g C a l l P r o c e e d i n g ( 4 ) 8.1.6 TCC_Transit Call Proceeding (5) 8.1.7 TCC_Call Alerting (6) 8.1.8 TCC_Call Active (7) 8.1.9 T C C _ A w a i t I n c o min g R e l e a s e ( 8 ) 8.1.10 T CC_ A w a it O u tg o in g Re le a s e ( 9 ) 8.1.11 TCC_Await Two-Way Release (10) 8.1.12 T CC_ A w a it I n c o min g D is c o n n e c t ( 1 1 ) 8.1.13 T CC_ A w a it O u tg o in g D is c o n n e c t ( 1 2 ) 8.1.14 T CC_ A w a it T w o - W a y D is c o n n e c t ( 1 3 )

7 8 8 8 8 8 8 8 8 8 9 9 9 9 9 9

General procedures 9.1 Use of the services of Signalling Carriage Mechanism 9.1.1 E s ta b lis h me n t o f a S ig n a llin g Ca r r ia g e Me c h a n is m c o n n e c tio n 9.1.2 Transfer of data 9.1.3 Signalling Carriage Mechanism reset 9.1.4 Signalling Carriage Mechanism failure 9 . 2 H a n d lin g o f p r o to c o l e r r o r c o n d itio n s 9.2.1 P r o to c o l d is c r imin a to r e r r o r 9.2.2 Me s s a g e to o s h o r t 9.2.3 Call reference error 9.2.4 Me s s a g e typ e o r me s s a g e s e q u e n c e e r r o r s 9.2.5 G e n e r a l i n f o r ma t i o n e l e me n t e r r o r s 9.2.6 Ma n d a t o r y i n f o r ma t i o n e l e me n t e r r o r s 9.2.7 N o n - ma n d a t o r y i n f o r ma t i o n e l e me n t e r r o r s 9.2.8 Signalling Carriage Mechanism reset 9.2.9 Signalling Carriage Mechanism failure 9 . 3 S ta tu s a n d s ta tu s e n q u ir y p r o to c o l p r o c e d u r e s 9.3.1 S ta tu s e n q u ir y p r o c e d u r e 9.3.2 R e c e i v i n g a S T A T U S me s s a g e

9 9 9 9 9 9 10 10 10 10 10 11 11 12 13 13 14 14 14

10 Circuit-switched Call Control procedures 10.1 C a l l e s t a b l i s h me n t 10.1.1 Call request 10.1.2 I n f o r ma tio n c h a n n e l s e le c tio n

16 17 17 17

- iii -

10.1.3 O v e r la p s e n d in g 10.1.4 Call proceeding 10.1.5 Ca ll c o n f ir ma tio n in d ic a tio n 10.1.6 Call connected 10.1.7 U s e o f th e P RO G RE S S me s s a g e 10.1.8 F a i l u r e o f c a l l e s t a b l i s h me n t 10.2 Call clearing 10.2.1 T e r min o lo g y 10.2.2 E x c e p tio n c o n d itio n s 10.2.3 Clearing 10.2.4 Clear collision 10.3 Call co llis io n s 10.4 T r a n s it P I N X Ca ll Co n tr o l r e q u ir e me n ts 10.4.1 R e c e i p t o f a d d r e s s i n f o r ma t i o n 10.4.2 State TCC_Await_Digits 10.4.3 State TCC_Await_Additional_Digits 10.4.4 State TCC_Overlap 10.4.5 Ch a n n e l th r o u g h c o n n e c tio n p r o c e d u r e s 10.4.6 S t a t e T C C _ I n c o min g _ C a l l _ P r o c e e d i n g 10.4.7 State TCC_Transit_Call_Proceeding 10.4.8 State TCC_Call_Alerting 10.4.9 State TCC_Call_Active 10.4.10 Call clearing at a Transit PINX 1 0 . 4 . 1 1 H a n d l i n g o f B a s i c C a l l i n f o r ma t i o n e l e me n t s a t a T r a n s i t P I N X 10.5 O r ig in a tin g P I N X Ca ll Co n tr o l r e q u ir e me n ts 10.5.1 T r a n s mis s io n o f th e S E T U P me s s a g e 10.5.2 A g r e e me n t o f t h e i n f o r ma t i o n c h a n n e l 10.5.3 Receipt of Progress indicators 10.5.4 R e c e i p t o f A L E R T I N G me s s a g e 10.5.5 R e c e i p t o f C O N N E C T me s s a g e 10.5.6 Call clearing initiated by the Originating PINX 10.5.7 R e c e i p t o f a n i n d i c at i o n o f c a l l c l e a r i n g 10.6 T e r min a tin g P I N X Ca ll Co n tr o l r e q u ir e me n ts 10.6.1 R e c e i p t o f t h e S E T U P me s s a g e 10.6.2 T r a n s mis s io n o f A L E RT I N G me s s a g e 10.6.3 T r a n s mis s io n o f P r o g r e s s in d ic a to r s 10.6.4 T r a n s mi s s i o n o f C O N N E C T me s s a g e 10.6.5 C a l l c l e a r i n g i n i t i a t e d b y t h e T e r mi n a t i n g P I N X 10.6.6 R e c e i p t o f a n i n d i c at i o n o f c a l l c l e a r i n g 10.7 I n c o min g G a te w a y P I N X Ca ll Co n tr o l r e q u ir e me n ts 10.7.1 T r a n s mis s io n o f th e S E T U P me s s a g e 10.7.2 I n te r w o r k in g in d ic a tio n s in th e S E T U P Me s s a g e 10.7.3 A g r e e me n t o f t h e i n f o r ma t i o n c h a n n e l 10.7.4 Receipt of Progress indicators 10.7.5 R e c e i p t o f A L E R T I N G me s s a g e 10.7.6 R e c e i p t o f C O N N E C T me s s a g e

18 18 19 20 20 21 21 21 21 22 22 22 23 23 24 24 25 26 26 27 28 28 29 30 30 31 31 31 31 32 32 32 32 32 33 33 33 33 34 34 34 35 35 35 35 36

- iv -

10.7.7 C a l l c l e a r i n g i n i t i a t e d b y t h e I n c o min g G a t e w a y P I N X 10.7.8 R e c e i p t o f a n i n d i c at i o n o f c a l l c l e a r i n g 10.8 O u tg o in g G a te w a y P I N X Ca ll Co n tr o l r e q u ir e me n ts 10.8.1 R e c e i p t o f t h e S E T U P me s s a g e 10.8.2 Co n n e c tio n o f th e in f o r ma tio n c h a n n e l 10.8.3 T r a n s mis s io n o f in te r w o r k in g in d ic a tio n s 10.8.4 T r a n s mis s io n o f A L E RT I N G me s s a g e 10.8.5 T r a n s mi s s i o n o f C O N N E C T me s s a g e 10.8.6 C a l l c l e a r i n g i n i t i a t e d b y t h e O u t g o in g G a t e w a y P I N X 10.8.7 R e c e i p t o f a n i n d i c at i o n o f c a l l c l e a r i n g

36 36 37 37 37 37 38 38 39 39

11 Procedures for layer management 11.1 Re s ta r t p r o c e d u r e s 11.1.1 S e n d in g RE S T A RT 11.1.2 Receipt of RESTART 11.1.3 Restart collision

39 39 39 40 40

Protocol timers

13 F u n c t io n a l d e f in it io n o f m e s s a g e s 13.1 Me s s a g e s f o r g e n e r a l p r o c e d u r e s 13.1.1 STATUS 13.1.2 STATUS ENQUIRY 13.2 Me s s a g e s f o r Cir c u it Mo d e Ca ll Co n tr o l 13.2.1 ALERTING 13.2.2 CALL PROCEEDING 13.2.3 CONNECT 13.2.4 CONNECT ACKNOWLEDGE 13.2.5 DISCONNECT 13.2.6 I N F O R MA T I O N 13.2.7 PROGRESS 13.2.8 RELEASE 13.2.9 RELEASE COMPLETE 13.2.10 SETUP 13.2.11 SETUP ACKNOWLEDGE 13.3 Me s s a g e s f o r la ye r ma n a g e me n t 13.3.1 RESTART 13.3.2 RESTART ACKNOWLEDGE

43 43 43 43 44 44 44 44 45 45 45 45 46 46 46 47 47 47 47

14 General message format and coding of information elements 14.1 Overview 14.2 P r o to c o l d is c r imin a to r 14.3 Call reference 14.4 Me s s a g e typ e 14.5 O th e r in f o r ma tio n e le me n ts f o r Ba s ic Ca ll c o n tr o l ( c o d e s e t 0 ) 14.5.1 Co d in g r u le s 14.5.2 E x te n s io n o f c o d e s e ts

48 48 48 49 50 51 51 53

- v -

14.5.3 L o c k in g s h if t p r o c e d u r e 14.5.4 N o n - lo c k in g s h if t p r o c e d u r e 14.5.5 Bearer capability 14.5.6 Call state 14.5.7 Ca lle d p a r ty n u mb e r 14.5.8 Ca lle d p a r ty s u b a d d r e s s 14.5.9 Ca llin g p a r ty n u mb e r 1 4 . 5 . 1 0 Ca llin g p a r ty s u b a d d r e s s 14.5.11 Cause 14.5.12 Channel identification 1 4 . 5 . 1 3 Co n n e c te d n u mb e r 1 4 . 5 . 1 4 Co n n e c te d s u b a d d r e s s 1 4 . 5 . 1 5 H i g h l a y e r c o mp a t i b i l i t y ( l a y e r s 4 - 7 ) 1 4 . 5 . 1 6 L o w l a y e r c o mp a t i b i l i t y ( l a y e r s 1 - 3 ) 1 4 . 5 . 1 7 P r o g r e s s in d ic a to r 14.5.18 Restart indicator 1 4 . 5 . 1 9 S e n d in g c o mp le te 14.6 I n f o r ma tio n e le me n ts o f c o d e s e t 5

54 55 55 57 58 61 61 62 62 67 70 70 71 71 71 72 73 73

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 ) f o r E C M A - 1 4 3

Annex B - Use of the cause information element

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

Annex D - Manufacturer specific information

Annex E - SDL diagram for the procedures over a symmetrical link between two peer PINX’s

A n n e x F - S D L d ia g r a m f o r t h e p r o c e d u r e s o n e it h e r s id e o f a Tr a n s it - P I N X

119

Annex G - Bibliography

137

A n n e x ZA - S e g m e n t a t i o n a n d r e a s s e m b l y p r o c e d u r e s

139

A n n e x ZB - A d d i t i o n a l p r o g r e s s d e s c r i p t i o n s

149

- vi -

Scope This Standard defines the signalling procedures and protocol for the purpose of circuit-switched Call Control at the Q-reference point between Private Integrated services Network eXchanges (PINXs) connected together within a Private Integrated Services Network (PISN). The Q reference point is defined in ECMA-133. This Standard is based upon that described in ITU-T Recommendation Q.931, including the provisions for symmetrical operation described in annex D of that recommendation. 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-142, ECMA-148 and ISO/IEC 11584. This Standard is applicable to PINXs which 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-155

Private Integrated ISO/IEC 11571)

ISO/IEC 8886

Information technology - Open Systems Interconnection - Data link service definition (1996)

ETS 300 387

Private Telecommunication Network (PTN); Method for the specification of basic and supplementary services (1994)

ITU-T Rec. E.164

The international public telecommunication numbering plan (1997)

ITU-T Rec. I.330

ISDN numbering and addressing principles (Blue Book) (1988)

ITU-T Rec. Q.931

ISDN user-network interface layer 3 specification for basic call control (1998)

ITU-T Rec. T.50

Information technology - 7-bit coded character set for information interchange (1992)

Services

Networks

Addressing

(International

Standard

Definitions For the purposes of this Standard, the following definitions apply.

4.1

Private Integrated Services Network (PISN) An ISDN providing services to a specific set of users (contrary to a public ISDN which provides services to the general public). NOTE This definition does not include legal and regulatory aspects and does not indicate any aspects of ownership.

- 2 -

4.2

Private Integrated services Network eXchange (PINX) A PISN nodal entity which provides automatic connection handling functions used for the provision of telecommunication services based on the definitions of the public ISDN services. A PISN nodal entity consists of one or more nodes.

4.3

Side, Incoming Side and Outgoing Side The term Side is used to describe either of the two PINXs at each end of an Inter-PINX link, and in particular to describe the PSS1 Protocol entity within a PINX. In the context of a call, the Outgoing Side is the Side which routes the call over the Inter-PINX link and the Incoming Side is the Side which receives the call. See figure 1.

4.4

Outgoing Call and Incoming Call From the point of view of the Outgoing Side a call is an Outgoing Call. From the point of view of the Incoming Side a call is an Incoming Call.

4.5

Originating PINX, Terminating PINX and Transit PINX Within the context of a call, the PINX to which the calling user is attached is known as the Originating PINX. Within the context of a call, the PINX to which the called user is attached is known as the Terminating PINX. Within the context of a call, any PINX through which the call passes, excluding the Originating PINX the Terminating PINX, an Incoming gateway PINX and an Outgoing gateway PINX, is known as a Transit PINX. See figure 1.

4.6

Gateway PINX, Incoming Gateway PINX and Outgoing Gateway PINX Within the context of a call, a PINX which performs interworking between PSS1 and another signalling system, either ISDN or non-ISDN, is known as a Gateway PINX. A Gateway PINX which routes an incoming call from a route employing another signalling system on to an Inter-PINX link employing PSS1 signalling is known as an Incoming Gateway PINX. A Gateway PINX which routes an incoming call from an Inter-PINX link employing PSS1 signalling on to a route employing another signalling system is known as an Outgoing Gateway PINX. See figure 1.

Forwards direction Originating PINX or Incoming Gateway PINX

Transit PINX Inter-PINX link

Outgoing side

Terminating PINX or Outgoing Gateway PINX

Backwards direction

Inter-PINX link

Incoming side

Outgoing side

Incoming side

Figure 1 - Illustration of terminology through example of a call routed over two Inter-PINX links employing PSS1

- 3 -

4.7

Preceding PINX and Subsequent PINX Within the context of a call, from the point of view of a PINX acting as the Incoming Side of an InterPINX link, the PINX at the other end of the link, acting as the Outgoing Side, is known as the Preceding PINX. Within the context of a call, from the point of view of a PINX acting as the Outgoing Side of an InterPINX link, the PINX at the other end of the link, acting as the Incoming Side, is known as the Subsequent PINX.

4.8

Inter-PINX link The totality of a signalling channel connecting two PINXs and the user information channels under the control of that signalling channel, as seen by each PINX. NOTE An Inter-PINX link can be provided by various types of Signalling Carriage Mechanism involving different types of physical interface. The signalling and user information channels referred to in this Standard are independent of the channels or timeslots at a physical interface.

4.9

Route A number of user information channels at the Q reference point that have the same characteristics (e.g. transmission capacity, time sequence integrity).

4.10

Signalling Carriage Mechanism (SCM) The infrastructure that transports messages between Protocol Control entities in two interconnected PINXs.

4.11

Unrecognised message An unrecognised message is defined as a message which is not specified in clause 13 of this Standard or in any other Standard relating to PSS1 Protocol to which the PINX claims conformance (e.g., a Standard specifying generic procedures for supplementary services). NOTE The handling of national/private messages is outside the scope of this Standard (see annex D).

4.12

Unexpected message Within the context of a particular Protocol Control state, an unexpected message is a message which is recognised, but for which no procedures are defined in clauses 9.3 and 10, and annex ZA of this Standard (or in any other Standard relating to PSS1 Protocol to which the PINX claims conformance) for receipt in that Protocol Control state.

4.13

Unrecognised information element An unrecognised information element is defined as an information element received in a particular message which is not specified as part of that message in clause 13 of this Standard or in any other Standard relating to PSS1 Protocol to which the PINX claims conformance (e.g., a Standard specifying generic procedures for supplementary services). NOTE The handling of national/private information elements is outside the scope of this Standard (see annex D).

4.14

Information elements with invalid contents An information element with invalid contents is defined as an information element which is recognised, but whose contents cannot be interpreted as valid using the rules specified in clause 14 of this Standard, or contains field values which are marked as “reserved” in clause 14 of this Standard. NOTE The receipt of reserved codepoints in octets 5, 6, and 7 of a Bearer Capability information element, shall not be treated as having invalid contents (see clause 14.5.5).

- 4 -

List of acronyms ANF

Additional Network Feature

DSS1

Digital Subscriber Signalling System Number 1

Information Element

ISDN

Integrated Services Digital Network

Mapping (functional grouping)

PICS

Protocol Implementation Conformance Statement

PISN

Private Integrated Services Network

PINX

Private Integrated services Network eXchange

PSS1

Private Integrated Signalling System Number 1

SCM

Signalling Carriage Mechanism

Terminal Equipment

General principles The Basic Call is a single invocation of a basic service. This Standard specifies the signalling procedures for establishing, maintaining and clearing a circuit-mode Basic Call at an interface between two PINXs. These signalling procedures are defined in terms of messages exchanged over a Signalling Carriage Mechanism (SCM) connection within the signalling channel of the Inter-PINX link. The result of successful Basic Call establishment is a connection for the purpose of user information transfer. This connection uses a user information channel of the Inter-PINX link. Throughout this Standard, the term user information channel is used to indicate any channel other than the signalling channel. Conceptually, an Inter-PINX link is attached to a PINX at the Q-reference point, and comprises a signalling channel and one or more user information channels. In practice, these channels are provided by bearer services of an intervening network (ISDN or non-ISDN).

6.1

Protocol model Figure 2 shows the relationship, within the Control Plane, between the signalling procedures and protocol at Q, and the adjacent layers.

- 5 -

PSS1 Signalling Layer PSS1 Call Control

PSS1 Protocol Control

PSS1 Protocol

PSS1 Signalling Carriage Mechanism

PSS1 Protocol Control

PSS1 Signalling Carriage Mechanism

PINX to PINX Connection

F ig u r e 2 - C o n t r o l P r o t o c o l M o d e l The Protocol Control entity provides services to Call Control. Call Control corresponds to the Call Control functional entity identified for the Basic Call at Stage 2 (see ECMA-142). Primitives exchanged across the boundary between Call Control and Protocol Control correspond to the information flows exchanged between the Call Control functional entities, as identified at Stage 2. Protocol Control provides the mapping between these primitives and the messages transferred across the Inter-PINX link. In order to transfer messages, Protocol Control uses the services of the Signalling Carriage Mechanism. The actual protocols visible at the C-reference point (see ECMA-133) are dependent upon the PINX interconnection scenario.

6.2

Services provided to Call Control Protocol Control provides services to Call Control whereby Call Control can send information flows to and receive information flows from the peer Call Control. A primitive from Call Control to Protocol Control of type “request” or “response” normally results in the associated information flow being presented to the peer Call Control as a primitive of type “indication” or “confirmation” respectively. The following primitives are used: – SETUP-REQUEST/INDICATION/RESPONSE/CONFIRMATION for the establishment of a call; – MORE_INFORMATION-REQUEST/INDICATION information during call establishment;

for

requesting

destination

addressing

– INFORMATION-REQUEST/INDICATION for providing more destination addressing information during call establishment; – PROCEED-REQUEST/INDICATION for indicating that sufficient destination addressing information has been received and call establishment is proceeding; – ALERTING-REQUEST/INDICATION for indicating that the destination user is being alerted; – PROGRESS-REQUEST/INDICATION for indicating interworking conditions and/or the availability of in-band patterns; – REJECT-REQUEST/INDICATION for the immediate rejection of a call; – DISCONNECT-REQUEST/INDICATION for the initiation of call release; – RELEASE-REQUEST/INDICATION for the completion of call release;

- 6 -

– DL_RESET-INDICATION for indicating to Call Control that a SCM reset has occurred.

6.3

Services required of the Signalling Carriage Mechanism The services required of the Signalling Carriage Mechanism can be defined in terms of the services provided by ISO/IEC 8886. Protocol Control uses the following acknowledged information transfer services and their associated primitives: – Data transfer (i.e. Protocol Control message transfer), using the DL-DATA-REQUEST/INDICATION primitives; – Establishment, using the DL-ESTABLISH-REQUEST/INDICATION/CONFIRM primitives; – Termination, using the DL-RELEASE-REQUEST/INDICATION primitives. NOTE An implementation is not constrained to use the ISO/IEC 8886 Protocol in order to provide these primitives.

Protocol Control states Protocol Control procedures for calls and layer management are specified in terms of: a) messages which are transferred across the Inter-PINX link, b) the primitives to and from Call Control at each PINX, c) the information processing and actions that take place within Protocol Control at each PINX, and d) the states that can exist within Protocol Control at each PINX. State machines are deemed to exist for each circuit-mode call. Further state machines are deemed to exist for layer management.

7.1

States for circuit-mode Call Control The states below are used in association with call references other than the global call reference.

7.1.1

N u ll S t a t e ( 0 ) No call exists.

7.1.2

Call Initiated (1) This state exists for an outgoing call when the Outgoing Side has sent a request for call establishment to the Incoming Side but has not yet received a response.

7.1.3

O v e r la p S e n d in g ( 2 ) This state exists for an outgoing call when the Outgoing Side has received acknowledgement that the Incoming Side is able to receive additional call information in overlap mode.

7.1.4

Outgoing Call Proceeding (3) This state exists for an outgoing call when the Outgoing Side has received acknowledgement that the Incoming Side has received all call information necessary to effect call establishment.

7.1.5

Call Delivered (4) This state exists for an outgoing call when the Outgoing Side has received from the Incoming Side an indication that the called user is being alerted.

7.1.6

C a ll P r e s e n t ( 6 ) This state exists for an incoming call when the Incoming Side has not yet responded to the request from the Outgoing Side for call establishment.

7.1.7

Call Received (7) This state exists for an incoming call when the Incoming Side has indicated to the Outgoing Side that the called user is being alerted.

- 7 -

7.1.8

Connect Request (8) This state exists for an incoming call when the Incoming Side has indicated to the Outgoing Side that the called user has answered the call. NOTE "answered" is the act of the end user accepting the call.

7.1.9

Incoming Call Proceeding (9) This state exists for an incoming call when the Incoming Side has sent to the Outgoing Side acknowledgement that it has received all call information necessary to effect call establishment.

7.1.10

A c t iv e ( 1 0 ) This state exists for an incoming call when the Incoming Side has received from the Outgoing Side an acknowledgement of the indication that the called user has answered the call. This state exists for an outgoing call when the Outgoing Side has received from the Incoming Side an indication that the called user has answered the call. NOTE "answered" is the act of the end user accepting the call.

7.1.11

D is c o n n e c t R e q u e s t ( 1 1 ) This state exists when a Side has sent to the other Side a request to disconnect the user information connection and is waiting for a response.

7.1.12

D is c o n n e c t I n d ic a t io n ( 1 2 ) This state exists when a Side has received from the other Side a request to disconnect the user information connection and has not yet responded.

7.1.13

R e le a s e R e q u e s t ( 1 9 ) This state exists when a Side has sent to the other Side a request to release the call and has not yet received a response.

7.1.14

Overlap Receiving (25) This state exists for an incoming call when the Incoming Side has sent acknowledgement to the Outgoing Side that it is able to receive additional call information in overlap mode.

7.2

States for layer management The states below are used in association with the global call reference.

7.2.1

N u ll S t a t e ( R e s t 0 ) No transaction exists.

7.2.2

Restart Request (Rest 1) This state exists for a restart transaction when the Side has sent a restart request to the other Side but has not yet received an acknowledgement.

7.2.3

Restart (Rest 2) This state exists for a restart transaction when the Side has received a restart request from the other Side but has not yet sent an acknowledgement.

Call Control In addition to specifying Protocol Control, this Standard also specifies those aspects of Call Control which are necessary for PINXs to cooperate in the control of calls through a PISN. Although the behaviour of a Protocol Control entity with respect to a call is dependent on whether the PINX is the Outgoing Side or the Incoming Side of the Inter-PINX link, its behaviour is independent of whether the PINX is a Transit PINX, an End (Originating or Terminating) PINX, or a Gateway PINX. Call Control requirements, on the other hand, are dependent on whether the PINX is a Transit PINX, an Originating PINX, a Terminating PINX, an Incoming Gateway PINX or an Outgoing Gateway PINX.

- 8 -

Subclause 10.4 specifies the special Call Control requirements of a Transit PINX for coordinating the two Protocol Control entities. The requirements of subclause 10.4 are in addition to the requirements of Protocol Control, which are to be satisfied for both the Incoming Inter-PINX link and the Outgoing Inter-PINX link. An SDL representation of Call Control for a Transit PINX appears in annex F. Subclause 10.5 specifies the special Call Control requirements for Originating PINXs. The requirements of subclause 10.5 are in addition to the requirements of Protocol Control, which are to be satisfied on the Outgoing Inter-PINX link. Subclause 10.6 specifies the special Call Control requirements for Terminating PINXs. The requirements of subclause 10.6 are in addition to the requirements of Protocol Control, which are to be satisfied on the Incoming Inter-PINX link. Subclause 10.7 specifies the special Call Control requirements for Incoming Gateway PINXs. The requirements of subclause 10.7 are in addition to the requirements of Protocol Control, which are to be satisfied on the Outgoing Inter-PINX link. Clause 10.8 specifies the special Call Control requirements for Outgoing Gateway PINXs. The requirements of subclause 10.8 are in addition to the requirements of Protocol Control, which are to be satisfied on the Incoming Inter-PINX link.

8.1

States for Transit PINX Call Control The states below are used in association with calls in Call Control of a Transit PINX. NOTE These states are used in order to describe the behaviour of the Transit PINX Call Control function. These internal states are a descriptive tool and are not intended to constrain implementations.

8.1.1

TC C _ I d le ( 0 ) No call exists.

8.1.2

TC C _ A wa it D ig it s ( 1 ) This state exists when Call Control has received a request for call establishment from the Preceding PINX and is awaiting additional call information in order to select a route to the Subsequent PINX.

8.1.3

TC C _ A wa it A d d it io n a l D ig it s ( 2 ) This state exists when Call Control has sent a request for call establishment to the Subsequent PINX and is awaiting possible additional call information from the Preceding PINX.

8.1.4

TC C _ O v e r la p ( 3 ) This state exists when Call Control is awaiting possible additional call information from the Preceding PINX, having received acknowledgement that the Subsequent PINX is able to receive additional call information in overlap mode.

8.1.5

TCC_Incoming Call Proceeding (4) This state exists when Call Control has determined that it has received all call information necessary to effect call establishment and has informed the Preceding PINX, but no response to the request for call establishment has been received from the Subsequent PINX.

8.1.6

TCC_Transit Call Proceeding (5) This state exists when Call Control has received from the Subsequent PINX a response to the request for call establishment and is no longer expecting additional call information to pass to the Subsequent PINX in overlap mode.

8.1.7

TC C _ C a ll A le r t in g ( 6 ) This state exists when Call Control has received from the Subsequent PINX an indication that the called user is being alerted and has relayed the indication on to the Preceding PINX.

8.1.8

TC C _ C a ll A c t iv e ( 7 ) This state exists when Call Control has received from the Subsequent PINX and relayed on to the Preceding PINX an indication that the called user has answered the call.

- 9 -

NOTE "answered" is the act of the end user accepting the call. 8.1.9

TC C _ A wa it I n c o m in g R e le a s e ( 8 ) This state exists when Call Control has initiated call clearing towards the Preceding PINX and is awaiting an acknowledgement.

8.1.10

TC C _ A wa it O u t g o in g R e le a s e ( 9 ) This state exists when Call Control has initiated call clearing towards the Subsequent PINX and is awaiting an acknowledgement.

8.1.11

TC C _ A wa it Two - W a y R e le a s e ( 1 0 ) This state exists when Call Control has initiated call clearing towards the Preceding PINX and towards the Subsequent PINX and is awaiting an acknowledgement from each.

8.1.12

TC C _ A wa it I n c o m in g D is c o n n e c t ( 1 1 ) This state exists when Call Control has applied an in-band tone or announcement towards the Preceding PINX and is awaiting the initiation of clearing procedures.

8.1.13

TC C _ A wa it O u t g o in g D is c o n n e c t ( 1 2 ) This state exists when Call Control has applied an in-band tone or announcement towards the Subsequent PINX and is awaiting the initiation of clearing procedures.

8.1.14

TC C _ A wa it Two - W a y D is c o n n e c t ( 1 3 ) This state exists when Call Control has applied an in-band tone or announcement towards both the Preceding PINX and the Subsequent PINX and is awaiting the initiation of clearing procedures.

General procedures

9.1

Use of the services of Signalling Carriage Mechanism This clause specifies the use by PSS1 of the services of the Signalling Carriage Mechanism. NOTE The SCM provides a defined service of quality.

9.1.1

Establishment of a Signalling Carriage Mechanism connection Before the procedures for Call Control, layer management or any of the general procedures in clauses 9.2, 9.3 and annex ZA can be performed, a SCM connection shall be established. If a SCM connection has not already been established, Protocol Control shall request establishment by sending a DLESTABLISH-REQUEST primitive to the Signalling Carriage Mechanism. Receipt of a DLESTABLISH-CONFIRMATION primitive or a DL-ESTABLISH-INDICATION primitive from the Signalling Carriage Mechanism indicates that a SCM connection has been established.

9.1.2

Tr a n s f e r o f d a t a A PSS1 message (or message segment) is transmitted by including it with a DL-DATA-REQUEST primitive to the Signalling Carriage Mechanism. A PSS1 message (or message segment) appears included with a DL-DATA-INDICATION primitive from the Signalling Carriage Mechanism.

9.1.3

Signalling Carriage Mechanism reset Receipt of a DL-ESTABLISH-INDICATION primitive from the Signalling Carriage Mechanism subsequent to establishment of the SCM connection indicates a spontaneous SCM reset. The procedures specified in subclause 9.2.8 shall apply.

9.1.4

Signalling Carriage Mechanism failure Receipt of a DL-RELEASE-INDICATION primitive from the SCM indicates a SCM malfunction. The procedures specified in subclause 9.2.9 shall apply.

- 10 -

9.2

Handling of protocol error conditions The procedures of clauses 9.3, 10, 11 and 12 of this specification are applicable only to those messages which pass the checks described in subclauses 9.2.1 through 9.2.7. Subclauses 9.2.1 through 9.2.7 are listed in order of precedence.

9.2.1

Protocol discriminator error When a message is received with a protocol discriminator not in accordance with subclause 14.2, that message shall be ignored. “Ignore” means to do nothing, as if the message had never been received.

9.2.2

Message too short When a message is received that is too short to contain a complete message type information element, that message shall be ignored.

9.2.3 Call reference error 9.2.3.1 Invalid call reference format If the Call reference information element octet 1, bits 5 through 8 do not equal “0000”, then the message shall be ignored. If octet 1, bits 1 through 4 of the call reference information element indicates a length greater than the maximum length supported by the receiving equipment, then the message shall be ignored. If a message containing the Dummy call reference is received, except when used in the context of other Standards which define its use, the message shall be ignored. 9.2.3.2

Call reference procedural errors Whenever any message except SETUP, STATUS, RELEASE or RELEASE COMPLETE is received specifying a call reference (other than the global call reference) which is not recognised as relating to an active call or to a call in progress, the receiving entity shall send a RELEASE COMPLETE message and remain in the null state. The RELEASE COMPLETE message shall contain the call reference of the received message and cause number 81, “invalid call reference value”. Alternatively, the receiving entity may send a RELEASE message (in place of the RELEASE COMPLETE message) in this situation, but this is not the preferred option. The RELEASE message shall contain the call reference of the received message and cause number 81, “invalid call reference value”. When a SETUP message is received specifying a call reference which is not recognised as relating to an active call or to a call in progress, and with a call reference flag incorrectly set to ONE, this message shall be ignored. When a STATUS message is received specifying a call reference which is not recognised as relating to an active call or to a call in progress, the procedures of subclause 9.3.2 shall apply. When a RELEASE message is received specifying a call reference which is not recognised as relating to an active call or to a call in progress, the receiving entity shall send a RELEASE COMPLETE message. The RELEASE COMPLETE message shall contain the call reference of the received message and cause number 81, “invalid call reference value”. When a RELEASE COMPLETE message is received specifying a call reference which is not recognised as relating to an active call or to a call in progress, no action shall be taken. When a SETUP message is received specifying a call reference which is recognised as relating to an active call or to a call in progress, this SETUP message shall be ignored. When any message except RESTART, RESTART ACKNOWLEDGE or STATUS is received specifying the global call reference, no action shall be taken on this message and a STATUS message specifying the global call reference with cause number 81 “invalid call reference value” shall be returned.

9.2.4

Message type or message sequence errors Whenever an unrecognised or unexpected message is received in any state other than the Null state, a STATUS message shall be returned with a cause information element. The cause value used shall be

- 11 -

number 98 “message not compatible with call state or message type non-existing or not implemented”. If the receiving entity can distinguish between unimplemented (or non-existing) message types and implemented message types which are incompatible with the call state, then the cause used shall be: – cause number 97 “message type non-existing or not implemented”; or – cause number 101 “message type not compatible with the call state” Alternatively, a STATUS ENQUIRY message may be sent requesting the Protocol Control state of the peer entity. There are two exceptions where a STATUS or STATUS ENQUIRY message shall not be sent. The first exception is when the outgoing or incoming side receives an unexpected RELEASE message (e.g., if the DISCONNECT message was corrupted by undetected transmission errors). In this case the receiving entity shall: disconnect and release the information channel; return RELEASE COMPLETE message to the originator; release the call reference; stop all timers; enter the Null state; and inform Call Control. The second exception is when the outgoing or incoming side receives an unexpected RELEASE COMPLETE message. In this case, the receiving entity shall: disconnect and release the information channel; release the call reference; stop all timers; enter the Null state; and inform Call Control. 9.2.5 General information element errors 9.2.5.1 Duplicated information elements If an information element is repeated in a message more times than is permitted for that particular message, only the contents of the occurrences of that information element up to the limit of repetitions shall be handled. All subsequent occurrences of the element shall be ignored. 9.2.5.2

Information elements exceeding maximum length Information elements with a length exceeding the maximum length (given in clause 14) shall be treated as information elements with content error.

9.2.5.3

Information elements out of sequence If a variable length information element is received out of sequence (i.e. its code value is lower than that of the previous variable length information element) the receiving entity may ignore this information element and continue to process the message. NOTE If the information element is mandatory and the receiver chooses to ignore the element, the error handling procedures of 9.2.6.1 will be followed. If the ignored information element is non-mandatory, the receiver will continue to process the message. Some implementations may choose to process all the information elements received, regardless of the order in which they are received.

9.2.6 Mandatory information element errors 9.2.6.1 Mandatory information element missing When a message other than SETUP, DISCONNECT, RELEASE, or RELEASE COMPLETE is received which has one or more mandatory information elements missing, no action shall be taken on the message and no state change shall occur. A STATUS message shall then be returned with cause number 96 “mandatory information element is missing”. When a SETUP message is received which has one or more mandatory information elements missing, a RELEASE COMPLETE message with cause number 96 “mandatory information element is missing” shall be returned. When a DISCONNECT message is received with one or more mandatory information elements missing, the actions taken shall be the same as if a DISCONNECT message with cause number 31 “normal, unspecified” was received (see clause 10.2), with the exception that the RELEASE message returned shall contain cause number 96 “mandatory information element missing”. When a RELEASE message is received as the first clearing message with one or more mandatory information elements missing the actions taken shall be the same as if a RELEASE message with cause number 31 “normal, unspecified” was received (see subclause 10.2), except that if a RELEASE

- 12 -

COMPLETE message is sent it shall contain cause number 96 “mandatory information element is missing”. When a RELEASE COMPLETE message is received as the first clearing message, with one or more mandatory information elements missing, it shall be assumed that a RELEASE COMPLETE message was received with cause number 31 “normal, unspecified”. 9.2.6.2

Mandatory information element content error When a message other than SETUP, DISCONNECT, RELEASE, or RELEASE COMPLETE is received which has one or more mandatory information elements with invalid content, no action shall be taken on the message and no state change shall occur. A STATUS message shall then be returned with cause number 100 “invalid information element contents”. When a SETUP message is received which has one or more mandatory information elements with invalid content, a RELEASE COMPLETE message with cause number 100 “invalid information element contents” shall be returned. When a DISCONNECT message is received with invalid content of the cause information element, the actions taken shall be the same as if a DISCONNECT message with cause number 31 “normal, unspecified” was received (see subclause 10.2.), with the exception that the RELEASE message returned shall contain cause number 100 “invalid information element contents”. When a RELEASE message is received with invalid content of the cause information element, the actions taken shall be the same as if a RELEASE message with cause number 31 “normal, unspecified” was received (see subclause 10.2), except that if a RELEASE COMPLETE message is sent, it shall contain cause number 100 “invalid information element contents”. When a RELEASE COMPLETE message is received with invalid content of the cause information element, it shall be assumed that a RELEASE COMPLETE message was received with cause number 31 “normal, unspecified”.

9.2.7 Non-mandatory information element errors 9.2.7.1 Non-mandatory information element not recognised When a message is received which has one or more non-mandatory information elements which are unrecognised, the receiving entity shall check whether they indicate “comprehension required” (refer to table 22 for the information element identifiers reserved with this meaning). If any information element is encoded to indicate “comprehension required” then the procedures in subclause 9.2.6.1 shall apply. If all unrecognised information elements are not encoded to indicate “comprehension required”, the following actions shall apply: – The receiving entity shall take action on the message and on those information elements which are recognised and have valid content; – When the received message is other than a DISCONNECT, RELEASE or RELEASE COMPLETE, a STATUS message may be returned containing one Cause information element. The Cause information element shall contain cause number 99 “information element non-existent or not implemented”, and the diagnostic field, if present, shall contain the unrecognised information element identifier for each information element that is unrecognised. The STATUS message shall indicate the call state which the receiving entity enters after processing the message in which the unrecognised information element was received. – If a DISCONNECT message is received with one or more unrecognised information elements, the actions taken shall be the same as if a DISCONNECT message was received without these unrecognised information elements (see subclause 10.2) with the exception that the RELEASE message returned shall contain cause number 99 “information element non-existent or not implemented”. This cause information element may contain a diagnostic field which shall contain the information element identifier for each unrecognised information element. – If a RELEASE message is received with one or more unrecognised information elements, the actions taken shall be the same as if a RELEASE message was received without these unrecognised information elements (see subclause 10.2) with the exception that the RELEASE

- 13 -

COMPLETE message returned shall contain cause number 99 “information element non-existent or not implemented”. This cause information element may contain a diagnostic field which shall contain the information element identifier for each unrecognised information element. – If a RELEASE COMPLETE message is received with one or more unrecognised information elements, the actions taken shall be the same as if a RELEASE COMPLETE message without those unrecognised information elements was received. 9.2.7.2

Non-mandatory information element content error When a message other than DISCONNECT, RELEASE or RELEASE COMPLETE is received which has one or more non-mandatory information elements with invalid content, action shall be taken on the message and those information elements which are recognised and have valid content. A STATUS message may be returned containing a cause information element with cause number 100 “invalid information element contents”, and the diagnostic field, if present, shall contain the information element identifier for each information element with invalid content. The STATUS message shall indicate the call state which the receiving entity enters after processing the message in which the information element content error was received. If a DISCONNECT, RELEASE or RELEASE COMPLETE message is received which has one or more non-mandatory information elements with invalid content, normal call clearing procedures (defined in subclause 10.2) shall apply.

9.2.8

Signalling Carriage Mechanism reset Whenever Protocol Control is informed of a spontaneous SCM reset by means of the DL-ESTABLISHINDICATION primitive, the following procedures shall apply: – for calls in the Overlap Sending state and the Overlap Receiving state, the entity shall initiate clearing by sending a DISCONNECT message with cause number 41 “Temporary Failure”, and following the procedures of clause 10.2. – for calls in the disestablishment phase (states 11, 12, and 19) no action shall be taken. – calls in the establishment phase (states 1, 3, 4, 6, 7, 8, and 9) and in the Active state shall be maintained. Optionally, a STATUS message may also be sent to report the current Protocol Control state to the peer entity or a STATUS ENQUIRY message may be sent to verify the Protocol Control state of the peer entity.

9.2.9

Signalling Carriage Mechanism failure Whenever Protocol Control is notified by its Signalling Carriage Mechanism entity via the DLRELEASE-INDICATION primitive that there is a SCM malfunction, the following procedure shall apply: – any calls not in the active state shall be cleared internally. For any call in the active state, timer T309 shall be started. If timer T309 is already running, it shall not be restarted. – the PSS1 entity shall request SCM re-establishment by sending a DL-ESTABLISH-REQUEST primitive. When informed of SCM re-establishment by means of the DL-ESTABLISH-CONFIRMATION primitive, the following procedure shall apply, for each active call: – timer T309 shall be stopped; – either: the PSS1 entity shall send a STATUS message to report the current Protocol Control state to the peer entity, or the PSS1 entity shall perform the status enquiry procedure to verify the Protocol Control state of the peer entity. Cause number 31 “normal, unspecified” is recommended to be used in the STATUS message. If timer T309 expires prior to SCM re-establishment, Protocol Control shall: release all resources; release the call reference; and enter the Null state. Call Control shall be informed of the failure of the call.

- 14 -

9.3 9.3.1

Status and status enquiry protocol procedures Status enquiry procedure Whenever Protocol Control wants to check the correctness of a Protocol Control state at a peer PSS1 entity, a STATUS ENQUIRY message may be sent requesting the Protocol Control state. Upon sending the STATUS ENQUIRY message, timer T322 shall be started in anticipation of receiving a STATUS message. While timer T322 is running, only one outstanding request for Protocol Control state shall exist. Therefore if timer T322 is already running, it shall not be restarted. If a clearing message is received before timer T322 expires, timer T322 shall be stopped, and the call clearing shall continue. Upon receipt of a STATUS ENQUIRY message, the receiving entity shall respond with a STATUS message, reporting the current Protocol Control state and containing cause number 30 “responding to STATUS ENQUIRY”. Receipt of the STATUS ENQUIRY message shall not result in a state change. The sending or receipt of the STATUS message in such a situation will not directly affect the Protocol Control state of either the sending or receiving entity. The side having received the STATUS message shall inspect the cause information element. If the STATUS message contains any cause other than cause number 30 “responding to STATUS ENQUIRY”, timer T322 shall continue to time for an explicit response to the STATUS ENQUIRY message. If a STATUS message is received that contains cause number 30 “response to STATUS ENQUIRY” the timer T322 shall be stopped, and the “appropriate actions” shall be taken. These “appropriate actions” are implementation dependent. However, the actions prescribed in 9.3.2 below shall apply. If the sender’s Protocol Control state changes after STATUS ENQUIRY has been sent, this shall be taken into account when checking for a compatible Protocol Control state in the received STATUS message. If timer T322 expires, and no STATUS message was received, the STATUS ENQUIRY message may be transmitted a number of times until a response is received. The number of times the STATUS ENQUIRY message may be retransmitted is a implementation dependent value. If the limit is exceeded, that call shall be cleared. The cause that should be used when clearing in this situation is cause number 41 “temporary failure”. Call Control shall be notified of the failure of the call. If T322 expires and a STATUS message, with a cause value other than number 30 “response to STATUS ENQUIRY”, was received the actions taken shall be an implementation option, which may be to process the received Protocol Control state in the same way as if the cause in the received STATUS message was number 30 “response to STATUS ENQUIRY”.

9.3.2

Receiving a STATUS message On receipt of a STATUS message containing a call reference value other than the Global Call Reference, the receiving entity shall check whether the Protocol Control state reported in the STATUS message is compatible with the state associated with that call reference internally. Table 1 indicates which Protocol Control states shall be considered compatible.

- 15 -

Ta b le 1 - C o m p a t ib le P r o t o c o l C o n t r o l s t a t e s Internal Protocol Control state associated Reported Protocol Control state in with call reference STATUS message 0

Null

Call Initiated

Call Present

Overlap Sending

Overlap Receiving

Outgoing Call Proceeding

Incoming Call Proceeding

Call Delivered

Call Received

Call Present

Call Initiated

Call Received

Call Delivered

Connect Request

Active

Incoming Call Proceeding

Outgoing Call Proceeding

Active

Connect Request

Disconnect Request

Disconnect Indication

9.3.2.1

Disconnect Request

Disconnect Indication

Disconnect Request

Release Request

Overlap Receiving

Overlap Sending

Receipt of a STATUS message reporting an incompatible Protocol Control state On receipt of a STATUS message reporting an incompatible Protocol Control state, the receiving entity shall either: clear the call by sending an appropriate clearing message with cause number 101 “message not compatible with call state”; or, take other actions which attempt to recover from a mismatch. These actions are an implementation decision. The following rules shall, however, apply: – if a STATUS message indicating any Protocol Control state except the Null state is received in the Null state, then a RELEASE COMPLETE message shall be sent. Alternatively, in this case a RELEASE message may be sent in place of the RELEASE COMPLETE message, but this is not the recommended option. – if a STATUS message indicating any Protocol Control state except the Null state is received in the Release Request state, no action shall be taken. – if a STATUS message, indicating the Null state, is received in any state except the Null state, the receiver shall release all resources and move into the Null state. Call Control shall be informed of the failure of the call. When in the Null state, the receiver of a STATUS message indicating the Null state shall take no action other than to discard the message and shall remain in the Null state.

9.3.2.2

R e c e i p t o f a S T A T U S m e s s a g e r e p o r t in g a c o m p a t i b l e P r o t o c o l C o n t r o l s t a t e No action shall normally be taken on receipt of a STATUS message indicating a compatible Protocol Control state except where the STATUS message contains one of the following causes: – cause number 96 “mandatory information element is missing” – cause number 97 “message type non-existent or not implemented”;

- 16 -

– cause number 99 “information element non-existent or not implemented”; or, – cause number 100 “invalid information element contents”. In these cases, the actions to be taken are an implementation option. The receiving entity should attempt to analyse the contents of the received STATUS message considering the current stage of the call in order to determine whether or not the call can continue. If successful analysis and recovery are not possible, the call may be cleared as described in subclause 10.2. NOTE To improve interworking between implementations that support the requirements of ECMA-165 and implementations that do not, it is recommended that the diagnostic field should be included in the Cause information element when sending a STATUS message with cause values 97 or 100. It is also recommended that a call should not be cleared on receipt of a STATUS message containing either of these cause values. Implementations that do not support ECMA-165 will normally return a STATUS message on receipt of a message or information element defined in ECMA-165. The clearing of the call in such situations should not be the normal behaviour. 9.3.2.3

Receiving a STATUS message containing the global call reference On receipt of a STATUS message containing the Global Call Reference, the receiving entity shall check whether the reported layer management state is compatible with its own internal layer management state, according to table 2. Layer management shall be informed if the STATUS message reports an incompatible state in Restart or Restart Request states (1 or 2), otherwise no action shall be taken. NOTE The Call Reference flag of the Global Call Reference applies to the Restart procedures. As a result, the state received in a STATUS message containing the Global call reference shall be compared with the layer management state of the specific Global Call Reference identified by the setting of the Call Reference flag. Table 2 - Compatible layer management states

Internal layer management state associated with global call reference

Reported layer management state in STATUS message

Null

Restart Request

Restart

Restart Request

Circuit-switched Call Control procedures The specification of the procedures for the control of circuit-switched calls across the network is contained in four parts. – The first part (subclauses 10.1 - 10.3) specifies the procedures and message flows over a symmetrical interface between two peer PINXs. Detailed specification and description language (SDL) diagrams for the procedures specified in these clauses are contained in annex E. – The second part (subclause 10.4) specifies how the procedures and message flows over either side of a Transit PINX are interrelated. Detailed specification and description language (SDL) diagrams for the procedures specified in this clause are contained in annex F. – The third part (subclauses 10.5 and 10.6) specifies the requirements for Call Control at an End PINX. – The fourth part (subclauses 10.7 and 10.8) specifies the requirements for Call Control at a Gateway PINX.

- 17 -

10.1 10.1.1

Call establishment C a ll r e q u e s t Call establishment shall be initiated by the Outgoing Side sending a SETUP message, and starting T303. The Outgoing Side shall select a channel (not known to be busy) for use by the call and indicate this in the channel identification information element. If the Outgoing Side knows all appropriate channels controlled by the signalling channel are in use, it shall not send a SETUP message. If no response (as prescribed in 10.1.4) is received from the Incoming Side before timer T303 expires, the SETUP message may optionally be retransmitted and timer T303 restarted. If no response is received before timer T303 expires for a second time, the Outgoing Side shall send a RELEASE COMPLETE message to the Incoming Side. This message should contain Cause number 102 “recovery on timer expiry”. Call Control shall be notified of the failure of the call. The SETUP message shall always contain a call reference, selected according to the procedures given in subclause 14.3. It shall also contain all the information required by the Incoming Side to process the call. The number digits within the Called party number information element may optionally be incomplete, thus requiring the use of overlap sending (see subclause 10.1.3). The SETUP message may optionally contain the Sending complete information element in order to indicate that the number is complete. NOTE If enbloc signalling only is used between two adjacent PINXs, overlap receiving procedures need not be tested. Following the transmission of the SETUP message, the Outgoing Side shall enter the Call Initiated state. On receipt of the SETUP message the Incoming Side shall enter the Call Present state.

10.1.2

I n f o r m a t io n c h a n n e l s e le c t io n In the SETUP message, the Outgoing Side shall include the Channel identification information element indicating the selected channel(s), encoded as defined in 14.5.12. All the channels indicated shall be within a Route containing channels for which time sequence integrity is maintained. If the information transfer rate implied by the channel(s) indicated in the Channel identification information element does not match the information transfer rate indicated in the Bearer capability information element, the procedures of 9.2.6.2 shall apply. The Channel identification information element shall indicate one of the following in the channel identification information element, in addition to the selected channel number: a) channel(s) are indicated, no acceptable alternative; or, b) channel(s) are indicated, any alternative is acceptable. In both cases, if the indicated channel(s) are available, the Incoming Side shall reserve them for the call. In case b) if the indicated channel(s) are not available, the Incoming Side shall reserve any available information channel associated with the signalling channel (within the constraints of the channel assignment specified above). The selected information channel(s) shall be indicated in the first message returned by the Incoming Side in response to the SETUP message (i.e. a SETUP ACKNOWLEDGE or CALL PROCEEDING message). The receipt of an ALERTING or CONNECT message as the first response to SETUP shall not Cause a protocol error, even though they would not normally be sent as the first responding message by Protocol Control. In case a) if the specified channel(s) are not available, or, in case b) if no channels, or insufficient channels are available, a RELEASE COMPLETE message containing a Cause information element shall be sent by the Incoming Side as described in subclause 10.2. Cause number 44 “requested circuit/channel not available” shall be the Cause sent in case a) and Cause number 34 “no circuit/channel available” shall be the Cause sent in case b). Call Control shall be informed of the failure of the call.

- 18 -

In case b) if the channel(s) indicated in the CALL PROCEEDING or SETUP ACKNOWLEDGE message are unacceptable to the Outgoing Side, the call shall be cleared in accordance with clause 10.2. The cause value used shall be appropriate to the clearing circumstances. For example, cause number 6 “channel unacceptable” or cause number 82 “identified channel does not exist”. Call Control shall be informed of the failure of the call. 10.1.3

O v e r la p s e n d in g NOTE If enbloc signalling only is used between two adjacent PINXs, overlap receiving procedures need not be tested. If the received SETUP message does not contain a Sending complete information element, and contains either: −

incomplete called number information; or,

−

called number information which the Incoming Side cannot determine to be complete

The Incoming Side shall start timer T302, send a SETUP ACKNOWLEDGE message to the Outgoing Side, and enter the Overlap Receiving state. When the SETUP ACKNOWLEDGE message is received, the Outgoing Side shall enter the Overlap Sending state, stop T303, and start timer T304. After receiving the SETUP ACKNOWLEDGE message, the Outgoing Side shall send the remainder of the Called party number digits (if any) in one or more INFORMATION messages. The Outgoing Side shall restart timer T304 when each INFORMATION message is sent. The INFORMATION message which completes the information sending may contain a “Sending complete” information element. The Incoming Side shall restart timer T302 on the receipt of every INFORMATION message not containing a Sending complete indication if it cannot determine that the Called party number is complete. If timer T304 expires the Outgoing Side shall initiate call clearing using the procedures in subclause 10.2. The Cause that should be used towards the calling user is Cause number 28 “invalid number format”; towards the called user, the Cause used should be Cause number 102 “recovery on timer expiry”. Call Control shall be informed of the failure of the call. At the expiry of timer T302, the Incoming Side shall: − if it determines that the call information is incomplete, initiate call clearing in accordance with clause 10.2 with Cause number 28 “invalid number format”; − otherwise send a CALL PROCEEDING message and enter the Incoming Call Proceeding state. 10.1.4 Call proceeding 10.1.4.1 Call proceeding, enbloc sending If enbloc sending is used (i.e. the Incoming Side can determine it has received sufficient information in the SETUP message from the Outgoing Side to establish the call) the Incoming Side shall send a CALL PROCEEDING message to the Outgoing Side to acknowledge the SETUP message and to indicate that the call is being processed. Upon receipt of the CALL PROCEEDING message, the Outgoing Side shall enter the Outgoing Call Proceeding state, stop timer T303 and, if applicable, start T310. After sending the CALL PROCEEDING message, the Incoming Side shall enter the Incoming Call Proceeding state. NOTE T310 is optional in the case of a Transit PINX and mandatory in the case of an Originating PINX (see 12). If, following the receipt of a SETUP message, the Incoming Side determines that for some reason the call cannot be supported, then the Incoming Side shall initiate call clearing as defined in subclause 10.2. Some of the Causes that may be used are given in subclause 10.1.8. This is not exhaustive.

- 19 -

10.1.4.2

Call proceeding, overlap sending NOTE 1 If enbloc signalling only is used between two adjacent PINXs, overlap receiving procedures need not be tested. Following the occurrence of one of these conditions: − the receipt by the Incoming Side of a Sending complete indication; or, − analysis by the Incoming Side that all call information necessary to effect call establishment has been received; and if the Incoming Side can determine that access to the requested service is available, the Incoming Side shall: send a CALL PROCEEDING message to the Outgoing Side; stop timer T302; and enter the Incoming Call Proceeding state. If, following the receipt of a SETUP message or during overlap sending the Incoming Side determines that for some reason the call cannot be supported, then the Incoming Side shall initiate call clearing as defined in subclause 10.2. Some of the Causes that may be used are given in subclause 10.1.8. This list is not exhaustive. NOTE 2 The CALL PROCEEDING message is sent to indicate that the requested call establishment has been initiated, and no more call establishment information will be accepted. When the Outgoing Side receives the CALL PROCEEDING message it shall enter the Outgoing Call Proceeding state, stop timer T304 and if applicable, start timer T310. NOTE 3 T310 is optional in the case of a Transit PINX and mandatory in the case of an Originating PINX (see 12). Upon receiving an indication that the called party is alerting or that the call has been answered, the incoming side shall stop timer T302 and send an ALERTING or CONNECT message, respectively, to the Outgoing Side. When the Outgoing Side receives a CONNECT or an ALERTING message, timer T304 shall be stopped. Any INFORMATION message received by the Incoming side, after having sent a CALL PROCEEDING, ALERTING or CONNECT message to the Outgoing side, shall be discarded and no further action shall be taken.

10.1.4.3

10.1.5

Expiry of timer T310 On expiry of T310 (i.e. if the Outgoing Side does not receive an ALERTING, CONNECT, DISCONNECT or PROGRESS message [containing CCITT progress description number 1 “call is not end to end ISDN, further information may be available in band” or number 8 “in band information or appropriate pattern now available”]) the Outgoing Side shall initiate clearing procedures as described in subclause 10.2. The clearing Cause sent to the Incoming Side should be Cause number 102 “Recovery On Timer Expiry”. Call Control shall be notified of the failure of the call.

C a ll c o n f ir m a t io n in d ic a t io n Upon receiving an indication that the called party is alerting, the Incoming Side shall send an ALERTING message to the Outgoing Side and enter the Call Received state. The ALERTING message shall only be sent after a SETUP ACKNOWLEDGE or a CALL PROCEEDING message has been sent across the interface. When the Outgoing Side receives the ALERTING message it shall enter the Call Delivered state, stop T310, if running, and optionally start T301. Any INFORMATION message received by the Incoming side, after having sent a CALL PROCEEDING, ALERTING or CONNECT message to the Outgoing side, shall be discarded and no further action shall be taken. If T301 expires prior to the receipt of a CONNECT message then the Outgoing Side shall clear the call in accordance with the procedures contained in subclause 10.2. The clearing Cause used should be Cause number 19 “No answer from user (user alerted)”.

- 20 -

10.1.6

C a ll c o n n e c t e d Upon receiving an indication from Call Control that the call has been answered and requires through connection in both the backward and forward directions, the Incoming Side shall send a CONNECT message to the Outgoing Side and either: start timer T313 and enter the Connect Request state; or enter the Active state. The CONNECT message shall not be sent before a SETUP ACKNOWLEDGE or a CALL PROCEEDING message has been sent across the interface. The CONNECT message indicates to the Outgoing Side that a connection has been established through the network and stops a possible local indication of alerting. On receipt of the CONNECT message, the Outgoing Side shall: stop T310, T301 or T304 (if running), send a CONNECT ACKNOWLEDGE message to the Incoming Side and enter the Active state. If, on receipt of the CONNECT ACKNOWLEDGE message the Incoming Side is in the Connect Request state, it shall enter the Active state and cancel timer T313. If the Incoming Side is in the Active state when a CONNECT ACKNOWLEDGE message is received, the message shall be ignored. Any INFORMATION message received by the Incoming side, after having sent a CALL PROCEEDING, ALERTING or CONNECT message to the Outgoing side, shall be discarded and no further action shall be taken. If T313 expires prior to the receipt of a CONNECT ACKNOWLEDGE message, then the Incoming Side shall initiate call clearing procedures by sending a DISCONNECT message to the Outgoing Side, as described in subclause 10.2. The Cause value used in this situation should be number 102 “recovery on timer expiry”. NOTE If by mutual agreement T313 is not implemented, the sending of CONNECT ACKNOWLEDGE message is optional.

10.1.7 U s e o f t h e P R O G R ES S m e s s a g e 1 0 . 1 . 7 . 1 D u r in g c a ll e s t a b lis h m e n t During call establishment, the call may leave the PISN environment (e.g. because of interworking with another network). When this situation occurs, a Progress indicator information element containing the appropriate progress description value may be sent over the PISN in the direction of the calling user. Where this indication cannot be sent in a Call Control message (e.g. ALERTING) it shall be sent in a PROGRESS message. On receipt of a PROGRESS message, no state change shall occur, but timer T310 (if running) should be stopped when CCITT progress description number 1 “call is not end to end ISDN, further progress information may be available in-band” , number 2 "destination address is non-ISDN", or number 8 “in-band information or appropriate pattern now available” is received. 10.1.7.2

D u r in g c a ll f a ilu r e If an in-band tone or announcement is to be applied to indicate to the calling user failure of a call which has not yet reached the active state, the Incoming Side shall send a PROGRESS message to ensure that the information channel is through connected from the provider of the tone to the calling user. If an in-band tone or announcement is applied to indicate to a user failure of a call that has reached the Active state, the in-band tone or announcement may be applied without sending a PROGRESS message, as the information channel would already be through connected in both directions. If used, the PROGRESS message shall contain CCITT progress description number 8 “in-band information or appropriate pattern now available” and a Cause information element indicating the failure Cause value. NOTE Normal call clearing will follow later, initiated either by the user receiving the in-band tone or announcement (potentially during the tone or announcement) or by the entity providing the tone or announcement if no clearing indication is received by the user within an appropriate time.

- 21 -

10.1.8

Failure of call establishment In the Call Present, Overlap Receiving, Incoming Call Proceeding or Call Received states, the Incoming Side may initiate clearing as described in subclause 10.2 with Cause. Examples of some of the Causes that may be used to clear the call, when the Incoming Side is in the Call Present, Overlap Receiving, or Incoming Call Proceeding state are as follows: −

number 1 “unassigned (unallocated) number”

−

number 3 “no route to destination”

−

number 17 “user busy”

−

number 18 “no user responding”

−

number 22 “number changed”

−

number 28 “invalid number format”

−

number 34 “no circuit channel available”

−

number 44 “requested circuit channel not available”

−

number 58 “bearer capability not presently available”

−

number 65 “bearer capability not implemented”

Examples of two of the Causes that may be used to clear the call when the Incoming Side is in the Call Received state are as follows:

10.2 10.2.1

−

number 19 “no answer from user (user alerted)”

−

number 21 “call rejected by user”

Call clearing Terminology The following terms are used in this Standard in the description of clearing procedures: − A channel is “connected” when the channel is part of a PISN connection established according to this Standard. − A channel is “disconnected” when the channel is no longer part of a PISN connection, but is not yet available for use in a new connection. − A channel is “released” when the channel is not part of a PISN connection and is available for use in a new connection. Similarly, a call reference that is “released” is available for reuse.

10.2.2

Ex c e p t io n c o n d it io n s Apart from the exceptions listed below, call clearing shall be initiated when the Outgoing Side or the Incoming Side sends a DISCONNECT message and follows the procedures defined in subclause 10.2.3. The exceptions to the above rule are as follows: − The rejection of a SETUP message by the Incoming Side when no responding message has previously been sent (e.g. because of the unavailability of a suitable information channel) shall be accomplished by returning a RELEASE COMPLETE message, releasing the call reference, and entering the null state. − Unsuccessful termination of the information channel selection procedure by the side offering the call shall be accomplished by sending a RELEASE message to the other side. The RELEASE message shall contain a cause value appropriate to the clearing circumstances. For example cause number 6 “channel unacceptable” or cause number 82 “identified channel does not exist”. − During call establishment, call clearing may be initiated towards the called user before a information channel has been agreed between the Outgoing and Incoming Sides. In this case, clearing shall be accomplished by sending either a DISCONNECT or a RELEASE message containing a Cause

- 22 -

information element to the Incoming Side. The Cause value used shall be appropriate to the clearing circumstances. For example, if the failure was due to the calling user clearing before the call reaches its destination node, the Cause value would be the value supplied by the calling user, e.g. Cause number 31 “normal, unspecified”. 10.2.3

C le a r in g Apart from the exceptions identified in subclauses 10.2.2 and 9.2, the clearing procedures are symmetrical and may be initiated by either the Outgoing or the Incoming Side. In the interest of clarity, the following procedures describe only the case where the Outgoing Side initiates clearing. On sending or receiving any call clearing message, any protocol timer other than T305 or T308 shall be terminated. The Outgoing Side shall initiate clearing by: sending a DISCONNECT message; starting timer T305; disconnecting the information channel(s); and entering the Disconnect Request state. Following the receipt of the DISCONNECT message, the Incoming Side shall consider the call to be in the Disconnect Indication state. On receipt of the DISCONNECT message the Incoming Side shall: disconnect the information channel(s) used in the call; send a RELEASE message to the Outgoing Side; start timer T308; and enter the Release Request state. On receipt of the RELEASE message the Outgoing Side shall: cancel timer T305; release the information channel(s); send a RELEASE COMPLETE message; release the call reference; and return to the Null state. On receipt of a RELEASE COMPLETE message from the Outgoing Side, the Incoming Side shall: stop timer T308; release both the information channel(s) and the call reference; and return to the Null state. If the Outgoing Side does not receive a RELEASE message in response to the DISCONNECT message before timer T305 expires, it shall send a RELEASE message to the Incoming Side with the Cause number originally contained in the DISCONNECT message, start timer T308 and enter the Release Request state. If in the Release Request state, a RELEASE COMPLETE message is not received before the first expiry of timer T308, the RELEASE message shall be retransmitted and timer T308 shall be restarted. If no RELEASE COMPLETE message is received before timer T308 expires a second time, the side that expected the message shall; place the information channel(s) in a maintenance condition; release the call reference; and return to the Null state.

10.2.4

Clear collision Clear Collision occurs when both the Incoming and Outgoing Sides simultaneously transfer DISCONNECT messages specifying the same call reference value. When either side receives a DISCONNECT message whilst in the Disconnect Request state, the side shall stop timer T305; disconnect the information channel(s) (if not already disconnected); send a RELEASE message to the other side; start timer T308 and enter the Release Request state. Clear collision can also occur when both sides simultaneously transfer RELEASE messages related to the same call reference value. The receiving side shall (on receiving such a RELEASE message in the Release request state) stop T308; release the call reference and information channel(s); and enter the null state (without sending a RELEASE COMPLETE message).

10.3

Call collisions In symmetric arrangements, call collisions can occur when both sides simultaneously transfer a SETUP message indicating the same channel or, in the case where multiple channels are indicated, one or more channels indicated by both sides. One side shall be designated side “A” and the other side “B” at the time the network is provisioned. Each side shall have knowledge of whether it has been designated “A” or “B”. In the three possible scenarios where the same channel or channels have been indicated by both sides, the following procedure shall apply: − “A” side preferred, “B” side preferred: The “A” side shall be awarded the channel(s), and alternative channel(s) (if free channels exist) shall be indicated in the first response to the SETUP message sent from side “B”.

- 23 -

− “A” side exclusive, “B” side exclusive: The “A” side shall be awarded the channel(s), and the call establishment attempt at side “B” shall be cleared with a RELEASE COMPLETE message. The Cause used shall be Cause number 44 “requested circuit/channel not available”. − “A” side exclusive, “B” side preferred; or “A” side preferred, “B” side exclusive: The side with an exclusive channel indicator in a SETUP message shall be awarded the channel(s) and one or more alternative channel(s) (assuming free channels exist) shall be indicated in the first response to the side that used a preferred indicator in the SETUP message. In order to minimise the chances of call collisions, it is recommended that side “A” assign the lowest available channel numbers and that side “B” assign the highest available channel numbers.

10.4

Transit PINX Call Control requirements NOTE The provision of transit PINX functionality is an option. When provided, the procedures contained herein are mandatory. This clause specifies those aspects of call control at a Transit PINX that are necessary for coordinating the incoming side and outgoing side protocol entities. These procedures refer to the Preceding PINX and the Subsequent PINX. These PINX’s are either side of Transit PINX. This terminology is used in order to clarify the text. The adjectives (Preceding/Subsequent) only have meaning when used in the context of a particular call. The call attempt will have passed from the Preceding PINX, through the Transit PINX, to the Subsequent PINX. Figure 3 shows the conceptual relationship between the Call Control and Incoming and Outgoing Protocol Control within a Transit PINX. Preceding PINX

Transit PINX

Subsequent PINX

Transit Call Control

Incoming Protocol control

Outgoing Protocol control

F ig u r e 3 - C o n c e p t u a l r e la t io n s h ip o f C a ll C o n t r o l t o P r o t o c o l C o n t r o l The Transit PINX’s Call Control states used in this clause are a different set of states from the Protocol States described in earlier clauses. The Transit PINX’s Call Control states are marked as such by “TCC_” in front of their names. These states are conceptual and used only as an aid to description of the actions required at a Transit PINX. As such, they are not directly visible in the protocol and cannot be tested directly. A short description of each of the states is given in subclause 7.1. On receipt of a SETUP message (possibly followed by one or more INFORMATION messages containing additional Called party number information) if the Call Control of the PINX chooses to route the call onwards on a further inter-PINX link employing PSS1 signalling, it shall conform to the procedures for a Transit PINX contained in this clause. The procedures defined in this clause show how the message flows of the two interfaces either side of a Transit PINX are interrelated. Detailed specification and description language (SDL) diagrams for the procedures specified in this clause are contained in annex F. 10.4.1

Receipt of address information On receipt of a SETUP message from the Preceding PINX, the call request shall be processed.

- 24 -

If the call processing is successful, and the Transit PINX determines that all the address information has been received in the SETUP message, a CALL PROCEEDING message shall be sent to the Preceding PINX, a SETUP message shall be sent to the Subsequent PINX, and the Transit PINX shall enter the TCC_Incoming_Call_Proceeding State. If the call processing is successful, and the Transit PINX determines that not all the address information has been received in the SETUP message or cannot determine that the address information is complete, a SETUP ACKNOWLEDGE message shall be sent to the Preceding PINX. If enough digits have been received to route the call a SETUP message shall be sent by the Transit PINX to the subsequent PINX and the Transit PINX shall enter the TCC_Await_Additional_Digits state; else the Transit PINX shall enter the TCC_Await_Digits state. NOTE The method by which the Transit PINX determines that the address information is adequate for the particular use is beyond the scope of this Standard. If the call processing is not successful, then a RELEASE COMPLETE message shall be sent to the Preceding PINX, and the Transit PINX shall remain in the TCC_Idle state. 10.4.2

S t a t e TC C _ A wa it _ D ig it s Additional address information is received in INFORMATION messages. Once enough address information has been received in order to route the call, a SETUP message shall be sent to the Subsequent PINX. If, on analysis of the digits, the Transit PINX identifies that there are no more digits expected, a CALL PROCEEDING message shall be sent to the preceding PINX and the Transit PINX shall enter the TCC_Incoming_Call_Proceeding state; otherwise the Transit PINX shall enter the TCC_Await_Additional_Digits state. NOTE The method by which the Transit PINX determines that the address information is adequate for the particular use is beyond the scope of this Standard. If a DISCONNECT message is received from the Preceding PINX, the call shall be cleared as described in clause 10.4.10. If a RELEASE or RELEASE COMPLETE message is received from the Preceding PINX, the call shall be cleared as described in subclause 10.4.10. If, for any reason, the Transit PINX decides to abort the call, it shall clear the call by sending a DISCONNECT message to the Preceding PINX and continuing normal clearing procedures as described in subclause 10.4.10. If the Protocol Control of the Incoming Side of the interface notifies the Transit Call Control that T302 has expired, then the PINX may either clear the call by sending DISCONNECT to the Preceding PINX, or attempt some other (unspecified) procedure.

10.4.3

S t a t e TC C _ A wa it _ A d d it io n a l_ D ig it s Any additional address information which is received in INFORMATION messages shall be buffered in the Transit PINX whilst waiting for a response to the SETUP message that has been sent to the Subsequent PINX. If the Transit PINX determines that the address information it has received is complete (e.g. on receipt of CALL PROCEEDING from the Subsequent PINX, on receipt of a Sending complete information element from the Preceding PINX, or by digit analysis), a CALL PROCEEDING message shall be sent to the preceding PINX and the Transit PINX shall enter the TCC_Incoming_Call_Proceeding state; otherwise it shall remain in the TCC_Await_Additional_Digits state. If a SETUP ACKNOWLEDGE message is received from the Subsequent PINX, and the channel(s) indicated are acceptable, then the Transit PINX shall enter the TCC_Overlap state and may through connect the information channel(s). Any buffered address information shall be forwarded to the subsequent PINX in an INFORMATION message. If the channel(s) indicated are not acceptable, the call shall be cleared towards the Subsequent PINX using a RELEASE message and the PINX shall either clear the call towards the Preceding PINX using a DISCONNECT message, or may attempt some other (unspecified) procedure.

- 25 -

If a RELEASE COMPLETE message is received from the Subsequent PINX the call may either be cleared as described in clause 10.4.10, or the PINX may attempt some other (unspecified) procedure. If a CALL PROCEEDING message is received from the Subsequent PINX and the channel(s) indicated are acceptable, no more address information shall be sent to the Subsequent PINX, and the Transit PINX shall enter the TCC_Transit_Call_Proceeding state and may through connect the information channel(s). Any buffered address information shall be discarded and any further INFORMATION messages received shall be ignored. If the channel(s) indicated are not acceptable the call shall be cleared towards the Subsequent PINX using a RELEASE message and the PINX shall either clear the call towards the Preceding PINX using a DISCONNECT message, or may attempt some other (unspecified) procedure. If a DISCONNECT message is received from the Preceding PINX, the call shall be cleared as described in clause 10.4.10. If a RELEASE or RELEASE COMPLETE message is received from the Preceding PINX, the call shall be cleared as described in subclause 10.4.10. If an ALERTING message is received from the Subsequent PINX and the channel(s) indicated are acceptable, the transit node may through connect the information channel(s). An ALERTING message shall be sent to the Preceding PINX and the Transit PINX shall enter the TCC_Call_Alerting state. If the received ALERTING message contained CCITT progress description number 1 “call is not end to end ISDN, further information may be available in band” or number 8 “in band information or appropriate pattern now available”, the information channel(s) shall be through connected in the backward direction, if this has not already occurred. If the channel(s) indicated are not acceptable the call shall be cleared towards the Subsequent PINX using a RELEASE message and the PINX shall either clear the call towards the Preceding PINX as described in subclause 10.4.10, or may attempt some other (unspecified) procedure. If a CONNECT message is received from the Subsequent PINX and the channel(s) indicated are acceptable, the transit node shall through connect the information channel(s) (in both directions) - if not already connected - send an CONNECT message to the Preceding PINX and enter the TCC_Call_Active state. If the channel(s) indicated are not acceptable the call shall be cleared towards the Subsequent PINX using a RELEASE message and the PINX shall either clear the call towards the Preceding PINX as described in clause 10.4.10, or may attempt some other (unspecified) procedure. If, for any reason, the Transit PINX decides to abort the call, it shall clear the call in both directions as described in subclause 10.4.10. If the Protocol Control of the Incoming Side of the interface notifies Transit Call Control that T302 has expired, then the PINX shall either send a CALL PROCEEDING message to the Preceding PINX and enter the TCC_Incoming_Call_Proceeding state, or may attempt some other (unspecified) procedure. 10.4.4

S t a t e TC C _ O v e r la p Any additional address information which is received in INFORMATION messages shall be sent on to the Subsequent PINX in INFORMATION messages. If it is known that the address information is complete, a Sending complete information element may optionally be sent in an INFORMATION message. If a CALL PROCEEDING message is received from the Subsequent PINX, no more address information shall be sent to the Subsequent PINX, and the Transit PINX shall enter the TCC_Transit_Call_Proceeding state. If the Transit PINX determines that it has received all the address information (e.g. on receipt of CALL PROCEEDING from the Subsequent PINX, on receipt of a Sending complete information element from the Preceding PINX, or by digit analysis) a CALL PROCEEDING message shall be sent to the Preceding PINX, and the Transit PINX shall enter the TCC_Transit_Call_Proceeding state; else it shall stay in the TCC_Overlap state. If a PROGRESS message is received from the Subsequent PINX, a PROGRESS message shall be sent to the Preceding PINX. If this message contains CCITT progress description number 1 “call is not end to end ISDN, further information may be available in band” or number 8 “in band information or appropriate pattern now available”, the information channel(s) shall be through connected in the backward direction, if this has not already occurred.

- 26 -

If an ALERTING message is received from the Subsequent PINX an ALERTING message shall be sent to the Preceding PINX, and the Transit PINX shall enter the TCC_Call_Alerting state. If this message contains CCITT progress description number 1 “call is not end to end ISDN, further information may be available in band” or number 8 “in band information or appropriate pattern now available”, the information channel(s) shall be through connected in the backward direction, if this has not already occurred. If a CONNECT message is received from the Subsequent PINX, a CONNECT message shall be sent to the Preceding PINX and the PINX shall through connect the information channel(s) in both directions (unless it has already done so) and enter the TCC_Call_Active state. If a DISCONNECT message is received from the Preceding PINX the call shall be cleared as described in subclause 10.4.10. If a DISCONNECT message is received from the Subsequent PINX the call may either be cleared as described in subclause 10.4.10, or other procedures may be attempted by the Transit PINX; however, the clearing sequence with the subsequent PINX shall be completed as described in subclause 10.4.10. If a RELEASE or RELEASE COMPLETE message is received from the Preceding PINX the call shall be cleared as described in subclause 10.4.10. If a RELEASE or RELEASE COMPLETE message is received from the Subsequent PINX’s the call may either be cleared using procedures as described in subclause 10.4.10, or other procedures may be attempted by the Transit PINX. If the Protocol Control of the Incoming Side of the interface notifies the Transit Call Control that T302 has expired, then the PINX shall either send a CALL PROCEEDING message to the Preceding PINX and enter the TCC_Transit_Call_Proceeding state, or attempt some other (unspecified) procedure. If, for any reason, the Transit PINX decides to abort the call, it shall clear the call in both directions as described in subclause 10.4.10. 10.4.5

Channel through connection procedures During call setup, the Transit PINX shall through connect the agreed information channel(s) to the Subsequent PINX as outlined below. The earliest point at which through connection may occur (in either forward, backward or both directions) is when the Transit PINX receives the first response to an outgoing SETUP message. The latest point that through connection in the backward direction shall occur is on receipt of ALERTING or PROGRESS message (with CCITT progress description number 1 “call is not end to end ISDN, further information may be available in band” or number 8 “in band information or appropriate pattern now available”) or CONNECT from the Subsequent PINX. The latest point that through connection in the forward direction shall occur is on the receipt of a CONNECT message from the subsequent PINX. NOTE It is recommended that through connection in both directions is achieved as early as possible during call set up. This is particularly appropriate for services providing the conveyance of speech information. Delaying through connection, particularly in the backward direction, to a later stage during call setup may lead to “speech clipping”.

10.4.6

State TCC_Incoming_Call_Proceeding If a SETUP ACKNOWLEDGE message is received from the Subsequent PINX and the channel(s) indicated are acceptable, the Transit PINX may through connect the information channel(s) and shall enter the TCC_Transit_Call_Proceeding state. If the channel(s) indicated are not acceptable, the call shall be cleared towards the Subsequent PINX using a RELEASE message and the PINX shall either clear the call towards the Preceding PINX using a DISCONNECT message, or may attempt some other (unspecified) procedure. If a RELEASE COMPLETE message is received from the Subsequent PINX the call shall either be cleared using procedures as described in subclause 10.4.10, or other procedures may be attempted by the Transit PINX.

- 27 -

If a CALL PROCEEDING message is received from the Subsequent PINX and the channel(s) indicated are acceptable, the Transit PINX may through connect the information channel(s) and shall enter the TCC_Transit_Call_Proceeding state. If any further INFORMATION messages are received they shall be ignored. If the channel(s) indicated are not acceptable, the call shall be cleared towards the Subsequent PINX using a RELEASE message. The PINX shall either clear the call towards the Preceding PINX using a DISCONNECT message, or may attempt some other (unspecified) procedure. If an ALERTING message is received from the subsequent PINX and, if one or more channels are indicated in the ALERTING message, the indicated channel number(s) are acceptable, an ALERTING message shall be sent to the Preceding PINX. The Transit PINX shall enter the TCC_Call_Alerting state. If the received ALERTING message contains CCITT progress description number 1 “call is not end to end ISDN, further information may be available in band” or number 8 “in band information or appropriate pattern now available”, the information channel(s) should be through connected in the backward direction if this has not already occurred. If one or more channels are indicated and are not acceptable, the call shall be cleared towards the Subsequent PINX using a RELEASE message. The PINX shall either clear the call towards the Preceding PINX as described in clause 10.4.10, or may attempt some other (unspecified) procedure. If a CONNECT message is received from the subsequent PINX and, if one or more channels are indicated in the CONNECT message, the indicated channel numbers are acceptable, a CONNECT message shall be sent to the Preceding PINX. The Transit PINX shall through connect the information channel(s) in both directions (unless it has already done so) and enter the TCC_Call_Active state. If a one or more channels are indicated and are not acceptable, the call shall be cleared towards the Subsequent PINX using a RELEASE message. The PINX shall either clear the call towards the Preceding PINX as described in clause 10.4.10, or may attempt some other (unspecified) procedure. If a DISCONNECT message is received from the Preceding PINX the call shall be cleared as described in subclause 10.4.10. If a RELEASE or RELEASE COMPLETE message is received from the Preceding PINX the call shall be cleared as described in subclause 10.4.10. If, for any reason, the Transit PINX decides to abort the call, it shall clear the call in both directions as described in subclause 10.4.10. 10.4.7

State TCC_Transit_Call_Proceeding If a PROGRESS message is received from the Subsequent PINX a PROGRESS message shall be sent to the Preceding PINX. If this message contains CCITT progress description number 1 “call is not end to end ISDN, further information may be available in band” or number 8 “in band information or appropriate pattern now available”, the information channel(s) shall be through connected in the backward direction if this has not already occurred. If a CALL PROCEEDING message is received from the Subsequent PINX, the Transit PINX shall remain in the TCC_Transit_Call_Proceeding state. If any further INFORMATION messages are received they shall be ignored. If an ALERTING message is received from the Subsequent PINX an ALERTING message shall be sent to the Preceding PINX, and the Transit PINX shall enter the TCC_Call_Alerting state. If this message contains CCITT progress description number 1 “call is not end to end ISDN, further information may be available in band” or number 8 “in band information or appropriate pattern now available”, the information channel(s) shall be through connected in the backward direction, if this has not already occurred. If a CONNECT message is received from the Subsequent PINX, a CONNECT message shall be sent to the Preceding PINX and the Transit PINX shall through connect the information channel(s) in both directions (unless it has already done so) and enter the TCC_Call_Active state. If a DISCONNECT message is received from the Preceding PINX the call shall be cleared as described in subclause 10.4.10. If a DISCONNECT message is received from the Subsequent PINX, the call shall either be cleared using procedures as described in subclause 10.4.10, or other procedures may be attempted by the Transit PINX.

- 28 -

If a RELEASE or RELEASE COMPLETE message is received from the Preceding PINX the call shall be cleared as described in subclause 10.4.10. If a RELEASE or RELEASE COMPLETE message is received from the Subsequent PINX the call shall either be cleared using procedures as described in subclause 10.4.10, or other procedures may be attempted by the Transit PINX. If, for any reason, the Transit PINX decides to abort the call, it shall clear the call in both directions as described in subclause 10.4.10. 10.4.8

S t a t e TC C _ C a ll_ A le r t in g If a PROGRESS message is received from the Subsequent PINX a PROGRESS message shall be sent to the Preceding PINX. If this message contains CCITT progress description number 1 or number 8, the information channel(s) shall be through connected in the backward direction if this has not already occurred. If a CONNECT message is received from the Subsequent PINX a CONNECT message shall be sent to the Preceding PINX and the Transit PINX shall through connect the information channel(s) in both directions (unless it has already done so) and enter the TCC_Call_Active state. If a DISCONNECT message is received from the Preceding PINX the call shall be cleared as described in clause 10.4.10. If a DISCONNECT message is received from the Subsequent PINX the call shall be cleared as described in clause 10.4.10. If a RELEASE or RELEASE COMPLETE message is received from the Preceding PINX the call shall be cleared as described in subclause 10.4.10. If a RELEASE or RELEASE COMPLETE message is received from the Subsequent PINX the call shall be cleared as described in subclause 10.4.10. If, for any reason, the Transit PINX decides to abort the call, it shall clear the call in both directions as described in subclause 10.4.10.

10.4.9

S t a t e TC C _ C a ll_ A c t iv e If a DISCONNECT message is received from either the Preceding or Subsequent PINX’s, the call shall be cleared as described in subclause 10.4.10. If a RELEASE or RELEASE COMPLETE message is received from either the Preceding or Subsequent PINX’s, the call shall be cleared as described in subclause 10.4.10. If a PROGRESS message is received from the Subsequent PINX a PROGRESS message shall be sent to the Preceding PINX. NOTE 1 As an alternative procedure, the Transit PINX may discard a PROGRESS message received from the Subsequent PINX without sending a PROGRESS message to the Preceding PINX. However, this procedure is not recommended. If a PROGRESS message is received from the Preceding PINX a PROGRESS message shall be sent to the Subsequent PINX. NOTE 2 As an alternative procedure, the Transit PINX may discard a PROGRESS message received from the Preceding PINX without sending a PROGRESS message to the Subsequent PINX. However, this procedure is not recommended. If, for any reason, the Transit PINX decides to abort the call, it shall clear the call in both directions as described in subclause 10.4.10.

- 29 -

1 0 . 4 . 1 0 C a ll c le a r in g a t a Tr a n s it P I N X 1 0 . 4 . 1 0 . 1 C a ll c le a r in g n o t in it ia t e d b y t h e Tr a n s it P I N X On receipt of a DISCONNECT, RELEASE or RELEASE COMPLETE message from the Preceding PINX, the Transit PINX shall: – if the information channel(s) to be used have been agreed between the Outgoing Side of the Transit PINX and the Incoming Side of the Subsequent PINX, disconnect the appropriate information channel(s), and send a DISCONNECT message to the Subsequent PINX. If a DISCONNECT message was received from the Preceding PINX, a RELEASE message shall be sent to the Preceding PINX. The Transit PINX shall enter the TCC_Await_Outgoing_Release state. When a RELEASE message is received from the Subsequent PINX the Transit PINX shall release any assigned resources and revert to the TCC_Idle state. – if the information channel(s) to be used have not been agreed between the Outgoing Side of the Transit PINX and the Incoming Side of the Subsequent PINX (i.e. the first response to an outgoing SETUP message has not been received), proceed according to the current Call Control state: i) If Call Control is in either of the TCC_Await_Additional_Digits TCC_Incoming_Call_Proceeding states, the Transit PINX shall either send:

− a RELEASE message to the Subsequent PINX. If DISCONNECT was received from the Preceding PINX, a RELEASE message shall be sent to the Preceding PINX. The Transit PINX shall enter the TCC_Idle state; or, − a DISCONNECT message to the Subsequent PINX. If DISCONNECT was received from the Preceding PINX, a RELEASE message shall be sent to the Preceding PINX. The Transit PINX shall enter the TCC_Await_Outgoing_Release state. ii) if Call Control is in the TCC_Await_Digits state, the Transit PINX shall send a RELEASE message to the Preceding PINX (if DISCONNECT was received from the Preceding PINX) and enter the TCC_Idle state. On receipt of a DISCONNECT, RELEASE or RELEASE COMPLETE message from the Subsequent PINX, the Transit PINX shall disconnect the appropriate information channel(s) and send a DISCONNECT message to the Preceding PINX. Alternatively, during call establishment, if the call has not yet reached the TCC_Call_Alerting state, the Transit PINX may attempt some other (unspecified) procedure instead of sending DISCONNECT to the Preceding PINX. If a DISCONNECT message was received from the Subsequent PINX, the Transit PINX shall send a RELEASE message to the Subsequent PINX. If a DISCONNECT message was sent to the Preceding PINX, the Transit PINX shall enter the TCC_Await_Incoming_Release state. When a RELEASE message is received from the Preceding PINX, the Transit PINX shall release any assigned resources and revert to the TCC_Idle state. 1 0 . 4 . 1 0 . 2 C a ll c le a r in g in it ia t e d b y t h e Tr a n s it P I N X If a Transit PINX decides to abort a call it may send, in both directions, a clearing message appropriate to the current Protocol Control state. Each side of the PINX shall then continue normal clearing procedures independently of the other. Alternatively, where an in-band tone or announcement is appropriate (i.e. if it conveys information which is not conveyable by PSS1), the Transit PINX, instead of sending a clearing message, may connect an in-band tone or announcement to either (or both) sides of the PINX and transmit a PROGRESS message, containing CCITT progress description number 8 “in band information or appropriate pattern now available” and an appropriate Cause. If Call Control is in the TCC_Call_Active state, the announcement may optionally be applied without sending a PROGRESS message, as the information channel(s) will be through connected in both directions at this stage. Call Control of the Transit PINX shall ensure that, for each side, if an indication of clearing has not been received by the time the tone or announcement is complete (or has been applied for sufficient time), normal clearing procedures (described in subclause 10.4.10) shall be invoked.

- 30 -

10.4.11 Handling of Basic Call information elements at a Transit PINX This clause applies only to information elements which are contained within messages and which may (but need not) be passed on by a Transit PINX. (Examples of these messages are SETUP, INFORMATION, ALERTING, CONNECT, PROGRESS and DISCONNECT). 10.4.11.1 Mandatory information elements All mandatory information elements will (by definition) appear in messages on both sides of the Transit PINX. Where necessary they will be processed within Transit PINX and may be different either side of the PINX. 10.4.11.2 Non-mandatory information elements Non-mandatory information elements fall into three categories: Category 1: If they are present, they shall be processed in the Transit PINX and shall be passed on to the next PINX if the message is passed on. They may be locally generated. Category 2: If they are present, they shall not be processed at a Transit PINX and shall be passed transparently onto the next PINX. Category 3: If they are present, they shall be processed at the Transit PINX and may be passed on to the next PINX. They may be locally generated. The three categories are identified using their information element identifiers. Table 3 defines to which of the three categories each of the non-mandatory information elements belong. Table 3 - Non-mandatory information element categories Information Element

Category 1

Called party number

•

Called party subaddress Calling party number

Category 2

May be modified

•

May be modified •

Cause (in PROGRESS)

•

Connected number

•

May be modified

Connected subaddress

•

High layer compatibility

•

Low layer compatibility

• •

Sending complete

10.5

Notes

•

Calling party subaddress

Progress indicator

Category 3

•

Originating PINX Call Control requirements This clause specifies requirements for Call Control at an Originating PINX on the Outgoing Side of an Inter PINX link. These requirements are additional to the Protocol Control procedures specified in clauses 9, 10.1 to 10.3 and 12. The following requirements apply when an Originating PINX chooses to route a call over an Inter PINX link employing PSS1 signalling and has selected a information channel to be used. Any reference to messages received shall be interpreted as meaning a message which has passed the validation checks of Protocol Control and which has therefore resulted in a notification being given to Call Control.

- 31 -

10.5.1

Tr a n s m is s io n o f t h e S ETU P m e s s a g e The Originating PINX shall transmit a SETUP message. The SETUP message shall include optional information elements according to the following rules. a) Sending complete. The Originating PINX may optionally send this information element if it can determine that the number in the Called party number information element is complete or if this has been indicated by the calling terminal. b) Progress indicator. The Originating PINX shall pass on, by means of the Progress indicator information element, progress information received from the calling user. The Originating PINX may insert a Progress indicator information element containing CCITT progress description 3 “Origination address is non-ISDN” if neither the calling terminal nor the combination of the PINX and the calling terminal has the functionality of an ISDN terminal. c) Calling party number. The Originating PINX shall include the calling party number information element identifying the calling user. The presentation indicator shall have the value “presentation restricted” if supplementary service Calling/Connected Line Identification Restriction (see ECMA148) has been invoked at the calling user. Otherwise the presentation indicator, if present, shall have the value "presentation allowed". d) Calling party subaddress. The Originating PINX shall include the calling party subaddress information element if a calling party subaddress is available. e) Called party subaddress. The Originating PINX shall include the called party subaddress information element if a called party subaddress is available. f) Low layer compatibility. The Originating PINX shall include the low layer compatibility information element if low layer compatibility information is available. g) High layer compatibility. The Originating PINX shall include the high layer compatibility information element if high layer compatibility information is available.

10.5.2

Agreement of the information channel On receipt of a SETUP ACKNOWLEDGE, CALL PROCEEDING, ALERTING or CONNECT message agreeing the channel(s) proposed in the SETUP message or suggesting one or more alternative channels which the Originating PINX finds acceptable, the Originating PINX may optionally connect the information channel(s) in the forward direction, in the backward direction or in both directions. NOTE 1 It is recommended that information channel(s) are connected in both directions at this stage, particularly for services involving the conveyance of speech information. Leaving the information channel(s) unconnected until a later stage, particularly in the backward direction, may lead to the “clipping” of speech. However, there may be reasons for delaying connection, particularly in the forward direction, e.g., to avoid the onward transmission of in-band signalling information from the user's access. NOTE 2 If the received message is an ALERTING or CONNECT message, 10.5.4 or 10.5.5 shall apply, respectively.

10.5.3

Receipt of Progress indicators Information received in a Progress indicator information element in a PROGRESS message, an ALERTING message or a CONNECT message, shall be conveyed to the calling user - dependent on the ability of the calling user's equipment to receive such information. On receipt of a Progress indicator information element with CCITT progress description number 8 “inband information or appropriate pattern now available” or CCITT progress description number 1 “call is not end-to-end ISDN, further call progress information may be available in-band” the Originating PINX shall connect the information channel(s) in the backward direction if it has not already done so.

10.5.4

Receipt of ALERTING message On receipt of an ALERTING message, an indication of alerting may be given to the calling user.

- 32 -

Through connection may occur at this point. If the received message contains a Progress indicator information element with CCITT progress description number 8 “in-band information or appropriate pattern now available” or CCITT progress description number 1 “call is not end-to-end ISDN, further call progress information may be available in-band” the Originating PINX shall connect the information channel(s) in the backward direction if it has not already done so. 10.5.5

Receipt of CONNECT message On receipt of a CONNECT message, the Originating PINX shall connect the information channel(s) in both directions, if it has not already done so, and shall indicate connection to the calling user. If the CONNECT message contains a Connected number information element and/or a Connected subaddress information element, this information may be used for purposes such as the provision of the Connected Line Identification Presentation supplementary service to the calling user. If the CONNECT message contains a Low Layer Compatibility information element, the information may be passed on to the calling user.

10.5.6

Call clearing initiated by the Originating PINX The Originating PINX may initiate clearing on the inter-PINX link employing PSS1 signalling if a clear request is received from the calling user or if a failure condition occurs. Clearing is initiated by informing Protocol Control and supplying a Cause. Alternatively, for services for which an in-band tone or announcement is appropriate, the Originating PINX may connect an in-band tone or announcement to the outgoing information channel(s) and may optionally transmit a PROGRESS message containing a Progress indicator information element with CCITT progress description 8 “in-band information or appropriate pattern now available” and an appropriate Cause. If an indication of clearing has not been received from Protocol Control by the time the tone or announcement is complete or has been applied for sufficient time, the Originating PINX shall instruct Protocol Control to initiate clearing. NOTE It is recommended that an in-band tone or announcement be provided by the Originating PINX only if it conveys call failure information which is not conveyable by PSS1.

10.5.7

10.6

Receipt of an indication of call clearing On receipt of an indication of call clearing from Protocol Control, the Originating PINX shall either indicate to the calling user that the call has cleared or take some other implementation dependent action.

Terminating PINX Call Control requirements This clause specifies requirements for Call Control at a Terminating PINX on the Incoming Side of an inter-PINX link. These requirements are additional to the Protocol Control procedures specified in clauses 9, 10.1 to 10.3 and 12. NOTE If enbloc signalling only is used between two adjacent PINXs, overlap receiving procedures need not be tested. The following requirements apply when a PINX receives a SETUP message, possibly followed by one or more INFORMATION messages conveying additional Called party number information, and determines that the destination is a user on that PINX. The PINX therefore becomes a Terminating PINX. Any reference to messages received shall be interpreted as meaning a message which has passed the validation checks of Protocol Control and which has therefore resulted in a notification being given to Call Control.

10.6.1

Receipt of the SETUP message Optional information elements in the received SETUP message shall be used as follows. a) Progress indicator. If the SETUP message contains a Progress indicator information element, the information therein may optionally be passed on to the called user. b) Low layer compatibility, high layer compatibility and called party subaddress. If the SETUP message contains one or more of these information elements, and if the user is connected by means of an

- 33 -

ISDN interface at the S reference point, the information element(s) shall be conveyed to the called user and the user may act upon the information therein. If the user is connected by means of a nonISDN interface, conveyance of the information to the user depends on the user's ability to receive it. c) Calling party number and calling party subaddress. Information in the calling party number information element, and also in the optional calling party subaddress information element, may be used for purposes such as the provision of the Calling Line Identification Presentation supplementary service to the called user. 10.6.2

Tr a n s m is s io n o f A LER TI N G m e s s a g e The Terminating PINX shall transmit an ALERTING message when it is aware that the called user is being alerted. For services which require an in-band tone or announcement to be supplied to the calling user during the period of alerting, the Terminating PINX is responsible for connecting the appropriate tone or announcement to the information channel(s) in the backwards direction. If a tone or announcement is connected, the Terminating PINX shall include a Progress indicator information element with CCITT progress description number 8 “in-band information or appropriate pattern now available” in the ALERTING message.

10.6.3

Tr a n s m is s io n o f P r o g r e s s in d ic a t o r s The Terminating PINX shall pass on, by means of the Progress indicator information element, progress information received from the called user, either before or after the transmission of an ALERTING message. The Terminating PINX may send a Progress indicator information element containing CCITT progress description number 2 “Destination address is non-ISDN” if neither the called terminal nor the combination of the PINX and the called terminal has the functionality of an ISDN terminal. A Progress indicator information element shall be transmitted in an ALERTING message or a CONNECT message if an ALERTING message or a CONNECT message is being sent at the time. Otherwise it shall be transmitted in a PROGRESS message.

10.6.4

Tr a n s m is s io n o f C O N N EC T m e s s a g e When the Terminating PINX is aware that the called user has accepted the call, it shall connect the information channel(s) in both directions and send a CONNECT message. Any in-band tone or announcement shall be disconnected. The Terminating PINX shall include in the CONNECT message the Connected number information element. The presentation indicator shall have the value “presentation restricted” if supplementary service Calling/Connected Line Identification Restriction (see ECMA-148) has been invoked at the called user. Otherwise the presentation indicator, if present, shall have the value "presentation allowed". The Terminating PINX shall include in the CONNECT message the Connected subaddress information element if a Connected subaddress is available. The Terminating PINX may include in the CONNECT message the low layer compatibility information element if low layer compatibility information has been supplied by the called terminal.

10.6.5

C a l l c l e a r i n g i n i t i a t ed b y t h e T e r m i n a t i n g P I N X The Terminating PINX may initiate clearing on the inter-PINX link employing PSS1 signalling if it is not able to proceed with call establishment, if a failure condition occurs after the call has been established, or if a clear request is received from the called user. Clearing is initiated by informing Protocol Control and supplying a Cause. Alternatively, for services for which an in-band tone or announcement is appropriate, the Terminating PINX may connect an in-band tone or announcement to the incoming information channel(s) and transmit a PROGRESS message containing a Progress indicator information element with CCITT progress description 8 “in-band information or appropriate pattern now available” and an appropriate Cause. If an indication of clearing has not been received from Protocol Control by the time the tone or announcement is complete or has been applied for sufficient time, the Terminating PINX shall instruct

- 34 -

Protocol Control to initiate clearing. The sending of the PROGRESS message is optional in the Active state but mandatory in other states. NOTE It is recommended that an in-band tone or announcement be provided by the Terminating PINX only if it conveys call rejection or failure information which is not conveyable by PSS1. 10.6.6

10.7

Receipt of an indication of call clearing On receipt of an indication of call clearing from Protocol Control, the Terminating PINX shall either indicate to the called user that the call has cleared or take some other implementation dependent action.

Incoming Gateway PINX Call Control requirements This clause specifies requirements for Call Control at an Incoming Gateway PINX on the Outgoing Side of an inter-PINX link. These requirements are additional to the Protocol Control procedures specified in clauses 9, 10.1 to 10.3 and 12. The following requirements apply when a call entering the PISN is routed, by the Incoming Gateway PINX, over an inter-PINX link employing PSS1 signalling, an information channel on that link having been selected. Any reference to messages received shall be interpreted as meaning a message which has passed the validation checks of Protocol Control and which has therefore resulted in a notification being given to Call Control.

10.7.1

Tr a n s m is s io n o f t h e S ETU P m e s s a g e The Incoming Gateway PINX shall transmit a SETUP message. The SETUP message shall include optional information elements according to the following rules. a) Sending complete. The Incoming Gateway PINX may optionally send this information element if it can determine that the number in the Called party number information element is complete or if this has been indicated by the other network. b) Progress indicator. The inclusion of a Progress indicator information element by the Incoming Gateway PINX shall be in accordance with clause 10.7.2. c) Calling party number. If the other network has supplied a calling party number with or without an indication that presentation is restricted or a restriction indication only, the Incoming Gateway PINX shall include this information in the SETUP message within the calling party number information element. Otherwise the calling party number information element shall either contain the presentation indicator value “number not available due to interworking” or be omitted. d) Calling party subaddress. If the other network is a public ISDN and supplies a calling party subaddress information element, the Incoming Gateway PINX shall pass on the information element unchanged in the SETUP message. The Incoming Gateway PINX may also include a calling party subaddress information element in the SETUP message if calling party subaddress information has been supplied by a non-ISDN. e) Called party subaddress. If the other network is a public ISDN and supplies a called party subaddress information element, the Incoming Gateway PINX shall pass on the information element unchanged in the SETUP message. The Incoming Gateway PINX may also include a called party subaddress information element in the SETUP message if called party subaddress information has been supplied by a non-ISDN. f) Low layer compatibility. If the other network is a public ISDN and supplies a low layer compatibility information element, the Incoming Gateway PINX shall pass on the information element unchanged in the SETUP message. The Incoming Gateway PINX may also include a low layer compatibility information element in the SETUP message if low layer compatibility information has been supplied by a non-ISDN. g) High layer compatibility. If the other network is a public ISDN and supplies a high layer compatibility information element, the Incoming Gateway PINX shall pass on the information element unchanged in the SETUP message. The Incoming Gateway PINX may also include a high

- 35 -

layer compatibility information element in the SETUP message if high layer compatibility information has been supplied by a non-ISDN. 10.7.2

I n t e r wo r k in g in d ic a t io n s in t h e S ETU P M e s s a g e The inclusion of the Progress indicator information element in the SETUP message shall be as specified below. If none of the specified conditions apply, no Progress indicator information element shall be included.

10.7.2.1

I n t e r w o r k i n g i n d i c a t io n s r e c e i v e d f r o m a p u b l i c I S D N If the call has arrived from a public ISDN and a Progress indicator information element containing one of the following CCITT progress descriptions has been received from the public ISDN, that information element shall be passed on: – 1 “call is not end-to-end ISDN, further call progress information may be available in-band” – 3 “origination address is non-ISDN”

10.7.2.2

I n t e r wo r k in g wit h a n o n - I S D N If the call has entered the PISN from a network (public or private) which is not ISDN, a Progress indicator information element may be sent containing CCITT progress description number 1 “call is not end-to-end ISDN, further call progress information may be available in-band”. NOTE Terminals in the PISN that support only the "Speech" bearer capability can only accept calls indicating either "Speech" bearer capability or "3.1kHz audio" bearer capability together with progress indicator containing CCITT progress description number 1 "call is not end to end ISDN, further call progress information may be available in-band". It is recommended that this is taken into account when providing an incoming gateway function to a non-ISDN network supporting speech based telephony.

10.7.3

Agreement of the information channel On receipt of a SETUP ACKNOWLEDGE, CALL PROCEEDING, ALERTING or CONNECT message agreeing the channel(s) proposed in the SETUP message or suggesting one or more alternative channels which the Incoming Gateway PINX finds acceptable, the Incoming Gateway PINX may optionally connect the information channel(s) in the forward direction, in the backward direction or in both directions. NOTE It is recommended that the information channel(s) are connected in both directions at this stage, particularly for services involving the conveyance of speech information. Leaving the information channel(s) unconnected until a later stage, particularly in the backward direction, may lead to the “clipping” of speech. However, there may be reasons for delaying connection, particularly in the forward direction, e.g., to avoid the onward transmission of in-band signalling information from the other network.

10.7.4

Receipt of Progress indicators Information received in a Progress indicator information element in a PROGRESS message, an ALERTING message, or a CONNECT message shall be passed on to the other network if the signalling system permits and if relevant. On receipt of a Progress indicator information element with CCITT progress description number 8 “inband information or appropriate pattern now available” or CCITT progress description number 1 “call is not end-to-end ISDN, further call progress information may be available in-band” the Incoming Gateway PINX shall connect the information channel(s) in the backward direction if it has not already done so.

10.7.5

Receipt of ALERTING message On receipt of an ALERTING message, an indication of alerting may be given to the other network if the signalling system permits. If the ALERTING message contains a Progress indicator information element with CCITT progress description number 8 “in-band information or appropriate pattern now available” or CCITT progress description number 1 “call is not end-to-end ISDN, further call progress information may be available

- 36 -

in-band” the Incoming Gateway PINX shall connect the information channel(s) in the backward direction if it has not already done so. 10.7.6

Receipt of CONNECT message On receipt of a CONNECT message, the Incoming Gateway PINX shall connect the information channel(s) in both directions, if it has not already done so, and shall indicate connection to the other network if the signalling system permits. If the CONNECT message contains a low layer compatibility information element, the information element shall be conveyed unchanged to the other network if that network is a public ISDN. Where the other network is non-ISDN, low layer compatibility information may be conveyed to the other network if the signalling system permits. If the CONNECT message contains a Connected number information element, conveyance of the information therein to the other network depends on the capability of the signalling system and whether the Connected number has significance in the other network. Translation of a number into the numbering plan of the other network may be performed in order to yield a number which has significance in the other network. If the CONNECT message contains a Connected subaddress information element, the information element shall be conveyed unchanged to the other network if that network is a public ISDN. Where the other network is non-ISDN, Connected subaddress information may be conveyed to the other network if the signalling system permits. If the received Connected number information element has the presentation indicator value “presentation restricted”, presentation of the number to the other network is outside the scope of this Standard, but will depend on such factors as the other network’s commitment to honour the restriction.

10.7.7

Call clearing initiated by the Incoming Gateway PINX The Incoming Gateway PINX may initiate clearing on the inter-PINX link employing PSS1 signalling if a clear request is received from other network or if a failure condition occurs. Clearing is initiated by informing Protocol Control and supplying a Cause. Alternatively, for services for which an in-band tone or announcement is appropriate, the Incoming Gateway PINX may connect an in-band tone or announcement to the outgoing information channel(s) and may optionally transmit a PROGRESS message containing a Progress indicator information element with CCITT progress description number 8 “in-band information or appropriate pattern now available” and an appropriate Cause. In cases where the other network indicates that it is providing an in-band tone or announcement in preparation for clearing, the Incoming Gateway PINX may transmit a PROGRESS message containing a Progress indicator information element with CCITT progress description number 8 “in-band information or appropriate pattern now available”. In all the above cases: – if an indication of clearing has not been received from Protocol Control by the time the tone or announcement is complete or has been applied for sufficient time, the Incoming Gateway PINX shall instruct Protocol Control to initiate clearing. – the sending of the PROGRESS message is optional in the Active state, but mandatory in other call states. NOTE It is recommended that an in-band tone or announcement be provided by the Incoming Gateway PINX only if it conveys call failure information which is not conveyable by PSS1.

10.7.8

Receipt of an indication of call clearing On receipt of an indication of call clearing from Protocol Control, the Incoming Gateway PINX shall either indicate to the other network that the call has cleared or take some other implementation dependent action.

- 37 -

10.8

Outgoing Gateway PINX Call Control requirements This clause specifies requirements for Call Control at an Outgoing Gateway PINX on the Incoming Side of an inter-PINX link. These requirements are additional to the Protocol Control procedures specified in clauses 9, 10.1 to 10.3 and 12. The following requirements apply when a PINX receives a SETUP message, possibly followed by one or more INFORMATION messages conveying additional Called party number information, and determines that the call is to be routed directly (not via any further PINX) to another network. The PINX therefore becomes an Outgoing Gateway PINX. Any reference to messages received shall be interpreted as meaning a message which has passed the validation checks of Protocol Control and which has therefore resulted in a notification being given to Call Control.

10.8.1

Receipt of the SETUP message Information elements in the received SETUP message shall be used as follows. a) Progress indicator. If the SETUP message contains a Progress indicator information element, the information therein shall be passed on to the other network if the signalling system permits and if relevant. b) Low layer compatibility, high layer compatibility, called party subaddress and calling party subaddress. If the SETUP message contains one or more of these information elements, the information element(s) shall be conveyed unchanged to the other network if that network is a public ISDN. Where the other network is non-ISDN, information from these elements may be conveyed to the other network if the signalling system permits. However, the calling party subaddress information element shall not be sent to the network if the presentation indicator in the received calling party number information element has the value “presentation restricted”. c) Calling party number. If the SETUP message contains a calling party number information element, conveyance of the information therein to the other network depends on the capability of the signalling system and whether the calling party number has significance in the other network. Translation of a number into the numbering plan of the other network may be performed in order to yield a number which has significance in the other network. If the received calling party number information element has the presentation indicator value "presentation restricted", presentation of the number to the other network is outside the scope of this Standard, but will depend on such factors as the other network's commitment to honour the restriction.

10.8.2

C o n n e c t io n o f t h e in f o r m a t io n c h a n n e l The Outgoing Gateway PINX may optionally connect the information channel(s) in the forward direction, in the backward direction or in both directions as soon as the channel(s) to the other network have been agreed. NOTE It is recommended that the information channel(s) are connected in both directions at this stage, particularly for services involving the conveyance of speech information. Leaving the information channel(s) unconnected until a later stage, particularly in the backward direction, may lead to the “clipping” of speech or the loss of in-band tones or announcements. However, there may be reasons for delaying connection, particularly in the forward direction, e.g., while transmitting in-band signalling information.

10.8.3

Tr a n s m is s io n o f in t e r wo r k in g in d ic a t io n s The Outgoing Gateway PINX shall transmit Progress indicator information elements as specified below. A Progress indicator information element shall be transmitted in a PROGRESS message, an ALERTING message or a CONNECT message as soon as the information becomes available, subject to a SETUP ACKNOWLEDGE or CALL PROCEEDING message having already been sent. A PROGRESS message shall be used unless an ALERTING or CONNECT message is to be sent at the time. All appropriate interworking indications shall be transmitted by the Outgoing Gateway PINX.

- 38 -

10.8.3.1

I n t e r w o r k i n g i n d i c a t io n s r e c e i v e d f r o m a p u b l i c I S D N If the call has entered a public ISDN and a Progress indicator information element containing one of the following CCITT progress descriptions has been received from the public ISDN, that information element shall be passed on: – 1 “call is not end-to-end ISDN, further call progress information may be available in-band” – 2 “destination address is non-ISDN” – 4 “call has returned to the ISDN” – 8 “in-band information or appropriate pattern now available” In the case of progress description number 1 “call is not end to end ISDN, further information may be available in band” and number 8 “in band information or appropriate pattern now available”, the Outgoing Gateway PINX shall connect the information channel in the backward direction if it has not already done so.

10.8.3.2

10.8.4

I n t e r wo r k in g wit h a n o n - I S D N If the call is to enter a network (public or private) which is not ISDN, a progress indicator information element may be sent containing CCITT progress description number 1 “call is not end-to-end ISDN, further call progress information may be available in-band”. If this Progress indicator information element is sent, the Outgoing Gateway PINX shall connect the information channel in the backward direction if it has not already done so.

Tr a n s m is s io n o f A LER TI N G m e s s a g e The Outgoing Gateway PINX shall transmit an ALERTING message when it receives an indication from the other network that the called user is being alerted. Some other networks may be unable to indicate alerting. For services which require an in-band tone or announcement to be supplied to the calling user during the period of alerting, the Outgoing Gateway PINX is responsible for connecting the appropriate tone or announcement to the information channel(s) in the backwards direction, unless an appropriate tone or announcement is being provided by the other network. If a tone or announcement is being provided either by the Outgoing Gateway PINX or by the other network, the Outgoing Gateway PINX shall include a Progress indicator information element with CCITT progress description 8 “in-band information or appropriate pattern now available” in the ALERTING message.

10.8.5

Tr a n s m is s io n o f C O N N EC T m e s s a g e When the Outgoing Gateway PINX receives an answer signal from the other network, it shall connect the information channel(s) in both directions, if it has not already done so, and send a CONNECT message. If the other network is not always able to supply an indication of call acceptance, the Outgoing Gateway PINX shall connect the information channel(s) in both directions and send a CONNECT message when a suitable time interval has elapsed following the sending of call information to the other network. The time interval chosen should take account of the shortest likely time to indicate the call acceptance. If, subsequent to sending a CONNECT message, an indication of call acceptance is received from the other network, the Outgoing Gateway PINX shall not send a second CONNECT message. If the other network has supplied a Connected number with or without an indication that presentation is restricted or a restriction indication only, the Outgoing Gateway PINX shall include this information in the CONNECT message within the Connected number information element. Otherwise the Connected number information element shall either contain the presentation indicator value “number not available due to interworking” or be omitted. If the other network is a public ISDN and supplies a Connected subaddress information element, the Outgoing Gateway PINX shall pass the information element on unchanged in the CONNECT message. The Outgoing Gateway PINX may also include a Connected subaddress information element in the CONNECT message if Connected subaddress information has been supplied by a non-ISDN. If the other network is a public ISDN and supplies a low layer compatibility information element, the Outgoing Gateway PINX may pass the information element on unchanged in the CONNECT message.

- 39 -

The Outgoing Gateway PINX may also include a low layer compatibility information element in the CONNECT message if low layer compatibility information has been supplied by a non-ISDN. 10.8.6

C a ll c le a r in g in it ia t e d b y t h e O u t g o in g G a t e wa y P I N X The Outgoing Gateway PINX may initiate clearing on the inter-PINX link employing PSS1 signalling if it is not able to proceed with call establishment, if a failure condition occurs after the call has been established, or if a clear request is received from the other network. Clearing is initiated by informing Protocol Control and supplying a Cause. Alternatively, for services for which an in-band tone or announcement is appropriate, the Outgoing Gateway PINX may connect an in-band tone or announcement to the incoming information channel(s) and transmit a PROGRESS message containing a Progress indicator information element with CCITT progress description 8 “in-band information or appropriate pattern now available” and an appropriate Cause. A PROGRESS message containing a Progress indicator information element with CCITT progress description number 8 “in-band information or appropriate pattern now available” may also be sent in cases where the other network indicates that it is providing an in-band tone or announcement in preparation for clearing. In all of the above cases: – If an indication of clearing has not been received from Protocol Control by the time the tone or announcement is complete or has been applied for sufficient time, the Outgoing Gateway PINX shall instruct Protocol Control to initiate clearing. – The sending of the PROGRESS message is optional in the Active state but mandatory in other states. NOTE It is recommended that an in-band tone or announcement be provided by the Outgoing Gateway PINX only if it conveys call rejection or failure information which is not conveyable by PSS1.

10.8.7

Receipt of an indication of call clearing On receipt of an indication of call clearing from Protocol Control, the Outgoing Gateway PINX shall either indicate to the other network that the call has cleared or take some other implementation dependent action.

Procedures for layer management

11.1

Restart procedures The restart procedure may be used to return a single channel, or all channels associated with the signalling channel, to the idle condition and calls associated with these channels to the Null state. The procedure may be invoked when the adjacent PINX does not respond to Call control messages, a failure has occurred or a maintenance action has taken place or for some other (unspecified) reason (e.g. following a SCM failure; or following the second expiry of timer T308 due to the absence of response to a clearing message).

11.1.1

Sending RESTART A RESTART message may be sent by either side in order to return an indicated channel, multiple indicated channels or all channels associated with the signalling channel to the idle state. The Restart indicator information element shall be present in the RESTART message to indicate whether one or more indicated channels or all channels are to be restarted. If the Restart indicator is coded as “indicated channel”, then the Channel identification information element shall be present to indicate which channel(s) are to be returned to the idle condition. In the case where multiple channels (but not all channels associated with the signalling channel) are to be restarted, the Channel identification information element shall be present to indicate the channels to be restarted. If the Restart indicator information element is coded “all channels”, then the Channel identification information element shall not be included. Upon transmitting the RESTART message the sending entity shall enter the Restart Request state, start timer T316, and wait for a RESTART ACKNOWLEDGE message. No further RESTART messages shall be sent until a RESTART ACKNOWLEDGE message is received or timer T316 expires.

- 40 -

Receipt of a RESTART ACKNOWLEDGE message shall stop timer T316, free the channels and Call reference values (associated with the channels identified by the RESTART message) for reuse, and cause the receiving entity to enter the Null state. If a RESTART ACKNOWLEDGE message is not received prior to expiry of timer T316 one or more subsequent RESTART messages may be sent until a RESTART ACKNOWLEDGE message is returned the limit of the number of times RESTART may be sent is implementation dependent. Meanwhile, no calls shall be placed or accepted on the channels identified in the RESTART message by the originator of the message. When the limit for the number of restarts is reached, the originator shall make no further restart attempts. An indication shall be provided to the appropriate maintenance entity. The channels identified shall be considered to be in an out-of-service condition until maintenance action has been taken. The RESTART and RESTART ACKNOWLEDGE messages shall contain the Global call reference value with which the Restart Request state is associated. 11.1.2

Receipt of RESTART Upon receiving a RESTART message the recipient shall enter the Restart state associated with the Global call reference. It shall then initiate the appropriate internal actions to return the specified channels to the idle condition and call reference(s) associated with those channels to the Null state. Upon completion of internal clearing a RESTART ACKNOWLEDGE message shall be transmitted to the originator, and the transmitting entity shall enter the Null state. Even if all Call references are in the Null state and all channels are in the idle condition, the receiving entity shall transmit a RESTART ACKNOWLEDGE message to the originator on receiving a RESTART message. If the Restart indicator information element is coded as “indicated channel” and the Channel identification information element is not included, the procedures of 9.2.6.1 shall apply.

11.1.3

Restart collision Restart collision occurs at Inter-PINX link when both sides of the inter-PINX link simultaneously transmit a RESTART message. The Call reference flag of the Global call reference applies to the restart procedures. In the case when both sides on an inter-PINX link initiate simultaneous restart requests, they shall be handled independently. In the case when the same channel(s) are specified, they shall not be considered for re-use until all the relevant restart procedures are completed.

Protocol timers The protocol timers are defined in table 4. All timer values given in this table have a tolerance of 10%. Legend to table 4, columns 7 and 8: – M

The timer is mandatory

– O

The timer is optional

– M(I) The timer is mandatory if the associated procedures are implemented.

- 41 -

Table 4 - Protocol timer definitions Timer Number

Timer Value

Call State Cause For Start

Normally terminated (note 1, note 2)

Action To Be Incoming Outgoing Taken When side side Timer Expires

T301

note 3

Call Delivered

On CONNECT received

Clear Call as specified in clause 10.1.5

T302

Minimum 14 s, Maximum 16 s

Overlap Receiving

T303 Minimum 4 s, Call Maximum 6 s Initiated

ALERTING received

Sending of On the sending of Clear call if SETUP CALL information is ACKNOWLEDG PROCEEDING, definitely E Restarted on ALERTING or incomplete (as receipt of CONNECT specified in INFORMATION clause 10.1.4.2) message else send CALL PROCEEDING On Sending SETUP

Minimum 20 s

Overlap Sending

On receipt of Retransmit CALL SETUP and PROCEEDING, restart T303, or CONNECT, clear the call as ALERTING, specified in SETUP ACK. or clause 10.1.1 RELEASE COMPLETE

On receipt of CALL PROCEEDING, CONNECT, ALERTING, SETUP ACK. or RELEASE COMPLETE

Clear Call as specified in clause 10.1.1

Receipt of Receiving CALL SETUP ACK. PROCEEDING, Retransmission of ALERTING or INFORMATION CONNECT restarts T304

Clear the call using procedures specified in clause 10.1.3

Second Minimum 4 s, Call On retransmission T303 Maximum 6 s Initiated of SETUP

T304

T305 Minimum 4 s, Disconnect On Sending Maximum Request DISCONNECT 30 s

Receipt of Send RELEASE or RELEASE, start DISCONNECT T308

T308 Minimum 4 s, Release Maximum 6 s Request

On Sending RELEASE

On Receiving RELEASE or RELEASE COM.

Retransmit RELEASE, restart T308

Second Minimum 4 s, Release T308 Maximum 6 s Request

On retransmission of RELEASE

On receiving RELEASE or RELEASE COMPLETE

Release Call Reference; place info channel in maintenance condition. (optionally initiate RESTART procedures)

- 42 -

T309

90 s note 4

Any State

SCM disconnection. Calls in Stable states are not lost

T310

note 5

Outgoing On receipt of Call CALL Proceeding PROCEEDING

On SCM reestablishment

Clear connection, release call reference and info channel

On Receipt of Clear the call as ALERTING, specified in CONNECT, clause 10.1.4.3 PROGRESS (#1, #2 or #8), DISCONNECT or RELEASE

M (Optional for a Transit PINX)

T313 Minimum 4 s, Connect Maximum 6 s Request

On sending CONNECT

On receipt of Clear call as CONNECT specified in ACKNOWLEDGE 10.1.6

T316

120 s

Restart request

On sending of RESTART

On Receipt of RESTART ACKNOWLEDGE

Retransmit RESTART, restart T316

Final T316

120 s

Restart request

On Final On Receipt of Notify retransmission of RESTART maintenance: RESTART ACKNOWLEDGE ‘Channel/interPINX link out of service’

M (I)

note 6

T322 Minimum 4 s, Any call STATUS Maximum 6 s state except ENQUIRY sent null.

STATUS, STATUS DISCONNECT, ENQUIRY may RELEASE or be transmitted RELEASE several times COMPLETE implementation received dependant.

NOTE 1 All protocol Timers, except T316, if running, should be terminated on entering the null state. NOTE 2 Timers T301, T302, T303, T304, T310 and T313 are all stopped (if running) on receipt or transmission of any clearing message. NOTE 3 The optional timer T301 is implementation dependent and is not specified as part of this Standard. NOTE 4 Additional (implementation specific) values for this timer may be supported. NOTE 5 The value of this timer is implementation dependent and shall be equal to, or greater than, 30 seconds. In the case of operation of certain call handling supplementary services in a PISN, the receipt of an ALERTING or CONNECT message may be delayed significantly beyond that expected for a normal call. In order to ensure that unnecessary failure of these services can be avoided, it is recommended that T310 be given a value of at least 110 seconds. NOTE 6 The number of times T316 is restarted is an implementation option.

- 43 -

Functional definition of messages This clause provides an overview of the structure of messages used in this Standard and defines the function and information contents (i.e. semantics) of each message. Whenever a message is sent, according to the procedures of clauses 9, 10 and 11, it shall contain the mandatory information elements, and optionally any combination of the optional information elements, specified in this clause for that message. Each definition includes: a) A brief description of the message direction and use. b) A table listing the information elements of codeset 0 in the order of their appearance in the message (same relative order for all message types). c) Indications for each information element in the table, specifying: •

the clause of this Standard describing the information element;

•

whether inclusion is mandatory (“M”) or optional (“O”);

•

the length (or length range) of the information element, where “*” denotes an undefined maximum length which may be network or service dependent. Note that certain optional information elements may be present in the message, but empty (length = 2 octets), but this case is not considered in the tables. d) Further explanatory notes, as necessary. Other messages and information elements may be required for the support of supplementary services and additional network features; these will be defined in other standards. Unless otherwise qualified by an individual note, information elements marked as optional in the definition of a message should be included whenever the sender is able to provide the information (i.e. the information is available at the sending side of a link), if it has not been sent before.

13.1 13.1.1

Messages for general procedures S TA TU S This message is sent by either side in response to a STATUS ENQUIRY message or at any time during a call to report certain error conditions. Table 5 - STATUS message content Message Type: STATUS Direction: both Information Element Protocol discriminator Call reference Message type Cause Call state

Reference 14.2 14.3 14.4 14.5 14.5

Type M M (note 1) M M M

Length 1 3 1 4-32 3

NOTE 1 This message may be sent with the global call reference. 13.1.2

S TA TU S EN Q U I R Y This message may be sent by either side at any time to solicit a STATUS message from the peer signalling entity. Table 6 - STATUS ENQUIRY message content Message Type: STATUS ENQUIRY Direction: both Information Element Protocol discriminator Call reference Message type

Reference 14.2 14.3 14.4

Type M M M

Length 1 3 1

- 44 -

13.2 13.2.1

Messages for Circuit Mode Call Control A LER TI N G This message is sent by the incoming side to the outgoing side to indicate that called user alerting has been initiated. Table 7 - ALERTING message content Message Type: ALERTING Direction: incoming to outgoing Information Element Protocol discriminator Call reference Message type Channel identification Progress indicator

Reference 14.2 14.3 14.4 14.5 14.5

Type M M M O (note 1) O

Length 1 3 1 4-* 4

NOTE 1 Mandatory if ALERTING is the first response to a SETUP message. 13.2.2

C A LL P R O C EED I N G This message is sent by the incoming side to indicate that the requested call establishment has been initiated and no more call establishment information will be accepted. Table 8 - CALL PROCEEDING message content Message Type: CALL PROCEEDING Direction: incoming to outgoing Information Element Protocol discriminator Call reference Message type Channel identification

Reference 14.2 14.3 14.4 14.5

Type M M M O (note 1)

Length 1 3 1 4-*

NOTE 1 Mandatory if CALL PROCEEDING is the first response to a SETUP message. 13.2.3

C O N N EC T This message is sent by the incoming side to the outgoing side to indicate call acceptance by the called user. Table 9 - CONNECT message content Message Type: CONNECT Direction: incoming to outgoing Information Element Protocol discriminator Call reference Message type Channel identification Progress indicator Connected number Connected subaddress Low layer compatibility

Reference 14.2 14.3 14.4 14.5 14.5 14.5 14.5 14.5

Type M M M O (note 1) O O O O

NOTE 1 Mandatory if CONNECT is the first response to a SETUP message.

Length 1 3 1 4-* 4 4-* 4-23 4-16

- 45 -

13.2.4

CONNECT ACKNOWLEDGE This message is sent by the outgoing side to acknowledge the receipt of a CONNECT message. Table 10 - CONNECT ACKNOWLEDGE message content Message Type: CONNECT ACKNOWLEDGE Direction: outgoing to incoming Information Element Protocol discriminator Call reference Message type

13.2.5

Reference 14.2 14.3 14.4

Type M M M

Length 1 3 1

D I S C O N N EC T This message is sent by either side as an invitation to terminate the connection. Table 11 - DISCONNECT message content Message Type: DISCONNECT Direction: both Information Element Protocol discriminator Call reference Message type Cause

13.2.6

Reference 14.2 14.3 14.4 14.5

Type M M M M

Length 1 3 1 4-32

I N F O R M A TI O N This message is sent by the outgoing side to provide additional information during call establishment (in the case of overlap sending). Table 12 - INFORMATION message content Message Type: INFORMATION Direction: outgoing to incoming Information Element Protocol discriminator Call reference Message type Sending complete Called party number

Reference 14.2 14.3 14.4 14.5 14.5

Type M M M O (note 1) O (note 1)

Length 1 3 1 1 4-*

NOTE 1 Either “sending complete” or “called party number” or both should normally be present. 13.2.7

P R O G R ES S This message is sent by the incoming side to indicate the progress of a call in the event of interworking or by either side in the connection with the provision of optional in-band information/patterns. Table 13 - PROGRESS message content Message Type: PROGRESS Direction: both Information Element Protocol discriminator Call reference Message type Cause Progress indicator

Reference 14.2 14.3 14.4 14.5 14.5

Type M M M O (note 1) M

Length 1 3 1 4-32 4

NOTE 1 Included if a call failure has to be reported and inband tones/announcements are provided.

- 46 -

13.2.8

RELEASE This message is used to indicate that the equipment sending the message has disconnected the channel (if any) and intends to release the channel and the call reference, and that the receiving equipment should release the channel and prepare to release the call reference after sending RELEASE COMPLETE. Table 14 - RELEASE message content Message Type: RELEASE Direction: both Information Element Protocol discriminator Call reference Message type Cause

Reference 14.2 14.3 14.4 14.5

Type M M M O (note 1)

Length 1 3 1 4-32

NOTE 1 Mandatory in the first call clearing message. 13.2.9

RELEASE COMPLETE This message is used to indicate that the equipment sending the message has released the channel (if any) and call reference, the channel is available for re-use, and the receiving equipment shall release the call reference. Table 15 - RELEASE COMPLETE message content Message Type: RELEASE COMPLETE Direction: both Information Element Protocol discriminator Call reference Message type Cause

Reference 14.2 14.3 14.4 14.5

Type M M M O (note 1)

Length 1 3 1 4-32

NOTE 1 Mandatory in the first call clearing message. 1 3 . 2 . 1 0 S ETU P This message is sent by the outgoing side to the incoming side to initiate call establishment. Table 16 - SETUP message content Message Type: SETUP Direction: outgoing to incoming Information Element Protocol discriminator Call reference Message type Sending complete Bearer capability Channel identification Progress indicator Calling party number Calling party subaddress Called party number Called party subaddress Low layer compatibility High layer compatibility

Reference 14.2 14.3 14.4 14.5 14.5 14.5 14.5 14.5 14.5 14.5 14.5 14.5 14.5

Type M M M O M M O O O M O O O

Length 1 3 1 1 4-12 4-* 4 4-* 4-23 4-* 4-23 4-16 4-5

- 47 -

1 3 . 2 . 1 1 S ETU P A C K N O W LED G E This message is sent by the incoming side to indicate that call establishment has been initiated, but additional information may be required. Table 17 - SETUP ACKNOWLEDGE message content Message Type: SETUP ACKNOWLEDGE Direction: incoming to outgoing Information Element Protocol discriminator Call reference Message type Channel identification

13.3 13.3.1

Reference 14.2 14.3 14.4 14.5

Type M M M M

Length 1 3 1 4-*

Messages for layer management R ES TA R T This message is used to request the recipient to restart (i.e. return to idle condition) the indicated channel(s). Table 18 - RESTART message content Message Type: RESTART Direction: both Information Element Protocol discriminator Call reference Message type Channel identification Restart indicator

Reference 14.2 14.3 14.4 14.5 14.5

Type M M (note 1) M O (note 2) M

Length 1 3 1 4-* 3

NOTE 1 This message is sent with the global call reference. NOTE 2 Included when the Restart indicator information element indicates that a particular channel is to be restarted. 13.3.2

RESTART ACKNOWLEDGE This message is used to acknowledge the receipt of a RESTART message and to indicate that the requested restart is complete. Table 19 - RESTART ACKNOWLEDGE message content Message Type: RESTART ACKNOWLEDGE Direction: both Information Element Protocol discriminator Call reference Message type Channel identification Restart indicator

Reference 14.2 14.3 14.4 14.5 14.5

Type M M (note 1) M O (note 2) M

Length 1 3 1 4-* 3

NOTE 1 This message is sent with the global call reference. NOTE 2 Included when the Restart indicator information element indicates that a particular channel has been restarted.

- 48 -

General message format and coding of information elements The figures and text in this section describe message contents. Within each octet, the bit designated “bit 1” is transmitted first, followed by bit 2, 3, 4 etc. Similarly, the octet shown at the top of each figure is sent first. Whenever a message is sent, according to the procedures of clauses 9, 10 and 11, it shall be coded as specified in this clause, except where the message is segmented according to the procedures of annex ZA, in which case each message segment shall be coded as specified in that annex.

14.1

Overview The coding rules follow ITU-T Recommendation Q.931. Every message consists of: a) Protocol discriminator, b) Call Reference, c) Message type, d) other information elements, as required. Information elements a), b) and c) are common to all messages and shall always be present, while elements d) are specific to each message type. 8

6 5 4 3 2 1 Protocol discriminator Length of call 0 0 0 0 reference value Call reference value 0 Message type Other information elements as required

octet 1 octet 2 octet 3 etc.

F ig u r e 4 - G e n e r a l m e s s a g e o r g a n is a t io n e x a m p le A particular message may contain more information than a particular (PISN) equipment needs or can understand. All equipment shall be able to ignore any extra information that is present in a message, but is not required for the proper operation of that equipment. Unless specified otherwise, a particular information element shall be present only once in a given message. The term “default” implies that the value defined shall be used in the absence of any assignment or negotiation of alternative values. When a field, such as the call reference value, extends over more than one octet, the order of bit values progressively decreases as the octet number increases. The least significant bit of the field is represented by the lowest numbered bit of the highest numbered octet of the field.

14.2

Protocol discriminator The purpose of the protocol discriminator is to distinguish messages of this specification from any protocol units which also use services of the SCM, but are coded according to other standards. The protocol discriminator is the first part of every message. The protocol discriminator is coded according to table 20. 8

6 5 4 3 2 Protocol discriminator

1 octet 1

F ig u r e 5 - P r o t o c o l d is c r im in a t o r

- 49 -

Ta b le 2 0 - P r o t o c o l d is c r im in a t o r Bits 8 7 6 5 4 3 2 1 0 0 0 0 1 0 0 0 ITU-T Q.931(I.451) user-network call control message (note 1) All other values are reserved NOTE 1 For the purposes of this Standard, this protocol discriminator should be understood to mean "PISN interexchange signalling messages".

14.3

Call reference The purpose of the call reference is to identify the call at the local inter-PINX link to which the particular message applies. The call reference does not have end-to-end significance across PISNs. The call reference is the second part of every message. The call reference is coded as shown in figure 6. 8

CRFlag

4 3 2 1 Length of call reference octet 1 value (in octets)

Call reference value

octet 2

Call reference value (cont.)

octet 3

Figure 6 - Call Reference The coding of the CR-Flag (octet 2 bit 8) shall be as follows: CR-Flag:

0 1

message is sent from the side that originated the CR (i.e. from the outgoing side) message is sent to the side that originated the CR (i.e. from the incoming side)

Length of call reference value (octet 1) The call reference value as defined for PSS1 shall always be two octets long; other length values are reserved. The receipt of a call reference value of one octet may not cause a protocol error. The actions taken by the receiver are based on the numerical value of the call reference and are independent of the length of the call reference information element. The call reference information (octet 2 etc.) comprises two fields: the call reference value and the call reference flag. Call reference values Call reference values are assigned by the outgoing side of an inter-PINX link for a call. These values are unique to the outgoing side only within a particular signalling channel SCM logical link connection. The call reference value is assigned at the beginning of a call and remains fixed for the lifetime of a call. After a call ends, the associated call reference value may be reassigned to a later call. Two identical call reference values on the same signalling channel SCM logical link connection may be used when each value pertains to a call originated at opposite ends of the link. Call reference flag The call reference Flag can take the values ZERO or ONE. The call reference flag is used to identify which end of the layer two logical link originated a call reference. The outgoing side always sets the call reference flag to ZERO. The incoming side always sets the call reference flag to ONE. Hence the call reference flag identifies the side which allocated the call reference value for this call and the only purpose of the call reference flag is to resolve simultaneous uses of the same call reference value.

- 50 -

Global call reference The numerical value of the “global call reference” is zero. It is coded as shown in figure 7. The equipment receiving a message containing the global call reference should interpret the message as pertaining to all call references associated with the SCM connection. 8 0 0/1 0

7 0 0 0

6 0 0 0

5 0 0 0

4 0 0 0

3 0 0 0

2 1 0 0

1 0 0 0

octet 1 octet 2 octet 3

Figure 7 - Global call reference Dummy call reference The Dummy call reference consists of a single octet with all zeros as defined in ITU-T Q.931. Its use is beyond the scope of this Standard.

14.4

Message type The purpose of the message type is to identify the function of the message being sent. The message type is the third part of every message and it is coded as shown in figure 8 and table 21. Bit 8 is reserved for possible future use as an extension bit. 8 0

5 4 3 Message type

F ig u r e 8 - M e s s a g e Ty p e

1 octet 1

- 51 -

Ta b le 2 1 - M e s s a g e t y p e s Bits 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 Escape to national or private message type (note 1) 0 0 0 0 0 0 0 0 0 0

0 0 0 1 0 0 1

0 0 1 1 0 1 1

0 1 1 1 1 0 0

Call Establishment messages: 1 ALERTING 0 CALL PROCEEDING 1 CONNECT 1 CONNECT ACKNOWLEDGE 1 PROGRESS 1 SETUP 1 SETUP ACKNOWLEDGE

0 0 1 0 0

0 1 1 0 1

1 1 0 1 1

0 0 1 1 1

Call clearing messages: 1 DISCONNECT 1 RELEASE 0 RELEASE COMPLETE 0 RESTART 0 RESTART ACKNOWLEDGE

0 1 0

0 1 1

Miscellaneous messages: 0 0 0 0 0 SEGMENT (note 2) 1 1 0 1 1 INFORMATION 1 1 1 0 1 STATUS 1 0 1 0 1 STATUS ENQUIRY All other values are reserved NOTE 1 The handling of national/private messages is outside the scope of this Standard (see annex D). NOTE 2 This message type is only used in conjunction with the message segmentation and re-assembly procedures defined in annex ZA.

14.5 14.5.1

Other information elements for Basic Call control (codeset 0) C o d in g r u le s The coding of other information elements follows the coding rules described below. These rules are formulated to allow each equipment which processes a message to find information elements important to it, and yet remain ignorant of information elements not relevant to that equipment. Two categories of information elements are defined: a) single octet information elements (see figures 9 and 10); b) variable length information elements (see figure 11). Table 22 summarises the coding of the information element identifier bits for those information elements of codeset 0 which are used in PSS1. The descriptions of the information elements below are ordered alphabetically. However, there is a particular order of appearance for each information element in a message within each codeset. The code values of the information element identifier for the variable length formats are assigned in ascending numerical order, according to the actual order of appearance of each information element in a message. This allows the receiving equipment to detect the presence or absence of a particular information element without scanning through an entire message. The receiving entity is entitled to disregard any information elements (of variable length) which are out of order. Single octet information elements may appear at any point in the message. Two types of single octet information elements have been defined. Type 1 elements provide the information element identification in bit positions 7, 6, 5. The value “010” in these bit positions is reserved for type 2 single octet elements.

- 52 -

Where the description of information elements in this specification contains spare bits, these bits are indicated as being set to “ZERO”. In order to allow compatibility with future implementations, message should not be rejected simply because a spare bit is set to “ONE”. The second octet of a variable length information element indicates the total length of the contents of that information element (i.e. the length starting with octet 3). It is the binary coding of the number of octets of the contents, with bit 1 as the least significant bit (20). An optional variable length information element may be present, but empty. For example, a SETUP message may contain a calling party number information element, the content of which is of zero length. This should be interpreted by the receiver as equivalent to that information element being absent. Similarly, an absent information element should be interpreted by the receiver as equivalent to that information element being empty. The following rules apply for the coding of the contents of variable length information elements (octets 3 etc.): a) The first digit in the octet number identifies one octet or a group of octets (i.e. the octets are numbered in a way that reflects the structuring of an information element into groups of one or more octets). b) Each octet group is a self contained entity. The internal structure of an octet group may be defined in alternative ways. c) An octet group is formed by using some extension mechanism. The preferred extension mechanism is to extend an octet (N) to the next octet(s) (Na, Nb, etc.) by using bit 8 in each octet as an extension bit. The bit value “ZERO” indicates that the octet continues through the next octet. The bit value “ONE” indicates that this octet is the last octet of the group. If one octet (e.g. Nb) is present, the preceding octets (N and Na) must also be present. In the format descriptions of the following paragraphs, bit 8 is marked “0/1 ext” if another octet follows. Bit 8 is marked “1” or “1 ext” if this is the last octet in the extension domain (octet group). Additional octets may be defined later (“1 ext” changed to “0/1 ext”) and equipments shall be prepared to receive such additional octets, although the equipment need not be able to interpret or act upon the content of these octets. d) In addition to the extension mechanism defined above, an octet (N) may be extended through the next octet(s) (N.1, N.2 etc.) by indications in bits 7-1 of octet N. e) The mechanisms in c) and d) may be combined. f) Optional octets are marked with asterisks (*). 8 1

7 6 5 4 3 2 1 Information Contents of octet 1 element identifier information element

Figure 9 - Single octet information element format (type 1) 8 1

7 0

6 5 4 3 2 1 1 0 x x x x Information element identifier

octet 1

Figure 10 - Single octet information element format (type 2)

- 53 -

8 7 6 5 4 3 2 1 0 Information element identifier Length of contents of information element (octets)

octet 1 octet 2

Contents of information element

octet 3 etc.

Figure 11 - Variable length information element format T a b l e 2 2 - I n f o r m a t i o n e l e m e n t i de n t i f i e r c o d i n g ( c o d e s e t 0 ) Coding 8 7 6 5 4 3 2 1 1 : : : - - - - Single octet information elements: 0 0 0 - - - - reserved 0 0 1 - - - - shift 0 1 0 0 0 0 1 Sending complete 0 : : : : : : : Variable length information elements: 0 0 0 0 0 0 0 Segmented message 0 0 0 0 1 0 0 Bearer capability 0 0 0 1 0 0 0 Cause 0 0 1 0 1 0 0 Call state 0 0 1 1 0 0 0 Channel identification 0 0 1 1 1 1 0 Progress indicator 1 0 0 1 1 0 0 Connected number 1 0 0 1 1 0 1 Connected subaddress 1 1 0 1 1 0 0 Calling party number 1 1 0 1 1 0 1 Calling party subaddress 1 1 1 0 0 0 0 Called party number 1 1 1 0 0 0 1 Called party subaddress 1 1 1 1 0 0 1 Restart indicator 1 1 1 1 1 0 0 Low layer compatibility 1 1 1 1 1 0 1 High layer compatibility All other values are reserved (note 2)

Reference

Max Length (octets)

14.5.3 14.5.19

1 1

annex ZA 14.5.5 14.5.11 14.5.6 14.5.12 14.5.17 14.5.13 14.5.14 14.5.9 14.5.10 14.5.7 14.5.8 14.5.18 12.5.16 14.5.15

note 1 12 32 3 note 1 4 note 1 23 note 1 23 note 1 23 3 16 5

NOTE 1 Network dependent. NOTE 2 The reserved values with bits 5-8 coded “0000” are for future information elements for which comprehension by the receiver is required. 14.5.2

Ex t e n s io n o f c o d e s e t s There is a certain number of possible information element identifier values using the formatting rules described in clause 14.5.1; 128 from the variable length information element format and at least 8 from the single octet information element format. One value in the single octet format is specified for the shift operations described below. One other value in both the single octet and variable length format is reserved. This leaves at least 133 information element identifier values available for assignment. It is possible to expand this structure to eight codesets of at least 133 information element identifier values each. One common value in the single octet format is employed in each codeset to facilitate shifting from one codeset to another. The contents of this shift information element identifies the codeset to be used for the next information element or elements. The codeset in use at any given time is referred to as the “active codeset”. By convention, codeset 0 is the initially active codeset. Two codeset shifting procedures are possible: Locking shift and non-locking shift.

- 54 -

Transition from one active codeset to another (i.e. by means of the locking shift procedure) may only be made to a codeset with a higher numerical value than the codeset being left. An information element belonging to one codeset may appear in between information elements belonging to another codeset (being the active codeset) by using the non-locking shift procedure. An equipment shall have the capability to recognise a shift information element and to treat the subsequent information element(s) as belonging to the specified shift. Information elements from nonsupported shifts shall be treated as unrecognised if received in a message. The error procedures for unrecognised information elements apply. Codeset 4 is used for ISO defined information elements. Codeset 5 is used by ETSI for information elements that are defined in addition to those defined by ITU-T or ISO. The rules for handling information elements of codeset 0 apply to codesets 4 and 5 too. Codeset 6 and/or codeset 7 may be used for conveying non-standardised information between adjacent PINXs (e.g. for manufacturer or network specific purposes). 14.5.3

Lo c k in g s h if t p r o c e d u r e The locking shift procedure employs an information element to indicate the new active codeset. The specified codeset remains active until another locking shift information element is encountered which specifies the use of another codeset. For example, codeset 0 is active at the start of message content analysis. If a locking shift to another codeset is encountered, the next information elements will be interpreted according to the information element identifiers assigned in the new codeset, until another shift information element is encountered. This procedure shall only be used to shift to a higher order codeset than the one being left. The locking shift is valid only within the message that contains the locking shift information element. At the start of every message content analysis, the active codeset is codeset 0. The locking shift information element uses the single octet information element format and is coded as shown in figure 12 and table 23. 8 1

7 0

6 0

5 1

4 0

3 2 1 New codeset identification

octet 1

Bits 7-5 are the shift identifier Bit 4 = “ZERO” indicates locking shift Figure 12 - Locking shift information element Table 23 - Locking/non-locking shift information element Codeset identification Bits 3 2 1 ITU-T Q.931 information elements (initially active codeset) 1 0 0 Codeset 4: Information elements defined by ISO 1 0 1 Codeset 5: Information elements defined by ETSI Information elements specific to the 1 1 0 Codeset 6: local network (public or private) 1 1 1 Codeset 7: User-specific information elements All other values are reserved (note 1) 0 0 0

Codeset 0:

NOTE 1 The handling of national/private information elements is outside the scope of this Standard (see annex D).

- 55 -

14.5.4

N o n - lo c k in g s h if t p r o c e d u r e The non-locking shift procedure provides a temporary shift to the specified lower or higher codeset. It uses a single octet information element to indicate the codeset to be used to interpret the next single information element. After the interpretation of that information element, the active codeset is again used for interpreting any following information elements. For example, codeset 0 is active at the beginning of message content analysis. If a non-locking shift to another codeset is encountered, only the next information element is interpreted according to the information element identifiers assigned in that codeset. After that codeset 0 will again be used to interpret the following information elements. A nonlocking shift information element indicating the current codeset shall not be regarded as an error. A locking shift information element shall not follow directly on a non-locking shift information element. If this combination is received it shall be interpreted as though a locking shift information element only had been received. The single octet non-locking shift information element format and coding is shown in figure 13 and table 23. 8

3 2 1 Temporary codeset identification

octet 1

Bits 7-5 are the shift identifier Bit 4 = “ONE” indicates non-locking shift Figure 13 - Non-locking shift information element 14.5.5

Bearer capability The purpose of the bearer capability information element is to indicate a requested ECMA-142or ISO/IEC 11584 bearer capability to be provided by the network. The bearer capability information element is coded as shown in figure 14 and table 24. NOTE This encoding represents a subset of ITU-T Rec. Q.931. 8

5 4 3 2 1 Bearer capability 0 0 0 0 0 1 0 0 Information element identifier Length of bearer capability contents 1 Coding Information transfer ext standard capability 1 Transfer Information transfer rate ext mode 1 Multiplier ext 0/1 0 1 User information ext Layer ID(1) layer 1 protocol

octet 1 octet 2 octet 3 octet 4 note 1 octet 4.1* note 2 octet 5* note 3

NOTE 1 - As only default values are used for all fields of ITU–T Rec. Q.931 octets 4a and 4b, these octets shall not be used. The following values shall be assumed: Structure: Configuration: Establishment: Symmetry:

circuit mode: 8kHz integrity point-to-point demand bidirectional symmetric

NOTE 2 - This octet shall be included if the Information transfer rate in octet 4 indicates ‘multi-rate’. Otherwise, it shall not be included.

- 56 -

NOTE 3 - The contents of optional octets 5a, 5b, 5c, 5d, 6 and 7 have no impact at the Q reference point, and are therefore not specified in this Standard. One or more of these octets may be included, in accordance with ITU-T Rec. Q.931. Receipt of any of these octets regardless of content shall not cause a protocol error. Figure 14 - Bearer capability information element Table 24 - Bearer capability information element Coding standard (octet 3) Bits 7 6 0 0 CCITT standardized coding All other values are reserved Information transfer capability (octet 3) Bits 5 4 3 2 1 0 0 0 0 0 Speech 0 1 0 0 0 unrestricted digital information Restricted digital information (applicable 0 1 0 0 1 only in interworking situations) 1 0 0 0 0 3.1 kHz audio Unrestricted digital information with tones / 1 0 0 0 1 announcements All other values are reserved Transfer mode(octet 4) Bits 7 6 0 0 circuit mode All other values are reserved Information transfer rate (octet 4) Bits 5 4 3 2 1 1 0 0 0 0 64 kbit/s 1 0 0 1 1 384 kbit/s (note 1) 1 0 1 0 1 1536 kbit/s (note 1) 1 0 1 1 1 1920 kbit/s (note 1) 1 1 0 0 0 multi-rate (64 kbit/s base rate) (note 2) All other values are reserved Multiplier (octet 4.1) Bits 7 6 5 4 3 2 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 1 0 0 0 0 1 1 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 1 0 0 0 1 0 1 0 0 0 1 1 0 0 0 0 1 1 0

1 0 1 0 1 0 1 0 1 0 1 0 1

2 3 4 5 6 7 8 9 10 11 12 13

- 57 -

0 0 0 1 1 1 0 14 0 0 0 1 1 1 1 15 0 0 1 0 0 0 0 16 0 0 1 0 0 0 1 17 0 0 1 0 0 1 0 18 0 0 1 0 0 1 1 19 0 0 1 0 1 0 0 20 0 0 1 0 1 0 1 21 0 0 1 0 1 1 0 22 0 0 1 0 1 1 1 23 0 0 1 1 0 0 0 24 0 0 1 1 0 0 1 25 0 0 1 1 0 1 0 26 0 0 1 1 0 1 1 27 0 0 1 1 1 0 0 28 0 0 1 1 1 0 1 29 0 0 1 1 1 1 0 30 All other values are reserved User information layer 1 protocol (octet 5) (note 3, note 4, note 5) Bits 5 4 3 2 1 0 0 0 1 0 CCITT Recommendation G.711 µ-law 0 0 0 1 1 CCITT Recommendation G.711 A-law All other values are beyond the scope of this Standard NOTE 1 - This codepoint may be used as an alternative to the combination of ‘multi-rate’ in octet 4 and a ‘Multiplier’ value in octet 4.1 as indicated below: Information transfer rate 384 kbit/s 1536 kbit/s 1920 kbit/s

Multiplier value 6 24 30

NOTE 2 If this codepoint is indicated, octet 4.1 shall be included, otherwise octet 4.1 shall be omitted. NOTE 3 If the transfer mode is “circuit mode”, and if the information transfer capability is “unrestricted digital information” or “restricted digital information”, octet 5 may be omitted. The receipt of octet 5 shall not cause a protocol error for invalid information element contents. NOTE 4 If the Transfer mode is “circuit mode” and the information transfer capability is 3.1kHz audio, octet 5 shall indicate either 00010 “G.711 µ-law” or 00011 “G.711 A-law”. NOTE 5 If the Transfer mode is “circuit mode” and the information transfer capability is speech, octet 5 shall indicate either 00010 “G.711 µ-law” or 00011 “G.711 A-law”. 14.5.6

C a ll s t a t e The purpose of the call state information element is to indicate the current state of a call or a global call reference state. The call state information element is coded as shown in figure 15 and table 25.

- 58 -

4 3 2 1 Call state 0 0 0 1 0 1 0 0 octet 1 Information element identifier Length of call state contents) octet 2 Coding Call state value/ octet 3 Standard Global call reference state value Figure 15 - Call state information element Table 25 - Call state information element Coding standard (octet 3) Bits 8 7 0 0 CCITT standardized coding All other values are reserved Call state value (octet 3) Bits 6 5 4 3 2 1 Value Circuit Mode Protocol Control State 0 0 0 0 0 0 0 Null 0 0 0 0 0 1 1 Call initiated 0 0 0 0 1 0 2 Overlap sending (note 1) 0 0 0 0 1 1 3 Outgoing call proceeding 0 0 0 1 0 0 4 Call delivered 0 0 0 1 1 0 6 Call present 0 0 0 1 1 1 7 Call received 0 0 1 0 0 0 8 Connect request 0 0 1 0 0 1 9 Incoming call proceeding 0 0 1 0 1 0 10 Active 0 0 1 0 1 1 11 Disconnect Request 0 0 1 1 0 0 12 Disconnect Indication 0 1 0 0 1 1 19 Release request 0 1 1 0 0 1 25 Overlap receiving (note 1) Global call reference state value(octet 3) Bits 6 5 4 3 2 1 State 0 0 0 0 0 0 REST 0 - null 1 1 1 1 0 1 REST 1 - restart request 1 1 1 1 1 0 REST 2 -restart NOTE 1 If enbloc signalling only is used between two adjacent PINXs, overlap receiving procedures need not be tested. 14.5.7

C a lle d p a r t y n u m b e r The purpose of the called party number information element is to identify the called party of a call. The called party number information element is coded as shown in figure 16 and table 26. The maximum length of the called party number information element is network dependent and therefore outside the scope of this Standard.

- 59 -

5 4 3 2 1 Called party number 0 1 1 1 0 0 0 0 Information element identifier Length of called party number contents Numbering plan 1 Type of number identification 0 Number digits(note 1) spare

octet 1 octet 2 octet 3 octet 4 repeated

NOTE 1 The number digits appear in multiple octets 4 in the same order in which they would be entered, i.e. the number digit which would be entered first is located in the first octet 4. Figure 16 - Called party number information element

- 60 -

Table 26 - Called party number information element Numbering Plan identification (octet 3) Bits 4 3 2 1 0 0 0 0 Unknown (note 1) 0 0 0 1 ISDN/Telephony numbering plan (ITU-T Rec. E.164/E.163) 1 0 0 1 Private numbering plan (ECMA-155) All other values are reserved Type of number (octet 3) when Numbering Plan identification is ISDN/Telephony numbering plan (note 2) Bits 7 6 5 0 0 0 Unknown (note 3) 0 0 1 International Number (note 4) 0 1 0 National Number (note 4) 1 0 0 Subscriber Number (note 4) All other values are reserved Type of number (octet 3) when Numbering Plan identification is Private numbering plan (note 2) Bits 7 6 5 0 0 0 Unknown 0 0 1 Level 2 Regional Number 0 1 0 Level 1 Regional Number 0 1 1 PISN specific number 1 0 0 Level 0 Regional Number All other values are reserved Type of number (octet 3) when Numbering Plan identification is Unknown (note 2) Bits 7 6 5 0 0 0 Unknown All other values are reserved Number digits (octet 4) This field is coded with ITU-T Recommendation T.50 characters, according to the formats specified in the appropriate numbering/dialling plan. NOTE 1 The numbering plan identification “unknown” is used when the user or the network has no knowledge of the numbering plan identification. In this case the number digits field is organised according to the network dialling plan; prefix or escape digits might be present. NOTE 2 Only the numbering combinations shown in this table may be used. NOTE 3 The type of number “unknown” is used when the user or the network has no knowledge of the type of number, e.g. international number, national number, etc. In this case the number digits field is organised according to the network dialling plan; prefix or escape digits might be present. NOTE 4 For the definition of international, national and subscriber number, see ITU-T Recommendation I.330. Prefix or escape digits shall not be included in these numbers.

- 61 -

14.5.8

C a lle d p a r t y s u b a d d r e s s The purpose of the called party subaddress information element is to identify the subaddress of the called party of a call. NOTE 1 For the definition of subaddress, see ECMA-155. Refer to ITU-T Rec. Q.931 for coding rules for this information element. The maximum length of the called party subaddress information element is 23 octets. NOTE 2 The encoding of this information element is not specified in this Standard for it is defined as transparent to the PSS1 protocol.

14.5.9

Calling party number The purpose of the calling party number information element is to identify the origin of a call. The calling party number information element is coded as shown in figure 17 and table 27. The maximum length of the calling party number information element is network dependent and therefore outside the scope of this Standard. 8 0

6 5 4 3 2 1 Calling party number 1 1 0 1 1 0 0 Information element identifier

octet 1

octet 2 (note 1) 0/1 Numbering plan octet 3 Type of number ext identification (note 1) 1 Presentation 0 0 0 Screening octet 3a* ext indicator Spare indicator (note 1) 0 octet 4 * Number digits spare (repeated) Length of calling party number contents

NOTE 1 Octets 2, 3 and 4 of this information element are coded as in the “called party number” information element. Figure 17 - Calling party number information element

- 62 -

Table 27 - Calling party number information element Presentation indicator note 1 (octet 3a) Bits 7 6 0 0 Presentation allowed 0 1 Presentation restricted 1 0 Number not available due to interworking 1 1 Reserved Screening indicator (octet 3a) note 2 Bits 2 1 0 0 User provided, not screened 0 1 User provided, verified and passed 1 0 Reserved 1 1 Network provided NOTE 1 If octet 3a is omitted “00-Presentation allowed” is assumed. NOTE 2 If octet 3a is omitted “00-User provided, not screened” is assumed. 14.5.10 Calling party subaddress The purpose of the calling party subaddress information element is to identify a subaddress associated with the origin of a call. NOTE 1 For the definition of subaddress, see ECMA-155. Refer to ITU-T Rec. Q.931 for coding rules for this information element. The maximum length of the calling party subaddress information element is 23 octets. NOTE 2 The encoding of this information element is not specified in this Standard for it is defined as transparent to the PSS1 protocol. 14.5.11 Cause The purpose of the cause information element is to describe the reason for generating certain messages, to provide diagnostic information in the event of procedural errors, and to indicate the location of the cause originator. The cause information element is coded as shown in figure 18 and tables 28, 29, 30. The maximum length of the cause information element is 32 octets.

- 63 -

0 1 ext 1 ext

4 3 2 1 Cause 0 0 0 1 0 0 0 Information element identifier Length of cause contents Coding 0 Location standard spare

octet 2 octet 3 (note 1)

Cause value

octet 4

octet 1

Diagnostics (if any) octet 5* NOTE 1 The optional octet 3a of ITU-T Rec. Q.931 has been omitted here since only the default value “Recommendation Q.931” is used. As stated in clause 14.5.1, an implementation shall be prepared to receive an extension octet 3a, which will not result in a protocol error for invalid contents. Figure 18 - Cause information element Table 28 - Cause information element Coding standard (octet 3) Bits 7 6 0 0 CCITT standardized coding as described below All other values are reserved Location (octet 3) Bits 4 3 2 1 0 0 0 0 User 0 0 0 1 Private network serving the local user 0 0 1 0 Public network serving the local user 0 0 1 1 Transit network 0 1 0 0 Public network serving the remote user 0 1 0 1 Private network serving the remote user 0 1 1 1 International network 1 0 1 0 Network beyond interworking point All other values are reserved Cause value (octet 4) The following rules apply to the coding of cause values: a) All values in the range 0 through 127 shall be accepted as valid cause values. b)

Table 29 lists cause values which are explicitly mentioned elsewhere in this Standard. These cause values are coded according to ITU-T Rec. Q.931: The value is divided into two fields, a class (bits 5 through 7) and a value within the class (bits 1 through 4). The class indicates the general nature of the event: Class (000): normal event Class (001): normal event Class (010): resource unavailable Class (011): service or option not available Class (100): service or option not implemented Class (101): invalid message (e.g. parameter out of range) Class (110): protocol error (e.g. unknown message) Class (111): interworking Refer to Q.931 for further details.

- 64 -

The list of cause values in table 29 is not exclusive, in the sense that the sending entity may choose values from Q.931 other than those listed in table 29, except where PSS1 procedures specify the use of particular cause values, in which case those values should be used.

Diagnostics (octet 5) Diagnostic information is not available for every cause; see tables 29 and 30 on the following pages. The inclusion of diagnostics is optional. If the diagnostic information cannot be interpreted this shall not lead to a protocol error. 8

0/1 ext

Attribute number

0/1 ext

Rejected attribute

1 ext

Available attribute

1 octet 5 (note 1, note 2) octet 5a (note 1, note 2) octet 5b* (note 1, note 2)

NOTE 1 When diagnostic information is provided, octets 5 and 5a shall be present, octet 5b is optional. NOTE 2 Octets 5 through 5b may be repeated to report multiple rejected attributes. F i g u r e 1 9 - C a u s e i n f o r m a t i o n e l e m e n t - D i a g no s t i c f i e l d f o r c a u s e s 5 7 , 5 8 , a n d 6 5

- 65 -

Table 29 - Cause information element Cause value Cause Cause Class Value no. 765 4321 000 0001 1. Unallocated (unassigned) number 000 0011 3. No route to destination 000 0110 6. Channel unacceptable 001 0000 16. Normal call clearing 001 0001 17. User busy 001 0010 18. No user responding 001 0011 19. No answer from user (user alerted) 001

0101

21.

Call rejected

001 001 001 001 001 010 010 010 011 011 011 100 101 101 101 110 110

0110 1011 1100 1110 1111 0010 1001 1100 1001 1010 1111 0001 0001 0010 1000 0000 0001

22. 27. 28. 30. 31. 34. 41. 44. 57. 58. 63. 65. 81. 82. 88. 96. 97.

110

0010

98.

110

0011

99.

110 110 110 110

0100 0101 0110 1111

100. 101. 102. 111.

Number changed Destination out of order Invalid number format Response to STATUS ENQUIRY Normal, unspecified No circuit/channel available Temporary failure Requested circuit/channel not available Bearer capability not authorized Bearer capability not presently available Service or option not available, unspecified Bearer capability not implemented Invalid call reference value Identified channel does not exist Incompatible destination Mandatory information element is missing Message type non-existent or not implemented Message not compatible with call state or message non-existent or not implemented Information element non-existent or not implemented Invalid information element contents Message not compatible with call state Recovery on timer expiry Protocol error, unspecified

Diagnostics note 1 note 1 ---note 1 ---------User supplied diagnostics note 1, note 2 New destination note 3 ---------------------note 4 note 4 ---note 4 ------Incomp. param. note 5. Info elem ID(s) note 6 Message type Message type Info elem ID(s) note 6, note 7 Info elem ID(s) note 6 Message type Timer number note 8 ---

NOTE 1 The following coding is used: Bit 8: Bit 7 - 3: Bit 2 - 1:

1 00000 persistence of condition as follows: 00 - unknown 01 - permanent 10 - transient

NOTE 2 User supplied diagnostics field is encoded according to the user specification, subject to the maximum length of the cause information element. The coding of the user supplied diagnostics should be made in such a way that it does not conflict with the coding described in note 1. NOTE 3 “New destination” is formatted as called party information element, including the information element identifier.

- 66 -

NOTE 4 The format of the diagnostic field for cause number 57, 58, and 65 is as shown in figure 19 and in table 30. NOTE 5 Incompatible information element identifier. NOTE 6 a) Locking and non-locking shift procedures are applied. b) In principle, information element identifiers are ordered in the same order as the information elements in the received message. NOTE 7 When only a locking shift information element is included and no variable length information element identifier follows, it means that the codeset in the locking shift itself is not implemented. NOTE 8 The timer is coded in ITU-T Recommendation T.50 characters, e.g. T308 is coded as “3” “0” “8” in bits 7-1 of octets 5, 5a, and 5b, with bit 8 being ZERO (spare).

- 67 -

Ta b le 3 0 - C o d in g o f d ia g n o s t ic s f ie ld f o r c a u s e s 5 7 , 5 8 a n d 6 5 Attribute number (octet 5) Bits 7 6 5 4 3 2 1 0 1 1 0 0 0 1 0 1 1 0 0 1 0 0 1 1 0 0 1 1 0 1 1 0 1 0 0 0 1 1 0 1 0 1 0 1 1 0 1 1 0 0 1 1 0 1 1 1 0 1 1 1 0 0 0 0 1 1 1 0 0 1

No. 1 2 3 4 5 6 7 8 9

Attribute Information transfer capability Information transfer mode Information transfer rate Structure (note 1) Configuration (note 1) Establishment (note 1 ) Symmetry (note 1) Information transfer rate (dest --> orig) (note 1) Layer identification (Layer 1, 2, 3)

Rejected attribute (octet 5a) / Available attribute (octet 5b) Attribute No 1 Information transfer capability Bits 7 - 6: 00 Bits 5 - 1: according to table 24, octet 3 2 Information transfer mode Bits 7 - 6: according to table 24, octet 4 Bits 5 - 1: 00000 3 Information transfer rate Bits 7 - 6: 00 Bits 5 - 1: according to table 24, octet 3 4 Structure Bits 7 - 5: according to Rec. Q.931, table 4-6/Q.931, octet 4a (note 1) Bits 4 - 1: 0000 5 Configuration Bits 7 - 5: 000 Bits 4 - 3: according to Rec. Q.931, table 4-6/Q.931, octet 4a (note 1) Bits 2 - 1: 00 6 Establishment Bits 7 - 3: 00000 Bits 2 - 1: according to Rec. Q.931, table 4-6/Q.931, octet 4a (note 1) 7 Symmetry Bits 7 - 6: according to Rec. Q.931, table 4-6/Q.931, octet 4b (note 1) Bits 5 - 1: 00000 8 Information transfer rate (dest --> orig) Bits 7 - 6: 00 Bits 5 - 1: according to Rec. Q.931, table 4-6/Q.931, octet 4b (note 1) 9 Layer identification Bits 7 - 1: according to table 24, octet 5 (Layer 1) or Rec. Q.931, table 4-6 NOTE 1 Attributes 4-8 each have only one value specified in this Standard, and therefore these attributes should not normally be the subject of the diagnostic field. 1 4 . 5 . 1 2 C h a n n e l id e n t if ic a t io n The purpose of the channel identification information element is to identify a channel which is controlled by these signalling procedures. NOTE All the channel identification information relates to Inter-PINX link channels. The channel identification information element is coded as shown in figures 20 and 21, and table 31. The default maximum length of the channel identification information element is network dependent.

- 68 -

8 0

1 ext 1 ext 0/1 ext

5 4 3 2 1 Channel identification 0 0 1 1 0 0 0 Information element identifier Length of channel identification contents Signalling 0 1 0 pref./ Info Channel channel spare Excl. selection ind. Number/ Coding standard Channel type Map Channel number Channel map

octet 1 octet 2 octet 3 (note 1) octet 3.2 octet 3.3 (note 2) (note 3) octet 3.3 (note 2)

NOTE 1 Since the interface is never explicitly identified at the Q reference point, octet 3.1 of ITU-T Rec. Q.931 is always omitted. NOTE 2 Channel number shall be used unless there is a bilateral agreement to use channel map. NOTE 3 This octet may be repeated to indicate multiple channels in the case of a multirate service, as defined in ISO/IEC 11584. See figure 21a. Figure 20 - Channel identification information element

- 69 -

Table 31 - Channel identification information element Preferred/Exclusive (octet 3) note 1 Bit 4 0 indicated channel is preferred 1 exclusive; only the indicated channel is acceptable Signalling channel indicator (octet 3) note 2 Bit 3 0 the channel identified is not the signalling channel 1 reserved Information channel selection (octet 3) note 3 Bits 2 1 0 1 as indicated in the following octets All other values are reserved Coding standard (octet 3.2) Bits 7 6 0 0 CCITT standard All other values are reserved Number/Map (octet 3.2) Bits 5 0 channel is indicated by the number in the following octet 1 channel map Channel type (octet 3.2) Bits 4 3 2 1 0 0 1 1 B channel units (64 kbit/s) All other values are reserved Channel number/Map (octet 3.3) note 4 Binary number assigned to the channel. Channels are numbered from 1 upwards (note 5). Bit position(s) in the slot map, see figure 21, correspond to the equivalent information channels. The use of a particular channel shall be encoded by means of a "1" in the appropriate bit position in the slot map (note 6). NOTE 1 Preferred/exclusive has significance only for information channel selection. NOTE 2 Signalling channel indication has significance in signalling channel use. No other information affects signalling channel use. NOTE 3 The information channel selection does not apply to the signalling channel. NOTE 4 Either “channel number” or channel map is used exclusively, depending on the “Number/Map” information in octet 3.2 bit 5.

- 70 -

NOTE 5 This octet may be extended if the channel number exceeds 127, (figure 21a). NOTE 6 Length of the channel map is decided by combination of channel unit size on which the channel map is mapped (e.g. B-channel) and map element. 8

etc. 16

1 octet 3.3.x-3 (note 1) octet 3.3.x-2 17 (note 1) octet 3.3.x-1 9 (note 1) octet 3.3.x 1 (note 1)

NOTE 1 The limit of x is outside the scope of this Standard. Figure 21 - Channel map field 8 1

7 0

6 0

5 0

4 1

3 0

2 0

1 1

octet 3.3.1

octet 3.3.2

octet 3.3.3

octet 3.3.4

F ig u r e 2 1 a – Ex a m p le o f c h a n n e l n u m b e r lis t : c h a n n e ls 9 , 1 0 a n d 1 3 1 14.5.13 Connected number The purpose of the connected number information element is to indicate which number is connected to a call. The connected number may be different from the Called party number because of changes (e.g. call redirection, transfer) during the lifetime of the call. The connected number information element is coded as shown in figure 22 and table 27 (see clause 14.5.9, Calling party number). 8

5 4 3 2 1 Connected number 0 1 0 0 1 1 0 0 octet 1 Information element identifier Length of connected number contents octet 3 0/1 Numbering plan Type of number octet 3 ext identification 1 Presentation 0 0 0 Screening octet 3a* ext indicator Spare indicator 0 octet 4 * Number digits spare (repeated) Figure 22 - Connected number information element 14.5.14 Connected subaddress The purpose of the connected subaddress information element is to identify the subaddress of the connected party of a call. The connected subaddress may be different from the called party subaddress because of changes (e.g. call redirection, transfer) during the lifetime of the call.

- 71 -

NOTE 1 For the definition of subaddress, see ECMA-155. The connected subaddress information element is coded in the same way as the called party subaddress IE, apart from the IE identifier (octet 1). The maximum length of the connected subaddress information element is 23 octets. NOTE 2 The encoding of this information element is not specified in this Standard for it is defined as transparent to the protocol at the ‘Q’ reference point. 14.5.15 High layer compatibility (layers 4-7) The purpose of the High layer compatibility information element is to provide a means which, in association with the Bearer capability and Low layer compatibility information elements, may be used by the remote user for compatibility checking. Refer to ITU-T Rec. Q.931 for the coding of the high layer compatibility information element. The maximum length of the high layer compatibility information element is 5 octets. The receipt of values not defined in ITU-T Rec. Q.931 shall not cause a protocol error, provided the maximum length is not exceeded. NOTE The encoding of this information element is not specified in this Standard for it is defined as transparent to the protocol at the ‘Q’ reference point. 14.5.16 Low layer compatibility (layers 1-3) The purpose of the Low layer compatibility information element is to provide a means which, in conjunction with the Bearer capability and High layer compatibility information elements, may be used by the addressed entity (e.g. remote user) for compatibility checking. Refer to ITU-T Rec. Q.931 for the coding of the low layer compatibility information element. The maximum length of the low layer compatibility information element is 16 octets. The receipt of values not defined in ITU-T Rec. Q.931 shall not cause a protocol error, provided the maximum length is not exceeded. NOTE The encoding of this information element is not specified in this Standard for it is defined as transparent to the protocol at the ‘Q’ reference point. 1 4 . 5 . 1 7 P r o g r e s s in d ic a t o r The purpose of the progress indicator information element is to describe an event which has occurred during the life of a call. The progress indicator information element is coded as shown in figure 23 and table 32. The maximum length of the progress indicator information element is 4 octets. The progress indicator information element may be repeated in a message up to three times. 8

5 4 3 2 1 Progress indicator 0 0 0 1 1 1 1 0 Information element identifier Length of progress indicator contents 1 Coding 0 Location ext standard spare 1 Progress description ext

octet 1 octet 2 octet 3 octet 4

Figure 23 - Progress indicator information element

- 72 -

Table 32 - Progress indicator information element Coding standard (octet 3) Bits 7 6 0 0 CCITT standardized coding as described below All other values are reserved (note 5) Location (octet 3) Bits 4 3 2 1 0 0 0 0 User 0 0 0 1 Private network serving the local user 0 0 1 0 Public network serving the local user 0 0 1 1 Transit network 0 1 0 0 Public network serving the remote user 0 1 0 1 Private network serving the remote user 0 1 1 1 International network 1 0 1 0 Network beyond interworking point All other values are reserved Progress description (octet 4) (note 5) Bits 7 6 5 4 3 2 1 No. 0 0 0 0 0 0 1 1 Call is not end-to-end ISDN, further call progress information may be available in-band (note 1) 0 0 0 0 0 1 0 2 Destination address is non-ISDN (note 2) 0 0 0 0 0 1 1 3 Origination address is non-ISDN (note 3) 0 0 0 0 1 0 0 4 Call has returned to the ISDN (note 4) 0 0 0 1 0 0 0 8 In-band information or appropriate pattern now available All other values are reserved (note 5 ) NOTE 1 Progress description 1 indicates that interworking with a non-ISDN has occurred within the network or networks which the call has traversed. NOTE 2 Progress description 2 indicates that the destination user equipment is non-ISDN equipment. NOTE 3 Progress description 3 indicates that origination user equipment is non-ISDN equipment. NOTE 4 Progress description 4 indicates that a call which has left the ISDN has returned at the same point it had left due to redirection within the non-ISDN. NOTE 5 Additional progress descriptions are specified in annex ZB. 1 4 . 5 . 1 8 R e s t a r t in d ic a t o r The purpose of the restart indicator is to identify the entity to be restarted or which has been restarted. The restart indicator information element is coded as shown in figure 24 and table 33.

- 73 -

5 4 3 2 1 Restart indicator 0 1 1 1 1 0 0 1 Information element identifier Length of restart indicator contents 1 0 0 0 0 Class ext

octet 1 octet 2 octet 3

Figure 24 - Restart indicator information element Table 33 - Restart indicator information element Class (octet 3) note 1 Bits 3 2 1 Meaning 0 0 0 indicated channel (note 2) 1 1 1 All channels (note 3) All other values are reserved NOTE 1 Since the interface is never explicitly identified at the Q reference point, the codepoint 110 “single interface” in the class field of ITU-T Rec. Q.931 is not used. NOTE 2 The channel identification information element shall be included, indicating which channel is to be restarted or which has been restarted. NOTE 3 All channels means the signalling channel on which the restart indicator is carried and all user information channels associated with that signalling channel. 1 4 . 5 . 1 9 S e n d in g c o m p le t e The purpose of the sending complete information element is to optionally indicate completion of the called party number. The sending complete is a single octet information element coded as shown in figure 25. 8 1

5 4 3 2 1 Sending complete 0 1 0 0 0 0 1 Information element identifier

octet 1

Figure 25 - Sending complete information element

14.6

Information elements of codeset 5 Codeset 5 contains information elements defined by ETSI. In general the coding rules described in clause 14.5.1 for codeset 0 apply to codeset 5 also. Table 34 lists the information element identifiers for information elements of codeset 5 used in this Standard.

- 74 -

Table 34 - Information element Identifier coding (Codeset 5) 8 1

Coding

Ref.

Length

7 : 0 0

6 : 0 0

5 : 0 1

4 -

3 -

2 -

1 -

Single Octet information elements: Reserved Shift

14.5.3

Variable length information elements:

All other values are reserved.

- 75 -

Annex A ( n o r ma tiv e )

Protocol Implementation Conformance Statement (PICS) for ECMA-143

A.1

Introduction The supplier of a protocol implementation which is claimed to conform to Standard ECMA-143 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 Standards PICS proforma; – by the user or potential user of the implementation, as a basis for initially checking the possibility of interworking with another implementation; NOTE 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.

- 76 -

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

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 ECMA-143. NOTE 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.

- 77 -

A.3

PICS proforma

A.3.1

Implementation Identification Supplier (note 1) Contact point for queries about the PICS (note 1) Implementation Name(s) and Version(s) (note 1, note 2) Other information necessary for full identification e.g., name(s) and version(s) for machines and/or operating systems; System name(s) NOTE 1 Only the first three items are required for all implementations; other information may be completed as appropriate in meeting the requirement for full identification. NOTE 2 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, ECMA-143 Protocol version

Third Edition

Addenda Implemented (if applicable) Amendments Implemented Have any exception items been required ?

No[ ]

Yes[ ]

(The answer Yes means that the implementation does not conform to ECMA-143) Date of Statement

- 78 -

A.3.3 ITEM

Bearers Supported QUESTION/FEATURE

REFERENCE

STATUS

N/A

SUPPORT

Support of the 64kbit/s Unrestricted Bearer

14.5.5

o.1

Yes[ ] No[ ]

Support of the 64kbit/s Bearer with Speech Transfer Capability

14.5.5

o.1

Yes[ ] No[ ]

Support of the 64kbit/s Bearer with 3.1kHz/Audio Transfer Capability

14.5.5

o.1

Yes[ ] No[ ]

Support of the Multi-rate Unrestricted Bearer

14.5.5

o.1

Yes[ ] No[ ]

Support of A-law User Information layer 1 protocol

14.5.5

(Z2 OR Z3):o.3

[]

Yes[ ] No[ ]

Support of µ-law User Information layer 1 protocol

14.5.5

(Z2 OR Z3):o.3

[]

Yes[ ] No[ ]

Support of the unrestricted digital information with tones / announcements bearer

14.5.5

A.3.4

Yes[ ] No[ ]

General procedures

A.3.4.1 Use of the services of the Signalling Carriage Mechanism ITEM A1

QUESTION/FEATURE Use of the services of the Signalling Carriage Mechanism

REFERENCE

STATUS

9.1

REFERENCE

STATUS

N/A

SUPPORT Yes[ ]

A . 3 . 4 . 2 H a n d lin g o f P r o t o c o l Er r o r C o n d it io n s ITEM

QUESTION/FEATURE

N/A

SUPPORT

Treatment of protocol discriminator error

9.2.1

Yes[ ]

Treatment of message too short

9.2.2

Yes[ ]

Treatment of call reference error

9.2.3

Yes[ ]

Treatment of message type or message sequence errors

9.2.4

Yes[ ]

A10

Treatment of information element errors

9.2.5 - 9.2.7

Yes[ ]

A11

Signalling Carriage Mechanism reset

9.2.8

Yes[ ]

A12

Signalling Carriage Mechanism failure

9.2.9

Yes[ ]

- 79 -

A.3.4.3 Status and Status Enquiry protocol procedures ITEM

QUESTION/FEATURE

REFERENCE STATUS

N/A

SUPPORT

A13

Receipt of a STATUS ENQUIRY message

9.3.1

Yes[ ]

A14

Sending of a STATUS ENQUIRY message

9.3.1

Yes[ ] No[ ]

A15

Receipt of a solicited STATUS message

9.3.2

c.1

Yes[ ] No[ ]

A16

Receipt of an Unsolicited STATUS message

9.3.2

Yes[ ]

c.1 If A14 then mandatory else optional

- 80 -

A.3.5

Circuit Switched Call Control

ITEM

QUESTION/FEATURE

REFERENCE

STATUS

N/A

SUPPORT

Is the implementation capable of functioning as an Originating PINX ?

10.5

o.2

Yes[ ] No[ ]

Is the implementation capable of functioning as an Incoming Gateway PINX ?

10.7

o.2

Yes[ ] No[ ]

Is the implementation capable of functioning as a Transit PINX ?

10.4

o.2

Yes[ ] No[ ]

Is the implementation capable of functioning as a Terminating PINX ?

10.6

o.2

Yes[ ] No[ ]

Is the implementation capable of functioning as an Outgoing Gateway PINX ?

10.8

o.2

Yes[ ] No[ ]

Support procedures for call request

10.1.1

c.2

[]

Yes[ ]

Does the implementation include a Sending Complete information element in every generated SETUP message ?

10.1.1

c.3

[]

Yes[ ] No[ ]

Information channel selection

10.1.2

[]

Yes[ ]

Overlap Receiving procedures

10.1.3

c.4 (note 1)

[]

Yes[ ] (note 1)

B10

Overlap Sending procedures

10.1.3

c.5

[]

Yes[ ]

B11

Call Proceeding - Enbloc Sending (Receipt and Origination)

10.1.4/ 10.1.4.1

[]

Yes[ ]

B12

Receipt of Call Proceeding - Overlap Sending

10.1.4/ 10.1.4.2

B10:m

[]

Yes[ ]

B13

Sending of Call Proceeding - Overlap Receiving

10.1.4/ 10.1.4.2

B9:m

[]

Yes[ ]

B14

Support of ALERTING origination

10.1.5

c.4

[]

Yes[ ]

B15

Support of ALERTING termination

10.1.5

c.2

[]

Yes[ ]

B16

Support of call connection procedures

10.1.6

m (note 2)

[]

Yes[ ] (note 2)

B17

Sending of call progress information during call establishment

10.1.7

c.6

[]

Yes[ ]

B18

Receipt of call progress information during call establishment

10.1.7

Yes[ ]

B19

Support of call clearing procedures

10.2

Yes[ ]

B20

Support of call collision procedures

10.3

Yes[ ]

NOTE 1 If enbloc signalling only is used between two adjacent PINXs, overlap receiving procedures need not be tested. NOTE 2 If by mutual agreement between adjacent PINXs T313 is not implemented, then the sending of CONNECT ACKNOWLEDGE message is optional. c.2

If B1 OR B2 OR B3 then mandatory else N/A

c.3

If B1 OR B2 OR B3 then optional else N/A

c.4

If B3 OR B4 OR B5 then mandatory else N/A

- 81 -

A.3.6 ITEM

c.5

If (B1 OR B2 OR B3) AND NOT B7 then mandatory else N/A

c.6

If (B3 OR B4 OR B5) then optional else N/A

Call Control at a Transit PINX QUESTION/FEATURE

REFERENCE STATUS

N/A

10.4/10.4.1 to 10.4.9

B3:m

[]

SUPPORT

Call origination/termination procedures

Call abort procedures

10.4.10.2

B3:o

Call clearing procedures

10.4.10.1

B3:m

[]

Yes[ ]

Handling of Category 1, 2 and 3 information elements at a Transit PINX

10.4.11

B3:m

[]

Yes[ ]

A.3.7

Call Control at a Originating PINX

ITEM

QUESTION/FEATURE

Yes[ ] Yes[ ] No[ ]

REFERENCE STATUS

N/A

SUPPORT

Call origination procedures

10.5/10.5.1 to 10.5.5

B1:m

[]

Yes[ ]

Call clearing procedures

10.5.6

B1:m

[]

Yes[ ]

A.3.8 ITEM

Call Control at a Terminating PINX QUESTION/FEATURE

Call termination procedures

Call clearing procedures

A.3.9 ITEM

REFERENCE STATUS

N/A

SUPPORT

10.6/10.6.1 to 10.6.4

B4:m

[]

Yes[ ]

10.6.5

B4:m

[]

Yes[ ]

Call Control at an Incoming Gateway PINX QUESTION/FEATURE

Establishment of calls from another network

Call clearing procedures

REFERENCE STATUS

N/A

SUPPORT

10.7/10.7.1 to 10.7.6

B2:m

[]

Yes[ ]

10.7.7

B2:m

[]

Yes[ ]

A.3.10 Call Control at an Outgoing Gateway PINX ITEM

QUESTION/FEATURE

Establishment of calls to another network

Call clearing procedures

REFERENCE STATUS

N/A

SUPPORT

10.8/10.8.1 to 10.8.5

B5:m

[]

Yes[ ]

10.8.6

B5:m

[]

Yes[ ]

- 82 -

A.3.11 Procedures for Layer Management ITEM

QUESTION/FEATURE

REFERENCE

STATUS

N/A

SUPPORT

Initiation of Restart procedures - All channels

11.1.1

Yes[ ] No[ ]

Initiation of Restart procedures - Multiple channels

11.1.1

Z4:o

Initiation of Restart procedures - Single channels

11.1.1

Yes[ ] No[ ]

Receipt of RESTART - All channels

11.1.2

Yes[ ]

Receipt of RESTART - Single channels

11.1.2

Yes[ ]

Receipt of RESTART - multiple channels

11.1.2

Z4:m

[]

Yes[ ]

Restart procedures - Restart collision

11.1.3

(H1 OR H2 OR H3):m

[]

Yes[ ]

REFERENCE

STATUS

N/A

SUPPORT

[]

Yes[ ] No[ ]

A.3.12 Timers ITEM

QUESTION/FEATURE

Implementation of T301

c.7

[]

Yes[ ] No[ ] Value [ ]

Implementation of T302

c.8

[]

Yes[ ]

Implementation of T303

c.9

[]

Yes[ ]

Implementation of T304

B10:m

[]

Yes[ ]

Implementation of T305

12/10.2.3

Yes[ ]

Implementation of T308

12/10.2.3

Yes[ ]

Implementation of T309

Yes[ ] Value [

Implementation of T310

c.10

[]

]

m:Yes[ ·] o:Yes[ ] No[ ] Value [ ]

Implementation of T313

c.11

[]

Yes[ ] No[ ]

I10

Implementation of T316

12/11.1.1

c.12

[]

Yes[ ]

I11

Implementation of T322

12/9.3.1

A14:m

[]

Yes[ ]

c.7

If B1 OR B2 OR B3 then optional else N/A

c.8

If B3 OR B4 OR B5 then mandatory else N/A

c.9

If B1 OR B2 OR B3 then mandatory else N/A

c.10 If B1 OR B2 mandatory else If B3 optional else N/A c.11 If B3 OR B4 OR B5 then optional else, N/A c.12 If H1 OR H2 then mandatory else N/A

- 83 -

A.3.13 Messages and information elements for general procedures NOTE Although an implementation may be marked "Yes" for questions regarding sending optional information elements, they will only be sent, for example, if they are received from a terminal or a preceding PINX. ITEM

QUESTION/FEATURE

REFERENCE STATUS

N/A

SUPPORT

Receipt of the messages in accordance with the procedures supported, and receipt of all the permitted information elements in those messages

Yes[ ]

Sending of messages, including for each message those information elements marked as mandatory for that message, in accordance with the procedures supported

Yes[ ]

Sending of the Channel Identification information element when mandatory in a SETUP ACKNOWLEDGE, CALL PROCEEDING, ALERTING or CONNECT message when that message is the first response to a SETUP message

Yes[ ]

Sending of a Sending Complete information element in an INFORMATION message when overlap sending is complete

13.2.6

Yes[ ] No[ ]

Sending of a Progress Indicator information element in an ALERTING message (except when relaying at a Transit PINX in accordance with C4)

13.2.1

Yes[ ] No[ ]

Sending of a Progress Indicator information element in a CONNECT message (except when relaying at a Transit PINX in accordance with C4)

13.2.3

Yes[ ] No[ ]

Sending of a Low layer compatibility information element in a CONNECT message (except when relaying at a Transit PINX in accordance with C4)

13.2.3

Yes[ ] No[ ]

Sending of a Connected Number information element in a CONNECT message (except when relaying at a Transit PINX in accordance with C4)

13.2.3

Yes[ ] No[ ]

Sending of a Connected Subaddress information element in a CONNECT message (except when relaying at a Transit PINX in accordance with C4)

13.2.3

Yes[ ] No[ ]

J10

Sending of a Cause information element in a PROGRESS message (except when relaying at a Transit PINX in accordance with C4)

13.2.7

Yes[ ] No[ ]

J11

Sending of a Cause information element in a RELEASE or a RELEASE COMPLETE message when it is not the first clearing message

13.2.8, 13.2.9

Yes[ ] No[ ]

J12

Sending of a Sending Complete information element in a SETUP message when enbloc sending

13.2.10

Yes[ ] No[ ]

J13

Sending of a Progress Indicator information element in a SETUP message (except when relaying at a Transit PINX in accordance with C4)

13.2.10

Yes[ ] No[ ]

J14

Sending of a Calling Party Number information element in a SETUP message (except when relaying at a Transit PINX in accordance with C4)

13.2.10

Yes[ ] No[ ]

- 84 -

J15

Sending of a Calling Party Subaddress information element in a SETUP message (except when relaying at a Transit PINX in accordance with C4)

13.2.11

Yes[ ] No[ ]

J16

Sending of a Called Party Subaddress information element in a SETUP message (except when relaying at a Transit PINX in accordance with C4)

13.2.11

Yes[ ] No[ ]

J17

Sending of a Low Layer Compatibility information element in a SETUP message (except when relaying at a Transit PINX in accordance with C4)

13.2.10

Yes[ ] No[ ]

J18

Sending of a High Layer Compatibility information element in a SETUP message (except when relaying at a Transit PINX in accordance with C4)

13.2.10

Yes[ ] No[ ]

J19

Sending of a Channel Identification information element in a RESTART message

13.3.1

H2:m

J20

Sending of a Channel Identification information element in a RESTART ACKNOWLEDGE message

13.3.2

Yes[ ] No[ ]

J21

Support of channel map

14.5.12

Yes[ ] No[ ]

J22

Type of number supported for ISDN/Telephony Numbering Plan: Unknown International number National number Subscriber number

14.5.7

Type of number supported for Private Numbering Plan: Unknown Level 2 regional number Level 1 regional number PISN specific number Level 0 regional number Abbreviated number

14.5.7

Type of number supported for Unknown Numbering Plan: Unknown

14.5.7

J23

J24

J25

Message formats and codings for messages and information elements supported

[]

Yes[ ]

Yes[ ] No[ ] Yes[ ] No[ ] Yes[ ] No[ ] Yes[ ] No[ ] o Yes[ ] No[ ] Yes[ ] No[ ] Yes[ ] No[ ] Yes[ ] No[ ] Yes[ ] No[ ] Yes[ ] No[ ] o Yes[ ] No[ ] 14

Yes[ ]

- 85 -

A.3.14 Message segmentation / re-assembly procedures ITEM

QUESTION/FEATURE

REFERENCE STATUS

N/A

SUPPORT

Maximum message size generated

ZA.3

Size [

]

Maximum message size received

ZA.3

Size [

]

Is length of signalling carriage mechanism information field < max. generated message size

ZA.3

Yes[ ] No[ ]

Is length of signalling carriage mechanism information field < max. received message size

ZA.3

Yes[ ] No[ ]

Procedures for messages segmentation

ZA.3.1

c.12

Yes[ ]

Procedures for messages re-assembly

ZA.3.2

c.13

[]

Yes[ ]

Message formats and codings for segmented messages and information elements supported

ZA.4, ZA.5

c.14

[]

Yes[ ]

Implementation of T314

ZA.6

c.13

[]

Yes[ ]

c.12 If K3, then mandatory

else, prohibited

c.13 If K4, then mandatory

else, not applicable

c.14 If K3 or K4, then mandatory

else, not applicable

A.3.15 Additional progress descriptions ITEM

QUESTION/FEATURE

REFERENCE STATUS

N/A

SUPPORT

Up to three Progress indicator information elements within the same message

annex ZB

Yes[ ]

Additional progress descriptions

annex ZB

Yes[ ]

- 86 -

- 87 -

Annex B ( in f o r ma tiv e )

Use of the cause information element

B.1

Definition of cause values Cause Number 1 “Unallocated (unassigned) number” This cause indicates that the destination requested by the calling user cannot be reached because, although the number is in a valid format, it is not currently assigned (allocated). “No route to destination” Cause Number 3 This cause indicates that the called user cannot be reached because the network through which the call has been routed does not serve the desired destination. “Channel unacceptable” Cause Number 6 This cause indicates that the channel most recently identified is not acceptable to the sending entity for use in this call. “Normal call clearing” Cause Number 16 This cause indicates that one of the users involved in the call has requested that the call be cleared. “User busy” Cause Number 17 This cause is used when the user equipment is compatible with the call but called user resources are temporarily unavailable. “No user responding” Cause Number 18 This cause is used when the called user’s equipment does not respond to a call establishment message with either an alerting or a connect indication within the prescribed period of time allocated. “No answer from user (user alerted)” Cause Number 19 This cause is used when a user has provided an alerting indication but has not provided a connect indication within a prescribed period of time. “Call rejected” Cause Number 21 This cause indicates that the called user does not wish to accept this call, although his equipment is neither busy nor incompatible. “Number changed” Cause Number 22 This cause is returned to a calling user when the called party number indicated by the calling user is no longer assigned. The new called party number may optionally be included in the diagnostic field.(If a network does not support this capability, cause number 1 "Unallocated (unassigned) number" shall be used). “Destination out of order” Cause Number 27 This cause indicates that the destination indicated by the user cannot be reached because the interface to the destination is not functioning correctly, i.e. a signalling message could not be delivered to the remote user (e.g., a Signalling Carriage Mechanism failure at the remote user, user equipment off-line, etc). “Invalid number format (address incomplete)” Cause Number 28 This cause indicates that the called user cannot be reached because the called party number is not a valid format or is not complete. “Response to STATUS ENQUIRY” Cause Number 30 This cause is included in the STATUS message when the reason for generating the STATUS message was the prior receipt of a STATUS ENQUIRY message. “Normal unspecified” Cause Number 31 This cause is used to report a normal event only when no other cause in the normal class applies.

- 88 -

Cause Number 34 “No circuit/channel available” This cause indicates that there is no appropriate circuit /channel presently available to handle the call. “Temporary failure” Cause Number 41 This cause indicates that the network is not functioning correctly and that the condition is not likely to last a long period of time. (The user may wish to try another call attempt almost immediately). “Requested circuit/channel not available” Cause Number 44 This cause is returned when the circuit or channel indicated by the requesting entity cannot be provided by the other side of the interface/by the peer entity. “Bearer capability not authorized” Cause Number 57 This cause indicates that the user has requested a bearer capability which is implemented by the equipment generating this cause but which the user is not authorized to use. “Bearer capability not presently available” Cause Number 58 This cause indicates that the user has requested a bearer capability which is implemented by the equipment generating this cause but which is not available at this instant. “Service or option not available, unspecified” Cause Number 63 This cause is used to report a service or option not available event only when no other cause in the service or option not available class applies. “Bearer capability not implemented” Cause Number 65 This cause indicates that the equipment sending this cause does not support the bearer capability requested. “Invalid call reference value” Cause Number 81 This cause indicates that the equipment sending this cause has received a message with a call reference which is not currently in use on that particular link. “Identified channel does not exist” Cause Number 82 This cause indicates that the equipment sending this cause has received a request to use a channel not activated on the inter PINX link. “Incompatible destination” Cause Number 88 This cause indicates that the equipment sending this cause has received a request to establish a call which has LLC, HLC, or other compatibility attributes (e.g. data rate) which cannot be accommodated. “Mandatory information element is missing” Cause Number 96 This cause indicates that the equipment sending this cause has received a message which is missing an information element that must be present in order for that message to be processed. “Message type non-existent or not implemented” Cause Number 97 This cause indicates that the equipment sending this cause has received a message with a message type it does not recognise either because this is a message not defined or defined but not implemented by the equipment sending this cause. “Message not compatible with call state or message type non-existent or not Cause Number 98 implemented” This cause indicates that the equipment sending this cause has received a message which it does not recognise or which is not compatible with the call state. “Information element non-existent or not implemented” Cause Number 99 This cause indicates that the equipment sending this cause has received a message which includes information elements not recognised because the information element identifier is not defined or it is defined but not implemented by the equipment sending the cause. “Invalid information element contents” Cause Number 100 This cause indicates that the equipment sending this cause has received an information element which it has implemented; however, one or more of the fields in the information element are coded in a way that has not been implemented by the equipment sending this cause. “Message not compatible with call state” Cause Number 101 This cause indicates that the equipment sending this cause has received a message which is incompatible with the call state, or a STATUS message indicating an incompatible call state.

- 89 -

Cause Number 102 “Recovery on timer expiry” This cause indicates that a procedure has been initiated by the expiry of a timer in association with the PSS1 error handling procedures. “Protocol error, unspecified” Cause Number 111 This cause is used to report a protocol error event only when no other cause in the protocol error class applies.

B.2

Use of causes for busy conditions The following cause values are used in PSS1 for busy (= congestion) cases: – cause number 34 “no circuit /channel available” should be generated by the side (incoming or outgoing) that determines that no suitable inter-PINX information channel is available to establish the call; – cause number 44 “requested circuit /channel not available” should be generated by the incoming side if it is unable to accept the particular inter-PINX information channel proposed by the outgoing side. In both cases the location field should be coded “PISN serving the local user”. This coding may be changed to “PISN serving the remote user” when received from another private network. Note that cause number 17 “user busy” should not be generated when congestion is encountered at the Qreference point.

- 90 -

- 91 -

Annex C ( in f o r ma tiv e )

Examples of message sequences

C.1

Enbloc sending

C.1.1

Successful call setup Figure C.1 shows an example of the message sequences across the PISN when a call is initiated from TE A to TE B (which is free) and the called party number in the original SETUP message is complete. TE A

PINX A

Transit PINX

PINX B

TE B

SETUP (cr1) SETUP (cr2) CALL PROCEEDING (cr1)

SETUP (cr3) CALL PROCEEDING (cr2)

SETUP (cr4) CALL PROCEEDING (cr3) ALERTING (cr4) ALERTING (cr3) CONNECT (cr4)

ALERTING (cr2) CONNECT (cr3)

ALERTING (cr1) CONNECT (cr2)

CONNECT ACK (cr4)

CONNECT (cr1)

CONNECT ACK (cr3) CONNECT ACK (cr2)

CONNECT ACK (cr1)

Call between TE-A and TE-B Active

Figure C.1 - Enblock setup, successful call

C.1.2

Unsuccessful call setup Figure C.2 shows an example of the message sequences across the PISN when a call is initiated from TE A to TE B (which is busy) and the called party number in the original SETUP message is complete. TE A

PTNX A

Transit PINX

PINX B

SETUP (cr1)

TE B Call Active (cr5)

SETUP (cr2) CALL PROCEEDING (cr1)

SETUP (cr3) CALL PROCEEDING (cr2)

SETUP (cr4) CALL PROCEEDING (cr3) RELEASE COMP (cr4) DISCONNECT (cr3)

DISCONNECT (cr2) DISCONNECT (cr1)

cause # 17

cause # 17 RELEASE (cr3)

cause # 17 RELEASE (cr2)

RELEASE COMP (cr3)

RELEASE (cr1) RELEASE COMP (cr2) RELEASE COMP (cr1)

Figure C.2 - Enblock setup, unsuccessful call

cause # 17

- 92 -

C.2

Overlap sending

C.2.1

Successful call setup Figure C.3 shows an example of the message sequences across the PISN when a call is initiated from TE A to TE B (which is free) and the called party number in the original SETUP message is empty. TE A

PINX A

(No. 12345)

Transit PINX

(node 12)

PINX B

(node 13)

TE B

(node 14)

(No. 14345)

SETUP (cr1) CPN empty SETUP ACK (cr1) INFO (cr1, CPN=1) INFO (cr1, CPN=4) SETUP (cr2, CPN=14) INFO (cr1, CPN=3)

SETUP (cr3, CPN=14) SETUP ACK (cr2)

INFO (cr1, CPN=4)

SETUP ACK (cr3) INFO (cr2, CPN=3)

INFO (cr1, CPN=5)

INFO (cr3, CPN=3) INFO (cr2, CPN=4)

CALL PROCEEDING (cr1)

INFO (cr3, CPN=4) INFO (cr2, CPN=5) INFO (cr3, CPN=5) CALL PROCEEDING (cr2)

SETUP (cr4) CALL PROCEEDING (cr3) ALERTING (cr4) ALERTING (cr3)

ALERTING (cr2) ALERTING (cr1)

CONNECT (cr4) CONNECT (cr3)

CONNECT (cr2)

CONNECT ACK (cr4) CONNECT ACK (cr3)

CONNECT (cr1) CONNECT ACK (cr2) CONNECT ACK (cr1)

Call between TE-A and TE-B Active

Figure C.3 - Overlap setup, successful call

- 93 -

C.2.2

Unsuccessful call setup Figure C.4 shows an example of the message sequences across the PISN when a call is initiated from TE A to TE B (which is busy) and the called party number in the original SETUP message is empty.

TE A

PINX A

(No. 12345)

Transit PINX

(node 12)

PINX B

(node 13)

TE B

(node 14)

(No. 14345)

SETUP (cr1) CPN empty Call Active (cr5)

SETUP ACK (cr1) INFO (cr1, CPN=1) INFO (cr1, CPN=4) SETUP (cr2, CPN=14) INFO (cr1, CPN=3)

SETUP (cr3, CPN=14) SETUP ACK (cr2)

INFO (cr1, CPN=4)

SETUP ACK (cr3) INFO (cr2, CPN=3)

INFO (cr1, CPN=5)

INFO (cr3, CPN=3) INFO (cr2, CPN=4)

CALL PROCEEDING (cr1)

INFO (cr3, CPN=4) INFO (cr2, CPN=5) INFO (cr3, CPN=5) CALL PROCEEDING (cr2)

SETUP (cr4) CALL PROCEEDING (cr3) RELEASE COMP (cr4) DISCONNECT (cr3)

DISCONNECT (cr2) DISCONNECT (cr1)

cause # 17

RELEASE (cr3) RELEASE (cr2) RELEASE COMP (cr3)

RELEASE (cr1) RELEASE COMP (cr2) RELEASE COMP (cr1)

Figure C.4 - Overlap setup, unsuccessful call

cause # 17

- 94 -

C.3

Call clearing

C.3.1

Normal call clearing (from originator) Figure C.5 shows an example of call clearing from the active state, initiated by TE A when TE A goes on hook. TE A

PINX A

Transit PINX

PINX B

TE B

Call between TE-A and TE-B Active DISCONNECT (cr1) DISCONNECT (cr2)

cause # 16

DISCONNECT (cr3)

RELEASE (cr1)

DISCONNECT (cr4)

cause # 16

RELEASE (cr2) RELEASE COMP (cr1)

RELEASE (cr3) RELEASE COMP (cr2)

RELEASE (cr4) RELEASE COMP (cr3) RELEASE COMP (cr4)

Figure C.5 - Normal call clearing by originator

C.3.2

Call abort by a Transit PINX Figure C.6 shows an example of a transit PINX aborting a call (for some reason) which is in the active state, without tones and announcements being provided. The use of cause number 41 "temporary failure" is shown only as an example, and is not intended to preclude the use of other cause values in this situation. TE A

PINX A

Transit PINX

PINX B

TE B

Call between TE-A and TE-B Active Abort Call

DISCONNECT (cr1)

DISCONNECT (cr2)

DISCONNECT (cr3)

cause # 41

RELEASE (cr2)

RELEASE (cr3)

RELEASE COMP (cr2)

RELEASE COMP (cr3)

DISCONNECT (cr4) cause # 41

cause # 41 RELEASE (cr1)

RELEASE (cr4)

RELEASE COMP (cr1)

RELEASE COMP (cr4)

F ig u r e C . 6 - C a ll a b o r t b y Tr a n s it P I N X

- 95 -

Annex D ( in f o r ma tiv e )

Manufacturer specific information

PSS1 permits the inclusion in messages of non-standardised information which is specific to a particular design of PINX, a particular network, etc. This information is known as Manufacturer Specific Information. This Standard also permits the use of non-standardised messages and information elements between adjacent PINXs. No procedures are defined in this Standard for the handling of these messages and information elements at PINXs except the error procedures defined in clauses 9.2.4 and 9.2.7, which will apply in the event of an unrecognised message or information element being received by a PINX. NOTE Ambiguity may arise when two implementations use the same message identifier or information element identifier for different purposes.

- 96 -

- 97 -

Annex E ( in f o r ma tiv e )

SDL diagram for the procedures over a symmetrical link between two peer PINX’s

E.1

Protocol Control SDL diagram Figure E.2 in this annex contains an SDL diagram which provides an example of the Protocol Control procedures as described in clauses 10.1 to 10.3 of this Standard. The procedures illustrated are not intended to be exhaustive, and several potential situations that may occur have been omitted from the SDL (e.g. some error conditions and procedures). Figure E.1 provides the key to the symbols used in figure E.2. The primitive symbols contain primitives which come from a number of sources, each identified by a prefix to the primitive name as indicated in table E.1 Ta b le E. 1 - K e y t o p r im it iv e t y p e s in P r o t o c o l C o n t r o l S D L d ia g r a m Prefix

Primitive from/to:

CC_

Call Control

GCC_

Global Call Control

DL_

Signalling Carriage Mechanism

Event_

An entity which provides Protocol Control with notification of protocol related events other than receipt of incoming messages or primitives from Call Control, Global Call Control or the Signalling Carriage Mechanism

Protocol Control state ‘n’

Option symbol

Incoming Primitive

Incoming Message

Outgoing Primitive

Outgoing Message

Task symbol

Decision symbol

F ig u r e E. 1 - K e y t o s y m b o ls u s e d in t h e P r o t o c o l C o n t r o l S D L d ia g r a m

- 98 -

Null

A CC_Setup Request

Allocate Call Reference

RELEASE COMPLETE

SETUP

Null

Mandatory IE missing or invalid content ?

YES

Idle B-channel Available ?

Call Reference flag =1 ?

YES

CC_Reject Indication

Select Idle Information - channel

Save Call Reference

SETUP

Idle B-channel Available ?

Null

YES

Null

YES

Start Timer T303

Valid Information ?

YES

Call Initiated

CC_Setup Indication

RELEASE COMPLETE

Call Present

Release Call Reference

F ig u r e E. 2 - P r o t o c o l C o n t r o l S D L d ia g r a m ( s h e e t 1 o f 2 2 )

Null

- 99 -

Call State Indicated ?

STATUS ENQUIRY

DL_Release Indication

STATUS

Null

RELEASE

Unexpected or unrecognised Message

RELEASE COMPLETE

State = 0

0 State ° 0

Null

Note 4

RELEASE COMPLETE

Null

RELEASE COMPLETE

STATUS (#30)

Null

F ig u r e E. 2 - P r o t o c o l C o n t r o l S D L d ia g r a m ( s h e e t 2 o f 2 2 ) ( c o n t in u e d )

Null

- 100 -

Call Initiated

CC_Disconnect Request

CC_Release Request

SETUP ACK

CALL PROCEEDING

RELEASE COMPLETE

Unexpected RELEASE

Stop T303

CC_Release Indication

DISCONNECT

RELEASE

Start T304

Start T310

CC_Reject Indication

RELEASE COMPLETE

Start T305

Start T308

CC_More Info Indication

CC_Proceed Indication

Release B-channel and Call Reference

Release Call reference

Disconnect Request

Release Request

Overlap Sending

Outgoing Call Proceeding

Null

F ig u r e E. 2 - P r o t o c o l C o n t r o l S D L d ia g r a m ( s h e e t 3 o f 2 2 ) ( c o n t in u e d )

- 101 -

B Note 3

Note 3

ALERTING

Event_Expiry T303

CONNECT

Unexpected DISCONNECT

Note 1 Stop T303

First Expiry ?

Stop T303

Stop all timers

YES

CC_Proceed Indication

CC_Alerting Indication

CC_Setup Confirmation

Optionally start T301

CONNECT ACKNOWLEDGE

Call Delivered

Call Active

SETUP

CC_Release Indication

Restart T303

RELEASE COMPLETE

Call Initiated

Release Call reference

CC_Disconnect indication

Null

F ig u r e E. 2 - P r o t o c o l C o n t r o l S D L d ia g r a m ( s h e e t 4 o f 2 2 ) ( c o n t in u e d )

Disconnect Indication

- 102 -

Overlap Sending

PROGRESS

CALL PROCEEDING

ALERTING

CONNECT

CC_Progress Indication

Stop T304

Overlap Sending

Start T310

CC_Alerting Indication

CC_Setup Confirm

CC_Proceed Indication

Optionally start T301

CONNECT ACKNOWLEDGE

Outgoing Call Proceeding

Call Delivered

Call Active

F ig u r e E. 2 - P r o t o c o l C o n t r o l S D L d ia g r a m ( s h e e t 5 o f 2 2 ) ( c o n t in u e d ) C CC_Release Request

Event_Expiry T304

CC_Information Request

Stop T304

DISCONNECT

INFORMATION

RELEASE

Start T305

Start T304

11 Start T308

Disconnect Request

Overlap Sending

Release Request

F ig u r e E. 2 - P r o t o c o l C o n t r o l S D L d ia g r a m ( s h e e t 6 o f 2 2 ) ( c o n t in u e d )

- 103 -

Outgoing Call Proceeding

CC_Release Request

ALERTING

PROGRESS

CONNECT

Event_expiry T310

Stop T310

Stop T310 (if CCITT Progress Description No.s 1, 2 or 8 received)

Stop T310

DISCONNECT

RELEASE

CC_Alerting Indication

CC_Progress Indication

CC_Setup Confirmation

Start T305

Release Request

Optionally start T301

Call Delivered

Outgoing Call Proceeding

CONNECT ACKNOWLEDGE

Disconnect Request

Call Active

F ig u r e E. 2 - P r o t o c o l C o n t r o l S D L d ia g r a m ( s h e e t 7 o f 2 2 ) ( c o n t in u e d )

- 104 -

Call Delivered

PROGRESS

CONNECT

Event_expiry T301

CC_Progress Indication

Stop T301 if running

DISCONNECT

Call Delivered

CC_Setup Confirmation

Start T305

CONNECT ACKNOWLEDGE

Disconnect Request

Call Active

F ig u r e E. 2 - P r o t o c o l C o n t r o l S D L d ia g r a m ( s h e e t 8 o f 2 2 ) ( c o n t in u e d )

- 105 -

Call Present

Note 3

CC_Setup Response

CC_Reject Request

CC_Proceed Request

CC_More Info Request

CC_Alerting Request

CONNECT

RELEASE COMPLETE

CALL PROCEEDING

SETUP ACKNOWLEDGE

ALERTING

Incoming Call Proceeding

Start T302

Release Call Reference

Start T313

25 Null

Connect Request

Overlap Receiving

10 Call Active

F ig u r e E. 2 - P r o t o c o l C o n t r o l S D L d ia g r a m ( s h e e t 9 o f 2 2 ) ( c o n t in u e d )

Call Received

- 106 -

Call Received

Connect Request

CC_Progress Request

CC_Setup Response

Event_Expiry T313

CONNECT ACK

PROGRESS

CONNECT

DISCONNECT

Stop T313

Call Received

Start T305

Start T313

10 Call Active

Connect Request

Call Active

Disconnect Request

F ig u r e E. 2 - P r o t o c o l C o n t r o l S D L d ia g r a m ( s h e e t 1 0 o f 2 2 ) ( c o n t in u e d )

Call Active

CC_Progress Request

PROGRESS

CC_Progress Indication

Call Active

States 7, 8 9 & 10

CONNECT ACKNOWLEDGE

Call Active

INFORMATION

Discard Information

Remain in current state

F ig u r e E. 2 - P r o t o c o l C o n t r o l S D L d ia g r a m ( s h e e t 1 1 o f 2 2 ) ( c o n t in u e d )

- 107 -

Disconnect Indication

CC_Setup Response

CC_Alerting Request

CC_Progress Request

RELEASE

CC_Release Request

CONNECT

ALERTING

PROGRESS

CC_Release Indication

RELEASE

Incoming Call proceeding

Release Information channel

RELEASE COMPLETE

Start T308

7 Start T313

Incoming Call Proceeding

Call received

Connect Request

19 Release Call Reference

Release Request

0 Null

F ig u r e E. 2 - P r o t o c o l C o n t r o l S D L d ia g r a m ( s h e e t 1 2 o f 2 2 ) ( c o n t in u e d )

- 108 -

Disconnect Request

RELEASE

DISCONNECT

Event_Expiry T305

Stop T305

Disconnect Information channel

RELEASE

Release B-channel

Stop T305

Start T308

CC_Release Indication

RELEASE

CC_Release Indication

RELEASE COMPLETE

Start T308

Release Call reference

0 Null

Release Request

CC_Release Indication

Release Request

F ig u r e E. 2 - P r o t o c o l C o n t r o l S D L d ia g r a m ( s h e e t 1 3 o f 2 2 ) ( c o n t in u e d )

- 109 -

Release request

RELEASE COMPLETE

RELEASE

19 Stop T308

STATUS (state °null)

Event_Expiry T308

Release request

First Timeout of T308 ?

YES

Release Information channel

RELEASE

Place Information channel in maintenance condition

Release Call reference

Restart T308

Release Call Reference

0 Null

Release Request

0 Null

F ig u r e E. 2 - P r o t o c o l C o n t r o l S D L d ia g r a m ( s h e e t 1 4 o f 2 2 ) ( c o n t in u e d )

- 110 -

Any state, excl: 0,1,11,12,19

Any state, excl: 0,1,6,11,12,19

CC_Disconnect Request

RELEASE

DISCONNECT

Stop all related Timers

Disconnect Information channel

Disconect and release Information channel

Disconnect Information channel

DISCONNECT

CC_Release Indication

CC_Disconnect Indication

Start T305

RELEASE COMPLETE

Disconnect Request

Release Call Reference

12 Disconnect Indication

Null

F ig u r e E. 2 - P r o t o c o l C o n t r o l S D L d ia g r a m ( s h e e t 1 5 o f 2 2 ) ( c o n t in u e d )

- 111 -

Overlap Receiving

INFORMATION

CC_Proceed Request

CC_Alerting Request

CC_Setup Response

Event_Expiry T302

CC_Progress Request

CC_Information Indication

Stop T302

CC_Timeout T302

PROGRESS

Note 2 CALL PROCEEDING

Start T302

Overlap Receiving

Incoming Call proceeding

ALERTING

CONNECT

Call Received

Start T313

Overlap Receiving

Connect Request

F ig u r e E. 2 - P r o t o c o l C o n t r o l S D L d ia g r a m ( s h e e t 1 6 o f 2 2 ) ( c o n t in u e d )

Overlap Receiving

- 112 -

Any State (Except 0)

Any State (except 0, 19)

STATUS ENQUIRY

STATUS (state = 0)

STATUS (state ° 0)

Note 5

CC_Release Indication

STATUS

Compatible State Indicated ?

YES

Note 5 Remain in current State

Release Call reference

RELEASE

Null State

Start T308

Implementation Option

CC_Release Indication

Release Request

F ig u r e E. 2 - P r o t o c o l C o n t r o l S D L d ia g r a m ( s h e e t 1 7 o f 2 2 ) ( c o n t in u e d )

- 113 -

Any State (Except Null)

Unexpected Message (except REL or REL COM)

SETUP (CR relates to active call)

Unrecognised Message

Remain in Current State

STATUS ENQUIRY

STATUS

STATUS ENQUIRY

STATUS

Remain in Current State

Remaininin Remain CurrentState State Current

Remain in Current State

F ig u r e E. 2 - P r o t o c o l C o n t r o l S D L d ia g r a m ( s h e e t 1 8 o f 2 2 ) ( c o n t in u e d )

- 114 -

Any State (Except 0, 1, 19)

RELEASE COMPLETE

Disconnect and release B-channel

Stop All Related Timers

CC_Release Indication

Release Call reference

0 Null State

F ig u r e E. 2 - P r o t o c o l C o n t r o l S D L d ia g r a m ( s h e e t 1 9 o f 2 2 ) ( c o n t in u e d )

- 115 -

Any State (except 0)

Message with mandatory IE missing

or unrecognised IE encoded comprehension required, other than DISC, REL or REL COMP.

Message with madatory IE content error

STATUS (cause no. 96)

STATUS (cause no. 100)

Remain in Current State

Other than DISC, REL or REL COMP.

GCC_Restart Request

Stop All Timers

CC_Release Indication

Release Call References and B-channels

GCC_Restart Confirm

0 Null

F ig u r e E. 2 - P r o t o c o l C o n t r o l S D L d ia g r a m ( s h e e t 2 0 o f 2 2 ) ( c o n t in u e d )

- 116 -

Any State, except: 2 & 25

Overlap Sending

Overlap Receiving

DL_Establish Indication

DL_Release Indication

DL_Establish Indication

DL_Release Indication

DL_Establish Indication

Remain in current state

CC_Release Indication

CC_Data Link Reset Indication

CC_Release Indication

CC_Data Link Reset Indication

Overlap Sending

Stop T302

Stop T304

Release Information channel and Call Reference

Null

25 Overlap Receiving

Null

F ig u r e E. 2 - P r o t o c o l C o n t r o l S D L d ia g r a m ( s h e e t 2 1 o f 2 2 ) ( c o n t in u e d )

- 117 -

Any State

Any State, except: 0, 2 & 25

DL_Establish Confirm

DL_Release Indication

Is Timer T309 running ?

Event_Expiry T309

Stop all timers running

Stop T309

YES

CC_Release Indication

Start Timer T309

DL_Establish Request

STATUS ENQUIRY

STATUS

Remain in Current state

Remain in current state

Disconnect and release Information channel, release Call Reference

0 Null

F ig u r e E. 2 - P r o t o c o l C o n t r o l S D L d ia g r a m ( s h e e t 2 2 o f 2 2 ) ( c o n c lu d e d ) NOTES to the Protocol Control SDL diagram: NOTE 1 The sending of SETUP a second time on expiry of T303 is an implementation option. NOTE 2 It is assumed that the decision whether complete information has been received or not, at the expiry of T302, will be made by Call Control. NOTE 3 The receipt of ALERTING or CONNECT as a first response to SETUP will not cause a protocol error, even though they would not normally be sent as the first response to the SETUP message. NOTE 4 The procedures section allows RELEASE COMPLETE or STATUS as a response to a STATUS ENQUIRY when an entity is in the Null state. Clause 9.2.3.2 allows RELEASE COMPLETE (with cause number 81 “invalid call reference value”) whereas clause 9.3.1 specifies that STATUS (with cause number 30 “response to STATUS ENQUIRY”) should be returned. NOTE 5 The action to be taken at this point is an implementation option.

- 118 -

- 119 -

Annex F ( in f o r ma tiv e )

SDL diagram for the procedures on either side of a Transit-PINX

F.1

Transit Call Control SDL Diagram NOTE The provision of a transit PINX functionality is an option. When provided, the procedures contained in clause 10.4 are mandatory. Figure F.2 in this annex contains an SDL diagram which provides an example of the Call Control procedures as described in clause 10.4. The procedures illustrated are not intended to be complete, merely an example of the procedures described in the text. Figure F.1 provides the key to the symbols used in figure F.2. The input symbols from the left hand side contain primitives from a number of sources, each identified by a prefix to the primitive name as indicated in table F.1. The output symbols to the left hand side contain primitives to the Incoming Side Protocol Control entity. The input/output symbols to the right hand side contain primitives which are sent from/to the Outgoing Side Protocol Control entity. T a b l e F . 1 - k e y t o p r i m i t i v e t yp e s i n C a l l C o n t r o l S D L d i a g r a m Prefix

Primitive from/to:

CC_

Protocol Control

Event_

An entity which provides Call Control with notification of call related events.

Call Control state ‘n’

Option symbol

Incoming Primitive from incoming side protocol control or event generator

Incoming Primitive from outgoing side protocol control

Outgoing Primitive to incoming side protocol control

Outgoing Primitive to outgoing side protocol control

Task symbol

Decision symbol

F ig u r e F . 1 - K e y t o s y m b o ls u s e d in t h e t r a n s it C a ll C o n t r o l S D L d ia g r a m

- 120 -

TCC_Idle

CC_Setup Indication

Call Processing Succesful ?

YES

Any More Digits Required?

Determine Reason

YES

Note 3 CC_Setup Request

CC_More Info Request

CC_Proceed Request

Sufficient digits to Route on ?

CC_Reject Request

YES

4 TCC_Incoming Call_Proceeding

TCC_Await Digits

F ig u r e F . 2 - Tr a n s it C a ll C o n t r o l S D L d ia g r a m ( s h e e t 1 o f 1 9 )

TCC_Idle

- 121 -

TCC_Await Digits

CC_Info Indication

CC_Disconnect Indication

Call Processing Successful ?

CC_Release Request

YES

Determine Reason

Disconnect (Release Resources) Sufficient Digits To Route On ?

CC_Disconnect Request

YES

Disconnect (Release Resources)

TCC_Idle

TCC_Await Digits

CC_Setup Request

TCC_Await Incoming_Release

Any More Digits Required ?

YES

CC_Proceed Request

TCC_Incoming Call_Proceeding

TCC_Await Additional_Digits

F ig u r e F . 2 - Tr a n s it C a ll C o n t r o l S D L d ia g r a m ( s h e e t 2 o f 1 9 ) ( c o n t in u e d )

- 122 -

CC_Data Link Reset Indication

CC_Timeout T302

Event_Call Abort

CC_Release Indication

Note 2 CC_Disconnect Request

CC_Disconnect Request

Disconnect (Release resources) In band Announcement Appropriate ?

Disconnect (Release Resources)

TCC_Await Incoming_Release

YES

TCC_Idle

CC_Progress Request

CC_Disconnect Request

(CCITT Description no.8)

11 TCC_Await Incoming_Disconnect

Disconnect (Release Resources)

TCC_Await Incoming_Release

F ig u r e F . 2 - Tr a n s it C a ll C o n t r o l S D L d ia g r a m ( s h e e t 3 o f 1 9 ) ( c o n t in u e d )

- 123 -

TCC_Await Additional Digits

C Note 9 CC_Timeout T302

CC_Reject Indication

Note 2

CC_More info Indication

Event_No more digits accepted

Note 2

CC_Disconnect Request

CC_Proceed Request

Channel Acceptable ?

YES

4 Disconnect

CC_Release Request

TCC_Incoming Call _Proceeding

Note 2 8

Note 6 CC_Info Request (empty buffer)

CC_Disconnect Request

TCC_Await Incoming Release

Disconnect

Note 1

Through Connect

3 TCC_Overlap

TCC_Await Incoming Release

F ig u r e F . 2 - Tr a n s it C a ll C o n t r o l S D L d ia g r a m ( s h e e t 4 o f 1 9 ) ( c o n t in u e d )

- 124 -

CC_Data Link Reset Indication

CC_Proceed Indication

CC_Release Request

CC_Info Indication

Save INFO in buffer.

Channel Acceptable ? YES

CC_Disconnect Request

Note 1 Through Connect

CC_Release Request

TCC_Await Additional_Digits

Note 2

Disconnect

CC_Disconnect Request

TCC_Await Incoming Release

Disconnect

TCC_Transit Call_Proceeding

TCC_Await Incoming Release

F ig u r e F . 2 - Tr a n s it C a ll C o n t r o l S D L d ia g r a m ( s h e e t 5 o f 1 9 ) ( c o n t in u e d )

3 TCC_Overlap

CC_Alerting Indication

CC_Setup Confirmation

CC_Info Indication

CC_Progress Indication

Note 7

Note 4

CC_Info Request

Through Connect

CC_Progress Request

CC_Alerting Request

CC_Setup Response

3 TCC_Overlap

TCC_Call_Alerting

7 TCC_Call_Active

F ig u r e F . 2 - Tr a n s it C a ll C o n t r o l S D L d ia g r a m ( s h e e t 6 o f 1 9 ) ( c o n t in u e d )

- 125 -

D Note 9 CC_Data Link Reset Indication

CC_Data Link Reset Indication

CC_Proceed Indication

Event_No More Digits Accepted

CC_Timeout T302

Note 2

CC_Disconnect Request

TCC_Transit Call_Proceeding

CC_Proceed Request

Note 2 CC_Disconnect Request

CC_Disconnect Request

TCC_Await Two_way_Release

5 TCC_Transit Call_Proceeding

TCC_Await Two_way_Release

F ig u r e F . 2 - Tr a n s it C a ll C o n t r o l S D L d ia g r a m ( s h e e t 7 o f 1 9 ) ( c o n t in u e d )

- 126 -

4 TCC_Incoming Call_Proceeding

CC_More Info Indication

Channel Acceptable ? YES

Number information buffered ?

CC_Disconnect Request

CC_Proceed Indication

CC_Disconnect Request

Channel Acceptable ? YES

Note 1

Through Connect

CC_Release Request

CC_Reject Indication

TCC_Await Incoming_Release

Note 1

Through Connect

Disconnect

CC_Release Request

CC_Disconnect Request

TCC_Transit Call_Proceeding

YES

CC_Info Request

Disconnect

TCC_Await Incoming_Release

Disconnect

(buffered information)

8 TCC_Transit Call_Proceeding

TCC_Await Incoming_Release

F ig u r e F . 2 - Tr a n s it C a ll C o n t r o l S D L d ia g r a m ( s h e e t 8 o f 1 9 ) ( c o n t in u e d )

- 127 -

TCC_Transit Call_Proceeding

CC_Alerting Indication

CC_Timeout T302

Note 4

Note 7

Note 2 CC_Proceed Request

CC_Setup Confirmation

TCC_Transit Call_Proceeding

Through Connect (if not already)

CC_Alerting Request

CC_Setup Response

TCC_Call Alerting

TCC_Call Active

F ig u r e F . 2 - Tr a n s it C a ll C o n t r o l S D L d ia g r a m ( s h e e t 9 o f 1 9 ) ( c o n t in u e d )

CC_Progress Indication

CC_Proceed Indication

Note 7 Through Connect (if not already)

TCC_Transit Call_Proceeding

CC_Progress Request

TCC_Transit Call_Proceeding

F ig u r e F . 2 - Tr a n s it C a ll C o n t r o l S D L d ia g r a m ( s h e e t 1 0 o f 1 9 ) ( c o n t in u e d )

- 128 -

6 TCC_Call_Alerting

CC_Setup Confirmation

CC_Progress Indication

Note 7 Through Connect (if not already)

CC_Setup Response

7 TCC_Call_Active

CC_Progress Request

6 TCC_Call_Alerting

F ig u r e F . 2 - Tr a n s it C a ll C o n t r o l S D L d ia g r a m ( s h e e t 1 1 o f 1 9 ) ( c o n t in u e d )

TCC_Await Incoming_Release

TCC_Await Outgoing_Release

CC_Release Indication

10 TCC_Await_Two Way_Release

CC_Release Indication

CC_Release Indication Release resources

Release resources

8 0

TCC_Idle

CC_Release Indication

TCC_Idle

TCC_Await Incoming_Release

TCC_Await Outgoing_Release

F ig u r e F . 2 - Tr a n s it C a ll C o n t r o l S D L d ia g r a m ( s h e e t 1 2 o f 1 9 ) ( c o n t in u e d )

- 129 -

Any State except 0,1,7,8,9,10,11,12 & 13

CC_Release Indication

CC_Disconnect Indication

CC_Release Request

Note 5

Note 2

CC_Disconnect Request

Disconnect (Release Resources)

TCC_Await Outgoing_Release

CC_Release Indication

8 TCC_Await Incoming_Release

F ig u r e F . 2 - Tr a n s it C a ll C o n t r o l S D L d ia g r a m ( s h e e t 1 3 o f 1 9 ) ( c o n t in u e d )

- 130 -

Event_Call Abort

Note 8 In band Announcement Appropriate ?

YES

CC_Progress Request

CC_Disconnect Request

(CCITT Progress Desc No. 8)

Note 5 CC_Progress Request

CC_Disconnect Request

10 TCC_Await_Two Way_Release

(CCITT Progress Desc No. 8)

TCC_Await_Two Way_Disconnect

F ig u r e F . 2 - Tr a n s it C a ll C o n t r o l S D L d ia g r a m ( s h e e t 1 4 o f 1 9 ) ( c o n t in u e d )

- 131 -

7 TCC_Call_Active

CC_Release Indication

CC_Disconnect Indication

CC_Release Request

Note 5

Note 2

CC_Disconnect Request

Disconnect (Release Resources)

TCC_Await Outgoing_Release

CC_Release Indication

8 TCC_Await Incoming_Release

F ig u r e F . 2 - Tr a n s it C a ll C o n t r o l S D L d ia g r a m ( s h e e t 1 5 o f 1 9 ) ( c o n t in u e d )

- 132 -

Event_Call Abort

Note 8 In band Announcement Appropriate ?

YES

CC_Progress Request

CC_Disconnect Request

(CCITT Progress Desc No. 8)

Note 5 CC_Progress Request

CC_Disconnect Request

10 TCC_Await_Two Way_Release

(CCITT Progress Desc No. 8)

TCC_Await_Two Way_Disconnect

F ig u r e F . 2 - Tr a n s it C a ll C o n t r o l S D L d ia g r a m ( s h e e t 1 6 o f 1 9 ) ( c o n t in u e d )

- 133 -

TCC_Await Incoming_Disconnect

Event_End of Tone or Announcement Reached

CC_Release Indication

CC_Disconnect Indication

CC_Release Request

CC_Disconnect Request

Disconnect (Release Incoming Resources)

TCC_Await Incoming_Release

0 TCC_Idle

F ig u r e F . 2 - Tr a n s it C a ll C o n t r o l S D L d ia g r a m ( s h e e t 1 7 o f 1 9 ) ( c o n t in u e d )

12 TCC_Await Outgoing_Disconnect

Event_End of Tone or Announcement Reached

CC_Release Indication

CC_Disconnect Indication

CC_Release Request

CC_Disconnect Request

TCC_Await Outgoing_Release

Disconnect (Release Incoming Resources)

0 TCC_Idle

F ig u r e F . 2 - Tr a n s it C a ll C o n t r o l S D L d ia g r a m ( s h e e t 1 8 o f 1 9 ) ( c o n t in u e d )

- 134 -

13 TCC_Await_Two Way_Disconnect

CC_Disconnect Indication

CC_Release Indication

Event_End of Tone or Announcement Reached

CC_Disconnect Indication

CC_Release Request

CC_Disconnect Request

Disconnect (Release Incoming Resources)

Disconnect (Release Outgoing Resources)

CC_Disconnect Request

11 TCC_Await Incoming_Disconnect

TCC_Await Outgoing_Disconnect

TCC_Await_Two Way_Release

F ig u r e F . 2 - Tr a n s it C a ll C o n t r o l S D L d ia g r a m ( s h e e t 1 9 o f 1 9 ) ( c o n c lu d e d ) NOTES to Transit Call Control SDL diagram: NOTE 1 This is the earliest point at which cut through of the information channel - in either, or both directions can occur, although it need not occur at this point. NOTE 2 The action to be taken at this point is manufacturer specific (i.e. implementation dependent) and the sequence here is give for information only. NOTE 3 T302 protocol timer started. NOTE 4 This is the latest point at which cut through of the information channel can occur. NOTE 5 In state 2, Release Request is used. NOTE 6 This request is only sent to the Outgoing Side Protocol Control if there has been information received from the Incoming Side Protocol Control which has been stored in an internal buffer. NOTE 7 Cut through of the information channel may occur at this point. If the received message contains CCITT progress description number 1 “call is not end to end ISDN, further information may be available in band” or number 8 “in band information or appropriate pattern now available”, the information channel should be cut through in the backward direction. NOTE 8 The optional in-band tones or announcements on call clearing may be provided in both directions, or only one direction as an implementation decision. The SDL shows only the example where tones are provided in both directions and is not intended to preclude the clearing of the call in one direction and provision of the tone or announcement in the other. In addition, if the call is aborted in the active state, the Transit PINX

- 135 -

may optionally apply the tone or announcement without sending a PROGRESS message, as the information channels are already through connected in the active state. NOTE 9 This event occurs when the Transit PINX determines that the address information it has received is complete. This may be, for example, on receipt of CALL PROCEEDING from the Subsequent PINX, on receipt of a Sending complete information element from the Preceding PINX, or by digit analysis.

- 136 -

- 137 -

Annex G ( in f o r ma tiv e )

Bibliography

ECMA-142

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

ECMA-148

Private Integrated Services Network - Specification, Functional Model and Information Flows Identification Supplementary Services (International Standard ISO/IEC 14136)

ECMA-165

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

ECMA-251

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

ISO/IEC 11584

Information technology - Telecommunications and information exchange between systems Private Integrated Services Network - Multi-rate circuit mode bearer service - Specification, functional model and information flows

CCITT Rec. G.711

Pulse code modulation (PCM) of voice frequencies (Blue Book) (1988)

ITU-T Rec. Q.930

ISDN user-network interface layer 3 - General aspects (3/93)

- 138 -

- 139 -

Annex ZA ( n o r ma tiv e )

Segmentation and reassembly procedures

ZA.1 Message segmentation and re-assembly functions Message segmentation and re-assembly functions shall be employed where the size of a message exceeds the maximum size of the SCM information field. The architectural relationship of segmentation and re-assembly functions to other PSS1 Protocol Control functions is shown in figure ZA.1. Call Control

Other Functions

Segmentation and Re-assembly Functions

PSS1 Protocol Control

Protocol Discriminator Filter

Signalling Carriage Mechanism

F i g u r e ZA . 1 - L o g i c a l a r c h i t e c t u r e o f P r o t o c o l C o n t r o l s h o w i n g s e g m e n t a t i o n a n d r e - a s s e m b l y functions Segmentation and re-assembly, where provided, effectively constitute a lower sublayer of PSS1 Protocol Control. NOTE 1 The only function of PSS1 Protocol Control below the segmentation and re-assembly functions is protocol discriminator filtering. This function filters out messages containing a protocol discriminator that does not match the one specified in this Standard. The primitives across the boundary between segmentation and re-assembly functions and other functions are the same as those between the Signalling Carriage Mechanism and PSS1 Protocol Control (see 6.3). The segmentation functions act upon DL-DATA-REQUEST primitives by converting, where necessary, a single primitive into two or more primitives before passing to the Signalling Carriage Mechanism. The re-assembly functions act upon DL-DATA-INDICATION primitives from the Signalling Carriage Mechanism by converting, where necessary, two or more primitives into a single primitive for passing up to the other functions of PSS1 Protocol Control. Other primitives to and from the Signalling Carriage Mechanism are not affected by the segmentation and re-assembly functions.

- 140 -

ZA.2 States for message segmentation / re-assembly Message segmentation and re-assembly procedures are each specified in terms of a state machine. Message segmentation uses a single state, Null (0). Message re-assembly uses two states, as listed below.

ZA.2.1 Null (0) No message is being reassembled.

ZA.2.2 Receiving segmented message (1) One or more segments of a segmented message have been received and one or more further segments are awaited.

ZA.3 Segmentation and re-assembly procedures This clause specifies message segmentation and re-assembly procedures for messages the length of which exceeds the maximum size of the Signalling Carriage Mechanism information field. The Signalling Carriage Mechanism information field size is dependent on the PINX interconnection scenario. A PINX shall conform to the segmentation procedures specified in clause ZA.3.1 if, for a given PINX interconnection scenario supported by the PINX, it is capable of transmitting a message that exceeds the maximum size of the Signalling Carriage Mechanism information field for that scenario. Segmentation procedures shall not be applied to messages that do not exceed the maximum size of the Signalling Carriage Mechanism information field. A PINX that claims conformance to this Standard shall declare the maximum size of message that it is able to receive. The declared maximum size shall not be less than 260 octets. If, for a given PINX interconnection scenario supported by the PINX, the maximum size of Signalling Carriage Mechanism information field is less than the declared maximum size of message the PINX can receive, the PINX shall conform to the reassembly procedures specified in clause ZA.3.2. NOTE 2 If a segmented message is received by a PINX that does not support re-assembly procedures, the procedures specified in clause 9.2.4 for message type errors will apply to each received segment.

ZA.3.1 Procedures for segmentation The following rules apply when a message for transmission exceeds the maximum size of the SCM information field: a) The maximum number of message segments is 8. If the message is too long to be segmented, the action taken shall be an implementation option. b) The first message segment shall begin with the Protocol discriminator information element immediately followed by the Call reference information element, the SEGMENT message type, the Segmented message information element, and octets starting with the first octet following the message type of the message being segmented, subject to the maximum length of the segment not exceeding the maximum size of the SCM information field. c) Each subsequent message segment shall begin with the Protocol discriminator information element, immediately followed by the Call reference information element, the SEGMENT message type, the Segmented message information element, and one or more octets of the message being segmented, starting with the first octet following the last octet transmitted in the previous segment and subject to the maximum length of the segment not exceeding the maximum size of the SCM information field. d) The first segment indicator field of the Segmented message information element shall be set to ONE (first segment of a segmented message) in the first segment of a segmented message and set to ZERO (subsequent segment to first segment) in each subsequent segment of that message. e) The number of segments remaining field of the Segmented message information element shall be set to indicate how many more segments are to be sent. f) The segmented message type field of the Segmented message information element shall indicate the message type of the original message.

- 141 -

g) Once the first segment has been transmitted on a particular SCM connection, then all remaining segments of that message shall be sent (in order) before any other message (segmented or not) for any other call reference is sent on that SCM connection. Only failure conditions (e.g., SCM failure) shall cause the transmission of a segmented message to be aborted. h) The octet order of the segmented message shall be preserved regardless of segment boundary.

ZA.3.2 Procedures for re-assembly The following rules apply to the receipt and re-assembly of segmented messages: a) A re-assembly function, on receiving a message of type SEGMENT containing the Segmented message information element as the first information element after the message type, shall treat that message as a segment. b) A re-assembly function in the Null state, on receiving a segment in which the first segment indicator field of the Segmented message information element is set to ONE (first segment of segmented message) and the number of segments remaining field of the Segmented message information element is set to a value greater than 0 and not exceeding 7, shall enter the Receiving segmented message state and save the segment contents. Timer T314 shall be initialised. Timer T314 is used to prevent the reassembly function waiting indefinitely to receive the next message segment. c) A re-assembly function in the Receiving segmented message state, on receiving a segment in which the call reference is equal to the call reference of the first segment received, the first segment indicator field of the Segmented message information element is set to ZERO (subsequent segment to first segment), the number of segments remaining field of the Segmented message information element is set to a value one less than the value in the previously received segment, and the segmented message type field has a value equal to the value of that field in the first segment received, shall treat the segment as a valid next segment. d) A re-assembly function in the Receiving segmented message state, on receiving a valid next segment in which the number of segments remaining field has a value greater than zero, shall save the segment contents along with the saved contents of the previous segment or segments, restart timer T314, and remain in the Receiving segmented message state. e) A re-assembly function in the Receiving segmented message state, on receiving a valid next segment in which the number of segments remaining field has a value equal to zero, shall stop timer T314, deliver the accumulated segments, including the last segment, as a single message for further PSS1 Protocol Control processing, and enter the Null state. The message delivered shall have a call reference equal to that in each received segment and a message type equal to that in the segmented message type field of the Segmented message information element of each received segment. Octets following the Segmented message information element in each received segment shall be included in the delivered message in the order received. f) A re-assembly function in the Null state shall deliver for further PSS1 Protocol Control processing any received message of type other than SEGMENT or that is too short to contain a message type. g) A re-assembly function in the Null state shall discard any received message of type SEGMENT that is not a valid first segment. Any other action taken shall be an implementation option. This applies to the following: − messages of type SEGMENT without a valid Segmented message information element following the message type; − segments in which the first segment indicator field of the Segmented message information element is set to ZERO (subsequent segment to first segment); − segments in which the number of segments remaining field of the Segmented message information element has a value 0 or a value exceeding 7. h) A re-assembly function in the Receiving segmented message state shall discard any saved segments, stop timer T314 and enter the Null state on receipt of any message which is not a valid next segment. This applies to the following: − Messages with a different call reference from that in the first received segment;

- 142 -

− Messages of type other than SEGMENT; − Messages of type SEGMENT without a valid Segmented message information element following the message type; − Segments in which the first segment indicator field of the Segmented message information element is set to ONE (first segment of segmented message); − Segments in which the number of segments remaining field of the Segmented message information element has a value which is not one less than the value in the previously received segment; − Segments in which the segmented message type field of the Segmented message information element has a value which is not equal to the value in the first received segment. In the case of a message with a different call reference from that in the first received segment or a message with a message type other than SEGMENT, the received message shall be processed as if it had been received while in the Null state. In all other cases the received message shall be discarded. Any other action taken shall be an implementation option. i) On expiry of timer T314, the re-assembly function shall discard any saved segments and enter the Null state. Any other action taken shall be an implementation option. j) If a DL-RELEASE-INDICATION or DL-ESTABLISH-INDICATION is received while the re-assembly function is in the Receiving segmented message state, the re-assembly function shall discard any saved segments, stop timer T314, and enter the Null state. The DL-RELEASE-INDICATION or DL-ESTABLISH-INDICATION shall be delivered for further PSS1 Protocol Control processing.

ZA.3.3 SDL for segmentation and re-assembly (informative) In the figures that follow, input signals from the left (except those indicating timer expiry) and output signals to the left are from and to the Other Functions of PSS1 Protocol Control, and input signals from the right and output signals to the right are from and to the Signalling Carriage Mechanism, via the Protocol Discriminator Filter. Figure ZA.2 shows the procedures for message segmentation in SDL form. The SDL process forms part of the Segmentation and Re-Assembly Functions of PSS1 Protocol Control (see ZA.1) and intercepts all primitives sent from Other Functions of PSS1 Protocol Control towards the Signalling Carriage Mechanism. Figures ZA.3, ZA.4 and ZA.5 show the procedures for message re-assembly in SDL form. The SDL process forms part of the Segmentation and Re-assembly Functions of PSS1 Protocol Control (see ZA.1) and intercepts all primitives received from the Signalling Carriage Mechanism via the Protocol Discriminator Filter.

- 143 -

0 Null

DL-DataRequest (message)

All other SCM primitives

Received SCM primitive

Message exceeds max. SCM size?

0 Null

Divide message at octet boundaries

DL-DATAREQUEST (message)

Y > 8 segments?

N Implementationdependent action

Insert segment header information for next segment

DL-DATAREQUEST (message segment)

Last segment sent?

0 Null

F i g u r e ZA . 2 - S e g m e n t a t i o n P r o c e s s S D L

- 144 -

0 Null

DL-DATAINDICATION All other SCM primitives

A N

Received SCM primitive

Message type = SEGMENT?

Y 0 Null

Segmented message information element immediately following

N Y

First segment indicator = first?

N Y

Number of segments remaining in range 1 to 7?

N Y Accumulate first segment Discard received segment Store call reference and segmented message type

Store number of remaining segments

Start timer T314

1 Receiving segmented message

F i g u r e ZA . 3 - R e - a s s e m b l y P r o c e s s S D L ( P a r t 1 )

Other implementationdependent action

0 Null

- 145 -

1 Receiving Segmented Message

All other SCM primitives

Discard accumulated segments

DL-DATAINDICATION

T314 expiry

Discard accumulated segments

Call reference = saved call reference?

N Stop T314

Stop T314

Message type = SEGMENT?

Received SCM primitive

Y 0 Null

Other implementationdependent action

Segmented message information element immediately following?

Discard accumulated segments

0 Null

Other implementationdependent action N A

First segment indicator = subsequent?

N Y

Number of segments remaining 1 less than saved value?

Stop T314

N Y

Segmented message type = saved value?

Y B

Discard accumulated segments

Other implementationdependent actions

0 Null

F i g u r e ZA . 4 - R e - a s s e m b l y P r o c e s s S D L ( P a r t 2 )

- 146 -

N Segments remaining = 0? Y Stop T314

Restart T314

Assemble message

Accumulate segment

Store number of remaining segments

DL-DATAINDICATION (assembled message

1 Receiving segmented message

0 Null

F i g u r e ZA . 5 - R e - a s s e m b l y P r o c e s s S D L ( P a r t 3 )

ZA.4 Message definition and content The SEGMENT message may be sent by either side whenever it is necessary to send a message, the length of which exceeds the maximum size of the Signalling Carriage Mechanism information field. The SEGMENT message has content as shown in table ZA.1. T a b l e ZA . 1 - S E G M E N T m e s s a g e c o n t e n t Message type: Direction:

SEGMENT both

Information element Protocol discriminator Call reference Message Type Segmented message Octets from the message being segmented

Reference 14.2 14.3 14.4, ZA.5.1 ZA.5 ZA.2

Type M M M M M

Length 1 3 1 4 1-*

ZA.5 Information elements ZA.5.1 Message type The Message type information element (see 14.4) shall have the format shown in figure 8 and shall be coded as shown in table ZA.2.

- 147 -

T a b l e ZA . 2 - C o d i n g f o r S E G M E N T m e s s a g e t y p e Bits 8 7 6 5 4 3 2 1 0 1 1 0 0 0 0 0

Miscellaneous messages SEGMENT

ZA.5.2 Segmented message The Segmented message information element is a variable length information element in codeset 0 with the format shown in figure ZA.6 and coded as shown in table ZA.3. NOTE 3 The general format and coding of variable length information elements is defined in 14.5.1. 8

5 4 3 Segmented message 0 0 0 0 Information element identifier Length of segmented message contents

1st seg ind. 0

Octet 1 Octet 2

Number of segments remaining

Octet 3

Segmented message type

Octet 4

F i g u r e ZA . 6 - S e g m e n t e d m e s s a g e i n f o r m a t i o n e l e m e n t T a b l e ZA . 3 - S e g m e n t e d m e s s a g e i n f o r m a t i o n e l e m e n t First segment indicator (octet 3) Bit 8 0 Subsequent segment to first segment 1 First segment of segmented message Number of segments remaining (octet 3) Binary number indicating the number of remaining segments within the message to be sent. Segmented message type (octet 4) Type of message being segmented, coded according to 14.4. This octet shall not contain the SEGMENT message type (binary value "01100000"). Bit 8 is reserved for possible future use as an extension bit.

ZA.6 Protocol timer definition There are no timer definitions for the segmentation procedures. The protocol timer definition in table ZA.4 shall apply for the re-assembly procedures.

- 148 -

T a b l e ZA . 4 - P r o t o c o l t i m e r d e f i n it i o n f o r r e - a s s e m b l y p r o c e d u r e s Timer number

Timer value

Call state

Cause for start

Normally terminated

Action to be taken when timer expires

Status

T314

4s, ±10%

Receiving segmented message

Message segment received

Last message segment received

Discard message

Mandatory if the associated procedures are implemented

- 149 -

Annex ZB ( n o r ma tiv e )

Additional progress descriptions

ZB.1 Introduction The coding of the Progress indicator information element in 14.5.17 defines several progress descriptions for interworking situations. The procedures in 10 specify the circumstances when each is used. In particular, progress descriptions are transmitted over an inter-PINX link: − by an Incoming Gateway PINX for calls entering the PISN from another network; and, − by an Outgoing Gateway PINX for calls passing from the PISN to another network. This annex specifies some additional codings (and their use) for the progress description field of the Progress indicator information element. These additional progress descriptions can be used to convey supplementary information about the interworking environment applicable to a particular call. It is mandatory to support the progress descriptions and procedures specified in this annex. The requirements specified in this annex are additional to the requirements specified in 10 of this Standard.

ZB.2 General requirements In addition to the progress descriptions listed in 14.5.17, a PINX shall also support the following progress descriptions: − 16 "interworking with a public network"; − 17 "interworking with a network unable to supply a release signal"; − 18 "interworking with a network unable to supply a release signal before answer"; and − 19 "interworking with a network unable to supply a release signal after answer". A PINX shall be capable of sending ALERTING, CONNECT, PROGRESS and SETUP messages containing up to three Progress indicator information elements, as appropriate to the circumstances of a particular call. NOTE 1 More than one Progress indicator information element may be sent in the same message, to indicate different conditions. A PINX shall also be capable of receiving and acting upon such messages, including in the case of a Transit PINX, passing all Progress indicators received on to the next PINX.

ZB.3 Coding requirements for additional progress descriptions The Progress indicator information element defined in 14.5.17 is a variable length category 1 (see 10.4.11.2) information element with the format shown in figure 23. Up to three Progress indicator information elements may appear in a single message (to indicate more than one condition). NOTE 2 The Progress indicator information element can be conveyed in ALERTING, CONNECT, PROGRESS, and SETUP messages. Clauses 13.2.1, 13.2.3, 13.2.7 and 13.2.10 respectively define these messages. The CCITT standardised coding for the information element is shown in table 32. The coding for the Additional progress descriptions is shown in table ZB.1.

- 150 -

T a b l e ZB. 1 - C o d i n g o f A d d i t i o n a l p r o g r e s s d e s c r i p t i o n s Coding standard (octet 3) Bits 7 6 0 1 ISO/IEC standard Other values are defined in table 32 Location (octet 3)

Coded as shown in table 32

Progress description (octet 4) (NOTE) Bits 7 6 5 4 3 2 1

Meaning

0 0 1 0 0 0 0 0 0 1 0 0 0 1 0 0 1 0 0 1 0

16 17 18

0 0 1 0 0 1 1

Interworking with a public network Interworking with a network unable to supply a release signal Interworking with a network unable to supply a release signal before answer Interworking with a network unable to supply a release signal after answer

All other values are reserved. NOTE Octet 4 shall be coded as shown in this table when the coding standard (octet 3) is "ISO/IEC standard". When the coding standard is "CCITT standardised coding", octet 4 shall be coded as shown in table 32.

ZB.4 Actions at a Transit PINX A Transit PINX receiving a message containing more than one valid Progress indicator information elements, one or more of which can contain one of the additional progress descriptions described in ZB.3.1, shall act as described in 10.4. That is to say: − if any of the Progress indicator information elements in the received message contains progress description number 1 "call is not end to end ISDN, further information may be available in band" or number 8 "in band information or appropriate pattern now available" the information channel shall be through connected in the backwards direction if this has not already occurred; and, − all Progress indicator information elements received shall be passed on to the next PINX.

ZB.5 Actions at an Incoming Gateway PINX The requirements specified in the following clauses are in addition to the requirements specified in 10.7.2, thus leading to the possibility of more than one Progress indicator information element being transmitted in the SETUP message.

ZB.5.1 Interworking with a public network If the call has entered the PISN from a public network (ISDN or non-ISDN), a Progress indicator information element shall be sent in the direction of the called user. This Progress indicator information element shall contain progress description 16 "Interworking with a public network".

ZB.5.2 Interworking with a network with limited release capability If the call has entered the PISN from a network that is unable, or not always able, to supply to the PISN with an indication that the call has been released, a Progress information element shall be sent in the direction of the called user. This Progress indicator information element shall contain one of the following progress descriptions: − 17 "interworking with a network unable to supply a release signal";

- 151 -

− 18 "interworking with a network unable to supply a release signal before answer"; or, − 19 "interworking with a network unable to supply a release signal after answer". Progress description number 18 shall be used if the other network is able to indicate release after it has received an answer signal from the PISN, but is not always able to indicate release prior to receiving an answer signal. In this case, the other network will rely on receiving a release signal from the PISN if answer does not occur within a reasonable time. Progress description number 19 shall be used if the other network is able to indicate release prior to the receipt of an answer signal from the PISN, but is not always able to indicate release after receiving an answer signal. In this case, the other network will rely on receiving a release signal from the PISN when release is initiated by the called user. Progress description number 17 shall be used if the other network is not always able to indicate release prior to answer and is not always able to indicate release after answer. In this case, the other network will rely on receiving a release signal from the PISN if answer does not occur within a reasonable time and when release is initiated by the called user.

ZB.5.3 On receipt of a PROGRESS, ALERTING or CONNECT message Action, if any, on receipt of any of the additional progress descriptions specified in table ZB.1 during call establishment is an implementation matter. NOTE 3 The Incoming Gateway PINX can make use of these progress descriptions to determine whether the call is to be allowed to continue. However, normally the peer Outgoing Gateway PINX will have avoided the establishment of undesirable calls, based on progress descriptions received in the SETUP message (see ZB.6.1).

ZB.5.4 On receipt of a Progress indicator information element subsequent to call establishment Action, if any, on receipt of any of the additional progress descriptions specified in table ZB.1 subsequent to call establishment is an implementation matter. NOTE 4 Any of these progress descriptions can be received from a peer Gateway PINX subsequent to the use of a supplementary service such as Call Transfer. The Incoming Gateway PINX can use this information in conjunction with local knowledge to determine whether the call is to be allowed to continue. Checks can be similar to those conducted at an Outgoing Gateway PINX on receipt of a SETUP message (see ZB.6.1).

ZB.6 Actions at an Outgoing Gateway PINX The requirements specified in the following clauses are in addition to the requirements specified in 10.8.3, thus leading to the possibility of more than one Progress indicator information element being transmitted.

ZB.6.1 On receipt of the SETUP message Certain information in the Progress indicator information element(s) contained within a SETUP message received by an Outgoing Gateway PINX may affect the decision of the PINX to route the call to another network. In particular, the Outgoing Gateway PINX shall not establish a call that cannot be released. This can be determined by the presence of a Progress indicator information element containing one of the progress descriptions: 17 "interworking with a network unable to supply a release signal", 18 "interworking with a network unable to supply a release signal before answer", or 19 "interworking with a network unable to supply a release signal after answer", and the Outgoing Gateway PINX's knowledge of the ability of the other network to signal release. In addition, the presence of a Progress indicator information element containing progress description 16 "interworking with a public network" may influence routeing. NOTE 5 For example, the establishment of a call between two public networks can be prevented, if required.

- 152 -

ZB.6.2 Interworking with a public network If the call is to enter a public network (ISDN or non-ISDN), a Progress indicator information element shall be sent in the direction of the calling user. This Progress indicator information element shall contain progress description 16 "Interworking with a public network".

ZB.6.3 Interworking with a network with limited release capability If the call is to enter a network that is unable, or not always able, to supply an indication to the PISN that the call has been released, a Progress indicator information element shall be sent in the direction of the calling user. This Progress indicator information element shall contain one of the following progress descriptions: − 17 "interworking with a network unable to supply a release signal"; − 18 "interworking with a network unable to supply a release signal before answer"; or, − 19 "interworking with a network unable to supply a release signal after answer". Progress description number 18 shall be used if the other network is able to indicate release after it has sent an answer signal to the PISN, but is not always able to indicate release in the event of no reply. The other network will rely on receiving a release signal from the PISN when release is initiated by the calling user or if answer does not occur within a reasonable time. Progress description number 19 shall be used if the other network is able to indicate release prior to sending an answer signal to the PISN, but is not always able to indicate release after sending an answer signal. In this case, the other network will rely on receiving a release signal from the PISN when release is initiated by the calling user. Progress description number 17 shall be used if the other network is not always able to indicate release prior to answer and is not always able to indicate release after answer. In this case, the other network will rely on receiving a release signal from the PISN if answer does not occur within a reasonable time and when release is initiated by the calling user.

ZB.6.4 On receipt of a Progress indicator information element subsequent to call establishment Action, if any, on receipt of any of the additional progress descriptions specified in table ZB.1 subsequent to call establishment is an implementation matter. NOTE 6 Any of these progress descriptions can be received from a peer Gateway PINX subsequent to the use of a supplementary service such as Call Transfer. The Outgoing Gateway PINX can use this information in conjunction with local knowledge to determine whether the call is to be allowed to continue. Checks can be similar to those conducted at an Outgoing Gateway PINX on receipt of a SETUP message (see ZB.6.1).

ZB.7 Actions at an Originating PINX or a Terminating PINX Action, if any, on receipt of any of the additional progress descriptions specified in table ZB.1 is an implementation matter. Possible actions include the following: − provision of an appropriate indication to the user on receipt of progress description 16; − use later in the call as part of the process of determining whether a request for a supplementary service such as Call Transfer should be accepted.

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-143 — Private Integrated Services Network (PISN) - Circuit mode bearer services - Inter-exchange signalling procedures and protocol (QSIG-BC) (December 2001)

Related documents