T-Rec-Q 931-199805-I!!pdf-E

INTERNATIONAL TELECOMMUNICATION UNION
ITU-T
TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU
Q.931
(05/98)
SERIES Q: SWITCHING AND SIGNALLING Digital subscriber Signalling System No. 1 Network layer
ISDN user-network interface layer 3 specification for basic call control
ITU-T Recommendation Q.931

(Previously CCITT Recommendation)
ITU-T Q-SERIES RECOMMENDATIONS SWITCHING AND SIGNALLING
SIGNALLING IN THE INTERNATIONAL MANUAL SERVICE INTERNATIONAL AUTOMATIC AND SEMI-AUTOMATIC WORKING FUNCTIONS AND INFORMATION FLOWS FOR SERVICES IN THE ISDN CLAUSES APPLICABLE TO ITU-T STANDARD SYSTEMS SPECIFICATIONS OF SIGNALLING SYSTEMS No. 4 AND No. 5 SPECIFICATIONS OF SIGNALLING SYSTEM No. 6 SPECIFICATIONS OF SIGNALLING SYSTEM R1 SPECIFICATIONS OF SIGNALLING SYSTEM R2 DIGITAL EXCHANGES INTERWORKING OF SIGNALLING SYSTEMS SPECIFICATIONS OF SIGNALLING SYSTEM No. 7 DIGITAL SUBSCRIBER SIGNALLING SYSTEM No. 1 General Data link layer Network layer User-network management Stage 3 description for supplementary services using DSS 1 PUBLIC LAND MOBILE NETWORK INTERWORKING WITH SATELLITE MOBILE SYSTEMS INTELLIGENT NETWORK BROADBAND ISDN
Q.1Q.3 Q.4Q.59 Q.60Q.99 Q.100Q.119 Q.120Q.249 Q.250Q.309 Q.310Q.399 Q.400Q.499 Q.500Q.599 Q.600Q.699 Q.700Q.849 Q.850Q.999 Q.850Q.919 Q.920Q.929 Q.930Q.939 Q.940Q.949 Q.950Q.999 Q.1000Q.1099 Q.1100Q.1199 Q.1200Q.1999 Q.2000Q.2999
For further details, please refer to ITU-T List of Recommendations.
ITU-T RECOMMENDATION Q.931 ISDN USER-NETWORK INTERFACE LAYER 3 SPECIFICATION FOR BASIC CALL CONTROL
Summary This Recommendation specifies the procedures for the establishing, maintaining and clearing of network connections at the ISDN user-network interface. These procedures are defined in terms of messages exchanged over the D-channel of basic and primary rate interface structures. The functions and procedures of this protocol, and the relationship with other layers, are described in general terms in Recommendation Q.930/I.450 [1]. Annex M contains the additional basic call signalling requirement for the support of private network interconnection for VPN applications.
Source ITU-T Recommendation Q.931 was revised by ITU-T Study Group 11 (1997-2000) and was approved under the WTSC Resolution No. 1 procedure on the 15th of May 1998.
Recommendation Q.931
(05/98)
FOREWORD ITU (International Telecommunication Union) is the United Nations Specialized Agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of the ITU. The ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Conference (WTSC), which meets every four years, establishes the topics for study by the ITU-T Study Groups which, in their turn, produce Recommendations on these topics. The approval of Recommendations by the Members of the ITU-T is covered by the procedure laid down in WTSC Resolution No. 1. In some areas of information technology which fall within ITU-T's purview, the necessary standards are prepared on a collaborative basis with ISO and IEC.
NOTE In this Recommendation the term recognized operating agency (ROA) includes any individual, company, corporation or governmental organization that operates a public correspondence service. The terms Administration, ROA and public correspondence are defined in the Constitution of the ITU (Geneva, 1992).
INTELLECTUAL PROPERTY RIGHTS The ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. The ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process. As of the date of approval of this Recommendation, the ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementors are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database.
ITU 1999 All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the ITU.
ii
(05/98)
CONTENTS Page 1 1.1 1.2 2 2.1 General........................................................................................................................ Scope of this Recommendation .................................................................................. Application to interface structures .............................................................................. Overview of call control ............................................................................................. Circuit-switched calls ................................................................................................. 2.1.1 2.1.2 2.2 2.2.1 2.2.2 2.3 2.3.1 2.3.2 2.4 2.4.1 2.4.2 3 3.1 Call states at the user side of the interface..................................................... Network call states......................................................................................... Access connection states at the user side of the interface.............................. Access connection states at the network side of the interface ....................... Call states at the user side of the interface..................................................... Network call states......................................................................................... Call states at the user side of the interface..................................................... Call states at the network side of the interface .............................................. 1 1 1 1 2 2 3 4 4 5 5 6 6 7 7 7 8 9 10 11 12 13 14 15 16 17 18 19 19 20 20 21 23 24 24 25
Packet-mode access connections ................................................................................
Temporary signalling connections ..............................................................................
States associated with the global call reference ..........................................................
Message functional definitions and content................................................................ Messages for circuit-mode connection control ........................................................... 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.1.6 3.1.7 3.1.8 3.1.9 ALERTING ................................................................................................... CALL PROCEEDING................................................................................... CONNECT .................................................................................................... CONNECT ACKNOWLEDGE .................................................................... DISCONNECT .............................................................................................. INFORMATION ........................................................................................... NOTIFY......................................................................................................... PROGRESS ................................................................................................... RELEASE......................................................................................................
3.1.10 RELEASE COMPLETE................................................................................ 3.1.11 RESUME ....................................................................................................... 3.1.12 RESUME ACKNOWLEDGE ....................................................................... 3.1.13 RESUME REJECT........................................................................................ 3.1.14 SETUP ........................................................................................................... 3.1.15 SETUP ACKNOWLEDGE ........................................................................... 3.1.16 STATUS ........................................................................................................ 3.1.17 STATUS ENQUIRY ..................................................................................... 3.1.18 SUSPEND .....................................................................................................
(05/98)
iii
3.1.19 SUSPEND ACKNOWLEDGE ..................................................................... 3.1.20 SUSPEND REJECT ...................................................................................... 3.2 Messages for packet-mode connection control........................................................... 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.2.7 3.2.8 3.2.9 ALERTING ................................................................................................... CALL PROCEEDING................................................................................... CONNECT .................................................................................................... CONNECT ACKNOWLEDGE .................................................................... DISCONNECT .............................................................................................. PROGRESS ................................................................................................... RELEASE...................................................................................................... RELEASE COMPLETE................................................................................ SETUP ...........................................................................................................
Page 25 26 26 27 28 29 29 30 30 31 32 33 35 35 36 37 37 38 38 39 39 40 40 41 43 43 44 44 45 45 46 46 47 47 47 48 50
3.2.10 STATUS ........................................................................................................ 3.2.11 STATUS ENQUIRY ..................................................................................... 3.3 Messages for user signalling bearer service control ................................................... 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.3.6 3.3.7 3.3.8 3.3.9 ALERTING ................................................................................................... CALL PROCEEDING................................................................................... CONGESTION CONTROL.......................................................................... CONNECT .................................................................................................... CONNECT ACKNOWLEDGE .................................................................... INFORMATION ........................................................................................... RELEASE...................................................................................................... RELEASE COMPLETE................................................................................ SETUP ...........................................................................................................
3.3.10 SETUP ACKNOWLEDGE ........................................................................... 3.3.11 STATUS ........................................................................................................ 3.3.12 STATUS ENQUIRY ..................................................................................... 3.3.13 USER INFORMATION ................................................................................ 3.4 Messages with the global call reference ..................................................................... 3.4.1 3.4.2 3.4.3 4 4.1 4.2 4.3 4.4 RESTART ..................................................................................................... RESTART ACKNOWLEDGE ..................................................................... STATUS ........................................................................................................
General message format and information elements coding ........................................ Overview..................................................................................................................... Protocol discriminator................................................................................................. Call reference .............................................................................................................. Message type...............................................................................................................
iv
(05/98)
Page 4.5 Other information elements ........................................................................................ 4.5.1 4.5.2 4.5.3 4.5.4 4.5.5 4.5.6 4.5.7 4.5.8 4.5.9 Coding rules................................................................................................... Extensions of codesets................................................................................... Locking shift procedure ................................................................................. Non-locking shift procedure .......................................................................... Bearer capability............................................................................................ Call identity ................................................................................................... Call state ........................................................................................................ Called party number ...................................................................................... Called party subaddress ................................................................................. 51 51 55 56 56 58 65 66 67 68 69 71 72 72 76 77 77 78 81 81 93 93 94 95 96 97 98 99 99 100 101 102 103 104 105 107 108 109
4.5.10 Calling party number ..................................................................................... 4.5.11 Calling party subaddress................................................................................ 4.5.12 Cause ............................................................................................................. 4.5.13 Channel identification.................................................................................... 4.5.14 Congestion level ............................................................................................ 4.5.15 Date/time ....................................................................................................... 4.5.16 Display........................................................................................................... 4.5.17 High layer compatibility ................................................................................ 4.5.18 Keypad facility............................................................................................... 4.5.19 Low layer compatibility................................................................................. 4.5.20 More data....................................................................................................... 4.5.21 Network-specific facilities............................................................................. 4.5.22 Notification indicator..................................................................................... 4.5.23 Progress indicator .......................................................................................... 4.5.24 Repeat indicator............................................................................................. 4.5.25 Restart indicator............................................................................................. 4.5.26 Segmented message ....................................................................................... 4.5.27 Sending complete .......................................................................................... 4.5.28 Signal ............................................................................................................. 4.5.29 Transit network selection............................................................................... 4.5.30 User-user........................................................................................................ 4.6 Information element for packet communications ....................................................... 4.6.1 4.6.2 4.6.3 4.6.4 4.6.5 4.6.6 Closed user group .......................................................................................... End-to-end transit delay................................................................................. Information rate ............................................................................................. Packet layer binary parameters ...................................................................... Packet layer window size............................................................................... Packet size .....................................................................................................
(05/98)
4.6.7 4.6.8 4.6.9 5 5.1
Redirecting number ....................................................................................... Reverse charging indication .......................................................................... Transit delay selection and indication ...........................................................
Page 109 111 112 112 113 113 114 115 116 116 117 118 118 118 118 118 119 120 120 121 123 126 127 127 127 128 128 128 129 129 131 131 131 132 132 134 134 134
Circuit-switched call control procedures .................................................................... Call establishment at the originating interface............................................................ 5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 5.1.6 5.1.7 5.1.8 5.1.9 Call request .................................................................................................... B-channel selection Originating ................................................................. Overlap sending............................................................................................. Invalid call information ................................................................................. Call proceeding.............................................................................................. Notification of interworking at the originating interface............................... Call confirmation indication.......................................................................... Call connected ............................................................................................... Call rejection..................................................................................................
5.1.10 Transit network selection............................................................................... 5.2 Call establishment at the destination interface............................................................ 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 5.2.6 5.2.7 5.2.8 5.2.9 5.3 5.3.1 5.3.2 5.3.3 5.3.4 5.3.5 5.4 5.5 Incoming call ................................................................................................. Compatibility checking.................................................................................. B-channel selection Destination ................................................................. Overlap receiving........................................................................................... Call confirmation........................................................................................... Notification of interworking at the terminating interface.............................. Call accept ..................................................................................................... Active indication............................................................................................ Non-selected user clearing............................................................................. Terminology .................................................................................................. Exception conditions ..................................................................................... Clearing initiated by the user ......................................................................... Clearing initiated by the network................................................................... Clear collision................................................................................................
Call clearing................................................................................................................
In-band tones and announcements .............................................................................. Restart procedure ........................................................................................................ 5.5.1 5.5.2 Sending RESTART message......................................................................... Receipt of RESTART message ..................................................................... Call suspension .............................................................................................. Call suspended...............................................................................................
5.6
Call rearrangements .................................................................................................... 5.6.1 5.6.2
vi
(05/98)
5.6.3 5.6.4 5.6.5 5.6.6 5.6.7 5.7 5.8
Call suspend error.......................................................................................... Call re-establishment ..................................................................................... Call resume errors.......................................................................................... Double suspension......................................................................................... Call rearrangement notification controlled by an NT2 ..................................
Page 135 135 136 136 136 136 137 137 137 137 138 139 139 140 142 142 143 143 144 145 145 146 146 146 148 149 150 151 151 152 152 153 154 155 156
Call collisions ............................................................................................................. Handling of error conditions....................................................................................... 5.8.1 5.8.2 5.8.3 5.8.4 5.8.5 5.8.6 5.8.7 5.8.8 5.8.9 Protocol discrimination error......................................................................... Message too short .......................................................................................... Call reference error ........................................................................................ Message type or message sequence errors..................................................... General information element errors............................................................... Mandatory information element errors .......................................................... Non-mandatory information element errors .................................................. Data link reset ................................................................................................ Data link failure .............................................................................................
5.8.10 Status enquiry procedure ............................................................................... 5.8.11 Receiving a STATUS message...................................................................... 5.9 5.10 User notification procedure......................................................................................... Basic telecommunication service identification and selection ................................... 5.10.1 Additional procedures at the coincident S and T reference point.................. 5.10.2 Procedures for interworking with private ISDNs .......................................... 5.11 Signalling procedures for bearer capability selection ................................................. 5.11.1 Procedures for the originating user to indicate bearer capability selection is allowed........................................................................................................... 5.11.2 Procedures for bearer capability selection at the destination side ................. 5.11.3 Procedures for interworking with private ISDNs .......................................... 5.11.4 Channel selection........................................................................................... 5.12 Signalling procedures for high layer compatibility selection...................................... 5.12.1 Procedures for the originating user to indicate high layer compatibility selection is allowed........................................................................................ 5.12.2 Procedures for high layer compatibility selection at the destination side...... 5.12.3 Procedures for interworking with private ISDNs .......................................... 6 6.1 Packet communication procedures ............................................................................. Outgoing access .......................................................................................................... 6.1.1 6.1.2 Circuit-switched access to PSPDN services (Case A)................................... Access to the ISDN virtual circuit service (Case B)......................................
(05/98)
vii
Page 6.2 Incoming access .......................................................................................................... 6.2.1 6.2.2 6.3 6.3.1 6.3.2 6.4 6.4.1 6.4.2 6.4.3 6.4.4 6.5 7 7.1 7.2 7.3 7.4 7.5 7.6 7.7 8 8.1 Access from PSPDN services (Case A)......................................................... Access from the ISDN virtual circuit service (Case B) ................................. Link layer establishment and release ............................................................. Packet layer virtual call set-up and release .................................................... B-channel access............................................................................................ D-channel access ........................................................................................... Additional error handling information........................................................... Cause mappings ............................................................................................. 157 157 158 163 163 163 164 164 165 165 166 169 169 169 170 170 170 171 171 172 172 172 172 172 174 174 174 174 176 176 176 176 176 176 176
X.25 virtual call establishment and release.................................................................
Call clearing................................................................................................................
Access collision .......................................................................................................... User signalling bearer service call control procedures ............................................... General characteristics ................................................................................................ Call establishment....................................................................................................... Transfer of USER INFORMATION messages........................................................... Congestion control of USER INFORMATION messages.......................................... Call clearing................................................................................................................ Handling of error conditions....................................................................................... Restart procedures....................................................................................................... Circuit-mode multirate (64 kbit/s base rate) procedures............................................. Call establishment at the originating interface............................................................ 8.1.1 8.1.2 8.1.3 Compatibility information ............................................................................. Channel selection........................................................................................... Interworking .................................................................................................. Compatibility information ............................................................................. Channel selection........................................................................................... Interworking ..................................................................................................
8.2
Call establishment at the destination interface............................................................ 8.2.1 8.2.2 8.2.3
8.3 8.4 8.5 9 9.1 9.2
Call clearing................................................................................................................ Restart procedures....................................................................................................... Call rearrangements .................................................................................................... List of system parameters ........................................................................................... Timers in the network side.......................................................................................... Timers in the user side ................................................................................................
viii
(05/98)
Page Annex A User side and network side SDL diagrams............................................................ Annex B Compatibility and address checking ...................................................................... B.1 B.2 B.3 Introduction................................................................................................................. Calling side compatibility checking............................................................................ Called side compatibility and address checking ......................................................... B.3.1 B.3.2 B.3.3 B.3.4 B.4 Checking of addressing information.............................................................. Network-to-user compatibility checking ....................................................... User-to-user compatibility checking.............................................................. User action tables........................................................................................... 182 252 252 253 253 253 253 253 254 254 256 256 256 257 257 257 257 258 258 258 258 259 259 259 259 260 260 260 261 261 262 262
Interworking with existing networks ..........................................................................
Annex C Transit network selection....................................................................................... C.1 C.2 Selection not supported............................................................................................... Selection supported.....................................................................................................
Annex D Extensions for symmetric call operation ............................................................... D.1 Additional message handling...................................................................................... D.1.1 D.1.2 D.1.3 D.1.4 D.2 D.3 B-channel selection Symmetric interface ................................................... Call confirmation........................................................................................... Clearing by the called user employing user-provided tones/announcements Active indication............................................................................................
Timers for call establishment...................................................................................... Call collisions .............................................................................................................
Annex E Network-specific facility selection ........................................................................ E.1 E.2 E.3 Default provider .......................................................................................................... Routing not supported................................................................................................. Routing supported.......................................................................................................
Annex F D-channel backup procedures ................................................................................ F.0 F.1 F.2 Foreword ..................................................................................................................... General........................................................................................................................ D-channel backup procedure ...................................................................................... F.2.1 F.2.2 Role of each D-channel ................................................................................. Switch-over of D-channels ............................................................................
Annex G Use of progress indicators .....................................................................................
(05/98)
ix
Page Annex H Message segmentation procedures ........................................................................ H.1 H.2 H.3 Introduction................................................................................................................. Message segmentation ................................................................................................ Reassembly of segmented messages........................................................................... 264 264 265 266 272 272 272 272 273 273 273 274 275 275 275 277 278 278 279 279 279 279 280 280 280 281 281 281 282 283 283 283 284
Annex I Low layer information coding principles ................................................................. I.1 I.2 Purpose........................................................................................................................ Principles .................................................................................................................... I.2.1 I.2.2 I.2.3 I.2.4 I.2.5 I.3 Definitions of types of information ............................................................... Examination by network................................................................................ Location of type I information....................................................................... Location of type II and III information .......................................................... Relationship between Bearer capability and Low layer capability information elements ..................................................................................... Examples for speech and 3.1 kHz audio bearer services............................... Examples for 64 kbit/s UDI circuit mode bearer service............................... Examples for ISDN virtual-circuit bearer service ......................................... Examples for speech and 3.1 kHz audio bearer services............................... Examples for 64 kbit/s UDI circuit-mode bearer services.............................
Information classification ........................................................................................... I.3.1 I.3.2 I.3.3
I.4
Scenarios outside the scope of ISDN standardization ................................................ I.4.1 I.4.2
Annex J Low layer compatibility negotiation ....................................................................... J.1 J.2 J.3 J.4 J.5 General........................................................................................................................ Low layer capability notification to the called user .................................................... Low layer compatibility negotiation between users.................................................... Low layer compatibility negotiation options .............................................................. Alternate requested values ..........................................................................................
Annex K Procedures for establishment of bearer connection prior to call acceptance......... K.1 K.2 General........................................................................................................................ Procedures...................................................................................................................
Annex L Optional procedures for bearer service change ...................................................... Annex M Additional basic call signalling requirements for the support of private network interconnection for Virtual Private Network applications .......................................... M.1 M.2 Introduction................................................................................................................. Scope........................................................................................................................... M.2.1 Acronyms used in this Annex........................................................................
(05/98)
M.2.2 References...................................................................................................... M.2.3 Definitions ..................................................................................................... M.3 M.4 Basic call states ........................................................................................................... Additional messages and content................................................................................ M.4.1 SETUP message ............................................................................................ M.4.2 CONNECT message...................................................................................... M.5 Additional information elements and coding.............................................................. M.5.1 Called party number ...................................................................................... M.5.2 Calling party number ..................................................................................... M.5.3 Connected number......................................................................................... M.5.4 Connected subaddress.................................................................................... M.5.5 Progress indicator .......................................................................................... M.5.6 Transit counter............................................................................................... M.5.7 VPN indicator ................................................................................................ M.6 Additional basic call control procedures..................................................................... M.6.1 Distinction between public network and VPN context ................................. M.6.2 Procedures applicable for signalling in a public network.............................. M.6.3 Procedures applicable for signalling in a VPN context ................................. M.7 System parameters ......................................................................................................
Page 285 285 286 287 287 287 287 287 288 290 290 290 290 290 291 291 291 292 295 296 296 297 307 307 307 308 320 323 325
Appendix M.I Discrimination of calls in a VPN context by means of the Network-specific facilities information element ..................................................................................... Annex N Flexible channel selection ..................................................................................... Appendix I Definition of causes values ................................................................................ Appendix II Example message flow diagrams and example conditions for cause mapping............................................................................................................. II.1 II.2 Example message flow diagrams................................................................................ II.1.1 Key to the figures........................................................................................... Example conditions for cause mapping ......................................................................
Appendix III Summary of assigned information element identifier and message type code points for the Q.93x-series and Q.95x-series of Recommendations........................... III.1 III.2 Acronyms used in this Recommendation ................................................................... References...................................................................................................................
(05/98)
xi
Recommendation Q.931 ISDN USER-NETWORK INTERFACE LAYER 3 SPECIFICATION FOR BASIC CALL CONTROL (Malaga-Torremolinos, 1984; modified at Helsinki, 1993; revised in 1998) 1 General
This Recommendation specifies the procedures for the establishing, maintaining and clearing of network connections at the ISDN user-network interface. These procedures are defined in terms of messages exchanged over the D-channel of basic and primary rate interface structures. The functions and procedures of this protocol, and the relationship with other layers, are described in general terms in Recommendation Q.930/I.450 [1]. This Recommendation is intended to specify the essential features, procedures, and messages required for call control in the D-channel. However, there are some details of procedure which have not yet been specified, and which will be the subject of further study. 1.1 Scope of this Recommendation
The procedures currently described in this Recommendation are for the control of circuit-switched connections, user-to-user signalling connections and packet-switched connections. The transport of other message-based information flows on the D-channel is a subject for further study and will be included in related Recommendations.
NOTE 1 The term "layer 3" is used for the functions and protocol described in this Recommendation (see Recommendation Q.930/I.450). The terms "data link layer" and "layer 2" are used interchangeably to refer to the layer immediately below layer 3. NOTE 2 Alignment of the functions and protocol with those of OSI network layer is for further study.
1.2
Application to interface structures
The layer 3 procedures apply to the interface structures defined in Recommendation I.412 [2]. They use the functions and services provided by layer 2. The unacknowledged information transfer service is used by layer 3 to provide point-to-multipoint operation as described in 5.2. The layer 3 procedures request the services of layer 2 and receive information from layer 2 using the primitives defined in Recommendation Q.921 [3]. These primitives are used to illustrate the communication between the protocol layers and are not intended to specify or constrain implementations. 2 Overview of call control
In this Recommendation, the terms "incoming" and "outgoing" are used to describe the call as viewed by the user side of the interface. In the subclauses which follow, states are defined for circuit-switched calls in 2.1 (call states), for packet-mode access connections in 2.2 (access connection states), for temporary signalling connections in 2.3 (call states) and for the interface in 2.4 (global call reference states). This clause defines the basic call control states that individual calls may have. These definitions do not apply to the state of the interface itself, any attached equipment, the D-channel, or the logical
(05/98)
links used for signalling on the D-channel. Because several calls may exist simultaneously at a usernetwork interface, and each call may be in a different state, the state of the interface itself cannot be unambiguously defined.
NOTE Additional states and SDL diagrams may be defined when new procedures are developed.
A detailed description of the procedures for call control is given in clauses 5, 6, 7, and 8 in terms of: a) b) the messages defined in clause 3 which are transferred across the user-network interface; and the information processing and actions that take place at the user side and the network side.
Overview and detailed SDL diagrams for call control of circuit-switched calls are contained in Annex A. Throughout this Recommendation, references are made to B-channels. For services using Hchannels, the references to B-channels should be taken to refer to the appropriate H-channel. Further study may be needed on other enhancements to support such services. 2.1 Circuit-switched calls
This subclause defines the basic call control states for circuit-switched calls. The procedures for call control are given in clause 5. Annex D contains optional procedures (as an extension to the basic procedures) to allow symmetric signalling. These states are defined in Annex D. 2.1.1 Call states at the user side of the interface
The states which may exist on the user side of the user-network interface are defined in this subclause. 2.1.1.1 null state (U0): No call exists. 2.1.1.2 call initiated (U1): This state exists for an outgoing call, when the user requests call establishment from the network. 2.1.1.3 overlap sending (U2): This state exists for an outgoing call when the user has received acknowledgement of the call establishment request which permits the user to send additional call information to the network in overlap mode. 2.1.1.4 outgoing call proceeding (U3): This state exists for an outgoing call when the user has received acknowledgement that the network has received all call information necessary to effect call establishment. 2.1.1.5 call delivered (U4): This state exists for an outgoing call when the calling user has received an indication that remote user alerting has been initiated. 2.1.1.6 call present (U6): This state exists for an incoming call when the user has received a call establishment request but has not yet responded. 2.1.1.7 call received (U7): This state exists for an incoming call when the user has indicated alerting but has not yet answered. 2.1.1.8 connect request (U8): This state exists for an incoming call when the user has answered the call and is waiting to be awarded the call. 2.1.1.9 incoming call proceeding (U9): This state exists for an incoming call when the user has sent acknowledgement that the user has received all call information necessary to effect call establishment.
(05/98)
2.1.1.10 active (U10): This state exists for an incoming call when the user has received an acknowledgement from the network that the user has been awarded the call. This state exists for an outgoing call when the user has received an indication that the remote user has answered the call. 2.1.1.11 disconnect request (U11): This state exists when the user has requested the network to clear the end-to-end connection (if any) and is waiting for a response. 2.1.1.12 disconnect indication (U12): This state exists when the user has received an invitation to disconnect because the network has disconnected the end-to-end connection (if any). 2.1.1.13 suspend request (U15): This state exists when the user has requested the network to suspend the call and is waiting for a response. 2.1.1.14 resume request (U17): This state exists when the user has requested the network to resume a previously suspended call and is waiting for a response. 2.1.1.15 release request (U19): This state exists when the user has requested the network to release and is waiting for a response. 2.1.1.16 overlap receiving (U25): This state exists for an incoming call when the user has acknowledged the call establishment request from the network and is prepared to receive additional call information (if any) in overlap mode. 2.1.2 Network call states
The call states that may exist on the network side of the user-network interface are defined in this subclause. 2.1.2.1 null state (N0): No call exists. 2.1.2.2 call initiated (N1): This state exists for an outgoing call when the network has received a call establishment request but has not yet responded. 2.1.2.3 overlap sending (N2): This state exists for an outgoing call when the network has acknowledged the call establishment request and is prepared to receive additional call information (if any) in overlap mode. 2.1.2.4 outgoing call proceeding (N3): This state exists for an outgoing call when the network has sent acknowledgement that the network has received all call information necessary to effect call establishment. 2.1.2.5 call delivered (N4): This state exists for an outgoing call when the network has indicated that remote user alerting has been initiated. 2.1.2.6 call present (N6): This state exists for an incoming call when the network has sent a call establishment request but has not yet received a satisfactory response. 2.1.2.7 call received (N7): This state exists for an incoming call when the network has received an indication that the user is alerting but has not yet received an answer. 2.1.2.8 connect request (N8): This state exists for an incoming call when the network has received an answer but the network has not yet awarded the call. 2.1.2.9 incoming call proceeding (N9): This state exists for an incoming call when the network has received acknowledgement that the user has received all call information necessary to effect call establishment. 2.1.2.10 active (N10): This state exists for an incoming call when the network has awarded the call to the called user. This state exists for an outgoing call when the network has indicated that the remote user has answered the call.
(05/98)
2.1.2.11 disconnect request (N11): This state exists when the network has received a request from the user to clear the end-to-end connection (if any). 2.1.2.12 disconnect indication (N12): This state exists when the network has disconnected the endto-end connection (if any) and has sent an invitation to disconnect the user-network connection. 2.1.2.13 suspend request (N15): This state exists when the network has received a request to suspend the call but has not yet responded. 2.1.2.14 resume request (N17): This state exists when the network has received a request to resume a previously suspended call but has not yet responded. 2.1.2.15 release request (N19): This state exists when the network has requested the user to release and is waiting for a response. 2.1.2.16 call abort (N22): This state exists for an incoming call for the point-to-multipoint configuration when the call is being cleared before any user has been awarded the call. 2.1.2.17 overlap receiving (N25): This state exists for an incoming call when the network has received acknowledgement of the call establishment request which permits the network to send additional call information (if any) in the overlap mode. 2.2 Packet-mode access connections
This subclause defines the basic packet-mode access connection control states for access to the ISDN virtual circuit bearer service (case B). The procedures for access connection control are given in clause 6. 2.2.1 Access connection states at the user side of the interface
The states which may exist on the user side of the user-network interface are defined in this subclause. 2.2.1.1 null state (U0): No access connection exists. 2.2.1.2 call initiated (U1): This state exists for an outgoing access connection when the user requests access connection establishment from the network. 2.2.1.3 outgoing call proceeding (U3): This state exists for an outgoing access connection when the user has received acknowledgement that the network has received all access connection information necessary to effect access connection establishment. 2.2.1.4 call present (U6): This state exists for an incoming access connection when the user has received an access connection establishment request but has not yet responded. 2.2.1.5 call received (U7): This state exists for an incoming access connection when the user has indicated alerting but has not yet answered. 2.2.1.6 connect request (U8): This state exists for an incoming access connection when the user has accepted the access connection and is waiting to be awarded the access connection. 2.2.1.7 incoming call proceeding (U9): This state exists for an incoming access connection when the user has sent acknowledgement that the user has received all access connection information necessary to effect access connection establishment. 2.2.1.8 active (U10): This state exists for an incoming access connection when the user has received an acknowledgement from the network that the user has been awarded the access connection. This state exists for an outgoing access connection when the user has received an indication that the local network has completed the access connection.
(05/98)
2.2.1.9 disconnect request (U11): This state exists when the user has requested the local network to clear the access connection and is waiting for a response. 2.2.1.10 disconnect indication (U12): This state exists when the user has received an invitation to disconnect because the network has disconnected the access connection to end connection (if any). 2.2.1.11 release request (U19): This state exists when the user has requested the network to release the access connection and is waiting for a response. 2.2.2 Access connection states at the network side of the interface
The states which may exist on the network side of the user-network interface are defined in this subclause. 2.2.2.1 null state (N0): No access connection exists. 2.2.2.2 call initiated (N1): This state exists for an outgoing access connection when the network has received an access connection establishment request but has not yet responded. 2.2.2.3 outgoing call proceeding (N3): This state exists for an outgoing access connection when the network has sent acknowledgement that the network has received all access connection information necessary to effect access connection establishment. 2.2.2.4 call present (N6): This state exists for an incoming access connection when the network has sent an access connection establishment request but has not yet received a satisfactory response. 2.2.2.5 call received (N7): This state exists for an incoming access connection when the network has received an indication that the user is alerting but has not yet received an answer. 2.2.2.6 connect request (N8): This state exists for an incoming access connection when the network has received an answer but the network has not yet awarded the access connection. 2.2.2.7 incoming call proceeding (N9): This state exists for an incoming access connection when the network has received acknowledgment that the user has received all access connection information necessary to effect access connection establishment. 2.2.2.8 active (N10): This state exists for an incoming access connection when the network has awarded the access connection to the called user. This state exists for an outgoing access connection when the local network has indicated that the access connection has been completed. 2.2.2.9 disconnect request (N11): This state exists when the network has received a request from the user to clear the access connection. 2.2.2.10 disconnect indication (N12): This state exists when the network has sent an invitation to disconnect the user-network access connection. 2.2.2.11 release request (N19): This state exists when the network has requested the user to release the access connection and is waiting for a response. 2.2.2.12 call abort (N22): This state exists for an incoming access connection for the point-tomultipoint configuration when the access connection is being cleared before any user has been awarded the access connection. 2.3 Temporary signalling connections
This subclause defines the basic call control states for user-to-user signalling not associated with circuit switched calls. The procedures for call control are given in 7.2.
(05/98)
2.3.1
Call states at the user side of the interface
The states which may exist on the user side of the user-network interface are defined in this subclause. 2.3.1.1 null state (U0): No call exists. 2.3.1.2 call initiated (U1): This state exists for an outgoing call when the user requests call establishment from the network. 2.3.1.3 overlap sending (U2): This state exists for an outgoing call when the user has received acknowledgement of the call establishment request which permits the user to send additional call information to the network in overlap mode. 2.3.1.4 outgoing call proceeding (U3): This state exists for an outgoing call when the user has received acknowledgement that the network has received all call information necessary to effect call establishment. 2.3.1.5 call delivered (U4): This state exists for an outgoing call when the calling user has received an indication that remote user alerting has been initiated. 2.3.1.6 call present (U6): This state exists for an incoming call when the user has received a call establishment request but has not yet responded. 2.3.1.7 call received (U7): This state exists for an incoming call when the user has indicated alerting but has not yet answered. 2.3.1.8 connect request (U8): This state exists for an incoming call when the user has answered the call and is awaiting to be awarded the call. 2.3.1.9 incoming call proceeding (U9): This state exists for an incoming call when the user has sent acknowledgement that the user has received all call information necessary to effect call establishment. 2.3.1.10 active (U10): This state exists for an incoming call when the user has received an acknowledgement from the network that the user has been awarded the call. This state exists for an outgoing call when the user has received an indication that the remote user has answered the call. 2.3.1.11 release request (U19): This state exists when the user has requested the network to release and is waiting for a response. 2.3.1.12 overlap receiving (U25): This state exists for an incoming call when the user has acknowledged the call establishment request from the network and is prepared to receive additional call information (if any) in overlap mode. 2.3.2 Network call states
The call states that may exist on the network side of the user-network interface are defined in this subclause. 2.3.2.1 null state (N0): No call exists. 2.3.2.2 call initiated (N1): This state exists for an outgoing call when the network has received a call establishment request but has not yet responded. 2.3.2.3 overlap sending (N2): This state exists for an outgoing call when the network has acknowledged the call establishment request and is prepared to receive additional call information (if any) in overlap mode.
(05/98)
2.3.2.4 outgoing call proceeding (N3): This state exists for an outgoing call when the network has sent acknowledgement that the network has received all call information necessary to effect call establishment. 2.3.2.5 call delivered (N4): This state exists for an outgoing call when the network has indicated that remote user alerting has been initiated. 2.3.2.6 call present (N6): This state exists for an incoming call when the network has sent a call establishment request but has not yet received a satisfactory response. 2.3.2.7 call received (N7): This state exists for an incoming call when the network has received an indication that the user is alerting but has not yet received an answer. 2.3.2.8 connect request (N8): This state exists for an incoming call when the network has received an answer but the network has not yet awarded the call. 2.3.2.9 incoming call proceeding (N9): This state exists for an incoming call when the network has received acknowledgement that the user has received all call information necessary to effect call establishment. 2.3.2.10 active (N10): This state exists for an incoming call when the network has awarded the call to the called user. This state exists for an outgoing call when the network has indicated that the remote user has answered the call. 2.3.2.11 release request (N19): This state exists when the network has requested the user to release and is waiting for a response. 2.3.2.12 call abort (N22): This state exists for an incoming call for the point-to-multipoint configuration when the call is being cleared before any user has been awarded the call. 2.3.2.13 overlap receiving (N25): This state exists for an incoming call when the network has received acknowledgement of the call establishment request which permits the network to send additional call information (if any) in the overlap mode. 2.4 States associated with the global call reference
This subclause defines the states that the protocol may adopt using the global call reference. The procedures for use of the global call reference for RESTART are contained in 5.5. There is only one global call reference per interface. 2.4.1 Call states at the user side of the interface
The states which may exist on the user side of the user network interface are defined in this subclause. 2.4.1.1 null (Rest 0): No transaction exists. 2.4.1.2 restart request (Rest 1): This state exists for a restart transaction when the user has sent a restart request but has not yet received an acknowledgement response from the network. 2.4.1.3 restart (Rest 2): This state exists when a request for a restart has been received from the network and responses have not yet been received from all locally active call references. 2.4.2 Call states at the network side of the interface
The states which may exist on the network side of the user-network interface are defined in this subclause. 2.4.2.1 null (Rest 0): No transaction exists.
(05/98)
2.4.2.2 restart request (Rest 1): This state exists for a restart transaction when the network has sent a restart request but has not yet received an acknowledgement response from the user. 2.4.2.3 restart (Rest 2): This state exists when a request for a restart has been received from the user and a response has not yet been received from all locally active call references. 3 Message functional definitions and content
This subclause provides an overview of the Q.931 message structure, which highlights the functional definition and information content (i.e. semantics) of each message. Each definition includes: a) A brief description of the message direction and use, including whether the message has: 1) local significance, i.e. relevant only in the originating or terminating access; 2) access significance, i.e. relevant in the originating and terminating access, but not in the network; 3) dual significance, i.e. relevant in either the originating or terminating access and in the network; or 4) global significance, i.e. relevant in the originating and terminating access and in the network. b) A table listing the codeset 0 information elements in the order of their appearance in the message (same relative order for all message types). For each information element, the table indicates: 1) the clause of this Recommendation describing the information element; 2) the direction in which it may be sent; i.e. user to network ("u n"), network to user ("n u"), or both;
NOTE 1 The user-network terminology in [3] refers to the TE-ET, TE-NT2, and NT2-ET interface structures. Annex D contains a description of the information element usage for symmetric NT2-NT2 interfaces.
3) whether inclusion is mandatory ("M") or optional ("O"), with a reference to Notes explaining the circumstances under which the information element shall be included; 4) the length of the information element (or permissible range of lengths), in octets, where "*" denotes an undefined maximum length, which may be network or service dependent;
NOTE 2 All messages may contain information elements from codesets 5, 6 and 7 and corresponding locking and non-locking shift information elements which comply with the coding rules specified in 4.5.2-4.5.4. None of these information elements, however, are listed in any of the tables in clause 3.
c)
further explanatory Notes, as necessary.
(05/98)
3.1
Messages for circuit-mode connection control
Table 3-1 summarizes the messages for circuit-mode connection control. Table 3-1/Q.931 Messages for circuit-mode connection control
Reference (subclauses) Call establishment messages: ALERTING CALL PROCEEDING CONNECT CONNECT ACKNOWLEDGE PROGRESS SETUP SETUP ACKNOWLEDGE Call information phase messages: RESUME RESUME ACKNOWLEDGE RESUME REJECT SUSPEND SUSPEND ACKNOWLEDGE SUSPEND REJECT Call clearing messages: DISCONNECT RELEASE RELEASE COMPLETE Miscellaneous messages: INFORMATION NOTIFY SEGMENT STATUS STATUS ENQUIRY 3.1.1 3.1.2 3.1.3 3.1.4 3.1.8 3.1.14 3.1.15 3.1.11 3.1.12 3.1.13 3.1.18 3.1.19 3.1.20 3.1.5 3.1.9 3.1.10 3.1.6 3.1.7 Annex H (Note 2) 3.1.16 3.1.17
NOTE 1 In Recommendation Q.931 (1988) [53], support of user-user signalling was included for a number of reasons, including support of additional compatibility checking upon bilateral agreement with other users or in accordance with other standards (e.g. Recommendation X.213 [23]). To utilize this capability, the User-user information element can be included in the ALERTING, CONNECT, DISCONNECT, PROGRESS, RELEASE, RELEASE COMPLETE and SETUP messages. Details on this capability (explicit and implicit Type 1 user-user signalling) are given in Recommendation Q.957 [54]. NOTE 2 The segment message is required if the optional segmentation procedure defined in Annex H is implemented.
(05/98)
3.1.1
ALERTING
This message is sent by the called user to the network and by the network to the calling user, to indicate that called user alerting has been initiated. See Table 3-2. Table 3-2/Q.931 ALERTING message content
Message type: ALERTING Significance: Global Direction: Both Information element Protocol discriminator Call reference Message type Bearer capability Channel identification Progress indicator Display Signal High layer compatibility Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 4.5 4.5 4.5 Direction Both Both Both Both Both (Note 2) Both nu nu Both Type M M M O (Note 1) O (Note 3) O (Note 4) O (Note 5) O (Note 7) O (Note 8) Length 1 2-* 1 4-12 2-* 2-4 (Note 6) 2-3 2-5
NOTE 1 The Bearer capability information element is included when the procedures of 5.11 for bearer capability selection apply. When present, progress description No. 5, interworking has occurred and has resulted in a telecommunication service change, shall also be present. NOTE 2 Included in the network-to-user direction for support of the procedures in Annex D. NOTE 3 Mandatory if this message is the first message in response to a SETUP, unless the user accepts the B-channel indicated in the SETUP message. NOTE 4 Included in the event of interworking. Included in the network-to-user direction in connection with the provision of in-band information/patterns. Included in the user-to-network direction in connection with the provision of in-band information/patterns if Annex K is implemented or in accordance with the procedures of 5.11.3 and 5.12.3. NOTE 5 Included if the network provides information that can be presented to the user. NOTE 6 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets. NOTE 7 Included if the network optionally provides information describing tones or alerting signals. NOTE 8 The High layer compatibility information element is included when the procedures of 5.12 for high layer compatibility selection apply. When present, progress description No. 5, interworking has occurred and has resulted in a telecommunication service change, shall also be present.
10
(05/98)
3.1.2
CALL PROCEEDING
This message is sent by the called user to the network or by the network to the calling user to indicate that requested call establishment has been initiated and no more call establishment information will be accepted. See Table 3-3. Table 3-3/Q.931 CALL PROCEEDING message content
Message type: CALL PROCEEDING Significance: Local Direction: Both Information element Protocol discriminator Call reference Message type Bearer capability Channel identification Progress indicator Display High layer compatibility Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 4.5 4.5 Direction Both Both Both Both Both Both nu Both Type M M M O (Note 5) O (Note 1) O (Note 2) O (Note 3) O (Note 6) Length 1 2-* 1 4-12 2-* 2-4 (Note 4) 2-5
NOTE 1 Mandatory in the network-to-user direction if this message is the first message in response to a SETUP message. It is mandatory in the user-to-network direction if this message is the first message in response to a SETUP message, unless the user accepts the B-channel indicated in the SETUP message. NOTE 2 Included in the event of interworking. Included in the network-to-user direction in connection with the provision of in-band information/patterns. Included in the user-to-network direction in connection with the provision of in-band information/patterns if Annex K is implemented or in accordance with the procedures of 5.11.3 and 5.12.3. NOTE 3 Included if the network provides information that can be presented to the user. NOTE 4 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets. NOTE 5 The Bearer capability information element is included when the procedures of 5.11 for bearer capability selection apply. When present, progress indication No. 5, interworking has occurred and has resulted in a telecommunication service change, shall also be present. NOTE 6 The High layer compatibility information element is included when the procedures of 5.12 for high layer compatibility selection apply. When present, progress indication No. 5, interworking has occurred and has resulted in a telecommunication service change, shall also be present.
(05/98)
11
3.1.3
CONNECT
This message is sent by the called user to the network and by the network to the calling user, to indicate call acceptance by the called user. See Table 3-4. Table 3-4/Q.931 CONNECT message content
Message type: CONNECT Significance: Global Direction: Both Information element Protocol discriminator Call reference Message type Bearer capability Channel identification Progress indicator Display Date/time Signal Low layer compatibility High layer compatibility Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 Direction Both Both Both Both Both (Note 2) Both nu nu nu Both Both Type M M M O (Note 1) O (Note 3) O (Note 4) O (Note 5) O (Note 7) O (Note 8) O (Note 9) O (Note 10) Length 1 2-* 1 4-12 2-* 2-4 (Note 6) 8 2-3 2-18 2-5
NOTE 1 The Bearer capability information element is included when the procedures of 5.11 for bearer capability selection apply. NOTE 2 Included in the network-to-user direction for support of the procedures in Annex D. NOTE 3 Mandatory if this is the first message in response to a SETUP, unless the user accepts the B-channel indicated in the SETUP message. NOTE 4 Included in the event of interworking or in connection with the provision of in-band information/patterns. NOTE 5 Included if the network provides information that can be presented to the user. NOTE 6 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets. NOTE 7 As a network option, it may be included to provide date and time information to the calling user for all calls or for calls involving specific telecommunication services. NOTE 8 Included if the network optionally provides additional information describing tones. NOTE 9 Included in the user-to-network when the answering user wants to return low layer compatibility information to the calling user. Included in the network-to-user direction if the user awarded the call included a Low layer compatibility information element in the CONNECT message. Optionally included for low layer compatibility negotiation, but some networks may not transport this information element to the calling user (see Annex J). NOTE 10 The High layer compatibility information element is included when the procedures of 5.12 for high layer compatibility selection apply.
12
(05/98)
3.1.4
CONNECT ACKNOWLEDGE
This message is sent by the network to the called user to indicate the user has been awarded the call. It may also be sent by the calling user to the network to allow symmetrical call control procedures. See Table 3-5. Table 3-5/Q.931 CONNECT ACKNOWLEDGE message content
Message type: CONNECT ACKNOWLEDGE Significance: Local Direction: Both Information element Protocol discriminator Call reference Message type Display Signal Reference (subclause) 4.2 4.3 4.4 4.5 4.5 Direction Both Both Both nu nu Type M M M O (Note 1) O (Note 3) Length 1 2-* 1 (Note 2) 2-3
NOTE 1 Included if the network provides information that can be presented to the user. NOTE 2 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets. NOTE 3 Included if the network optionally provides additional information describing tones.
(05/98)
13
3.1.5
DISCONNECT
This message is sent by the user to request the network to clear an end-to-end connection or is sent by the network to indicate that the end-to-end connection is cleared. See Table 3-6. Table 3-6/Q.931 DISCONNECT message content
Message type: DISCONNECT Significance: Global Direction: Both Information element Protocol discriminator Call reference Message type Cause Progress indicator Display Signal Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 4.5 Direction Both Both Both Both (Note 1) nu nu Type M M M M O (Note 2) O (Note 3) O (Note 5) Length 1 2-* 1 4-32 2-4 (Note 4) 2-3
NOTE 1 Included in the network-to-user direction if the network provides in-band tones. See Annex D for usage in the user-to-network direction. NOTE 2 Included by the network if in-band tones are provided. However, the user may include the progress indicator and provide in-band tones. See Annex D. In such cases, the network will ignore this information element and will not convey the in-band tones. NOTE 3 Included if the network provides information that can be presented to the user. NOTE 4 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets. NOTE 5 Included if the network optionally provides additional information describing tones.
14
(05/98)
3.1.6
INFORMATION
This message is sent by the user or the network to provide additional information. It may be used to provide information for call establishment (e.g. overlap sending) or miscellaneous call-related information. See Table 3-7. Table 3-7/Q.931 INFORMATION message content
Message type: INFORMATION Significance: Local (Note 1) Direction: Both Information element Protocol discriminator Call reference Message type Sending complete Display Keypad facility Signal Called party number Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 4.5 4.5 Direction Both Both Both Both nu un nu both Type M M (Note 2) M O (Note 3) O (Note 4) O (Note 6) O (Note 7) O (Note 8) Length 1 2-* 1 1 (Note 5) 2-34 2-3 2-*
NOTE 1 This message has local significance, but may carry information of global significance. NOTE 2 This message may be sent with the dummy call reference defined in 4.3 when feature key management procedures are used (see Recommendation Q.932); otherwise the minimum length is 2 octets. NOTE 3 Included if the user optionally indicates completion of overlap sending to the network, or if the network optionally indicates completion of overlap receiving to the user. NOTE 4 Included if the network provides information that can be presented to the user. NOTE 5 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets. NOTE 6 Either the Called party number or the Keypad facility information element is included by the user to transfer called party number information to the network during overlap sending. The Keypad facility information element may also be included if the user wants to convey other call establishment information to the network, or to convey supplementary service information. NOTE 7 Included if the network optionally provides additional information describing tones. NOTE 8 Either the Called party number or the Keypad facility information element is included by the user to convey called party number information to the network during overlap sending. The Called party number information element is included by the network to convey called party number information to the user during overlap receiving.
(05/98)
15
3.1.7
NOTIFY
This message is sent by the user or the network to indicate information pertaining to a call, such as user suspended. See Table 3-8. Table 3-8/Q.931 NOTIFY message content
Message type: NOTIFY Significance: Access Direction: Both Information element Protocol discriminator Call reference Message type Bearer capability Notification indicator Display Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 Direction Both Both Both nu Both nu Type M M M O (Note 1) M O (Note 2) Length 1 2-* 1 2-12 3 (Note 3)
NOTE 1 Included by the network to indicate a change of the bearer capability (see Annex L). NOTE 2 Included if the network provides information that can be presented to the user. NOTE 3 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets.
16
(05/98)
3.1.8
PROGRESS
This message is sent by the user or the network to indicate the progress of a call in the event of interworking or in relation with the provision of in-band information/patterns. See Table 3-9. Table 3-9/Q.931 PROGRESS message content
Message type: PROGRESS Significance: Global Direction: Both Information element Protocol discriminator Call reference Message type Bearer capability Cause Progress indicator Display High layer compatibility Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 4.5 4.5 Direction Both Both Both Both Both Both nu Both Type M M M O (Note 1) O (Note 2) M O (Note 3) O (Note 5) Length 1 2-* 1 4-12 2-32 4 (Note 4) 2-5
NOTE 1 The Bearer capability information element is included when the procedures of 5.11 for bearer capability selection apply. The Bearer capability information element indicates the bearer service now being used for the call. NOTE 2 Included by the user or the network to provide additional information concerning the provision of in-band information/patterns. NOTE 3 Included if the network provides information that can be presented to the user. NOTE 4 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets. NOTE 5 The High layer compatibility information element is included when the optional procedures of 5.12 for high layer compatibility selection apply. The High layer compatibility information element indicates the high layer compatibility now being used for the call.
(05/98)
17
3.1.9
RELEASE
This message is sent by the user or the network to indicate that the equipment sending the message has disconnected the channel (if any) and intends to release the channel and the call reference. Thus the receiving equipment should release the channel and prepare to release the call reference after sending a RELEASE COMPLETE. See Table 3-10. Table 3-10/Q.931 RELEASE message content
Message type: RELEASE Significance: Local (Note 1) Direction: Both Information element Protocol discriminator Call reference Message type Cause Display Signal Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 Direction Both Both Both Both nu nu Type M M M O (Note 2) O (Note 3) O (Note 5) Length 1 2-* 1 2-32 (Note 4) 2-3
NOTE 1 This message has local significance; however, it may carry information of global significance when used as the first call clearing message. NOTE 2 Mandatory in the first call clearing message, including when the RELEASE message is sent as a result of an error handling condition. NOTE 3 Included if the network provides information that can be presented to the user. NOTE 4 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets. NOTE 5 Included if the network optionally provides additional information describing tones.
18
(05/98)
3.1.10 RELEASE COMPLETE This message is sent by the user or the network to indicate that the equipment sending the message has released the channel (if any) and call reference, the channel is available for reuse, and the receiving equipment shall release the call reference. See Table 3-11. Table 3-11/Q.931 RELEASE COMPLETE message content
Message type: RELEASE COMPLETE Significance: Local (Note 1) Direction: Both Information element Protocol discriminator Call reference Message type Cause Display Signal Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 Direction Both Both Both Both nu nu Type M M M O (Note 2) O (Note 3) O (Note 5) Length 1 2-* 1 2-32 (Note 4) 2-3
NOTE 1 This message has local significance; however, it may carry information of global significance when used as the first call clearing message. NOTE 2 Mandatory in the first call clearing message, including when the RELEASE COMPLETE message is sent as a result of an error handling condition. NOTE 3 Included if the network provides information that can be presented to the user. NOTE 4 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets. NOTE 5 Included if the network optionally provides additional information describing tones.
3.1.11 RESUME This message is sent by the user to request the network to resume a suspended call. See Table 3-12. Table 3-12/Q.931 RESUME message content
Message type: RESUME Significance: Local Direction: User-to-network Information element Protocol discriminator Call reference Message type Call identity Reference (subclause) 4.2 4.3 4.4 4.5 Direction un un un un Type M M M O (Note) Length 1 2-* 1 2-10
NOTE Included when the SUSPEND message used to suspend the call included a Call identity information element.
(05/98)
19
3.1.12 RESUME ACKNOWLEDGE This message is sent by the network to the user to indicate completion of a request to resume a suspended call. See Table 3-13. Table 3-13/Q.931 RESUME ACKNOWLEDGE message content
Message type: RESUME ACKNOWLEDGE Significance: Local Direction: Network-to-user Information element Protocol discriminator Call reference Message type Channel identification Display Reference (subclause) 4.2 4.3 4.4 4.5 4.5 Direction nu nu nu nu nu Type M M M M O (Note 1) Length 1 2-* 1 3-* (Note 2)
NOTE 1 Included if the network provides information that can be presented to the user. NOTE 2 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets.
3.1.13 RESUME REJECT This message is sent by the network to the user to indicate failure of a request to resume a suspended call. See Table 3-14. Table 3-14/Q.931 RESUME REJECT message content
Message type: RESUME REJECT Significance: Local Direction: Network-to-user Information element Protocol discriminator Call reference Message type Cause Display Reference (subclause) 4.2 4.3 4.4 4.5 4.5 Direction nu nu nu nu nu Type M M M M O (Note 1) Length 1 2-* 1 4-32 (Note 2)
20
(05/98)
3.1.14 SETUP This message is sent by the calling user to the network and by the network to the called user to initiate call establishment. See Table 3-15. Table 3-15/Q.931 SETUP message content
Message type: SETUP Significance: Global Direction: Both Information element Protocol discriminator Call reference Message type Sending complete Repeat indicator Bearer capability Channel identification Progress indicator Network-specific facilities Display Date/Time Keypad facility Signal Calling party number Calling party subaddress Called party number Called party subaddress Transit network selection Repeat indicator Low layer compatibility High layer compatibility Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 Direction Both Both Both Both Both Both Both Both Both nu un un nu Both Both Both Both un Both Both Both Type M M M O (Note 1) O (Note 2) M (Note 3) O (Note 4) O (Note 5) O (Note 6) O (Note 7) O (Note 19) O (Note 9) O (Note 10) O (Note 11) O (Note 12) O (Note 13) O (Note 14) O (Note 15) O (Note 16) O (Note 17) O (Note 18) Length 1 2-* 1 1 1 4-12 2-* 2-4 2-* (Note 8) 8 2-34 2-3 2-* 2-23 2-* 2-23 2-* 1 2-18 2-5
NOTE 1 Included if the user or the network optionally indicates that all information necessary for call establishment is included in the SETUP message. NOTE 2 The Repeat indicator information element is included immediately before the first Bearer capability information element when the bearer capability negotiation procedure is used (see Annex L). NOTE 3 May be repeated if the bearer capability negotiation procedure is used (see Annex L). For bearer capability negotiation, two Bearer capability information elements may be included in descending order of priority, i.e. highest priority first. Although support of multiple Bearer capability information elements may not be supported on all networks, on networks that do support it, and through suitable subscription arrangements, three Bearer capability information elements may be included (see 5.11). When they are not preceded by a Repeat indicator information element, they are included in ascending order of priority. NOTE 4 Mandatory in the network-to-user direction. Included in the user-to-network direction when a user wants to indicate a channel. If not included, its absence is interpreted as "any channel acceptable".
(05/98)
21
Table 3-15/Q.931 SETUP message content (concluded)

NOTE 5 Included in the event of interworking or in connection with the provision of in-band information/patterns. NOTE 6 Included by the calling user or the network to indicate network-specific facilities information (see Annex E). NOTE 7 Included if the network provides information that can be presented to the user. NOTE 8 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets. NOTE 9 Either the Called party number or the Keypad facility information element is included by the user to convey called party number information to the network. The Keypad facility information element may also be included by the user to convey other call establishment information to the network. NOTE 10 Included if the network optionally provides additional information describing tones. NOTE 11 May be included by the calling user or the network to identify the calling user. Not included in the network-to-user direction for basic call control, but may be included for some supplementary services. NOTE 12 Included in the user-to-network direction when the calling user wants to indicate the calling party subaddress. Not included in the network-to-user direction for basic call control, but may be included for some supplementary services. NOTE 13 Either the Called party number or the Keypad facility information element is included by the user to convey called party number information to the network. The Called party number information element is included by the network when called party number information is to be conveyed to the user. NOTE 14 Included in the user-to-network direction when the calling user wants to indicate the called party subaddress. Included in the network-to-user direction if the calling user included a Called party subaddress information element in the SETUP message. NOTE 15 Included by the calling user to select a particular transit network (see Annex C). NOTE 16 Included when two or more Low layer compatibility information elements are included for low layer compatibility negotiation. NOTE 17 Included in the user-to-network direction when the calling user wants to pass low layer compatibility information to the called user. Included in the network-to-user direction if the calling user included a Low layer compatibility information element in the SETUP message. Two, three or four information elements may be included in descending order of priority, i.e. highest priority first, if the low layer compatibility negotiation procedures are used (see Annex J). NOTE 18 Included in the user-to-network direction when the calling user wants to pass high layer compatibility information to the called user. Included in the network-to-user direction if the calling user included a High layer compatibility information element in the SETUP message. Although support of multiple High layer compatibility information elements may not be supported on all networks, on networks that do support it, and through suitable subscription arrangements, two High layer compatibility information elements may be included (see 5.12). When they are not preceded by a Repeat indicator information element, they are included in ascending order of priority. NOTE 19 As a network option, it may be included to provide date and time information to the called user.
22
(05/98)
3.1.15 SETUP ACKNOWLEDGE This message is sent by the network to the calling user, or by the called user to the network, to indicate that call establishment has been initiated, but additional information may be required. See Table 3-16. Table 3-16/Q.931 SETUP ACKNOWLEDGE message content
Message type: SETUP ACKNOWLEDGE Significance: Local Direction: Both Information element Protocol discriminator Call reference Message type Channel identification Progress indicator Display Signal Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 4.5 Direction Both Both Both Both Both nu nu Type M M M O (Note 1) O (Note 2) O (Note 3) O (Note 5) Length 1 2-* 1 2-* 2-4 (Note 4) 2-3
NOTE 1 Mandatory in all cases, except when the user accepts the specific B-channel indicated in the SETUP message. NOTE 2 Included in the event of interworking or in connection with the provision of in-band information/patterns. NOTE 3 Included if the network provides information that can be presented to the user. NOTE 4 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets. NOTE 5 Included if the network optionally provides information describing tones (e.g. activate dial tone).
(05/98)
23
3.1.16 STATUS This message sent is by the user or the network in response to a STATUS ENQUIRY message or at any time during a call to report certain error conditions listed in 5.8. See Table 3-17. Table 3-17/Q.931 STATUS message content
Message type: STATUS Significance: Local Direction: Both Information element Protocol discriminator Call reference Message type Cause Call state Display Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 Direction Both Both Both Both Both nu Type M M M M M O (Note 1) Length 1 2-* 1 4-32 3 (Note 2)
3.1.17 STATUS ENQUIRY The STATUS ENQUIRY message is sent by the user or the network at any time to solicit a STATUS message from the peer layer 3 entity. Sending a STATUS message in response to a STATUS ENQUIRY message is mandatory. See Table 3-18. Table 3-18/Q.931 STATUS ENQUIRY message content
Message type: STATUS ENQUIRY Significance: Local Direction: Both Information element Protocol discriminator Call reference Message type Display Reference (subclause) 4.2 4.3 4.4 4.5 Direction Both Both Both nu Type M M M O (Note 1) Length 1 2-* 1 (Note 2)
24
(05/98)
3.1.18 SUSPEND This message is sent by the user to request the network to suspend a call. See Table 3-19. Table 3-19/Q.931 SUSPEND message content
Message type: SUSPEND Significance: Local Direction: User-to-network Information element Protocol discriminator Call reference Message type Call identity Reference (subclause) 4.2 4.3 4.4 4.5 Direction un un un un Type M M M O (Note) Length 1 2-* 1 2-10
NOTE Included if the user wants to identify the suspended call explicitly.
3.1.19 SUSPEND ACKNOWLEDGE This message is sent by the network to the user to indicate completion of a request to suspend a call. See Table 3-20. Table 3-20/Q.931 SUSPEND ACKNOWLEDGE message content
Message type: SUSPEND ACKNOWLEDGE Significance: Local Direction: Network-to-user Information element Protocol discriminator Call reference Message type Display Reference (subclause) 4.2 4.3 4.4 4.5 Direction nu nu nu nu Type M M M O (Note 1) Length 1 2* 1 (Note 2)
(05/98)
25
3.1.20 SUSPEND REJECT This message is sent by the network to the user to indicate failure of a request to suspend a call. See Table 3-21. Table 3-21/Q.931 SUSPEND REJECT message content
Message type: SUSPEND REJECT Significance: Local Direction: Network-to-user Information element Protocol discriminator Call reference Message type Cause Display Reference (subclause) 4.2 4.3 4.4 4.5 4.5 Direction nu nu nu nu nu Type M M M M O (Note 1) Length 1 2-* 1 4-32 (Note 2)
3.2
Messages for packet-mode connection control
Table 3-22 summarizes the messages for packet-mode access connection control. The message tables in this subclause should be used for Case B (packet-switched access to an ISDN virtual circuit service) as defined in clause 6. For Case A (circuit-switched access to PSPDN services), the message tables in 3.1 should be used. Table 3-22/Q.931 Messages for packet-mode access connection control
Reference (subclause) Access connection establishment messages: ALERTING CALL PROCEEDING CONNECT CONNECT ACKNOWLEDGE PROGRESS SETUP Access connection clearing messages: DISCONNECT RELEASE RELEASE COMPLETE Miscellaneous messages: STATUS STATUS ENQUIRY 3.2.10 3.2.11 3.2.5 3.2.7 3.2.8 3.2.1 3.2.2 3.2.3 3.2.4 3.2.6 3.2.9
26
(05/98)
3.2.1
ALERTING
This message is sent by the called user to the network to indicate that called user alerting has been initiated. See Table 3-23. Table 3-23/Q.931 ALERTING message content
Message type: ALERTING Significance: Local Direction: User-to-network Information element Protocol discriminator Call reference Message type Channel identification Progress indicator Reference (subclause) 4.2 4.3 4.4 4.5 4.5 Direction un u n un un un Type M M M O (Note 1) O (Note 2) Length 1 2-* 1 2-* 2-4
NOTE 1 Mandatory if this message is the first message in response to SETUP, unless the user accepts the channel indicated in the SETUP message. NOTE 2 Included in the event of interworking within a private network.
(05/98)
27
3.2.2
CALL PROCEEDING
This message is sent by the called user or by the network to the calling user to indicate that requested access connection establishment has been initiated. See Table 3-24. Table 3-24/Q.931 CALL PROCEEDING message content
Message type: CALL PROCEEDING Significance: Local Direction: Both Information element Protocol discriminator Call reference Message type Channel identification Progress indicator Display Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 Direction Both Both Both Both un nu Type M M M O (Note 1) O (Note 2) O (Note 3) Length 1 2-* 1 2-* 2-4 (Note 4)
NOTE 1 Mandatory in the network-to-user direction if this message is the first message in response to a SETUP. Mandatory in the user-to-network direction if this message is the first message in response to SETUP message, unless the user accepts the channel indicated in the SETUP message. NOTE 2 Included in the event of interworking. Included in the network-to-user direction in connection with the provision of in-band information/patterns. Included in the user-to-network direction in connection with in-band information/patterns if Annex K is implemented or in accordance with the procedures of 5.11.3 and 5.12.3. NOTE 3 Included if the network provides information that can be presented to the user. NOTE 4 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets.
28
(05/98)
3.2.3
CONNECT
This message is sent by the called user to the network, and by the network to the calling user, to indicate acceptance of the access connection. See Table 3-25. Table 3-25/Q.931 CONNECT message content
Message type: CONNECT Significance: Global Direction: Both Information element Protocol discriminator Call reference Message type Channel identification Progress indicator Display Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 Direction Both Both Both un un nu Type M M M O (Note 1) O (Note 4) O (Note 2) Length 1 2-* 1 2-* 2-4 (Note 3)
NOTE 1 Mandatory if this message is the first message in response to SETUP, unless the user accepts the channel indicated in the SETUP message. NOTE 2 Included if the network provides information that can be presented to the user. NOTE 3 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets. NOTE 4 Included in the event of interworking within a private network.
3.2.4
CONNECT ACKNOWLEDGE
This message is sent by the network to the called user to indicate that the user has been awarded the access connection. It may also be sent by the calling user to the network to allow symmetrical access connection control procedures. See Table 3-26. Table 3-26/Q.931 CONNECT ACKNOWLEDGE message content
Message type: CONNECT ACKNOWLEDGE Significance: Local Direction: Both Information element Protocol discriminator Call reference Message type Display Reference (subclause) 4.2 4.3 4.4 4.5 Direction Both Both Both nu Type M M M O (Note 1) Length 1 2-* 1 (Note 2)
(05/98)
29
3.2.5
DISCONNECT
This message is sent by the user to request the network to clear an access connection or is sent by the network to the user to indicate clearing of the access connection. See Table 3-27. Table 3-27/Q.931 DISCONNECT message contents
Message type: DISCONNECT Significance: Local Direction: Both Information element Protocol discriminator Call reference Message type Cause Display User-user Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 Direction Both Both Both Both nu un Type M M M M O (Note 1) O (Note 3) Length 1 2-* 1 4-32 (Note 2) (Note 4)
NOTE 1 Included if the network provides information that can be presented to the user. NOTE 2 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets. NOTE 3 May be sent if the access connection has not yet reached the active state. However, user-user information is not sent after the access connection has reached the active state since X.25 procedures would be used for this information transfer. NOTE 4 The minimum length is 2 octets; the standard default maximum length is 131 octets.
3.2.6
PROGRESS
This message is sent by the called user or the network to indicate the progress of an access connection establishment in the event of interworking within a private network. See Table 3-28. Table 3-28/Q.931 PROGRESS message content
Message type: PROGRESS Significance: Local Direction: User-to-network Information element Protocol discriminator Call reference Message type Cause Progress indicator Reference (subclause) 4.2 4.3 4.4 4.5 4.5 Direction un un un un un Type M M M O (Note) M Length 1 2-* 1 2-32 4
NOTE Included by the called user to provide additional information.
30
(05/98)
3.2.7
RELEASE
This message is sent by the user or the network 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. The RELEASE message is sent by the network to the user to indicate that the access connection is awarded on either the D-channel or an existing channel and that the network intends to release the call reference. See Table 3-29. Table 3-29/Q.931 RELEASE message content
Message type: RELEASE Significance: Local (Note 1) Direction: Both Information element Protocol discriminator Call reference Message type Cause Display User-user Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 Direction Both Both Both Both nu un Type M M M O (Note 2) O (Note 3) O (Note 5) Length 1 2-* 1 2-32 (Note 4) (Note 6)
NOTE 1 This message has local significance; however, it may carry information of global significance when used as the first call clearing message. NOTE 2 Mandatory in the first clearing message, including when the RELEASE message is sent as a result of an error handling condition. NOTE 3 Included if the network provides information that can be presented to the user. NOTE 4 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets. NOTE 5 User-user information may be sent if RELEASE is the first clearing message and the access connection has not yet reached the active state and Q.931/X.25 mapping service is provided by the network. However, user-user information is not sent if the access connection has reached the active state since X.25 procedures would be used for this information transfer. NOTE 6 The minimum length is 2 octets; the standard default maximum length is 131 octets.
(05/98)
31
3.2.8
RELEASE COMPLETE
This message is sent by the user or the network to indicate that the equipment sending the message has released the channel (if any) and call reference. The channel is available for reuse, and the receiving equipment shall release the call reference. See Table 3-30. Table 3-30/Q.931 RELEASE COMPLETE message content
Message type: RELEASE COMPLETE Significance: Local (Note 1) Direction: Both Information element Protocol discriminator Call reference Message type Cause Display User-user Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 Direction Both Both Both Both nu un Type M M M O (Note 2) O (Note 3) O (Note 5) Length 1 2-* 1 2-32 (Note 4) (Note 6)
NOTE 1 This message has local significance; however, it may carry information of global significance when used as the first call clearing message. NOTE 2 Mandatory in the first call clearing message, including when the RELEASE COMPLETE message is sent as a result of an error handling condition. NOTE 3 Included if the network provides information that can be presented to the user. NOTE 4 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets. NOTE 5 User-user information may be sent if RELEASE COMPLETE is the first clearing message and the access connection has not yet reached the active state and Q.931/X.25 mapping service is provided by the network. However, user-user information is not sent if the access connection has reached the active state since X.25 [5] procedures would be used for this information transfer. NOTE 6 The minimum length is 2 octets; the standard default maximum length is 131 octets.
32
(05/98)
3.2.9
SETUP
This message is sent by the calling user to the network and by the network to the called user to initiate access connection establishment. See Table 3-31. Table 3-31/Q.931 SETUP message content
Message type: SETUP Significance: Global Direction: Both Information element Protocol discriminator Call reference Message type Bearer capability Channel identification Progress indicator Display Information rate End-end transit delay Transit delay selection and indication Packet layer binary parameters Packet layer window size Packet size Closed user group Reverse charging indication Calling party number Calling party subaddress Called party number Called party subaddress Redirecting number User-user Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 4.5 4.6 4.6 4.6 4.6 4.6 4.6 4.6 4.6 4.5 4.5 4.5 4.5 4.6 4.5 Direction Both Both Both Both Both un nu nu nu nu nu nu nu nu nu Both Both nu nu nu nu Type M M M M (Note 1) O (Note 2) O (Note 3) O (Note 4) O (Note 6) O (Note 8) O (Note 7) O (Note 9) O (Note 10) O (Note 11) O (Note 12) O (Note 13) O (Note 14) O (Note 15) O (Note 16) O (Note 17) O (Note 18) O (Note 19) Length 1 2-* 1 4-12 2-* 2-4 (Note 5) 2-6 2-11 2-5 2-3 2-4 2-4 4-7 3 2-* 2-23 2-* 2-23 2-* (Note 20)
NOTE 1 May be used to describe an ITU-T telecommunication service involving packet-mode access connections, if appropriate. NOTE 2 Mandatory in the network-to-user direction. Included in the user-to-network direction when the user wants to indicate a channel. If not included, its absence is interpreted as "any channel acceptable". NOTE 3 Included in the event of interworking within a private network. NOTE 4 Included if the network provides information that can be presented to the user. NOTE 5 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets.
(05/98)
33

NOTE 6 Included in the network-to-user direction if the network implements X.25 [5]/Q.931 information element mapping and provides indication to the called user of the information rate for the call. NOTE 7 Included in the network-to-user direction if the network implements X.25/Q.931 information element mapping and provides indication to the called user of the maximum permissible transit delay for the call. NOTE 8 Included in the network-to-user direction if the network implements X.25/Q.931 information element mapping and provides indication to the called user of the end-end transit delay for the call. NOTE 9 Included in the network-to-user direction if the network implements X.25/Q.931 information element mapping and provides indication to the called user of the packet layer binary parameters for the call. NOTE 10 Included in the network-to-user direction if the network implements X.25/Q.931 information element mapping and provides indication to the called user of the packet layer window size for the call. NOTE 11 Included in the network-to-user direction if the network implements X.25/Q.931 information element mapping and provides indication to the called user of the packet size for the call. NOTE 12 Included in the network-to-user direction if the network implements X.25/Q.931 information element mapping and provides indication to the called party of the closed user group that belongs for that call. NOTE 13 Included in the network-to-user direction if the network implements X.25/Q.931 information element mapping and provides indication to the called party of the reverse charging request that applies for that call. NOTE 14 Included in the user-to-network direction depending on the user/network identification requirements. Included in the network-to-user direction if the network implements X.25/Q.931 information element mapping and provides indication to the called user of the calling party number. NOTE 15 Included in the user-to-network direction depending on the user/network identification requirements. Included in the network-to-user direction if the network implements X.25/Q.931 information element mapping and provides indication to the called user of the calling party subaddress. NOTE 16 Included in the network-to-user direction if the network implements X.25/Q.931 information element mapping and provides indication to the called user of the called party number. NOTE 17 Included in the network-to-user direction if the network implements X.25/Q.931 information element mapping and provides indication to the called user of the called party subaddress. NOTE 18 Included in the network-to-user direction if the network implements X.25/Q.931 information element mapping and provides indication to the called user of the number from which a call diversion or transfer was invoked. NOTE 19 Included in the network-to-user direction if the calling user included user information and the network implements X.25/Q.931 information element mapping. NOTE 20 The minimum length is 2 octets; the standard default maximum length is 131 octets.
34
(05/98)
3.2.10 STATUS This message is sent by the user or the network in response to a STATUS ENQUIRY message or at any time to report certain error conditions listed in 5.8. See Table 3-32. Table 3-32/Q.931 STATUS message content
Message Type: STATUS Significance: Local Direction: Both Information element Protocol discriminator Call reference Message type Cause Call state Display Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 Direction Both Both Both Both Both nu Type M M M M M O (Note 1) Length 1 2-* 1 4-32 3 (Note 2)
3.2.11 STATUS ENQUIRY The STATUS ENQUIRY message is sent by the user or the network at any time to solicit a STATUS message from the peer layer 3 entity. Sending a STATUS message in response to a STATUS ENQUIRY message is mandatory. See Table 3-33. Table 3-33/Q.931 STATUS ENQUIRY message content
(05/98)
35
3.3
Messages for user signalling bearer service control
Table 3-34 summarizes the messages for the control of non-call associated temporary signalling connections and the transfer of user-user information. Table 3-34/Q.931 Messages for temporary signalling connection control
Reference (subclause) Call establishment messages: ALERTING CALL PROCEEDING CONNECT CONNECT ACKNOWLEDGE SETUP SETUP ACKNOWLEDGE Call information phase messages: USER INFORMATION Call clearing messages: RELEASE RELEASE COMPLETE Miscellaneous messages: CONGESTION CONTROL INFORMATION STATUS STATUS ENQUIRY 3.3.3 3.3.6 3.3.11 3.3.12 3.3.7 3.3.8 3.3.13 3.3.1 3.3.2 3.3.4 3.3.5 3.3.9 3.3.10
NOTE In Recommendation Q.931 (1988), support of user-user signalling was included for a number of reasons, including support of additional compatibility checking upon bilateral agreement with other users or in accordance with other standards (e.g. Recommendation X.213 [23]). To utilise this capability, the User-user information element can be included in the ALERTING, CONNECT, RELEASE, RELEASE COMPLETE and SETUP messages. Details on this capability (explicit and implicit Type 1 user-user signalling) are given in Recommendation Q.957 [54].
36
(05/98)
3.3.1
ALERTING
This message is sent by the called user to the network, and by the network to the calling user, to indicate that called user alerting has been initiated. See Table 3-35. Table 3-35/Q.931 ALERTING message content
Message type: ALERTING Significance: Global Direction: Both Information element Protocol discriminator Call reference Message type Channel identification Display Reference (subclause) 4.2 4.3 4.4 4.5 4.5 Direction Both Both Both un nu Type M M M O (Note 1) O (Note 2) Length 1 2-* 1 2-* (Note 3)
NOTE 1 Mandatory if this is the first message in response to SETUP, unless the user accepts the D-channel indicated in the SETUP message. NOTE 2 Included if the network provides information that can be presented to the user. NOTE 3 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets.
3.3.2
CALL PROCEEDING
This message is sent by the called user to the network or by the network to the calling user to indicate that requested call establishment has been initiated and no more call establishment information will be accepted. See Table 3-36. Table 3-36/Q.931 CALL PROCEEDING message content
Message type: CALL PROCEEDING Significance: Local Direction: Both Information element Protocol discriminator Call reference Message type Channel identification Display Reference (subclause) 4.2 4.3 4.4 4.5 4.5 Direction Both Both Both Both nu Type M M M O (Note 1) O (Note 2) Length 1 2-* 1 2-* (Note 3)
NOTE 1 Mandatory in the network-to-user direction if this message is the first message in response to a SETUP. Mandatory in the user-to-network direction if this message is the first message in response to a SETUP, unless the user accepts the D-channel indicated in the SETUP message. NOTE 2 Included if the network provides information that can be presented to the user. NOTE 3 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets.
(05/98)
37
3.3.3
CONGESTION CONTROL
This message is sent by the network or the user to indicate the establishment or termination of flow control on the transmission of USER INFORMATION messages. See Table 3-37. Table 3-37/Q.931 CONGESTION CONTROL message content
Message type: CONGESTION CONTROL Significance: Local (Note 1) Direction: Both Information element Protocol discriminator Call reference Message type Congestion level Cause Display Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 Direction Both Both Both Both Both nu Type M M M M M O (Note 2) Length 1 2-* 1 1 4-32 (Note 3)
NOTE 1 This message has local significance, but may carry information of global significance. NOTE 2 Included if the network provides information that can be presented to the user. NOTE 3 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets.
3.3.4
CONNECT
This message is sent by the called user to the network, and by the network to the calling user, to indicate call acceptance by the called user. See Table 3-38. Table 3-38/Q.931 CONNECT message content
Message type: CONNECT Significance: Local Direction: Both Information element Protocol discriminator Call reference Message type Channel identification Display Reference (subclause) 4.2 4.3 4.4 4.5 4.5 Direction Both Both Both un nu Type M M M O (Note 1) O (Note 2) Length 1 2-* 1 2-* (Note 3)
NOTE 1 Mandatory if this is the first message in response to a SETUP, unless the user accepts the D-channel indicated in the SETUP message. NOTE 2 Included if the network provides information that can be presented to the user. NOTE 3 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets.
38
(05/98)
3.3.5
CONNECT ACKNOWLEDGE
This message is sent by the network to the called user to indicate that the user has been awarded the call. It may also be sent by the calling user to the network to allow symmetrical call control procedures. See Table 3-39. Table 3-39/Q.931 CONNECT ACKNOWLEDGE message content
Message type: CONNECT ACKNOWLEDGE Significance: Local Direction: Both Information element Protocol discriminator Call reference Message type Display Reference (subclause) 4.2 4.3 4.4 4.5 Direction Both Both Both nu Type M M M O (Note 1) Length 1 2-* 1 (Note 2)
3.3.6
INFORMATION
This message is sent by the user or the network to provide additional information. It may be used to provide information for call establishment (e.g. overlap sending and receiving) or miscellaneous callrelated information. See Table 3-40. Table 3-40/Q.931 INFORMATION message content
Message type: INFORMATION Significance: Local (Note 1) Direction: Both Information element Protocol discriminator Call reference Message type Sending complete Cause Display Keypad facility Called party number Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 4.5 4.5 Direction Both Both Both Both nu nu un Both Type M M M O (Note 2) O (Note 3) O (Note 4) O (Note 6) O (Note 7) Length 1 2-* 1 1 2-32 (Note 5) 2-34 2-*
(05/98)
39
Table 3-40/Q.931 INFORMATION message content (concluded)

NOTE 1 This message has local significance, but may carry information of global significance. NOTE 2 Included when the user optionally indicates completion of overlap sending to the network, or if the network optionally indicates completion of overlap receiving to the user. NOTE 3 Included when the network optionally conveys additional information pertaining to user-user signalling (see clause 7). NOTE 4 Included if the network provides information that can be presented to the user. NOTE 5 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets. NOTE 6 Either the Called party number or the Keypad facility information element is included by the user to convey called party number information to the network during overlap sending. NOTE 7 The Called party number information element is included by the network to convey called party number information to the user during overlap receiving.
3.3.7
RELEASE
This message is sent by the user or the network 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. See Table 3-41. Table 3-41/Q.931 RELEASE message content
Message type: RELEASE Significance: Local (Note 1) Direction: Both Information element Protocol discriminator Call reference Message type Cause Display Reference (subclause) 4.2 4.3 4.4 4.5 4.5 Direction Both Both Both Both nu Type M M M O (Note 2) O (Note 3) Length 1 2-* 1 2-32 (Note 4)
NOTE 1 This message has local significance; however, it may carry information of global significance when used as the first call clearing message. NOTE 2 Mandatory in the first call clearing message, including when the RELEASE message is sent as a result of an error handling condition. NOTE 3 Included if the network provides information that can be presented to the user. NOTE 4 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets.
3.3.8
RELEASE COMPLETE
This message is sent by the user or the network to indicate that the equipment sending the message has released the channel (if any) and call reference. The channel is available for reuse, and the receiving equipment shall release the call reference. See Table 3-42.
40
(05/98)
Table 3-42/Q.931 RELEASE COMPLETE message content

Message type: RELEASE COMPLETE Significance: Local (Note 1) Direction: Both Information element Protocol discriminator Call reference Message type Cause Display Reference (subclause) 4.2 4.3 4.4 4.5 4.5 Direction Both Both Both Both nu Type M M M O (Note 2) O (Note 3) Length 1 2-* 1 2-32 (Note 4)
NOTE 1 This message has local significance; however, it may carry information of global significance when used as the first call clearing message. NOTE 2 Mandatory in the first call clearing message, including when the RELEASE message is sent as a result of an error handling condition. NOTE 3 Included if the network provides information that can be presented to the user. NOTE 4 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets.
3.3.9
SETUP
This message is sent by the calling user to the network and by the network to the called user to initiate call establishment. See Table 3-43. Table 3-43/Q.931 SETUP message content
Message type: SETUP Significance: Global Direction: Both Information element Protocol discriminator Call reference Message type Sending complete Bearer capability Channel identification Network-specific facility Display Keypad facility Calling party number Calling party subaddress Called party number Called party subaddress Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 Direction Both Both Both Both Both Both Both nu un Both Both Both Both Type M M M O (Note 1) M (Note 2) M O (Note 3) O (Note 4) O (Note 6) O (Note 7) O (Note 8) O (Note 9) O (Note 10) Length 1 2-* 1 1 6-8 3-* 2-* (Note 5) 2-34 2-* 2-23 2-* 2-23
(05/98)
41

Message type: SETUP Significance: Global Direction: Both Information element Transit network selection Low layer compatibility High layer compatibility Reference (subclause) 4.5 4.5 4.5 Direction un Both Both Type O (Note 11) O (Note 12) O (Note 13) Length 2-* 2-18 2-5
NOTE 1 Included if the user or the network optionally indicates that all information necessary for call establishment is included in the SETUP message. NOTE 2 The Bearer capability and Low layer compatibility information elements may be used to describe an ITU-T telecommunication service, if appropriate. NOTE 3 Included by the calling user or the network to indicate network-specific facilities information (see Annex E). NOTE 4 Included if the network provides information that can be presented to the user. NOTE 5 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets. NOTE 6 Either the Called party number or the Keypad facility information element is included by the user to convey called party number information to the network during overlap sending. The Keypad facility information element may also be included by the user to convey other call establishment information to the network. NOTE 7 May be included by the calling user or the network to identify the calling user. NOTE 8 Included in the user-to-network direction when the calling user wants to indicate the calling party subaddress. Included in the network-to-user direction if the calling user included a Calling party subaddress information element in the SETUP message. NOTE 9 Either the Called party number or the Keypad facility information element is included by the user to convey called party number information to the network during overlap sending. The Called party number information element is included by the network when called party number information is conveyed to the user. NOTE 10 Included in the user-to-network direction when the calling user wants to indicate the called party subaddress. Included in the network-to-user direction if the calling user included a Called party subaddress information element in the SETUP message. NOTE 11 Included by the calling user to select a particular transit network (see Annex C). NOTE 12 Included in the user-to-network direction when the calling user wants to pass low layer compatibility information to the called user. Included in the network-to-user direction if the calling user included a Low layer compatibility information element in the SETUP message. NOTE 13 Included in the user-to-network direction when the calling user wants to pass high layer compatibility information to the called user. Included in the network-to-user direction if the calling user included a High layer compatibility information element in the SETUP message.
42
(05/98)
3.3.10 SETUP ACKNOWLEDGE This message is sent by the network to the calling user, or by the called user to the network, to indicate that call establishment has been initiated but additional information may be required. See Table 3-44. Table 3-44/Q.931 SETUP ACKNOWLEDGE message content
Message type: SETUP ACKNOWLEDGE Significance: Local Direction: Both Information element Protocol discriminator Call reference Message type Channel identification Display Reference (subclause) 4.2 4.3 4.4 4.5 4.5 Direction Both Both Both Both nu Type M M M O (Note 1) O (Note 2) Length 1 2-* 1 2-* (Note 3)
NOTE 1 Mandatory in all cases, except when the user accepts the D-channel indicated in the SETUP message. NOTE 2 Included if the network provides information that can be presented to the user. NOTE 3 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets.
3.3.11 STATUS This message is sent by the user or the network in response to a STATUS ENQUIRY message or at any time during a call to report certain error conditions listed in 5.8. See Table 3-45. Table 3-45/Q.931 STATUS message content
Message type: STATUS Significance: Local Direction: Both Information element Protocol discriminator Call reference Message type Cause Call state Display Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 Direction Both Both Both Both Both nu Type M M M M M O (Note 1) Length 1 2-* 1 4-32 3 (Note 2)
(05/98)
43
3.3.12 STATUS ENQUIRY This message is sent by the user or the network at any time to solicit a STATUS message from the peer layer 3 entity. Sending a STATUS message in response to a STATUS ENQUIRY message is mandatory. See Table 3-46. Table 3-46/Q.931 STATUS ENQUIRY message content
3.3.13 USER INFORMATION This message is sent by the user to the network to transfer information to the remote user. This message is also sent by the network to the user to deliver information from the other user. See Table 3-47. Table 3-47/Q.931 USER INFORMATION message content
Message type: USER INFORMATION Significance: Access Direction: Both Information element Protocol discriminator Call reference Message type More data User-user Reference (subclause) 4.2 4.3 4.4 4.5 4.5 Direction Both Both Both Both Both Type M M M O (Note) M Length 1 2-* 1 1 2-255
NOTE Included by the sending user to indicate that another USER INFORMATION message pertaining to the same message block will follow.
44
(05/98)
3.4
Messages with the global call reference
Table 3-48 summarizes the messages which may use the global call reference defined in 4.3. Table 3-48/Q.931 Messages used with the global call reference
Messages RESTART RESTART ACKNOWLEDGE STATUS Reference (subclause) 3.4.1 3.4.2 3.4.3
3.4.1
RESTART
This message is sent by the user or network to request the recipient to restart (i.e. return to an idle condition) the indicated channel(s) or interface. See Table 3-49. Table 3-49/Q.931 RESTART message content
Message type: RESTART Significance: Local Direction: Both Information element Protocol discriminator Call reference Message type Channel identification Display Restart indicator Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 Direction Both Both Both Both nu Both Type M M (Note 1) M O (Note 2) O (Note 3) M Length 1 2-* 1 2-* (Note 4) 3
NOTE 1 This message is sent with the global call reference defined in 4.3. NOTE 2 Included when necessary to indicate the particular channel(s) to be restarted. NOTE 3 Included if the network provides information that can be presented to the user. NOTE 4 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets.
(05/98)
45
3.4.2
RESTART ACKNOWLEDGE
This message is sent to acknowledge the receipt of the RESTART message and to indicate that the requested restart is complete. See Table 3-50. Table 3-50/Q.931 RESTART ACKNOWLEDGE message content
Message type: RESTART ACKNOWLEDGE Significance: Local Direction: Both Information element Protocol discriminator Call reference Message type Channel identification Display Restart indicator Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 Direction Both Both Both Both nu Both Type M M (Note 1) M O (Note 2) O (Note 3) M Length 1 2-* 1 2-* (Note 4) 3
NOTE 1 This message is sent with the global call reference defined in 4.3. NOTE 2 Included when necessary to indicate the particular channel(s) which have been restarted. May be repeated in the case of non-associated signalling that controls two or more interfaces. NOTE 3 Included if the network provides information that can be presented to the user. NOTE 4 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets.
3.4.3
STATUS
This message is sent by the user or the network at any time during a call to report certain error conditions listed in 5.8. See Table 3-51. Table 3-51/Q.931 STATUS message content
Message type: STATUS Significance: Local Direction: Both Information element Protocol discriminator Call reference Message type Cause Call state Display Reference (subclause) 4.2 4.3 4.4 4.5 4.5 4.5 Direction Both Both Both Both Both nu Type M M (Note 1) M M M O (Note 2) Length 1 2-* 1 4-32 3 (Note 3)
NOTE 1 This message may be sent with the global call reference defined in 4.3. NOTE 2 Included if the network provides information that can be presented to the user. NOTE 3 The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets.
46
(05/98)
General message format and information elements coding
The figures and text in this clause describe message contents. Within each octet, the bit designated "bit 1" is transmitted first, followed by bits 2, 3, 4, etc. Similarly, the octet shown at the top of each figure is sent first. 4.1 a) b) c) d) Overview protocol discriminator; call reference; message type; other information elements, as required.
Within this protocol, every message shall consist of the following parts:
Information elements a), b) and c) are common to all the messages and shall always be present, while information element d) is specific to each message type. This organization is illustrated in the example shown in Figure 4-1. A particular message may contain more information than a particular (user or network) equipment needs or can understand. All equipment should be able to ignore any extra information, present in a message, which is not required for the proper operation of that equipment. For example, a user may ignore the calling party number if that number is of no interest to the user when a SETUP message is received.
8 0 0 7 0 5 4 3 2 1 Protocol discriminator 0 0 Length of call reference value (in octets) Call reference value Message type Other information elements as required 6 Octet 1 2 3 etc.
Figure 4-1/Q.931 General message organization example
Unless specified otherwise, a particular information element may be present only once in a given message. The term "default" implies that the value defined should be used in the absence of any assignment, or the 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. 4.2 Protocol discriminator
The purpose of the protocol discriminator is to distinguish messages for user-network call control from other messages (to be defined). It also distinguishes messages of this Recommendation from those OSI network layer protocol units which are coded to other ITU-T Recommendations and other standards.
NOTE A protocol discriminator field is also included in the User-user information element to indicate the user protocol within the user information; however, the coding of the protocol discriminator in this case is shown in 4.5.30.
(05/98)
47
The protocol discriminator is the first part of every message. The protocol discriminator is coded according to Table 4-1.
8 0 7 6 5 4 3 2 Q.931/I.451 user-network call control messages protocol discriminator 0 0 0 1 0 0 1 0 Octet 1
Figure 4-2/Q.931 Protocol discriminator
Table 4-1/Q.931 Protocol discriminator

Bits 87654321 00000000 through 00000111 00001000 00001001 00010000 through 00111111 01000000 through 01001111 01010000 through 11111110 Assigned in 4.5.30; not available for use in the message protocol discriminator
Recommendation Q.931/I.451 user-network call control messages Recommendation Q.2931 user-network call control messages Reserved for other network layer or layer 3 protocols, including Recommendation X.25 [5] (Note) National use
Reserved for other network layer or layer 3 protocols, including Recommendation X.25 (Note)
All other values are reserved. NOTE These values are reserved to discriminate these protocol discriminators from the first octet of an X.25 packet including general format identifier.
4.3
Call reference
The purpose of the call reference is to identify the call or facility registration/cancellation request at the local user-network interface to which the particular message applies. The call reference does not have end-to-end significance across ISDNs. The call reference is the second part of every message. The call reference is coded as shown in Figure 4-3. The length of the call reference value is indicated in octet 1, bits 1-4. The default maximum length of the call reference information element is three octets long. 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. At a minimum, all networks and users must be able to support a call reference value of one octet for a basic user-network interface, and a call reference value of two octets for a primary rate interface. As a network option for a primary rate interface, the call reference value may be one octet also. In this case, a call reference value up to 127 may be sent in one or two octets. The call reference information element includes the call reference value and the call reference flag.
48
(05/98)
Call reference values are assigned by the originating side of the interface for a call. These values are unique to the originating side only within a particular D-channel layer two logical link connection. The call reference value is assigned at the beginning of a call and remains fixed for the lifetime of a call (except in the case of call suspension). After a call ends, or, after a successful suspension, the associated call reference value may be reassigned to a later call. Two identical call reference values on the same D-channel layer two logical link connection may be used when each value pertains to a call originated at opposite ends of the link.
8 0 Flag 7 0 6 0 5 0 4 3 2 1 Length of call reference value (in octets) Octet 1 2 etc.
Call reference value NOTE For call reference flag (octet 2) Bit 8 The message is sent from the side that originates the call reference 0 1 The message is sent to the side that originates the call reference
Figure 4-3/Q.931 Call reference information element
The call reference flag can take the values "0" or "1". The call reference flag is used to identify which end of the layer two-logical link originated a call reference. The origination side always sets the call reference flag to "0". The destination side always sets the call reference flag to a "1". Hence the call reference flag identifies who allocated the call reference value for this call, and the only purpose of the call reference flag is to resolve simultaneous attempts to allocate the same call reference value. The call reference flag also applies to functions which use the global call reference (e.g. restart procedures).
NOTE 1 The call reference information element containing a dummy call reference is one octet long and is coded "0000 0000". The use of the dummy call reference is specified in Recommendation Q.932. NOTE 2 The numerical value of the global call reference is zero. The equipment receiving a message containing the global call reference should interpret the message as pertaining to all call references associated with the appropriate data link connection identifier. See Figure 4-5.
8 0 7 0 6 0 5 0 4 3 2 1 Length of call reference value 0 0 0 0 Octet 1
Figure 4-4/Q.931 Dummy call reference
(05/98)
49
8 0 Flag 0/1
7 0 0 a)
6 0 0
3 2 1 Length of call reference value 0 0 0 0 1 Call reference value 0 0 0 0 0 One-octet call reference value
Octet 1 2
8 0 Flag 0/1 0
7 0 0 0 b)
6 0 0 0
3 2 Length of call reference value 0 0 0 1 Call reference value 0 0 0 0 0 0 0 0 Two-octet call reference value
1 0 0 0
Octet 1 2 3
Figure 4-5/Q.931 Examples of the encoding for global call reference
4.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. The message type is coded as shown in Figure 4-6 and Table 4-2. Bit 8 is reserved for possible future use as an extension bit.
8 0 7 6 5 4 Message type 3 2 1 Octet 1
Figure 4-6/Q.931 Message type
50
(05/98)
Table 4-2/Q.931 Message types

Bits 8 7 0 0 0 0 5 4 3 2 1 0 0 0 0 0 Escape to nationally specific message type (Note) - - - - Call establishment message: 0 0 0 0 1 ALERTING 0 0 0 1 0 CALL PROCEEDING 0 0 1 1 1 CONNECT 0 1 1 1 1 CONNECT ACKNOWLEDGE 0 0 0 1 1 PROGRESS 0 0 1 0 1 SETUP 0 1 1 0 1 SETUP ACKNOWLEDGE 0 0 1 - - - - Call information phase message: 0 0 1 1 0 RESUME 0 1 1 1 0 RESUME ACKNOWLEDGE 0 0 0 1 0 RESUME REJECT 0 0 1 0 1 SUSPEND 0 1 1 0 1 SUSPEND ACKNOWLEDGE 0 0 0 0 1 SUSPEND REJECT 0 0 0 0 0 USER INFORMATION 0 1 0 - - - - Call clearing messages: 0 0 1 0 1 DISCONNECT 0 1 1 0 1 RELEASE 1 1 0 1 0 RELEASE COMPLETE 0 0 1 1 0 RESTART 0 1 1 1 0 RESTART ACKNOWLEDGE 0 1 1 - - - - Miscellaneous messages: 0 0 0 0 0 SEGMENT 1 1 0 0 1 CONGESTION CONTROL 1 1 0 1 1 INFORMATION 0 1 1 1 0 NOTIFY 1 1 1 0 1 STATUS 1 0 1 0 1 STATUS ENQUIRY NOTE When used, the message type is defined in the following octet(s), according to the national specification 6 0 0
4.5 4.5.1
Other information elements Coding rules
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 important to that equipment. Two categories of information elements are defined: a) b) single-octet information elements [see diagrams a) and b) of Figure 4-7]; variable length information elements [see diagram c) of Figure 4-7].
(05/98)
51
8 1
7 6 5 Information element identifier a)
3 2 1 Contents of information element
Octet 1
Single octet information element format (type 1) 6 5 4 3 Information element identifier 2 1 Octet 1
8 1
7 b)
Single octet information element format (type 2) 5 4 3 Information element identifier Length of contents of information element (octets) Contents of information element c) Variable length information element format 6 2 1 Octet 1 2 3 etc.
8 0
Figure 4-7/Q.931 Formats of information elements
For the information elements listed below, the coding of the information element identifier bits is summarized in Table 4-3. Table 4-3/Q.931 Information element identifier coding
Reference subclause Bits 87654321 1: : : - - - 000 - - - 001 - - - 0100000 0100001 011 - - - 101 - - - 0 : : : : : :: 0000000 0000100 0001000 0010000 0010100 0011000 0011110 0100000 0100111 0101000 0101001 Maximum length (octets) (Note 1)
Single octet information elements: Reserved Shift (Note 2) More data Sending complete Congestion level Repeat indicator Variable length information element: Segmented message Bearer capability (Note 2) Cause (Note 2) Call identity Call state Channel identification (Note 2) Progress indicator (Note 2) Network-specific facilities (Note 2) Notification indicator Display Date/time 4.5.26 4.5.5 4.5.12 4.5.6 4.5.7 4.5.13 4.5.23 4.5.21 4.5.22 4.5.16 4.5.15 4 12 32 10 3 (Note 4) 4 (Note 4) 3 34/82 8 4.5.3/4.5.4 4.5.20 4.5.27 4.5.14 4.5.24 1 1 1 1 1
52
(05/98)
Table 4-3/Q.931 Information element identifier coding (concluded)

Reference subclause Bits 87654321 0101100 0110100 1000000 1000010 1000011 1000100 1000101 1000110 1000111 1001010 1101100 1101101 1110000 1110001 1110100 1111000 1111001 1111100 1111101 1111110 1111111 Maximum length (octets) (Note 1)
Keypad facility Signal (Note 2) Information rate End-to-end transit delay Transit delay selection and indication Packet layer binary parameters Packet layer window size Packet size Closed user group Reverse charging indication Calling party number Calling party subaddress Called party number Called party subaddress Redirecting number Transit network selection (Note 2) Restart indicator Low layer compatibility (Note 2) High layer compatibility (Note 2) User-user Escape for extension (Note 3)
4.5.18 4.5.28 4.6.3 4.6.2 4.6.9 4.6.4 4.6.5 4.6.6 4.6.1 4.6.8 4.5.10 4.5.11 4.5.8 4.5.9 4.6.7 4.5.29 4.5.25 4.5.19 4.5.17 4.5.30
34 3 6 11 5 3 4 4 7 3 (Note 4) 23 (Note 4) 23 (Note 4) (Note 4) 3 18 5 35/131
All other values are reserved (Note 5) NOTE 1 The length limits described for the variable length information elements take into account only the present ITU-T standardized coding values. Future enhancements and expansions to this Recommendation will not be restricted to these limits. NOTE 2 This information element may be repeated. NOTE 3 This escape mechanism is limited to codesets 4, 5, 6 and 7 (see 4.5.2). When the escape for extension is used, the information element identifier is contained in octet-group 3 and the content of the information element follows in the subsequent octets as shown in Figure 4-8. NOTE 4 The maximum length is network dependent. NOTE 5 The reserved values with bits 5-8 coded "0000" are for future information elements for which comprehension by the receiver is required (see 5.8.7.1).
The descriptions of the information elements below are organized in alphabetical order. However, there is a particular order of appearance for each information element in a message within each codeset (see 4.5.2). 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.
(05/98)
53
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. Where the description of information elements in this Recommendation contains spare bits, these bits are indicated as being set to "0". In order to allow compatibility with future implementation, messages should not be rejected simply because a spare bit is set to "1". The second octet of a variable length information element indicates the total length of the contents of that information element regardless of the coding of the first octet (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 called 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 variable length information elements (octets 3, etc.): a) b) c) The first digit in the octet number identifies one octet or a group of octets. Each octet group is a self-contained entity. The internal structure of an octet group may be defined in alternative ways. An octet group is formed by using some extension mechanism. The preferred extension mechanism is to extend an octet (N) through the next octet(s) (Na, Nb, etc.) by using bit 8 in each octet as an extension bit. The bit value "0" indicates that the octet continues through the next octet. The bit value "1" indicates that this octet is the last octet. If one octet (Nb) is present, also the preceding octets (N and Na) must be present. In the format descriptions appearing in 4.5.5 etc., bit 8 is marked "0/1 ext." if another octet follows. Bit 8 is marked "1 ext." if this is the last octet in the extension domain. 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) e) In addition to the extension mechanism defined above, an octet (N) may be extended through the next octet(s) (N1, N2 etc.) by indications in bits 7-1 (of octet N). The mechanisms in c) and d) may be combined. Mechanism c) shall take priority in the ordering, such that all octets Na, Nb, etc. shall occur before octets N1, N2, etc. This rule shall apply even where the extension to octets N1, N2, etc. is indicated in one of octet Na, Nb, etc. Similar conventions apply even when mechanism d) is being repeated, i.e. octets N.1 shall occur before octets N.1.1, N.1.2, etc. Optional octets are marked with asterisks (*).
f) g)
NOTE 1 It is not possible to use mechanism c) repeatedly, i.e. it is not possible to construct an octet 4a as this would become octet 4b. NOTE 2 Protocol designers should exercise care in using multiple extension mechanisms to ensure that a unique interpretation of the resultant coding is possible. NOTE 3 For a number of information elements, there is a field that defines the coding standard. When the coding standard defines a national standard, it is recommended that the national standard be structured similar to the information element defined in this Recommendation.
54
(05/98)
8 0 ext. 1
7 1
4 3 Escape for extension 1 1 1 1 Length of information element contents Information element identifier Contents of information element
2 1
1 1
Octet 1 2 3 4 etc.
Figure 4-8/Q.931 Information element format using escape for extension
4.5.2
Extensions of codesets
There is a certain number of possible information element identifier values using the formatting rules described in 4.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 shift operations described below. One other value in both the single octet and variable 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 supported: locking shift and non-locking shift. Codeset 4 is reserved for use by ISO/IEC Standards. Codeset 5 is reserved for information elements reserved for national use. Codeset 6 is reserved for information elements specific to the local network (either public or private). Codeset 7 is reserved for user-specific information elements. The coding rules specified in 4.5.1 shall apply for information elements belonging to any active codeset. Transitions 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 codesets 4, 5, 6, or 7 may appear together with information elements belonging to codeset 0 (being the active codeset) by using the non-locking shift procedure (see 4.5.4). A user of network equipment shall have the capability to recognize a Shift information element and to determine the length of the following information element, although the equipment need not be able to interpret and act upon the content of the information element. This enables the equipment to determine the start of a subsequent information element. Codeset 7 information element shall be handled according to the procedures for unrecognized information elements (see 5.8.7.1) by the first exchange in the local network, unless allowed by a future service definition, bilateral agreement, or provision is made to support this across the local network for a specific user.
(05/98)
55
Codeset 6 is reserved for information elements specific to the local network (either public or private). As such they do not have significance across the boundaries between local networks, or across a national, or international boundary. Therefore, codeset 6 information elements shall be handled according to the procedures for unrecognized information elements (see 5.8.7.1) beyond local network boundary, unless allowed by bilateral agreement. Codeset 5 is reserved for information elements reserved for national use. As such they do not have significance across an international boundary. Therefore, codeset 5 information elements shall be handled according to the procedures for unrecognized information elements (see 5.8.7.1) at the first exchange beyond the international boundary, unless there are bilateral agreements to the contrary. Codeset 4 is reserved for information elements specified in ISO/IEC Standards. 4.5.3 Locking shift procedure
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 codeset 5 is encountered, the next information elements will be interpreted according to the information element identifiers assigned in codeset 5, until another shift information element is encountered. This procedure is used only to shift to a higher order codeset than the one being left. The locking shift is valid only within that message which 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 coding shown in Figure 4-9 and Table 4-4. 4.5.4 Non-locking shift procedure
The non-locking shift procedure provides a temporary shift to the specified lower or higher codeset. The non-locking shift procedure uses a single octet information element to indicate the codeset to be used to interpret the next single information element. After the interpretation of the next single 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 nonlocking shift to codeset 6 is encountered, only the next information element is interpreted according to the information element identifiers assigned in codeset 6. After this information element is interpreted, 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.
8 1 7 0 6 Shift identifier 0 5 1 4 0 3 2 1 Octet 1
New codeset identification
"0" in this position indicates locking shift
Figure 4-9/Q.931 Locking Shift information element
56
(05/98)
Table 4-4/Q.931 Locking Shift information element

Codeset identification (bits 3 to 1) Bits 321 000 Not applicable 001 to Reserved 011 100 Codeset 4: information elements for ISO/IEC use 101 110 111 Codeset 5: information elements for national use Codeset 6: information elements specific to the local network (either public or private) Codeset 7: user-specific information elements
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 non-locking Shift information element uses the single octet information element format and coding shown in Figure 4-10 and Table 4-5.
8 1 7 0 6 Shift identifier 0 5 1 4 1 3 2 1 Temporary codeset identification Octet 1
"1" in this position indicates non-locking shift
Figure 4-10/Q.931 Non-locking Shift information element
Table 4-5/Q.931 Non-locking Shift information element

Codeset identification (bits 3 to 1) Bits 321 000 Codeset 0 (initially active): Q.931 information elements 001 to Reserved 011 100 Codeset 4: information elements for ISO/IEC use 101 110 111 Codeset 5: information elements for national use Codeset 6: information elements specific to the local network (either public or private) Codeset 7: user-specific information elements
(05/98)
57
4.5.5
Bearer capability
The purpose of the Bearer capability information element is to indicate a requested I.231 [6] bearer service to be provided by the network. It contains only information which may be used by the network (see Annex I). The use of the Bearer capability information element in relation to compatibility checking is described in Annex B. The Bearer capability information element is coded as shown in Figure 4-11 and Table 4-6. No default bearer capability may be assumed by the absence of this information element. The maximum length of this information element is 12 octets.
NOTE Future extensions to the codings of the Bearer capability information element should not be in conflict with the initially defined coding of the Low layer compatibility information element. See 4.5.19.
8 0 ext. 1 ext. 1 ext. 1 ext. 0/1 ext. 0/1 ext. 0/1 ext. 0/1 ext. 0/1 ext. 1 ext. 1 ext. 0 ext. 0 ext. 1 7 0 6 0 5 4 3 2 Bearer capability information element identifier 0 0 1 0 Length of the bearer capability contents Information transfer capability Information transfer rate Rate multiplier Layer 1 ident. 0 1 Synch./ Negot. asynch Intermediate rate User information layer 1 protocol User rate NIC on Tx NIC on Rx Flow control on Tx Assignor/ee Flow control on Rx In-band neg. Parity Spare 0 Spare 0 1 0 Octet 1 2 3 4 4.1* (Note 1) 5* 5a* (Note 2) 5b* (Note 3) 5b* (Note 4) 5c* (Note 2) 5d* (Note 2) 6* 7* 7a* (Note 5) 7b* (Note 5)
Coding standard Transfer mode
Hdr/ no Hdr
Multiframe
Mode
LLI negot.
Number of stop bits Duplex mode Layer 2 ident. 1 0 Layer 3 ident. 1 1 Spare 0 0 Spare 0 0
Number of data bits Modem type
User information layer 2 protocol User information layer 3 protocol Additional layer 3 protocol information (most significant bits) Additional layer 3 protocol information (most significant bits)
0 0
NOTE 1 This octet is required if octet 4 indicates multirate (64 kbit/s base rate). Otherwise, it shall not be present. NOTE 2 This octet may be present if octet 3 indicates unrestricted digital information and octet 5 indicates either of the ITU-T standardized rate adaptions V.110, I.460 and X.30 or V.120 [9]. It may also be present if octet 3 indicates 3.1 kHz audio and octet 5 indicates G.711. NOTE 3 This structure of octet 5b only applies if octet 5 indicates ITU-T standardized rate adaption (see Recommendations V.110 [7], I.460 [15] and X.30 [8]). NOTE 4 This structure of octet 5b only applies if octet 5 indicates ITU-T standardized rate adaption (see Recommendation V.120 [9]). NOTE 5 This octet may be included if octet 7 indicates ISO/IEC TR 9577 (Protocol Identification in the network layer).
Figure 4-11/Q.931 Bearer capability information element
58
(05/98)
Table 4-6/Q.931 Bearer capability information element

Coding standard (octet 3) Bits 7 6 0 0 ITU-T standardized coding as described below 0 1 ISO/IEC Standard (Note 1) 1 0 National standard (Note 1) 1 1 Standard defined for the network (either public or private) present on the network side of the interface (Note 1) NOTE 1 These other coding standards should be used only when the desired bearer capability cannot be represented with the ITU-T-standardized coding. 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 0 1 0 0 1 Restricted digital information 1 0 0 0 0 3.1 kHz audio 1 0 0 0 1 Unrestricted digital information with tones/announcements (Note 2) 1 1 0 0 0 Video All other values are reserved. NOTE 2 Unrestricted digital information with tones/announcements (UDI-TA) is the new information transfer attribute value that had previously been named "7 kHz audio" in Recommendation Q.931 (1988). Transfer mode (octet 4) Bits 7 6 0 0 Circuit mode 1 0 Packet mode All other values are reserved. Information transfer rate (octet 4 , bits 5 to 1) Bits 5 4 3 2 1 Circuit mode Packet-mode 0 0 0 0 0 This code shall be used for packet-mode calls 1 0 0 0 0 64 kbit/s 1 0 0 0 1 2 64 kbit/s 1 0 0 1 1 384 kbit/s 1 0 1 0 1 1536 kbit/s 1 0 1 1 1 1920 kbit/s 1 1 0 0 0 Multirate (64 kbit/s base rate) All other values are reserved. NOTE 3 When the information transfer rate 2 64 kbit/s is used, the coding of octets 3 and 4 refer to both 64 kbit/s channels. NOTE 4 Additional attributes are defined in Table 4-7. Rate multiplier (octet 4.1) NOTE 5 Coded as a binary representation of the multiplier to the base rate. The multiplier can take any value from 2 up to the maximum number of B-channels available on the interface.
(05/98)
59
Table 4-6/Q.931 Bearer capability information element (continued)

User information layer 1 protocol (octet 5) Bits 5 4 3 2 1 0 0 0 0 1 ITU-T standardized rate adaption V.110, I.460 and X.30. This implies the presence of octet 5a and optionally octets 5b, 5c and 5d as defined below 0 0 0 1 0 Recommendation G.711 [10] -law 0 0 0 1 1 Recommendation G.711 A-law 0 0 1 0 0 Recommendation G.721 [11] 32 kbit/s ADPCM and Recommendation I.460 0 0 1 0 1 Recommendations H.221 and H.242 0 0 1 1 0 Recommendations H.223 [92] and H.245 [93] 0 0 1 1 1 Non-ITU-T standardized rate adaption. This implies the presence of octet 5a and, optionally, octets 5b, 5c and 5d. The use of this codepoint indicates that the user rate specified in octet 5a is defined by the user. Additionally, octets 5b, 5c and 5d, if present, are defined in accordance with the user specified rate adaption 0 1 0 0 0 ITU-T standardized rate adaption V.120 [9]. This implies the presence of octets 5a and 5b as defined below, and optionally octets 5c and 5d 0 1 0 0 1 ITU-T standardized rate adaption X.31 [14] HDLC flag stuffing All other values are reserved. NOTE 6 If the transfer mode is "circuit mode", and if the information transfer capability is "unrestricted digital information" or "restricted digital information", and if the user information layer 1 protocol is to be identified only to the addressed entity octet 5 shall be omitted. If the transfer mode is packet mode, octet 5 may be omitted. Otherwise, octet 5 shall be present. Synchronous/Asynchronous (octet 5a) Bit 7 0 Synchronous data 1 Asynchronous data NOTE 7 Octets 5b-5d may be omitted in the case of synchronous user rates. Negotiation (octet 5a) Bit 6 0 In-band negotiation not possible 1 In-band negotiation possible NOTE 8 See Recommendations V.110 [7], I.460 [15] and X.30 [8] or modem type Recommendation. User rate (octet 5a) Bits 5 4 3 2 1 0 0 0 0 0 For I.460, rate is specified by bits 7, 6 of octet 5b, intermediate rate. For V.110 and X.30, rate is indicated by E-bits (synchronous data only) or may be negotiated in-band. For V.120, rate is unspecified or may be negotiated in-band. 0 0 0 0 1 0.6 kbit/s Recommendation X.1 [17] 0 0 0 1 0 1.2 kbit/s 0 0 0 1 1 2.4 kbit/s Recommendation X.1 0 0 1 0 0 3.6 kbit/s 0 0 1 0 1 4.8 kbit/s Recommendation X.1 0 0 1 1 0 7.2 kbit/s 0 0 1 1 1 8 kbit/s Recommendation I.460
60
(05/98)

0 1 0 0 0 9.6 kbit/s Recommendation X.1 0 1 0 0 1 14.4 kbit/s 0 1 0 1 0 16 kbit/s Recommendation I.460 0 1 0 1 1 19.2 kbit/s 0 1 1 0 0 32 kbit/s Recommendation I.460 0 1 1 0 1 38.4 kbit/s Recommendation V.110 [87] 0 1 1 1 0 48 kbit/s Recommendations X.1 0 1 1 1 1 56 kbit/s 1 0 0 1 0 57.6 kbit/s Recommendation V.14 extended [88] 1 0 0 1 1 28.8 kbit/s Recommendation V.110 [89] 1 0 1 0 0 24 kbit/s Recommendation V.110 [89] 1 0 1 0 1 0.1345 kbit/s Recommendation X.1 1 0 1 1 0 0.100 kbit/s Recommendation X.1 1 0 1 1 1 0.075/1.2 kbit/s Recommendation X.1 (Note 9) 1 1 0 0 0 1.2/0.075 kbit/s Recommendation X.1 (Note 9) 1 1 0 0 1 0.050 kbit/s Recommendation X.1 1 1 0 1 0 0.075 kbit/s Recommendation X.1 1 1 0 1 1 0.110 kbit/s Recommendation X.1 1 1 1 0 0 0.150 kbit/s Recommendation X.1 1 1 1 0 1 0.200 kbit/s Recommendation X.1 1 1 1 1 0 0.300 kbit/s Recommendation X.1 1 1 1 1 1 12 kbit/s All other values are reserved. NOTE 9 The first rate is the transmit rate in the forward direction of the call. The second rate is the transmit rate in the backward direction of the call. Octet 5b for V.110, I.460 and X.30 rate adaption Intermediate rate (octet 5b) Bits 76 0 0 Not used 0 1 8 kbit/s 1 0 16 kbit/s 1 1 32 kbit/s Network Independent Clock (NIC) on transmission (Tx) (octet 5b) (Note 10) Bit 5 0 Not required to send data with network independent clock 1 Required to send data with network independent clock NOTE 10 Refers to transmission in the forward direction of the call. NOTE 11 See Recommendations V.110 [7], I.460 [15] and X.30 [8].
(05/98)
61

Network Independent Clock (NIC) on reception (Rx) (octet 5b) (Note 12) Bit 4 0 Cannot accept data with network independent clock (i.e. sender does not support this optional procedure). 1 Can accept data with network independent clock (i.e. sender does support this optional procedure). NOTE 12 Refers to transmission in the backward direction of the call. NOTE 13 See Recommendations V.110 [7], I.460 [15] and X.30 [8]. Flow control on transmission (Tx) (octet 5b) (Note 14) Bit 3 0 Not required to send data with flow control mechanism 1 Required to send data with flow control mechanism NOTE 14 Refers to transmission in the forward direction of the call. NOTE 15 See Recommendations V.110, I.460 and X.30. Flow control on reception (Rx) (octet 5b) (Note 16) Bit 2 0 Cannot accept data with flow control mechanism (i.e. sender does not support this optional procedure) 1 Can accept data with flow control mechanism (i.e. sender does support this optional procedure) NOTE 16 Refers to transmission in the backward direction of the call. NOTE 17 See Recommendations V.110, I.460 and X.30. Octet 5b for V.120 [9] rate adaption Rate adaption header/no header (octet 5b) Bit 7 0 Rate adaption header not included 1 Rate adaption header included Multiple frame establishment support in data link (octet 5b) Bit 6 0 Multiple frame establishment not supported. Only UI frames allowed 1 Multiple frame establishment supported Mode of operation (octet 5b) Bit 5 0 Bit transparent mode of operation 1 Protocol sensitive mode of operation Logical link identifier negotiation (octet 5b) Bit 4 0 Default, LLI = 256 only 1 Full protocol negotiation (Note 18) NOTE 18 A connection over which protocol negotiation will be executed is indicated in bit 2 of octet 5b.
62
(05/98)

Assignor/assignee (octet 5b) Bit 3 0 Message originator is "Default assignee" 1 Message originator is "Assignor only" In-band/out-band negotiation (octet 5b) Bit 2 0 Negotiation is done with USER INFORMATION messages on a temporary signalling connection 1 Negotiation is done in-band using logical link zero Number of stop bits (octet 5c) Bits 76 0 0 Not used 0 1 1 bit 1 0 1.5 bits 1 1 2 bits Number of data bits excluding parity Bit if present (octet 5c) Bits 54 0 0 Not used 0 1 5 bits 1 0 7 bits 1 1 8 bits Parity information (octet 5c) Bits 321 000 Odd 010 Even 011 None 100 Forced to 0 101 Forced to 1 All other values are reserved. Mode duplex (octet 5d) Bit 7 0 Half duplex 1 Full duplex
(05/98)
63

Modem type (octet 5d) Bits 654321 000000 through National use 000101 0 1 0 0 0 1 Recommendation V.21 [55] 0 1 0 0 1 0 Recommendation V.22 [56] 01 0 0 1 1 Recommendation V.22 bis [57] 0 1 0 1 0 0 Recommendation V.23 [58] 0 1 0 1 0 1 Recommendation V.26 [59] 0 1 0 1 1 0 Recommendation V.26 bis [60] 0 1 0 1 1 1 Recommendation V.26 ter [61] 0 1 1 0 0 0 Recommendation V.27 [62] 0 1 1 0 0 1 Recommendation V.27 bis [63] 0 1 1 0 1 0 Recommendation V.27 ter [64] 0 1 1 0 1 1 Recommendation V.29 [65] 0 1 1 1 0 1 Recommendation V.32 [66] 0 1 1 1 1 0 Recommendation V.34 [90] 100000 through National use 101111 110000 through User specified 111111 All other values reserved. User information layer 2 protocol (octet 6) Bits 54321 00010 Recommendation Q.921/I.441 [3] 00110 Recommendation X.25 [5], link layer 01100 LAN logical link control (ISO/IEC 8802-2) (Note 23) All other values are reserved. NOTE 19 If the transfer mode is "packet mode", octet 6 shall be present. For other cases, if the user layer 2 protocol is to be identified to the network, then octet 6 shall be present; otherwise octet 6 shall be omitted. User information layer 3 protocol (octet 7) Bits 54321 0 0 0 1 0 Recommendation Q.931 0 0 1 1 0 Recommendation X.25, packet layer 0 1 0 1 1 ISO/IEC TR 9577 [82] (Protocol identification in the network layer) (Notes 21 and 23) All other values are reserved. NOTE 20 If the user information layer 3 protocol is to be identified to the network, octet 7 shall be present; otherwise octet 7 shall be omitted. NOTE 21 If the user information layer 3 protocol indicates "Network layer protocol identification", octet 7a and 7b may be included to identify the actual user information layer 3 protocol to the network.
64
(05/98)
Table 4-6/Q.931 Bearer capability information element (concluded)

Octets 7a and 7b (Notes 21 and 22) Bit 8 (ext.) set to 0 in octet 7a and set to 1 in octet 7b. Bits 7 to 5 are spare (set to 0) in both octets. 7a 7b Bits Bits 4321 4321 1100 1100 Internet Protocol (RFC 791) (ISO/IEC TR 9577 [82]) 1100 1111 Point-to-point Protocol (RFC 1548) NOTE 22 If the user information layer 3 protocol indicates "Network layer protocol Identification", octet 7a and 7b may be included to identify the actual user information layer 3 protocol to the network. These codepoints are assigned consistently with ISO/IEC TR 9577 [82]. NOTE 23 These codings can only be used where transfer mode is "circuit mode".
Table 4-7/Q.931 Bearer capability attributes

BC attributes Transfer mode Circuit Circuit Circuit Circuit Circuit Information transfer capability Speech Unrestricted data Restricted data 3.1 kHz audio Structure Additional attributes Configuration Establishment Symmetry
8 kHz integrity 8 kHz integrity 8 kHz integrity 8 kHz integrity
Point-to-point Point-to-point Point-to-point Point-to-point Point-to-point
Demand Demand Demand Demand Demand
Bi-directional symmetric Bi-directional symmetric Bi-directional symmetric Bi-directional symmetric Bi-directional symmetric
Unrestricted 8 kHz integrity data with tones/ announcements Video Unrestricted data 8 kHz integrity Service data unit integrity
Circuit Packet
Point-to-point Point-to-point
Demand Demand
Bi-directional symmetric Bi-directional symmetric
NOTE 1 When the information transfer rate 2 64 kbit/s is used, 8 kHz integrity with Restricted Differential Time Delay (RDTD) is offered. NOTE 2 When multirate (64 kbit/s base rate) is indicated as the information transfer rate, Time Slot Sequence integrity shall be provided.
4.5.6
Call identity
The purpose of the Call identity information element is to identify the suspended call. The call identity provided by the user is guaranteed by the network to be unique over the user-network interface on which the user resides. The call identity is assigned at the start of the call suspension, and is available for reuse after the resume procedure has completed successfully.
(05/98)
65
The Call identity information element is coded as shown in Figure 4-12. The default maximum length of this information element is ten octets. 4.5.7 Call state
The purpose of the Call state information element is to describe the current status of a call, (see 2.1) or an access-connection (see 2.2) or a global interface state (see 2.4). The Call state information element is coded as shown in Figure 4-13 and Table 4-8. The length of this information element is three octets.
8 0 7 0 5 4 3 2 Call identity information element identifier 0 1 0 0 0 Length of call identity contents Call identity (any bit pattern allowed, e.g. IA5 characters) 6 1 0 Octet 1 2 3 etc.
Figure 4-12/Q.931 Call identity information element

8 0 Coding standard 7 0 6 0 5 4 3 2 Call state information element identifier 1 0 1 0 Length of call state contents Call state value / global interface state value (state value is coded in binary) 1 0 Octet 1 2 3
Figure 4-13/Q.931 Call state information element
Table 4-8/Q.931 Call state information element

Coding standard (octet 3) Bits 87 00 01 10 11 ITU-T standardized coding, as described below ISO/IEC standard (Note) National standard (Note) Standard defined for the network (either public or private) present on the network side of the interface (Note)
NOTE These other coding standards should only be used only when the desired call states cannot be represented by ITU-T-standardized coding.
66
(05/98)
Table 4-8/Q.931 Call state information element (concluded)

Call state value (octet 3) Bits 6 5 4 3 2 1 User State 0 0 0 0 0 0 U0 Null 0 0 0 0 0 1 U1 Call initiated 0 0 0 0 1 0 U2 Overlap sending 0 0 0 0 1 1 U3 Outgoing call proceeding 0 0 0 1 0 0 U4 Call delivered 0 0 0 1 1 0 U6 Call present 0 0 0 1 1 1 U7 Call received 0 0 1 0 0 0 U8 Connect request 0 0 1 0 0 1 U9 Incoming call proceeding 0 0 1 0 1 0 U10 Active 0 0 1 0 1 1 U11 Disconnect request 0 0 1 1 0 0 U12 Disconnect indication 0 0 1 1 1 1 U15 Suspend request 0 1 0 0 0 1 U17 Resume request 0 1 0 0 1 1 U19 Release request 010110 ----0 1 1 0 0 1 U25 Overlap receiving Global interface state value (octet 3) Bits 654321 000000 111101 111110 State REST0 Null REST1 Restart request REST2 Restart Network state N0 Null N1 Call initiated N2 Overlap sending N3 Outgoing call proceeding N4 Call delivered N6 Call present N7 Call received N8 Connect request N9 Incoming call proceeding N10 Active N11 Disconnect request N12 Disconnect indication N15 Suspend request N17 Resume request N19 Release request N22 Call abort N25 Overlap receiving
All other values are reserved.
4.5.8
Called party number
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 4-14 and Table 4-9. The maximum length of this information element is network dependent.
8 0 ext. 1 0 7 1 6 5 4 3 2 1 Called party number information element identifier 1 1 0 0 0 0 Length of called party number contents Type of number Numbering plan identification Number digits (IA5 characters) (Note) Octet 1 2 3 4 etc.
NOTE The number digits appear in multiple octet 4s in the same order in which they would be entered, that is, the number digit which would be entered first is located in the first octet 4.
Figure 4-14/Q.931 Called party number information element
(05/98)
67
Table 4-9/Q.931 Called party number information element

Type of number (octet 3) (Note 1) Bits 765 000 Unknown (Note 2) 001 International number (Note 3) 010 National number (Note 3) 011 Network specific number (Note 4) 100 Subscriber number (Note 3) 110 Abbreviated number (Note 5) 111 Reserved for extension All other values are reserved. NOTE 1 For the definition of international, national and subscriber number, see Recommendation I.330 [18]. NOTE 2 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 organized according to the network dialling plan, e.g. prefix or escape digits might be present. NOTE 3 Prefix or escape digits shall not be included. NOTE 4 The type of number "network specific number" is used to indicate administration/service number specific to the serving network, e.g. used to access an operator. NOTE 5 The support of this code is network dependent. The number provided in this information element presents a shorthand representation of the complete number in the specified numbering plan as supported by the network. Numbering plan identification (octet 3) Numbering plan (applies for type of number = 000, 001, 010 and 100) Bits 4321 0000 Unknown (Note 6) 0001 ISDN/telephony numbering plan (Recommendation E.164 [19]) 0011 Data numbering plan (Recommendation X.121 [21]) 0100 Telex numbering plan (Recommendation F.69 [22]) 1000 National standard numbering plan 1001 Private numbering plan 1111 Reserved for extension All other values are reserved. NOTE 6 The numbering plan "unknown" is used when the user or network has no knowledge of the numbering plan. In this case, the number digits field is organized according to the network dialling plan, e.g. prefix or escape digits might be present. Number digits (octets 4, etc.) This field is coded with IA5 characters, according to the formats specified in the appropriate numbering/dialling plan.
4.5.9
Called party subaddress
The purpose of the Called party subaddress information element is to identify the subaddress of the called party of the call. The network does not interpret this information. For the definition of subaddress, see Recommendation I.330 [18]. The Called party subaddress information element is coded as shown in Figure 4-15 and Table 4-10.
68
(05/98)
The maximum length of this information element is 23 octets.

8 0 ext. 1 7 6 5 4 3 2 Called party subaddress information element identifier 1 1 1 0 0 0 Length of called party subaddress contents Odd/even Type of subaddress Spare indicator 0 0 Subaddress information 1 1 Octet 1 2 3 4 etc.
Figure 4-15/Q.931 Called party subaddress information element
Table 4-10/Q.931 Called party subaddress information element

Type of subaddress (octet 3) Bits 765 000 NSAP (ITU-T Rec. X.213 [23] and ISO/IEC 8348 Add.2 [24]) 010 User specified All other values are reserved. Odd/even indicator (octet 3) Bit 4 0 Even number of address signals 1 Odd number of address signals NOTE 1 The odd/even indicator is used when the type of subaddress is "user specified" and the coding is BCD. Subaddress information (octets 4, etc.) The NSAP X.213 and ISO/IEC 8348, Add.2 address shall be formatted as specified by octet 4 which contains the Authority and Format Identifier (AFI). The encoding is made according to the "preferred binary encoding" as defined in ITU-T Rec. X.213 and ISO/IEC 8348, Add.2 except when used for Terminal selection at the S interface (see Note 3). For the definition of this type of subaddress, see Recommendation I.334 [25]. For user specified subaddress, this field is encoded according to the user specification, subject to a maximum length of 20 octets. When interworking with X.25 [5] networks, BCD coding should be applied. NOTE 2 It is recommended that users apply the NSAP subaddress type since this subaddress type allows the use of decimal, binary and IA5 syntaxes in a standardized manner. NOTE 3 It is recommended that users apply the Local IDI format (the AFI field coded 50 in BCD) when the subaddress is used for terminal selection purposes at the S interface. In this case, the IA5 character syntax using only digits 0 to 9 shall be used for the DSP. Each character is then encoded in one octet according to Recommendation T.50 and ISO/IEC 646, with zero parity in the most significant position.
4.5.10 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 4-16 and Table 4-11. The maximum length of this information element is network dependent.
(05/98)
69
8 0 ext. 0/1 ext. 1 0
7 1
6 5 4 3 2 1 Calling party number information element identifier 1 0 1 1 0 0 Length of calling party number contents Type of number Numbering plan identification Spare 0 Screening indicator
Octet 1 2 3 3a* 4*
Presentation indicator
Number digits (IA5 characters)
Figure 4-16/Q.931 Calling party number information element
Table 4-11/Q.931 Calling party number information element

Type of number (octet 3) (Note 1) Bits 765 000 Unknown (Note 2) 001 International number (Note 3) 010 National number (Note 3) 011 Network specific number (Note 4) 100 Subscriber number (Note 3) 110 Abbreviated number (Note 5) 111 Reserved for extension All other values are reserved. NOTE 1 For the definition of international, national and subscriber number, (see Recommendation I.330 [18]). NOTE 2 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 organized according to the network dialling plan; e.g. prefix or escape digits might be present. NOTE 3 Prefix or escape digits shall not be included. NOTE 4 The type of number "network specific number" is used to indicate administration/service number specific to the serving network, e.g. used to access an operator. NOTE 5 The support of this code is network dependent. The number provided in this information element presents a shorthand representation of the complete number in the specified numbering plan as supported by the network. Numbering plan identification (octet 3) Numbering plan (applies for type of number = 000, 001, 010 and 100) Bits 4321 0000 Unknown (Note 6) 0001 ISDN/telephony numbering plan (Recommendation E.164 [19]) 0011 Data numbering plan (Recommendation X.121 [21]) 0100 Telex numbering plan (Recommendation F.69 [22]) 1000 National standard numbering plan 1001 Private numbering plan 1111 Reserved for extension All other values are reserved.
70
(05/98)
Table 4-11/Q.931 Calling party number information element (concluded)

NOTE 6 The numbering plan "unknown" is used when the user or network has no knowledge of the numbering plan. In this case, the number digits field is organized according to the network dialling plan, e.g. prefix or escape digits might be present. Presentation indicator (octet 3a) Bits 76 Meaning 00 Presentation allowed 01 Presentation restricted 10 Number not available due to interworking 11 Reserved NOTE 7 The meaning and the use of this field is defined in clause 3/Q.951 and clause 4/Q.951. Screening indicator (octet 3a) Bits 21 00 User-provided, not screened 01 User-provided, verified and passed 10 User-provided, verified and failed 11 Network provided NOTE 8 The meaning and the use of this field is defined in clause 3/Q.951 and clause 4/Q.951. Number digits (octets 4, etc.) This field is coded with IA5 characters, according to the formats specified in the appropriate numbering/dialling plan.
4.5.11 Calling party subaddress The purpose of the Calling party subaddress information element is to identify a subaddress associated with the origin of a call. For the definition of subaddress, see Recommendation I.330 [18]. The Calling party subaddress information element is coded as shown in Figure 4-17 and Table 4-12. The maximum length of this information element is 23.
8 0 ext. 1 7 6 5 4 3 2 Calling party subaddress information element identifier 1 1 0 1 1 0 Length of calling party subaddress contents Odd/even Type of subaddress Spare indicator 0 0 Subaddress information 1 1 Octet 1 2 3 4 etc.
Figure 4-17/Q.931 Calling party subaddress information element
(05/98)
71
Table 4-12/Q.931 Calling party subaddress information element

Type of subaddress (octet 3) Bits 765 000 NSAP (ITU-T Rec. X.213 [23] and ISO/IEC 8348, Add.2 [24]) 010 User specified All other values are reserved. Odd/even indicator (octet 3) Bit 4 0 Even number of address signals 1 Odd number of address signals NOTE 1 The odd/even indicator is used when the type of subaddress is "user specified" and the coding is BCD. Subaddress information (octets 4, etc.) The NSAP ITU-T Rec. X.213 and ISO/IEC 8348, Add.2 address shall be formatted as specified by octet 4 which contains the Authority and Format Identifier (AFI). The encoding is made according to the "preferred binary encoding" as defined in ITU-T Rec. X.213and ISO/IEC 8348, Add.2 except when used for Terminal selection at the S interface (see Note 3). For the definition of this type of subaddress, see Recommendation I.334 [25]. For user specified subaddress, this field is encoded according to the user specification, subject to a maximum length of 20 octets. When interworking with X.25 [5] networks, BCD coding should be applied. NOTE 2 It is recommended that users apply the NSAP subaddress type since this subaddress type allows the use of decimal, binary and IA5 syntaxes in a standardized manner. NOTE 3 It is recommended that users apply the Local IDI format (the AFI field coded 50 in BCD) when the subaddress is used for terminal selection purposes at the S interface. In this case, the IA5 character syntax using only digits 0 to 9 shall be used for the DSP. Each character is then encoded in one octet according to Recommendation T.50 [49] and ISO/IEC 646, with zero parity in the most significant position.
4.5.12 Cause The content and use of the Cause information element is defined in Recommendation Q.850 [67]. 4.5.13 Channel identification The purpose of the Channel identification information element is to identify a channel within the interface(s) controlled by these signalling procedures. The Channel identification information element is coded as shown in Figures 4-18 and 4-19 and Table 4-13. The channel identification element may be repeated in a message, e.g. to list several acceptable channels during channel negotiation. The default maximum length for this information element is network dependent.
72
(05/98)
8 0 ext. 1 ext. 0/1 ext. 1
6 5 4 3 2 1 Channel identification information element identifier 0 0 1 1 0 0 0 Length of channel identification contents D-channel Pref./Excl. Int. id. Int. type Spare Info. channel ind present 0 selection Interface identifier Coding standard
Number/ Map
Octet 1 2 3 3.1*, etc. (Note 1) 3.2* (Note 2) (Note 5) 3.3* (Note 2) (Note 4) (Note 5)
Channel type/Map element type
Channel number/Slot map (Note 3)
NOTE 1 When the "interface identifier present" field in octet 3 indicates "interface implicitly identified" octet 3.1 is omitted. When octet 3.1 is present, it may be extended by using the extension bit (bit 8). NOTE 2 When the "interface type" field in octet 3 indicates "basic interface", octets 3.2 and 3.3 are functionally replaced by the "information channel selection" field in octet 3, and thus omitted. NOTE 3 When channel number is used and a single channel is indicated, bit 8 shall be set to "1". When channel number is used and multiple channels are indicated, bit 8 shall be used as an extension bit to indicate an extension to subsequent channels and coded according to the rules specified in 4.5.1. NOTE 4 When channel number is used, this octet may be repeated to indicate multiple channels. NOTE 5 These octets shall be omitted when the entire interface is to be identified.
Figure 4-18/Q.931 Channel identification information element
Table 4-13/Q.931 Channel identification information element

Interface identifier present (octet 3) Bit 7 0 Interface implicitly identified (Note 1) 1 Interface explicitly identified in one or more octets, beginning with octet 3.1. NOTE 1 The interface which includes the D-channel carrying this information element is indicated. Interface type (octet 3) Bit 6 0 Basic interface 1 Other interface, e.g. primary rate (Note 2) NOTE 2 The type of interface should be understood because the interface is identified by the "interface identifier present" field (octet 3, bit 7) and the interface identifier field (octet 3.1), if any. Preferred/Exclusive (octet 3) Bit 4 0 Indicated channel is preferred 1 Exclusive; only the indicated channel is acceptable NOTE 3 Preferred/exclusive has significance only for B-channel selection.
(05/98)
73
Table 4-13/Q.931 Channel identification information element (continued)

D-channel indicator (octet 3) Bit 3 0 The channel identified is not the D-channel 1 The channel identified is the D-channel NOTE 4 D-channel indication has significance in D-channel use. No other information affects D-channel use. Information channel selection (octet 3) (Note 5) Basic interface Other interfaces Bits 21 00 No channel No channel 01 B1 channel As indicated in following octets 10 B2 channel Reserved 11 Any channel (Note 6) Any channel NOTE 5 The information channel selection does not apply to the D-channel. NOTE 6 This value shall be used on a basic access when both B-channels are to be identified, e.g. multirate (64 kbit/s base rate). This shall not be used for restart procedures. Interface identifier (octet 3.1) Binary code assigned to the interface at subscription time. At subscription time, the binary code for the interface will specify the number of octets to be used and the content of each octet. NOTE 7 When the 'information channel selection' field of octet 3 (bit 2-1) indicates 'any channel', if present the interface 'identifier' field is set to all '0'. Coding standard (octet 3.2) Bits 76 00 ITU-T standardized coding, as described below 01 ISO/IEC Standard (Note 8) 10 National standard (Note 8) 11 Standard defined for the network (either public or private) present on the network side of the interface (Note 8) NOTE 8 These other coding standards should only be used when the desired call states cannot be represented by ITU-T-standardized coding. Number/map (octet 3.2) Bit 5 0 Channel is indicated by the number in the following octet 1 Channel is indicated by the slot map (Map) in the following octet(s) NOTE 9 When the information transfer rate is 64 kbit/s, the channel number shall be used unless there exists a bilateral agreement between the user and the network to use the slot map. NOTE 10 Slot map shall be used when supporting the multirate (64 kbit/s base rate) bearer capability on a primary rate access.
74
(05/98)
Table 4-13/Q.931 Channel identification information element (concluded)

Channel type/map element type (octet 3.2) Bits 4321 0011 B-channel units (Note 11) 0110 H0-channel units 1000 H11-channel units 1001 H12-channel units All other values are reserved. NOTE 11 This value shall be used for multirate (64 kbit/s base rate) bearer capability. Channel number (octet 3.3) Binary number assigned to the channel. For B-channels, the channel number equals the time slot number. See Recommendation I.431 [27]. NOTE 12 Either "Channel Number" or "Slot map" is used exclusively, depending on the "Number/Map" information. Slot map (octet 3.3) Bit position(s) in slot map corresponding to time slot(s) used by the channel is set to 1, see Figure 4-19. The remaining bits are set to 0. NOTE 13 The length of the slot map (in bits) is defined by the capacity of the interface type (e.g. 1534 kbit/s or 2048 kbit/s for a primary rate interface) divided by the capacity of the channel type/mapelement type (e.g. 64 kbit/s for a B-channel). The length of the slot map is the smallest number of complete octets that contain the length in bits.
(05/98)
75
8 24 16 8
7 23 15 7
6 22 14 6
5 4 21 20 13 12 5 4 1544 kbit/s
3 19 11 3
2 18 10 2
1 17 9 1
Octet 3.3.1 3.3.2 3.3.3
8 31 23 15 7 a) 8
7 30 22 14 6
5 4 3 2 28 27 26 25 20 19 18 17 12 11 10 9 4 3 2 1 2048 kbit/s Primary rate interface, map element type = B-channel 6 5 4 d(4) 1544 kbit/s 3 c(3) 2 b(2)
6 29 21 13 5
1 24 16 8 0
Octet 3.3.1 3.3.2 3.3.3 3.3.4
1 a(1)
Octet 3.3
5 4 3 2 e(5) d(4) c(3) b(2) 2048 kbit/s b) Primary rate interface, map element type = H0 channel NOTE 1 See Annex A/I.431 [27], concerning meaning of a-e. H0-channel is represented by channel number in octet 3.3.
1 a(1)
Octet 3.3
NOTE 2 Number within ( ) indicates the associated H0-channel number used when corresponding
1 H11(1)
Octet 3.3
1544 kbit/s 8 7 6 5 4 3 2 1 H12(1) Octet 3.3
c)
2048 kbit/s Primary rate interface, map element type = H1-channel
NOTE 3 Number within ( ) indicates the associated H1-channel number used when corresponding H1-channel is represented by channel number in octet 3.3. NOTE 4 For 2048 kbit/s interface, H11 slot will be indicated by the same format.
Figure 4-19/Q.931 Slot map field
4.5.14 Congestion level The purpose of the Congestion level information element is to describe the congestion status of the call. It is a single octet information element coded as shown in Figure 4-20 and Table 4-14.
8 7 6 5 Congestion level information element identifier 0 1 1 4 3 2 1 Octet
Congestion level
Figure 4-20/Q.931 Congestion level information element
76
(05/98)
Table 4-14/Q.931 Congestion level information element

Congestion level (octet 1) Bits 4321 0000 Receiver ready 1111 Receiver not ready All other values are reserved.
4.5.15 Date/time The purpose of the Date/time information element is to provide the date and time to the user. It indicates the point in time when the message has been generated by the network.
NOTE It is a network dependent matter whether the time indicated is local time or Coordinated Universal Time (UTC) and which calendar is used for referencing the date.
The Date/time information element is coded as shown in Figure 4-21.

5 4 3 2 Date/time information element identifier 0 0 1 0 1 0 0 Length of date/time contents Year Month Day Hour Minute Second NOTE Octets 3-8 are binary coded (bit 1 being the least significant bit). 8 7 6 1 1 Octet 1 2 3 4 5 6* 7* 8*
Figure 4-21/Q.931 Date/time information element
4.5.16 Display The purpose of the Display information element is to supply display information that may be displayed by the user. The information contained in this element is coded in IA5 characters. The display information element is coded as shown in Figure 4-22. The Display information element has a network dependent default maximum length of 34 or 82 octets. The evolution to a single maximum value of 82 octets is an objective. If a user receives a Display information element with a length exceeding the maximum length which the user can handle, the information element should be truncated by the user.
8 0 0 7 0 6 1 5 4 3 Display information element identifier 0 1 0 Length of display contents Display information (IA5 characters) 2 0 1 0 Octet 1 2 3 etc.
Figure 4-22/Q.931 Display information element
(05/98)
77
4.5.17 High layer compatibility The purpose of the High layer compatibility information element is to provide a means which should be used by the remote user for compatibility checking. See Annex B. The High layer compatibility information element is coded as shown in Figure 4-23 and Table 4-15. The High layer compatibility information element can be repeated in the SETUP message to indicate dual high layer capabilities for selection. By default, if the High layer compatibility information element is repeated without the Repeat indicator information element, it shall be interpreted as increasing order of priority. The maximum length of this information element is five octets.
NOTE The High layer compatibility information element is transported transparently by an ISDN between a call originating entity, e.g. a calling user and the addressed entity, e.g. a remote user or a high layer function network node addressed by the call originating entity. However, if explicitly requested by the user (at subscription time), a network which provides some capabilities to realize teleservices may interpret this information to provide a particular service.
8 0 ext. 1 ext. 0/1 ext. 1 ext. 1 6 5 4 3 2 1 High layer compatibility information element identifier 1 1 1 1 1 0 1 Length of high layer compatibility contents Coding standard Interpretation Presentation method of protocol profile High layer characteristics identification Extended high layer characteristics identification Extended videotelephony characteristics identification 7 Octet 1 2 3 4 4a* (Note 1) 4a* (Note 2)
NOTE 1 This octet may be present when octet 4 indicates Maintenance or Management. NOTE 2 This octet may be present when octet 4 indicates audio visual.
Figure 4-23/Q.931 High layer compatibility information element
78
(05/98)
Table 4-15/Q.931 High layer compatibility information element

Coding standard (octet 3) Bits 76 00 01 10 11
ITU-T standardized coding, as described below ISO/IEC standard (Note 1) National standard (Note 1) Standard defined for the network (either public or private) present on the network side of the interface (Note 1) NOTE 1 These other coding standards should only be used only when the desired high layer compatibility cannot be represented by ITU-T standardized coding. Interpretation (octet 3) Bits 543 100
First (primary or only) high layer characteristics identification (in octet 4) to be used in the call All other values are reserved. NOTE 2 "Interpretation" indicates how the "High layer characteristics identification" (in octet 4) should be interpreted. NOTE 3 Currently, "Interpretation" has only a single value. However, "Interpretation", when enhanced, will be able to indicate how the "High layer characteristics identification" in the same information element shall be interpreted when multiple "High layer characteristics identifications" are used and exact relationship among them needs to be indicated (e.g. sequential usage, alternative list, simultaneous usage). Such enhancements in conjunction with the possible negotiation procedures are left for further study. Presentation method of protocol profile (octet 3) Bits 21 01 High layer protocol profile (without specification of attributes) All other values are reserved. NOTE 4 Currently, "Presentation method of protocol profile" has only a single value, i.e. a "profile value" is used to indicate a service to be supported by high layer protocols as required. Necessity of other presentation methods, e.g. service indications in the forum of layer-by-layer indication of protocols to be used in high layers, is left for further study. High layer characteristics identification (octet 4) Bits 7654321 0000001 0000100 0100001 0100100 0101000 0110001 0110010 0110011 0110101 0111000
Telephony Facsimile Group 2/3 (Recommendation F.182 [68]) Facsimile Group 4 Class I (Recommendation F.184 [69]) Facsimile service Group 4, Classes II ad III (Recommendation F.184) (Note 7) (Note 7) Syntax based Videotex (Recommendation F.300 [73] and T.102 [74]) International Videotex interworking via gateways or interworking units (Recommendation F.300 and T.101 [75]) Telex service (Recommendation F.60 [76]) Message Handling Systems (MHS) (X.400-series Recommendation [77])
(05/98)
79
Table 4-15/Q.931 High layer compatibility information element (continued)

1000001 1000010 1011110 1011111 1100000 1100001 1100010 OSI application (Note 6) (X.200-series Recommendations [78]) FTAM application (ISO 8571) Reserved for maintenance (Note 8) Reserved for management (Note 8) Videotelephony (Recommendations F.720 [91] and F.721 [79]) and F.731 profile 1a) (Note 9) Videoconferencing Recommendation F.702 [94] and F.731 [97] Profile 1b (Note 9) Audiographic conferencing Recommendations F.702 [94] and F.731 [97] (including at least profile 2a2 and optionally 2a1, 2a3, 2b1, 2b2, and 2bc) (Notes 9 and 10)
1100011 through Reserved for audiovisual service (F.700-series Recommendations [80]) 1100111 1 1 0 1 0 0 0 Multimedia services F.700-series Recommendations [80] (Note 9) 1100011 through Reserved for audiovisual services (F.700-series Recommendations [80]) 1101111 1 1 1 1 1 1 1 Reserved All other values are reserved Extended high layer characteristics identification (octet 4a for maintenance or management) Bits 7654321 0000001 0000100 0100001 0100100 0101000 0110001 0110010 0110011 0110101 0111000 1000001 1000010 1011110 1011111 1100000 1100001 1100010 1100011 through 1100111 1101000
Telephony Facsimile Group 2/3 (Recommendation F.182) Facsimile Group 4 Class I (Recommendation F.184) Facsimile service Group 4, Classes II and III (Recommendation F.184) (Note 11) (Note 11) Syntax based Videotex (Recommendations F.300 and T.102) International Videotex interworking via gateways or interworking units (Recommendations F.300 and T.101) Telex service (Recommendation F.60) Message Handling Systems (MHS) (X.400-series Recommendations [77]) OSI application (Note 6) (X.200-series Recommendations [78]) FTAM application (ISO 8571) Not available for assignment Not available for assignment Videotelephony (Recommendations F.720 [91] and F.721 [79] and F.731, profile 1a) Videoconferencing Recommendations F.702 [94] and F.731 [97], profile 1b Audiographic conferencing Recommendations F.702 [94] and F.731 [97] (including at least profile 2a2 and optionally 2a1, 2a3, 2b1, 2b2 and 2bc) Reserved for audiovisual services (F.700-series Recommendations [80]) Multimedia services (F.700-series Recommendations [80])
80
(05/98)
Table 4-15/Q.931 High layer compatibility information element (concluded)

1101001 through Reserved for audiovisual services (F.700-series Recommendations [80]) 1101111 1 1 1 1 1 1 1 Reserved All other values are reserved Extended audiovisual characteristics identification (octet 4a for videotelephony) Bits 7654321 0 0 0 0 0 0 1 Capability set of initial channel of H.221 0 0 0 0 0 1 0 Capability set of subsequent channel of H.221 0 1 0 0 0 0 1 Capability set of initial channel associated with an active 3.1 kHz audio or speech call. NOTE 5 The coding above applies in case of "Coding standard" = "ITU-T Standard" and "Presentation method of protocol profile" = "High layer protocol profile". NOTE 6 Further compatibility checking will be executed by the OSI high layer protocol. NOTE 7 Codepoints are added only to those services for which ITU-T Recommendations are available. See also the I.241-series of Recommendations [34]. NOTE 8 When this coding is included, octet 4 may be followed by octet 4a. NOTE 9 When this coding is used, octet 4 may be followed by octet 4a. NOTE 10 The multimedia services identified by this codepoint mush have a mandatory common core functionality of speech that will ensure a minimum capability to communicate. NOTE 11 This codepoint was previously allocated for an F.200-series Recommendation that has been deleted.
4.5.18 Keypad facility The purpose of the Keypad facility information element is to convey IA5 characters, e.g. entered by means of a terminal keypad. The Keypad facility information element is coded as shown in Figure 4-24. The maximum length of this information element is 34 octets.
8 0 0 7 0 6 5 4 3 2 Keypad facility information element identifier 1 0 1 1 0 Length of the keypad facility contents Keypad facility information (IA5 characters) 1 0 Octet 1 2 3 etc.
Figure 4-24/Q.931 Keypad facility information element
4.5.19 Low layer compatibility The purpose of the Low layer compatibility information element is to provide a means which should be used for capability checking by an addressed entity (e.g. a remote user or an interworking unit or a high layer function network node addressed by the calling user). The Low layer compatibility information element is transferred transparently by an ISDN between the call originating entity (e.g. the calling user) and the addressed entity. See Annexes B and I.
(05/98)
81
If low layer compatibility negotiation is allowed by the network (see Annex J), the Low layer compatibility information element is also passed transparently from the addressed entity to originating entity. The Low layer compatibility information element is coded as shown in Figure 4-25 and Table 4-16. The maximum length of this information element is 18 octets.
NOTE Some networks conforming to Recommendation Q.931 (1988) may support a maximum information element length of only 16 octets.
82
(05/98)
8 0 ext. 0/1 ext. 1 ext. 1 ext. 1 ext. 0/1 ext. 0/1 ext. 0/ 1 ext. 0/1 ext. 0/1 ext. 1 ext. 0/1 ext. 0/1 ext. 1 ext. 1 ext. 0/1 ext. 1 ext. 0/1 ext. 0/1 ext. 1 ext. 0 ext. 1
6 5 4 3 2 Low layer compatibility information element identifier 1 1 1 1 1 0 Length of the low layer compatibility contents Coding standard Information transfer capability Negot. indic. 0 Transfer mode Spare 0 0 0 Information transfer rate Rate multiplier Layer 1 ident. 0 1 Synch./ Negot. asynch. Intermediate rate User information layer 1 protocol User rate NIC on Tx Mode NIC on Rx Negot. LLI Flow control on Tx
Assignor/ Assignor ee
1 0
Octet 1 2 3 3a*
0 4 4.1* (Note 1) 5* 5a* (Note 2) 5b* (Note 3) 5b* (Note 4) 5c* (Note 2) 5d* (Note 2) 6* 6a* (Note 5) 6a* (Note 6) 6b* (Note 5) 7 7a* (Note 8) 7a* (Note 7) 7b* (Note 7) 7c* (Note 7) 7a* (Note 9) 7b* (Note 9)
Hdr/no Hdr
Multifra me
Flow control on Rx In-band negot. Parity
Spare 0 Spare 0
Number of stop bits Duplex mode layer 2 ident. 1 0 Mode
Number of data bits Modem type
User information layer 2 protocol Spare 0 0 0 User specified layer 2 protocol information Window size (k) Q.933 use
layer 3 ident. 1 1
User information layer 3 protocol Optional layer 3 protocol information
Mode 0 0 Spare 0 0 0
Spare 0 0 Default packet size
Packet window size Spare 0 Spare 0 Additional layer 3 protocol information (most significant bits) Additional layer 3 protocol information (least significant bits)
0 0
0 0
Figure 4-25/Q.931 Low layer compatibility information element
(05/98)
83
NOTES to Figure 4-25

NOTE 1 This octet is required if octet 4 indicates multirate (64 kbit/s base rate). Otherwise, it shall not be present. NOTE 2 This octet may be present if octet 3 indicates unrestricted digital information and octet 5 indicates either of the ITU-T standardized rate adaptions V.110, I.460 and X.30 or V.120 [9]. It may also be present if octet 3 indicates 3.1 kHz audio and octet 5 indicates G.711. NOTE 3 This structure of octet 5b only applies if octet 5 indicates ITU-T standardized rate adaption (V.110 [7], I.460 [15] and X.30 [8]). NOTE 4 This structure of octet 5b only applies if octet 5 indicates ITU-T standardized rate adaption V.120 [9]. NOTE 5 This octet may be present only if octet 6 indicates certain acknowledged mode HDLC elements of procedure as indicated in Table 4-16. NOTE 6 This octet may be present only if octet 6 indicates user specified layer 2 protocol. NOTE 7 This octet may be present only if octet 7 indicates a layer 3 protocol based on ITU-T X.25 [5], ISO/IEC 8208 [41] or ITU-T Rec. X.223 [96] and ISO/IEC 8878 [81] as indicated in Table 4-16. NOTE 8 This octet may be present only if octet 7 indicates user specified layer 3 protocol. NOTE 9 This may be included if octet 7 indicates ISO/IEC TR 9577.
Table 4-16/Q.931 Low layer compatibility information element

Coding standard (octet 3) Bits 76 0 0 ITU-T standardized coding, as described below 0 1 ISO/IEC Standard (Note 1) 1 0 National standard (Note 1) 1 1 Standard defined for the network (either public or private) present on the network side of the interface (Note 1) NOTE 1 These other coding standards should only be used only when the desired low layer compatibility cannot be represented by ITU-T-standardized coding. Information transfer capability (octet 3) Bits 54321 00000 Speech 01000 Unrestricted digital information 01001 Restricted digital information 10000 3.1 kHz audio 10001 Unrestricted digital information with tones/announcements (Note 2) 11000 Video All other values are reserved. NOTE 2 Unrestricted digital information with tones/announcements (UDI-TA) is the new information transfer attribute value that had previously been named "7 kHz audio" in Recommendation Q.931 (1988). Negotiation indicator (octet 3a) Bit 7 0 Out-band negotiation not possible 1 Out-band negotiation possible NOTE 3 See Annex J for description of low layer compatibility negotiation. NOTE 4 When octet 3a is omitted, "out-band negotiation not possible" shall be assumed.
84
(05/98)
Table 4-16/Q.931 Low layer compatibility information element (continued)

Transfer mode (octet 4) Bits 76 00 Circuit mode 10 Packet-mode All other values are reserved. Information transfer rate (octet 4) Bits 54321 Circuit mode Packet-mode 00000 This code shall be used for all packet calls 10000 64 kbit/s 10001 2 64 kbit/s 10011 384 kbit/s 10101 1536 kbit/s 10111 1920 kbit/s 11000 Multirate (64 kbit/s base rate) All other values are reserved. NOTE 5 When the information transfer rate 2 64 kbit/s is used, the coding of octets 3 and 4 refer to both 64 kbit/s channels. NOTE 6 Additional attributes are defined in Table 4-17. Rate multiplier (octet 4.1) Coded as a binary representation of the multiplier to the base rate. The multiplier can take any value from 2 up to the maximum number of B-channels available on the interface. User information layer 1 protocol (octet 5) Bits 54321 00001 ITU-T standardized rate adaption V.110 [7], I.460 [15] and X.30 [8]. This implies the presence of octet 5a and optionally octets 5b, 5c and 5d as defined below. 00010 Recommendation G.711 [10] -law. 00011 Recommendation G.711 A-law. 00100 Recommendation G.721 [11] 32 kbit/s ADPCM and Recommendation I.460 [15]. 00101 Recommendations H.221 and H.242. 00110 Recommendations H.223 [92] and H.245 [93] 00111 Non-ITU-T standardized rate adaption. This implies the presence of octet 5a and, optionally, octets 5b, 5c and 5d. The use of this codepoint indicates that the user rate specified in octet 5a is defined by the user. Additionally, octets 5b, 5c and 5d, if present, are defined in accordance with the user specified rate adaption. 01000 ITU-T standardized rate adaption V.120 [9]. This implies the presence of octets 5a and 5b as defined below, and optionally octets 5c and 5d. 01001 ITU-T standardized rate adaption X.31 [14] HDLC flag stuffing. All other values are reserved. NOTE 7 If the transfer mode is "circuit mode" and if the information transfer capability is "unrestricted digital information" or "Restricted digital information", and if a specific user information layer 1 protocol is to be identified to the addressed entity, octet 5 shall be present. If the transfer mode is packet mode, octet 5 may be omitted.
(05/98)
85

Synchronous/Asynchronous (octet 5a) Bit 7 0 Synchronous data 1 Asynchronous data NOTE 8 Octets 5b-5d may be omitted in the case of synchronous user rates. Negotiation (octet 5a) Bit 6 0 1
In-band negotiation not possible In-band negotiation possible
NOTE 9 See Recommendations V.110 [7], I.460 [15] and X.30 [8] or modem type Recommendations. User rate (octet 5a) Bits 54321 00000
00001 00010 00011 00100 00101 00110 00111 01000 01001 01010 01011 01100 01101 01110 01111 10000 10010 10011 10100 10101 10110 10111 11000
For I.460, rate is specified by bits 7, 6 of octet 5b, Intermediate rate. For V.110 and X.30, rate is indicated by E-bits (synchronous data only) or may be negotiated in-band. For V.120, rate is unspecified or may be negotiated in-band. 0.6 kbit/s Recommendation X.1 [17] 1.2 kbit/s 2.4 kbit/s Recommendation X.1 3.6 kbit/s 4.8 kbit/s Recommendation X.1 7.2 kbit/s 8 kbit/s Recommendation I.460 9.6 kbit/s Recommendation X.1 14.4 kbit/s 16 kbit/s Recommendation I.460 19.2 kbit/s 32 kbit/s Recommendation I.460 38.4 kbit/s Recommendation V.110 [7] 48 kbit/s Recommendation X.1 56 kbit/s 64 kbit/s Recommendation X.1 57.6 kbit/s Recommendation V.14 [88] extended 28.8 kbit/s Recommendation V.110 [89] 24 kbit/s Recommendation V.110 [89] 0.1345 kbit/s Recommendation X.1 0.100 kbit/s Recommendation X.1 0.075/1.2 kbit/s Recommendation X.1 (Note 10) 1.2/0.075 kbit/s Recommendation X.1 (Note 10)
86
(05/98)

11001 11010 11011 11100 11101 11110 11111 0.050 kbit/s Recommendation X.1 0.075 kbit/s Recommendation X.1 0.110 kbit/s Recommendation X.1 0.150 kbit/s Recommendation X.1 0.200 kbit/s Recommendation X.1 0.300 kbit/s Recommendation X.1 12 kbit/s
All other values are reserved. NOTE 10 The first rate is the transmit rate in the forward direction of the call. The second rate is the transmit rate in the backward direction of the call. Octet 5b for V.110 [7], I.460 [15] and X.30 [8] rate adaption Intermediate rate (octet 5b) Bits 76 00 01 10 11 Bit 5 0 1
Not used 8 kbit/s 16 kbit/s 32 kbit/s
Network Independent Clock (NIC) on transmission (Tx) (octet 5b) (Note 11)
Not required to send data with network independent clock Required to send data with network independent clock
NOTE 11 Refers to transmission in the forward direction of the call. NOTE 12 See Recommendations V.110, I.460 [15] and X.30. Network Independent Clock (NIC) on reception (Rx) (octet 5b) (Note 13) Bit 4 0 Cannot accept data with Network Independent Clock (i.e. sender does not support this optional procedure) 1 Can accept data with Network Independent Clock (i.e. sender does support this optional procedure)
NOTE 13 Refers to transmission in the backward direction of the call. NOTE 14 See Recommendations V.110 [7], I.460 [15] and X.30 [8]. Flow control on transmission (Tx) (octet 5b) (Note 15) Bit 3 0 1
Not required to send data with flow control mechanism Required to send data with flow control mechanism
NOTE 15 Refers to transmission in the forward direction of the call. NOTE 16 See Recommendations V.110, I.460 and X.30.
(05/98)
87

Flow control on reception (Rx) (octet 5b) (Note 17) Bit 2 0 1
Cannot accept data with flow control mechanism (i.e. sender does not support this optional procedure) Can accept data with flow control mechanism (i.e. sender does support this optional procedure)
NOTE 17 Refers to transmission in the backward direction of the call. NOTE 18 See Recommendations V.110, I.460 and X.30. Octet 5b for V.120 [9] Rate adaption Rate adaption header/no header (octet 5b) Bit 7 0 1 Bit 6 0 1 Bit 5 0 1 Bit 4 0 1
Rate adaption header not included Rate adaption header included
Multiple frame establishment support in data link (octet 5b)
Multiple frame establishment not supported. Only UI frames allowed Multiple frame establishment supported
Mode of operation (octet 5b)
Bit transparent mode of operation Protocol sensitive mode of operation
Logical link identifier negotiation (octet 5b)
Default, LLI = 256 only Full protocol negotiation (Note 19)
NOTE 19 A connection over which protocol negotiation will be executed is indicated in bit 2 of octet 5b. Assignor/assignee (octet 5b) Bit 3 0 1 Bit 2 0 1
Message originator is "default assignee" Message originator is "assignor only"
In-band/out-band negotiation (octet 5b)
Negotiation is done with USER INFORMATION messages on a temporary signalling connection Negotiation is done in-band using logical link zero
88
(05/98)

Number of stop bits (octet 5c) Bits 7 6 0 0 0 1 1 0 1 1 Bits 5 4 0 0 0 1 1 0 1 1 Bits 321 000 010 011 100 101
Not used 1 bit 1.5 bits 2 bits
Number of data bits excluding parity bit if present (octet 5c)
Not used 5 bits 7 bits 8 bits
Parity information (octet 5c)
Odd Even None Forced to 0 Forced to 1
All other values are reserved. Duplex mode (octet 5d) Bit 7 0 1 Bits 654321 000000 through 000101 010001 010010 010011 010100 010101 010110 010111 011000 011001 011010 011011 011100
Half duplex Full duplex
Modem type (octet 5d)
National use Recommendation V.21 Recommendation V.22 Recommendation V.22 bis Recommendation V.23 Recommendation V.26 Recommendation V.26 bis Recommendation V.26 ter Recommendation V.27 Recommendation V.27 bis Recommendation V.27 ter Recommendation V.29 Recommendation V.32
(05/98)
89

0 1 1 1 1 0 Recommendation V.34 [90] 100000 through National use 101111 110000 through User specified 111111 All other values reserved. User information layer 2 protocol (octet 6) Bits 54321 00001 Basic mode ISO 1745 [36] 00010 Recommendation Q.921/I.441 [3] (Note 23) 00110 Recommendation X.25 [5], link layer (Notes 20, 23) 00111 Recommendation X.25 Multilink (Note 23) 01000 Extended LAPB; for half duplex operation (Recommendation T.71 [37]) 01001 HDLC ARM (ISO/IEC 4335 [38]) (Note 23) 01010 HDLC NRM (ISO/IEC 4335) (Note 23) 01011 HDLC ABM (ISO/IEC 4335) (Note 23) 01100 LAN logical link control (ISO/IEC 8802-2 [39]) 01101 Recommendation X.75 [40]. Single Link Procedure (SLP) (Note 23) 01110 Recommendation Q.922 (Note 23) 01111 Core aspects of Recommendation Q.922 10000 User specified (Note 21) 10001 ISO/IEC 7776 DTE-DCE operation (Notes 22, 23) All other values are reserved. NOTE 20 This Recommendation is compatible with ISO/IEC 7776 DTE-DCE operation. NOTE 21 When this coding is included, octet 6a will include user coding for the user specified Layer 2 protocol. NOTE 22 This Standard is compatible with Recommendation X.75 modified by the application rules defined in Recommendation T.90. NOTE 23 When this coding is included, octets 6a and 6b with ITU-T encoding may be included. Octet 6a for ITU-T codings Mode of operation (octet 6a) Bits 76 01 Normal mode of operation 10 Extended mode of operation All other values are reserved. Q.933 use (octet 6a) Bits 21 00 For use when the coding defined in Recommendation Q.933 is not used All other values are reserved. Octet 6a for user protocol User specified layer 2 protocol information (octet 6a) The use and coding of octet 6a is according to user defined requirements. Window size (k) (octet 6b) Bits 7-1 binary coding of k parameter value in the range from 1 to 127.
90
(05/98)

User information layer 3 protocol (octet 7) Bits 54321 00010 Recommendation Q.931/I.451 00110 Recommendation X.25, packet layer (Note 25) 00111 ISO/IEC 8208 [41] (X.25 packet level protocol for data terminal equipment) (Note 25) 01000 ITU-T Rec. X.223 and ISO/IEC 8878 [81] (use of ISO/IEC 8208 [41] and Recommendation X.25 to provide the OSI-CONS) (Note 25) 01001 ISO/IEC 8473 [43] (OSI connectionless mode protocol) 01010 Recommendation T.70 [32] minimum network layer 01011 ISO/IEC TR 9577 [82] (Protocol identification in the network layer) (Note 26) 10000 User specified (Note 24) All other values are reserved. NOTE 24 When this coding is included, octet 7a will include user coding for the user specified layer 3 protocol. NOTE 25 When this coding is included, octets 7a, 7b and 7c with ITU-T X.25, X.223 and ISO/IEC TR 9577 encoding may be included. NOTE 26 When this coding is included, octets 7a and 7b with ITU-T X.25, X.223 [96] and ISO/IEC TR 9577 encoding may be included. Octet 7a, 7b and 7c X.25 packet layer, ISO/IEC 8208 and X.223 codings Mode of operation (octet 7a) Bits 76 01 10
Normal packet sequence numbering Extended packet sequence numbering
All other values are reserved. Default packet size (octet 7b) Bits 4321 0100 0101 0110 0111 1000 1001 1010 1011 1100
Default packet size 16 octets Default packet size 32 octets Default packet size 64 octets Default packet size 128 octets Default packet size 256 octets Default packet size 512 octets Default packet size 1024 octets Default packet size 2048 octets Default packet size 4096 octets
All other values are reserved. Packet window size (octet 7c) Bits 7-1 binary coding of packet window size value in the range from 1 to 127. Octet 7a for user protocol User specified layer 3 protocol information (octet 7a) The use and coding of octet 7a depends on user defined requirements Octets 7a and 7b for ISO/IEC TR 9577 coding (Notes 26 and 27) Bit 8 (ext.) set to 0 in octet 7a and set to 1 in octet 7b. Bits 7 to 5 are spare (set to 0) in both octets.
(05/98)
91
Table 4-16/Q.931 Low layer compatibility information element (concluded)

7a Bits 4321 1100 1100 7b Bits 4321 1 1 0 0 Internet Protocol (RFC 791) (Annex C of ISO/IEC TR 9577 [82]) 1 1 1 1 Point-to-Point Protocol (RFC 1548)
All other values are reserved. NOTE 27 If the user information layer 3 protocol indicates "Network layer protocol identification", it may be included to identify the actual user information layer 3 protocol to the addressed entity (see Annex I). Any Network layer Protocol Identifier code defined in ISO/IEC TR 9577 [82] may be included. Octet 7c shall not be included.
Table 4-17/Q.931 Low layer compatibility attributes

LLC attributes Transfer mode Circuit Circuit Circuit Circuit Circuit Circuit Packet Information transfer capability Speech Unrestricted data Restricted data 3.1 kHz audio Unrestricted data with tones/announcements Video Unrestricted data Structure 8 kHz integrity 8 kHz integrity 8 kHz integrity 8 kHz integrity 8 kHz integrity 8 kHz integrity Service data unit integrity Additional attributes Configuration Point-to-point Point-to-point Point-to-point Point-to-point Point-to-point Point-to-point Point-to-point Establishment Demand Demand Demand Demand Demand Demand Demand Symmetry Bi-directional symmetric Bi-directional symmetric Bi-directional symmetric Bi-directional symmetric Bi-directional symmetric Bi-directional symmetric Bi-directional symmetric
NOTE 1 When the information transfer rate 2 64 kbit/s is used, 8 kHz integrity with Restricted Differential Time Delay (RDTD) is offered. NOTE 2 When multirate (64 kbit/s base rate) is indicated as the information transfer rate, Time Slot Sequence integrity shall be provided.
92
(05/98)
4.5.20 More data The More data information element is sent by the user to the network in a USER INFORMATION message, and delivered by the network to the destination user(s) in the corresponding USER INFORMATION message. The presence of the More data information element indicates to the destination user that another USER INFORMATION message will follow, containing information belonging to the same block. The use of the More data information element is not supervised by the network. The More data information element is coded as shown in Figure 4-26. The length of this information element is one octet.
8 1 7 0 6 1 5 4 3 2 More data information element identifier 0 0 0 0 1 0 Octet 1
Figure 4-26/Q.931 More data information element
4.5.21 Network-specific facilities The purpose of the Network-specific facilities information element is to indicate which network facilities are to be invoked. The Network-specific facilities information element is coded as shown in Figure 4-27 and Table 4-18. No more than four Network-specific facilities information elements may be included in a single message. The maximum length of this information element is network dependent.
8 0 6 5 4 3 2 Network-specific facilities information element identifier 0 1 0 0 0 0 Length of network-specific facilities contents Length of network identification Type of network identification Network identification plan Network identification (IA5 characters) 7 1 0 Octet 1 2 3 3.1* 3.2* 4
ext. 1 Spare 0
Network-specific facility specification NOTE 1 Octets 3.1 and 3.2 are only present when the length in octet 3 is non-zero. NOTE 2 Octet 3.2 may be repeated as appropriate.
Figure 4-27/Q.931 Network-specific facilities information element
(05/98)
93
Table 4-18/Q.931 Network-specific facilities information element

Length of network identification (octet 3) This field contains the length, in octets, of the network identification found in octet 3.1 and the repetition of octet 3.2. If the value is "0000 0000", then the default provider (see E.1) is assumed and octets 3.1 and 3.2 are omitted. Type of network identification (octet 3.1) Bits 765 000 User specified 010 National network identification (Note 1) 011 International network identification All other values are reserved. NOTE 1 In the case that "type of network identification" is coded as 010, "national network identification", "national identification plan" is coded according to national specification. Network identification plan (octet 3.1) Bits 4321 0 0 0 0 Unknown 0 0 0 1 Carrier Identification Code (Note 2) 0 0 1 1 Data network identification code (Recommendation X.121 [21]) All other values are reserved. NOTE 2 Carrier Identification Codes may be an appropriate method of identifying the network serving the remote user. Network identification (octets 3.2, etc.) These IA5 characters are organized according to the network identification plan specified in octet 3.1. Network-specific facilities (octets 4, etc.) This field is encoded according to the rules specified by the identified network.
4.5.22 Notification indicator The purpose of the Notification indicator information element is to indicate information pertaining to a call. The Notification indicator information element is coded as shown in Figure 4-28 and Table 4-19. The maximum length of this information element is three octets.
8 0 ext. 1 7 0 6 5 4 3 2 Notification indicator information element identifier 1 0 0 1 1 Length of notification indicator contents Notification description 1 1 Octet 1 2 3
Figure 4-28/Q.931 Notification indicator information element
94
(05/98)
Table 4-19/Q.931 Notification indicator information element

Notification description (octet 3) Bits 7654321 0 0 0 0 0 0 0 User suspended 0 0 0 0 0 0 1 User resumed 0 0 0 0 0 1 0 Bearer service change All other values are reserved.
4.5.23 Progress indicator The purpose of the Progress indicator information element is to describe an event which has occurred during the life of a call. The information element may occur two times in a message. The Progress indicator information element is coded as shown in Figure 4-29 and Table 4-20. The maximum length of this information element is four octets.
8 0 ext. 1 ext. 1 7 6 5 4 3 2 Progress indicator information element identifier 0 0 1 1 1 1 Length of progress indicator contents Coding Spare Location standard 0 Progress description 1 0 Octet 1 2 3 4
Figure 4-29/Q.931 Progress indicator information element
(05/98)
95
Table 4-20/Q.931 Progress indicator information element

Coding standard (octet 3) Bits 76 00 01 10 11
ITU-T standardized coding, as described below ISO/IEC Standard (Note 1) National standard (Note 1) Standard specific to identified location (Note 1)
NOTE 1 These other coding standards should be used only when the desired progress indication can not be represented with the ITU-T-standardized coding. Location (octet 3) Bits 4321 0000 0001 0010 0011 0100 0101 1010
User Private network serving the local user Public network serving the local user Transit network (Note 2) Public network serving the remote user Private network serving the remote user Network beyond the interworking point
All other values are reserved. NOTE 2 This value may be generated by some networks. NOTE 3 Depending on the location of the users, the local public network and remote public network may be the same network. Progress description (octet 4) Bits 7654321 0000001 0000010 0000011 0000100 0000101 0001000 No. 1. Call is not end-to-end ISDN; further call progress information may be available in-band 2. Destination address is non-ISDN 3. Origination address is non-ISDN 4. Call has returned to the ISDN 5. Interworking has occurred and has resulted in a telecommunication service change (Note 5) 8. In-band information or an appropriate pattern is now available
All other values are reserved. NOTE 4 The use of different progress descriptions is further explained in Annex G. NOTE 5 This progress description value shall be used only in the case of interworking in a full ISDN environment, e.g. when bearer capability selection is not supported or when resource or route of the preferred capability is not available. In case of interworking with a non-ISDN environment, a progress description No. 1 shall be used. If the destination address is non-ISDN, the progress description No. 2 shall be used.
4.5.24 Repeat indicator The purpose of the Repeat indicator information element is to indicate how repeated information elements shall be interpreted, when included in a message. The Repeat indicator information element is included before the first occurrence of the information element which will be repeated in a message. The Repeat indication information element is coded as shown in Figure 4-30 and Table 4-21.
96
(05/98)
The length of this information element is one octet.

NOTE Use of the Repeat indicator information element in conjunction with an information element that occurs only once in a message shall not of itself constitute an error.
8 7 6 5 Repeat indicator information element identifier 1 0 1 4 3 2 1 Octet
Repeat indication
Figure 4-30/Q.931 Repeat indicator information element
Table 4-21/Q.931 Repeat indicator information element

Repeat indication (octet 1) Bits 4321 0010 Prioritized list for selecting one possibility (Note) All other values are reserved. NOTE Used for Bearer service change procedures (see Annex L).
4.5.25 Restart indicator The purpose of the Restart indicator information element is to identify the class of the facility (i.e. channel or interface) to be restarted. The Restart indicator information element is coded as shown in Figure 4-31 and Table 4-22. The maximum length of this information element is three octets.
8 0 ext. 1 7 1 0 6 5 4 3 2 Restart indicator information element identifier 1 1 1 0 0 Length of restart indicator contents 0 0 0 Class 1 1 Octet 1 2 3
Figure 4-31/Q.931 Restart indicator information element
(05/98)
97
Table 4-22/Q.931 Restart indicator information element

Class (octet 3) Bits 321 000 Indicated channels (Note 1) 110 Single interface (Note 2) 111 All interfaces (Note 3) All other values are reserved. NOTE 1 The channel identification information element must be included and indicates which channels are to be restarted. NOTE 2 If non-associated signalling is used, the channel identification information element must be included to indicate the interface to be restarted if it is other than the one on which the D-channel is present. NOTE 3 May be used when there are two or more interfaces controlled by the D-channel. The channel identification information element must not be included with this coding.
4.5.26 Segmented message The purpose of the Segmented message information element is to indicate that the transmission in which it appears is part of a segmented message, in addition to the use of message type SEGMENT. When included in a message segment, it appears directly after the Message type information element (see Annex H). The Segmented message information element is coded as shown in Figure 4-32 and Table 4-23. The length of this information element is four octets.
8 0
First segment indicator
7 0
6 5 4 3 2 Segmented message information element identifier 0 0 0 0 0 Length of segmented message contents Number of segments remaining Segmented message type
1 0
Octet 1 2 3 4
Figure 4-32/Q.931 Segmented message information element
Table 4-23/Q.931 Segmented message information element

First segment indicator (octet 3) Bit 8 0 1
Subsequent segment to first segment 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 as per 4.4. NOTE Bit 8 is reserved for possible future use as an extension bit.
98
(05/98)
4.5.27 Sending complete The purpose of the Sending complete information element is to optionally indicate completion of called party number, see 5.1.3, 5.2.1 and 5.2.4. It is a single octet information element coded as shown in Figure 4-33.
8 1 7 0 6 5 4 3 2 Sending complete information element identifier 1 0 0 0 0 1 1 Octet 1
Figure 4-33/Q.931 Sending complete information element
4.5.28 Signal The purpose of the Signal information element is to allow the network to optionally convey information to a user regarding tones and alerting signals. (See clause 7). The Signal information element is coded as shown in Figure 4-34 and Table 4-24. The length of this information element is three octets. The Signal information element may be repeated in a message.
8 0 0 7 0 0 6 1 0 5 4 3 Signal information element identifier 1 0 1 Length of signal contents 0 0 0 Signal value 2 0 0 1 0 1 Octet 1 2 3
Figure 4-34/Q.931 Signal information element
(05/98)
99
Table 4-24/Q.931 Signal information element

Signal value (octet 3) Bits 87654321 00000000 00000001 00000010 00000011 00000100 00000101 00000110 00000111 00001000 00001001 00111111 01000000 01000001 01000010 01000011 01000100 01000101 01000110 01000111 01001111
Dial tone on Ring back tone on Intercept tone on Network congestion tone on Busy tone on Confirm tone on Answer tone on Call waiting tone Off-hook warning tone Pre-emption tone on Tones off Alerting on pattern 0 (Note 1) Alerting on pattern 1 (Note 1) Alerting on pattern 2 (Note 2) Alerting on pattern 3 (Note 1) Alerting on pattern 4 (Note 1) Alerting on pattern 5 (Note 1) Alerting on pattern 6 (Note 1) Alerting on pattern 7 (Note 1) Alerting off
All other values are reserved. NOTE 1 The use of these patterns is network dependent. NOTE 2 Used for special/priority alerting.
4.5.29 Transit network selection The purpose of the Transit network selection information element is to identify one requested transit network. The Transit network selection information element may be repeated in a message to select a sequence of transit networks through which a call must pass (see Annex C). The Transit network selection information element is coded as shown in Figure 4-35 and Table 4-25. The maximum length of this information element is network dependent.
8 0 ext. 1 0 6 5 4 3 2 Transit network selection information element identifier 1 1 1 1 0 0 Length of transit network selection contents Type of network identification Network identification plan Network identification (IA5 characters) 7 1 0 Octet 1 2 3 4 etc.
Figure 4-35/Q.931 Transit network selection information element
100
(05/98)
Table 4-25/Q.931 Transit network selection information element

Type of network identification (octet 3) Bits 765 000 010 011
User specified National network identification (Note 1) International network identification
All other values are reserved. NOTE 1 In the case that "type of network identification" is coded as 010, "national network identification", "national identification plan" is coded according to national specification. Network identification plan (octet 3) Bits 4321 0000 0001 0011
Unknown Carrier Identification Code (Note 2) Data network identification code (Recommendation X.121 [21])
All other values are reserved. NOTE 2 Carrier Identification Codes may be an appropriate method of identifying the network serving the remote user. Network identification (octet 4) These IA5 characters are organized according to the network identification plan specified in octet 3.
4.5.30 User-user The purpose of the User-user information element is to convey information between ISDN users. This information is not interpreted by the network, but rather is carried transparently and delivered to the remote user(s). The User-user information element is coded as shown in Figure 4-36 and Table 4-26. There are no restrictions on content of the user information field. In SETUP, ALERTING, CONNECT, DISCONNECT, RELEASE and RELEASE COMPLETE messages, the User-user information element has a network dependent maximum size of 35 or 131 octets. The evolution to a single maximum value is the long term objective; the exact maximum value is the subject of further study. In USER INFORMATION messages sent in association with a circuit-mode connection, the Useruser information element has a network dependent maximum size of 35 or 131 octets. For USER INFORMATION messages sent in a temporary or permanent user-user signalling connection, the user information field contained inside this information element has a maximum size equal to the maximum size of messages defined in clause 3, that is 260 octets.
NOTE The User-user information element is transported transparently by an ISDN between a call originating entity, e.g. a calling user and the addressed entity, e.g. a remote user or a high layer function network node addressed by the call originating entity.
(05/98)
101
8 0
7 1
6 1
5 4 3 User-user information element identifier 1 1 1 Length of user-user contents Protocol discriminator User information
2 1
1 0
Octet 1 2 3 4 etc.
Figure 4-36/Q.931 User-user information element
Table 4-26/Q.931 User-user information element

Protocol discriminator (octet 3) Bits 87654321 00000000 00000001 00000010 00000011 00000100 00000101 00000111 00001000 00010000 through 00111111 01000000 through 01001111 01010000 through 11111110
User-specific protocol (Note 1) OSI high layer protocols Recommendation X.244 [44] (Note 2) Reserved for system management convergence function IA5 characters (Note 4) X.208 and X.209 coded user information (Note 5) Recommendation V.120 [9] rate adaption Q.931/I.451 user-network call control messages Reserved for other network layer or layer 3 protocols, including Recommendation X.25 [5] (Note 3)
National use Reserved for other network layer or layer 3 protocols, including Recommendation X.25 (Note 3)
All other values are reserved. NOTE 1 The user information is structured according to user needs. NOTE 2 The user information is structured according to Recommendation X.244 which specifies the structure of X.25 call user data. NOTE 3 These values are reserved to discriminate these protocol discriminators from the first octet of an X.25 packet including general format identifier. NOTE 4 The user information consists of IA5 characters. NOTE 5 The number of X.208 and X.209 components contained in a User-user information element as well as their semantics and use are user-application dependent and may be subject to other Recommendations.
4.6
Information element for packet communications
The information elements defined below are intended to be used in the support of packet communications as described in clause 6 and Recommendation X.31 [14]. The use of these information elements for out-of-band call control for packet calls is for further study.
102
(05/98)
4.6.1
Closed user group
The purpose of the Closed user group information element is to indicate the closed user group to be used for that call. It may be used for X.25 packet-mode calls when either an X.25 CUG selection facility or an X.25 CUG with Outgoing Access selection facility is received in an X.25 Incoming Call packet and X.25 and Q.931 mapping applies. The Closed user group information element is coded as shown in Figure 4-37 and Table 4-27. The maximum length of this information element is 7 octets.
8 0 ext. 1 Spare 0 7 1 6 5 4 3 2 Closed user group information element identifier 0 0 0 1 1 Length of information element contents Spare 0 0 0 CUG indication CUG index code (IA5) characters) 1 1 Octet 1 2 3 4 etc.
Figure 4-37/Q.931 Closed user group information element
Table 4-27/Q.931 Closed user group information element

CUG indication (octet 3) Bits 321 0 0 1 Closed user group selection 0 1 0 Closed user group with outgoing access selection and indication All other values are reserved. CUG index code (octet 4) Bits 7654321 0110000 0110001 0110010 0110011 0110100 0110101 0110110 0110111 0111000 0111001 CUG index 0 1 2 3 4 5 6 7 8 9
All other values are reserved. NOTE The CUG index code should be represented by up to four IA5 characters, encoded as shown above.
(05/98)
103
4.6.2
End-to-end transit delay
The purpose of the End-to-end transit delay information element is to request and indicate the nominal maximum permissible transit delay applicable on a per call basis to that virtual call. The End-to-end transit delay information element is coded as shown in Figure 4-38 and Table 4-28. The maximum length of this information element is 11 octets.
8 0 ext. 0 ext. 0 ext. 1 ext. 0 ext. 0 ext. 1 ext. 0 ext. 0 ext. 1 7 1 6 5 4 3 2 1 End-to-end transit delay information element identifier 0 0 0 0 1 0 Length of end-to-end transit delay contents Spare Cumulative transit 0 0 0 0 delay value Cumulative transit delay value (cont.) Cumulative transit delay value (cont.)
Requested end-toSpare end transit delay value 0 0 0 0 Requested end-to-end transit delay value (cont.)
Octet 1 2 3 3a 3b 4* (Note 1) 4a* 4b* 5* (Note 2) 5a* 5b*
Requested end-to-end transit delay value (cont.)

Maximum end-toSpare end transit delay value 0 0 0 Maximum transit delay value (cont.)
Maximum transit delay value (cont.)
NOTE 1 Octets 4, 4a and 4b are optional. If present, these octets are always interpreted as Requested end-to-end transit delay. NOTE 2 Octets 5, 5a and 5b are optional. If present, octets 4, 4a and 4b must also be present.
Figure 4-38/Q.931 End-to-end transit delay information element
104
(05/98)
Table 4-28/Q.931 End-to-end transit delay information element

Cumulative transit delay value [octet 3 (bits 1-2) octets 3a and 3b] Cumulative transit delay value binary encoded in milliseconds. Bit 2 of octet 3 is the highest order bit and bit 1 of octet 3b is the lowest order bit. The cumulative transit delay value occupies 16 bits total. Requested end-to-end transit delay value [octet 4 (bits 1-2) octets 4a and 4b] Requested end-to-end transit delay value binary encoded in milliseconds. Bit 2 of octet 4 is the highest order bit and bit 1 of octet 4b is the lowest order bit. The requested end-to-end transit delay value occupies 16 bits total. Maximum end-to-end transit delay value [octet 5 (bits 1-2) octets 5a and 5b] Maximum end-to-end transit delay value binary encoded in milliseconds. Bit 2 of octet 5 is the highest order bit and bit 1 of octet 5b is the lowest order bit. The maximum end-to-end transit delay value occupies 16 bits total. NOTE For an X.31 type of access to an ISDN, the procedures only apply in the notification phase at the terminating exchange. At the terminating exchange, if the End-to-End Transit Delay facility is present in the X.25 [5] incoming call request packet, the contents should be copied into End-to-end transit delay information element as follows: i) The cumulative transit delay field (octets 3 and 4) of the X.25 end-to-end transit delay facility should be copied into octets 3, 3a and 3b. The bit order should be preserved as described above in the description. ii) If octets 5 and 6 are present in the X.25 end-to-end transit delay facility, they should be interpreted as the requested end-to-end transit delay value. The value present should be copied into octets 4, 4a and 4b. The bit order should be preserved as described above in the description. iii) If octets 7 and 8 are present in the X.25 end-to-end transit delay facility, the value present is the minimum end-to-end transit delay allowed. Octets 7 and 8 should be copied into octets 5, 5a and 5b. The bit order should be preserved as described above in the description.
4.6.3
Information rate
The purpose of the Information rate information element is to notify the terminating user of the throughput indicated by the incoming X.25 call request packet. The Information rate information element is coded as shown in Figure 4-39 and Tables 4-29 and 4-30. The maximum length of this information element is 6 octets.
(05/98)
105
8 0 ext. 1 ext. 1 ext. 1 ext. 1
6 5 4 3 2 Information rate information element identifier 1 1 0 0 0 0 Length of information rate contents Spare Incoming information rate 0 0 Spare Outgoing information rate 0 0 Spare 0 0 Minimum incoming information rate Spare 0 0 Minimum outgoing information rate
1 0
Octet 1 2 3 4 5 6
NOTE This information element applies only in the notification phase at the terminating exchange. If the throughput class facility/minimum throughput class facility is present in the X.25 incoming call packet, the contents may be copied into the Information rate information element. The Information rate for the direction of data transmission from the calling user is copied into octet 3/5. The information rate for the direction of data transmission from the called user is copied into octet 4/6. The bit order should be preserved as described in Table 4-30.
Figure 4-39/Q.931 Information rate information element Table 4-29/Q.931 Information rate information element
Incoming/outgoing information rate (octets 3 and 4) The incoming outgoing information rate fields are used to indicate the information rate in the direction network-to-user, and user-to-network, respectively. The information rate for the direction of data transmission from the calling DTE is indicated in bits 5, 4, 3, 2 and 1 of octet 3. The information rate for the direction of data transmission from the called DTE is indicated in bits 5, 4, 3, 2 and 1 of octet 4. The bits are coded as specified in Table 4-30. Minimum incoming/outgoing information rate (octets 5 and 6) The minimum information rate for the direction of data transmission from the calling DTE is indicated in bits 5, 4, 3, 2 and 1 of octet 5. The minimum information rate for the direction of data transmission from the called DTE is indicated in bits 5, 4, 3, 2 and 1 of octet 6. The bits are encoded as specified in Table 4-30.
106
(05/98)
Table 4-30/Q.931 Throughput class coding

Bits 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 3 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1 2 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 Throughput class (bit/s) Reserved Reserved Reserved 75 150 300 600 1 200 2 400 4 800 9 600 19 200 48 000 64 000 Reserved Reserved
4.6.4
Packet layer binary parameters
The purpose of the Packet layer binary parameters information element is to indicate requested layer 3 parameter values to be used for the call. The Packet layer binary parameters information element is coded as shown in Figure 4-40 and Table 4-31. The maximum length of this information element is 3 octets.
8 0 ext. 1 7 6 5 4 3 2 1 Packet layer binary parameters information element identifier 1 0 0 0 1 0 0 Length of packer layer binary parameters contents Spare Fast selected Exp Delivery Modulus 0 0 data conf. Octet 1 2 3
Figure 4-40/Q.931 Packet layer binary parameters information element
(05/98)
107
Table 4-31/Q.931 Packet layer binary parameters information element

Fast select (octet 3) Bits 54 00 01 10 11
Fast select not requested Fast select requested with no restriction of response Fast select requested with restrictions of response
Expedited data (octet 3) Bit 3 0 No request/request denied 1 Request indicated/request accepted Delivery confirmation (octet 3) Bit 2 0 Link-by-link confirmation 1 End-to-end confirmation Modulus (octet 3) Bit 1 0 1
Modulus 8 sequencing Modulus 128 sequencing
4.6.5
Packet layer window size
The purpose of the Packet layer window size information element is to indicate the requested layer 3 window size value to be used for the call. The values are binary encoded. The Packet layer window size information element is coded as shown in Figure 4-41. The maximum length of this information element is 4 octets.
8 0 ext. 1 ext. 1 7 1 6 5 4 3 2 Packet layer window size information element identifier 0 0 0 1 0 Length of packer layer window size contents Forward value Backward value 1 1 Octet 1 2 3 4* (Note)
NOTE This octet may be omitted. When omitted, it indicates a request for the default value.
Figure 4-41/Q.931 Packet layer window size information element
108
(05/98)
4.6.6
Packet size
The purpose of the Packet size information element is to indicate the requested packet size values to be used for the call. The values are encoded log 2. The Packet size information element is coded as shown in Figure 4-42. The maximum length of this information element is 4 octets.
8 0 ext. 1 ext. 1 7 1 6 5 4 3 2 Packet size information element identifier 0 0 0 1 1 Length of packet size contents Forward value (Note 2) Backward value (Note 2) 1 0 Octet 1 2 3 4* (Note 1)
NOTE 1 This octet may be omitted. When omitted, it indicates a request for the default value. NOTE 2 000 0000 is reserved.
Figure 4-42/Q.931 Packet size information element
4.6.7
Redirecting number
The purpose of the Redirecting number information element is to identify the number from which a call diversion or transfer was invoked. The Redirecting number information element is coded as shown in Figure 4-43 and Table 4-32. The maximum length of this information element is network dependent.
8 0 ext. 0/1 ext. 0/1 ext. 1 Spare 0 7 1 6 5 4 3 2 1 Redirecting number information element identifier 1 1 0 1 0 0 Length of redirecting number contents Type of number Numbering plan identification Spare 0 Screening 0 indicator Reason for redirection Octet 1 2 3 3a* 1 3b* 1 4 etc.
Presentation indicator Spare 0 0
0 Number digits (IA5 characters)
Figure 4-43/Q.931 Redirecting number information element
(05/98)
109
Table 4-32/Q.931 Redirecting number information element

Type of number (octet 3) (Note 1) Bits 765 000 Unknown (Note 2) 001 International number (Note 3) 010 National number (Note 3) 011 Network specific number (Note 4) 100 Subscriber number (Note 3) 110 Abbreviated number 111 Reserved for extension All other values are reserved. NOTE 1 For the definition of international, national and subscriber number, see Recommendation I.330 [18]. NOTE 2 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 of digits field is organized according to the network dialling plan; e.g. prefix or escape digits might be present. NOTE 3 Prefix or escape digits shall not be included. NOTE 4 The type of number "network specific number" is used to indicate administration/service number specific to the serving network, e.g. used to access an operator. Numbering plan identification (octet 3) Numbering plan (applies for type of number = 000, 001, 010 and 100) Bits 4321 0 0 0 0 Unknown (Note 5) 0 0 0 1 ISDN/telephony numbering plan (Recommendation E.164 [19]) 0 0 1 1 Data numbering plan (Recommendation X.121 [21]) 0 1 0 0 Telex numbering plan (Recommendation F.69 [22]) 1 0 0 0 National standard numbering plan 1 0 0 1 Private numbering plan 1 1 1 1 Reserved for extension All other values are reserved. NOTE 5 The numbering plan "unknown" is used when the user on network has no knowledge of the numbering plan. In this case, the number digits field is organized according to the network dialling plan; e.g. prefix or escape digits might be present. Presentation indicator (octet 3a) Bits 76 00 Presentation allowed 01 Presentation restricted 10 Number not available due to interworking 11 Reserved NOTE 6 The meaning and use of this field is defined in clause 3/Q.951 and clause 4/Q.951
110
(05/98)
Table 4-32/Q.931 Redirecting number information element (concluded)

Screening indicator (octet 3a) Bits 21 00 User-provided, not screened 01 User-provided, verified and passed 10 User-provided, verified and failed 11 Network provided NOTE 7 If octet 3a is omitted, "00 user-provided, not screened" is assumed. Reason for redirection (octet 3b) Bits 4321 0 0 0 0 Unknown 0 0 0 1 Call forwarding busy or called DTE busy 0 0 1 0 Call forwarding no reply 0 1 0 0 Call deflection 1 0 0 1 Called DTE out of order 1 0 1 0 Call forwarding by the called DTE 1 1 1 1 Call forwarding unconditional or systematic call redirection All other values are reserved. Number digits (octets 4, etc.) This field is coded with IA5 characters, according to the formats specified in the appropriate numbering/dialling plan.
4.6.8
Reverse charging indication
The purpose of the Reverse charging information element is to indicate that reverse charging has been requested for that call. It may be used for X.25 packet-mode calls when either an X.25 Reverse charging facility is received in an X.25 Incoming Call packet and X.25 and Q.931 mapping applies. The Reverse charging information element is coded as shown in Figure 4-44 and Table 4-33. The maximum length of this information element is 3 octets.
8 0 ext. 1 7 1 6 5 4 3 2 1 Reverse charging indication information element identifier 0 0 1 0 1 0 Length of information element contents Spare Reverse charging indication 0 0 0 Octet 1 2 3
Figure 4-44/Q.931 Reverse charging indication information element
Table 4-33/Q.931 Reverse charging indication information element

Reverse charging indication (octet 3) Bits 321 0 0 1 Reverse charging requested All other values are reserved.
(05/98)
111
4.6.9
Transit delay selection and indication
The purpose of the Transit delay selection and indication information element is to request the nominal maximum permissible transit delay applicable on a per call basis to that virtual call. The Transit delay selection and indication information element is coded as shown in Figure 4-45 and Table 4-34. The maximum length of this information element is 5 octets.
8 0 ext. 0 ext. 0 ext. 1 7 6 5 4 3 2 1 Transit delay selection and indication information element identifier 1 0 0 0 0 1 1 Length of transit delay selection and indication contents Transit delay selection Spare and indication value 0 0 0 0 0 Transit delay selection and indication value (cont.) Transit delay selection and indication value (cont.) Octet 1 2 3 3a 3b
Figure 4-45/Q.931 Transit delay selection and indication information element
Table 4-34/Q.931 Transit delay selection and indication information element

Transit delay selection and indication value [octet 3 (bits 1-2), octets 3a and 3b] Transit delay value binary encoded in milliseconds. Bit 2 of octet 3 is the highest order bit and bit 1 of octet 3b is the lowest order bit. The transit delay value occupies 16 bits total. NOTE For an X.31 [14] type of access to an ISDN, the procedures only apply in the notification phase at the terminating exchange. At the terminating exchange, if the Transit Delay Selection and Indication facility is present in the X.25 [5] incoming call request packet, the two-octet value should be copied into octets 3, 3a and 3b with the highest order bit contained in bit 2 of octet 3 and the lowest order bit contained in bit 1 of octet 3b.
Circuit-switched call control procedures
This clause provides the D-channel signalling procedures in support of circuit-mode bearer capabilities other than multirate (64 kbit/s base rate). Extensions to this basic protocol and exceptions that apply in the case of packet-mode connections or of circuit-mode multirate (64 kbit/s base rate) or supplementary services are described elsewhere in this Recommendation. The call states referred to in this clause cover the states perceived by the network, states perceived by the user, and states which are common to both user and network. Unless specifically qualified, all states described in the following text should be understood as common (see 2.1.1 and 2.1.2 for user and network call states respectively). An overview diagram of call states is given in Figures A.2 and A.3 (see Annex A). Detailed Specification and Description Language (SDL) diagrams for the procedures specified in this clause are contained in Figures A.4 through A.6. When there is an ambiguity in the narrative text, the SDL diagrams in Figures A.4 through A.6 should be used to resolve the conflict. Where the text and the SDLs are in disagreement, the text should be used as the prime source.
112
(05/98)
NOTE 1 This clause describes the sequences of messages associated with the control of circuit-switched connections. Optional extensions to this basic protocol and exceptions that apply in the case of packet-mode connections or supplementary services are described elsewhere in this Recommendation, in Recommendation Q.932 [4] or the Q.95x-series Recommendations [83]. Annex D also contains extensions to the basic call establishment procedures defined in clause 5 for symmetric signalling.
All messages in this Recommendation may contain two types of information elements, functional and/or stimulus. Functional information elements are characterized as requiring a degree of intelligent processing by the terminal in either their generation or analysis. Stimulus information elements, on the other hand, are either generated as a result of a single event at the user/terminal interface or contain a basic instruction from the network to be executed by the terminal. As a general principle, all the messages sent by the network to the user may contain a Display information element whose contents may be displayed by the terminal; the content of this information element shall be network dependent.
NOTE 2 Keypad facility information elements shall be conveyed only in the direction user-to-network. Display information elements shall be conveyed only in the direction network-to-user.
In addition to the messages exchanged as described in the following subclauses, INFORMATION messages for call control may be sent by the user or by the network only after the first response to a SETUP message has been sent or received, and before the clearing of the call reference is initiated. An INFORMATION message received in the Release Request state may be ignored. In order to accommodate the transfer of Layer 3 messages which exceeds the data link layer maximum frame length (i.e. defined in Recommendation Q.921 [3]), a method of message segmentation and reassembly may optionally be implemented as described in Annex H. Message segmentation shall only be used where all the information comprising the unsegmented message is available at the time of sending the first message segment.
NOTE 3 Message segmentation is not used to replace existing procedures where information is yet to be provided by call control, e.g. digit-by-digit sending in overlap mode, although this may be used in addition. Message segmentation shall only be used when the message length exceeds the value of the N201 parameter defined in Recommendation Q.921 [3].
5.1
Call establishment at the originating interface
Before these procedures are invoked, a reliable data link connection must be established between the user (TE/NT2) and the network. All layer 3 messages shall be sent to the data link layer using a DL-DATA request primitive. The data link services described in Recommendations Q.920/I.440 [45] and Q.921 [3] are assumed. 5.1.1 Call request
A user initiates call establishment by transferring a SETUP message across the user-network interface. Following the transmission of the SETUP message, the call shall be considered by the user to be in the call initiated state. The message shall always contain a call reference, selected according to the procedures given in 4.3. In selecting a call reference, the dummy call reference value shall not be used in association with the basic call. The bearer capability information element is mandatory in the SETUP message, even in the case of overlap sending. If the user knows all appropriate channels controlled by the D-channel are in use, it shall not transfer a SETUP message across the user-network interface. If the user does not monitor the status of channels in use, it may send a SETUP during an all channels busy condition. In this case, the network returns a RELEASE COMPLETE message with cause No. 34, no circuit/channel available.
(05/98)
113
Furthermore, the SETUP message may also contain all or part of the call information (i.e. address and facility requests) necessary for call establishment depending on whether en bloc or overlap procedures are being used respectively (see 5.1.3). If en bloc sending is used, the SETUP message shall contain all the information required by the network to process the call, and, in particular, the called party address information if present, is contained as follows: a) b) in the called party number information element possibly completed by the called party subaddress information element; or the Keypad facility information element which may also be used to convey other call information.
NOTE The support of a) is mandatory in all networks. Whether the support of b) is mandatory or optional requires further study.
If en bloc sending is used, the SETUP message may contain the sending complete indication (i.e. either the Sending complete information element or the "#" character within the Called party number information element). It is mandatory for the network to recognize at least one of the sending complete indications; however, the recognition of the sending complete IE is preferred. For overlap sending, see 5.1.3. Called party subaddress information, if present, shall be given in the Called party subaddress information element and, in the case of overlap sending, shall be sent only in the SETUP message. 5.1.2 a) B-channel selection Originating channel is indicated, no acceptable alternative [i.e. channel is indicated by the information channel selection field of octet 3 (bits 2-1) and, if applicable, octet 3.3, and the preferred/exclusive field (bit 4 of octet 3) is set to "1" in the Channel identification information element]; or channel is indicated, any alternative is acceptable [i.e. channel is indicated by the information channel selection field of octet 3 (bits 2-1) and, if applicable, octet 3.3, and the preferred/exclusive field (bit 4 of octet 3) is set to "0" in the Channel identification information element]; or any channel is acceptable [i.e. either the information channel selection field of octet 3 (bits 2-1) of the Channel identification information element indicate "any channel" or the Channel identification information element is not present].
In the SETUP message, the user will indicate one of the following:
b)
c)
If no indication is included, alternative c) is assumed. In cases a) and b), if the indicated channel is available, the network selects it for the call. In case b), if the network cannot grant the preferred channel, it selects any other available B-channel associated with the D-channel. In case c), the network selects any available B-channel associated with the D-channel.
NOTE It is recommended that TEs connected to the ISDN basic access in a point-to-multipoint configuration use alternative c) for basic circuit-switched call control unless the TE is already using a given B-channel.
The selected B-channel is indicated in the Channel identification information element coded as "channel is indicated, no acceptable alternative" in the first message returned by the network in response to the SETUP message (i.e. a SETUP ACKNOWLEDGE or CALL PROCEEDING message). After transmitting this message, the network shall activate the B-channel connection.
114
(05/98)
The user need not attach until receiving a CALL PROCEEDING/SETUP ACKNOWLEDGE/PROGRESS/ALERTING message with the progress indicator No. 8, in-band information or appropriate pattern is now available, or progress indicator No. 1, call is not end-toend ISDN; further call progress information may be available in-band. Prior to this time, the network cannot assume that the user has attached to the B-channel. After this time, the user shall be connected to the B-channel, provided the equipment does not generate local tone. Upon receipt of the CONNECT message, the user shall attach to the B-channel (if it has not already done so). In case a) if the specified channel is not available, and in cases b) and c) if no channel is available, a RELEASE COMPLETE message with cause No. 44, requested circuit/channel not available or cause No. 34, no circuit/channel available, respectively, is sent by the network as described in 5.3. In case a), if the specified channel does not exist, cause No. 82, identified channel does not exist, is included in the RELEASE COMPLETE message. 5.1.3 a) b) c) Overlap sending no called number information; or incomplete called number information; or called number information which the network cannot determine to be complete.
If overlap sending is used, the SETUP message contains either:
On receipt of such a SETUP message, the network starts timer T302 (the value of timer T302 is specified in 9.1), sends a SETUP ACKNOWLEDGE message to the user and enters the overlap sending state. In case a), the network will return dial tone, if required by the tone option. In this case, it may include progress indicator No. 8, in-band information or appropriate pattern is now available, in the SETUP ACKNOWLEDGE message.
NOTE 1 Some networks which systematically provide the conventional telephone dial tone will not generate the progress indicator when providing the dial tone.
When the SETUP ACKNOWLEDGE message is received, the user enters the overlap sending state and optionally starts timer T304 (the value of timer T304 is specified in 9.2). After receiving the SETUP ACKNOWLEDGE message, the user sends the remainder of the call information (if any) in one or more INFORMATION messages. The called party number information may be provided by the user as follows: a) b) in the called party number information element; or in the Keypad facility information element, exclusively.
The called party number must be sent in a unique way.

NOTE 2 The support of a) is mandatory in all networks. Whether the support of b) is mandatory or optional requires further study. NOTE 3 Besides the possible called party number [conveyed by method a) or b) as described above], the INFORMATION messages may contain additional call information (i.e. for supplementary services). The interpretation of the contents of Keypad facility information elements is network-specific, and in accordance with the dialling plan provided to that user. It should be noted that the user shall transfer all the additional call information (contained within the Keypad facility information element) before the network determines that the called party number (contained within the Called party number information element or the Keypad facility information element) is complete, and terminates the overlap sending procedure using the CALL PROCEEDING message as recommended in 5.1.5.2.
If, for symmetry purposes, the user employs timer T304, the user restarts timer T304 when each INFORMATION message is sent.
(05/98)
115
The call information in the message which completes the information sending may contain a sending complete indication, (e.g. the # character or, as a network option, the sending complete information element) appropriate to the dialling plan being used. The network shall restart timer T302 on the receipt of every INFORMATION message not containing a sending complete indication. 5.1.4 Invalid call information
If, following the receipt of a SETUP message or during overlap sending, the network determines that the call information received from the user is invalid, (e.g. invalid number), then the network shall follow the procedures described in 5.3 with a cause such as one of the following: No. 1 Unallocated (unassigned) number; No. 3 No route to destination; No. 22 Number changed; No. 28 Invalid number format (address incomplete). 5.1.5 5.1.5.1 Call proceeding Call proceeding, en bloc sending
If en bloc sending is used, (i.e. the network can determine that the SETUP message contains all the information required from the user to establish the call), and if the network can determine that access to the requested service is authorized and available, the network shall send a CALL PROCEEDING message to the user. This acknowledges the SETUP message and indicates that the call is being processed. The network will then enter the Outgoing Call Proceeding state. When the user receives the CALL PROCEEDING message, the user shall also enter the Outgoing Call Proceeding state. Similarly, if the network determines that a requested service is not authorized or is not available, the network shall initiate call clearing in accordance with 5.3, with one of the following causes: No. 57 Bearer capability not authorized; No. 58 Bearer capability not presently available; No. 63 Service or option not available, unspecified; or No. 65 Bearer capability not implemented.
NOTE 1 If a supplementary service is not authorized or is not available, the procedure to be used is defined in the supplementary service control procedures. NOTE 2 When the network cannot assign a channel due to congestion, the procedures of 5.1.2 shall be followed.
5.1.5.2 a) b)
Call proceeding, overlap sending the receipt by the network of a sending complete indication which the network understands; or analysis by the network that all call information necessary to effect call establishment has been received,
If overlap sending is used, then following the occurrence of one of these conditions:
and if the network can determine that access to the requested service and supplementary service is authorized and available, the network shall: send a CALL PROCEEDING message to the user; stop timer T302; and enter the Outgoing Call Proceeding state. Similarly, if the network determines that a requested service or supplementary service is not authorized or is not available, the network shall initiate call clearing in accordance with 5.3, with one of the following causes: No. 57 Bearer capability not authorized;
116
(05/98)
No. 58 Bearer capability not presently available; No. 63 Service or option not available, unspecified; or No. 65 Bearer capability not implemented.
NOTE 1 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. NOTE 2 If a supplementary service is not authorized or is not available, the procedure to be used is defined in the supplementary service control procedures. NOTE 3 When the network cannot assign a channel due to congestion, the procedures of 5.1.2 shall be followed.
When the user receives the CALL PROCEEDING message, the user shall enter the outgoing call proceeding state. If, for symmetry purposes, the calling user employs timer T304, the user shall stop timer T304 when the CALL PROCEEDING message is received. If, for symmetry purposes, the calling user employs timer T304 then, on expiry of T304, the user shall initiate call clearing in accordance with 5.3 with cause No. 102, recovery on timer expiry. An alerting or connect indication received from the called party will stop timer T302 and cause an ALERTING or CONNECT message respectively to be sent to the calling user. No CALL PROCEEDING message shall be sent by the network. If, for symmetry purposes, the calling user employs timer T304, the user shall stop timer T304 on receiving the ALERTING or CONNECT message. At the expiration of timer T302, the network shall: i) initiate call clearing in accordance with 5.3, with cause No. 28, invalid number format (address incomplete) sent to the calling user and with cause No. 102, recovery on timer expiry, sent towards the called user, if the network determines that the call information is definitely incomplete; otherwise send a CALL PROCEEDING message and enter the outgoing call proceeding state. Notification of interworking at the originating interface
ii) 5.1.6
During call establishment, the call may leave the ISDN environment, e.g. because of interworking with another network, with a non-ISDN user, or with non-ISDN equipment within the called user's premises. When such situations occur, a progress indication shall be returned to the calling user either: a) b) in an appropriate call control message when a state change is required: CALL PROCEEDING, ALERTING, SETUP ACKNOWLEDGE or CONNECT; or in the PROGRESS message when no state change is appropriate.
One of the following progress description values shall be included in the Progress indicator information element in the messages sent to the user, (for further information, see Annex G). 1) 2) 3) No. 1 Call is not end-to-end ISDN; further call progress information may be available inband; No. 2 Destination address is non-ISDN; No. 4 Call has returned to the ISDN.
If the Progress indicator information element is included in a call control message, the procedures as described in the rest of 5.1 apply but T310 shall not be started if progress indicator 1 or 2 has been delivered in the CALL PROCEEDING message or in a previous PROGRESS message. If the Progress indicator information element is included in the Progress message, no state change will occur but any supervisory timers shall be stopped except user timer T301 and network timer T302. In
(05/98)
117
both cases, if Progress description No 1 is received by the user, the user shall connect to (if not connected already) and then monitor the B channel for further in-band information. If the interface at which the progress indication originates is the point at which a call enters the ISDN environment from a non-ISDN environment, one or more of the following progress indicator information elements shall be included in the SETUP message sent to the network: i) ii) 5.1.7 No. 1 Call is not end-to-end ISDN; further call progress information may be available inband; No. 3 Origination address is non-ISDN. Call confirmation indication
Upon receiving an indication that user alerting has been initiated at the called address, the network shall send an ALERTING message across the user-network interface of the calling address, and shall enter the call delivered state. When the user receives the ALERTING message, the user may begin an internally-generated alerting indication and shall enter the call delivered state. 5.1.8 Call connected
Upon the network receiving an indication that the call has been accepted, the network shall send a CONNECT message across the user-network interface to the calling user, and shall enter the Active state. As a network option, the Date/time information element may be included in the CONNECT message. This message indicates to the calling user that a connection has been established through the network and stops a possible local indication of alerting. On receipt of the CONNECT message, the calling user shall stop any user-generated alerting indication, may optionally send a CONNECT ACKNOWLEDGE message and shall enter the active state. The network shall not take any action on receipt of a CONNECT ACKNOWLEDGE message when it perceives the call to be in the active state. 5.1.9 Call rejection
Upon receiving an indication that the network or the called user is unable to accept the call, the network shall initiate call clearing at the originating user-network interface as described in 5.3, using the cause provided by the terminating network or the called user. 5.1.10 Transit network selection When the transit network selection information element is present, the call shall be processed according to Annex C. 5.2 Call establishment at the destination interface
This procedure assumes that a data link connection providing services described in Recommendation Q.920/I.440 [45] may not exist before the first layer 3 message (SETUP) is transferred across the interface. However, reliable data link connections must be established by each of the users (terminals and/or NT2s) at the interface before they respond to the SETUP message. Data link connections may be established by the TA, TE or NT2 as soon as a TEI is assigned (either locally or by automatic assignment procedure), and may be retained indefinitely. This may be recommended as a network option. The SETUP message offered on a point-to-point data link shall be delivered to layer 2 using a DL-DATA request primitive. No use shall be made of the DL-UNIT-DATA request primitive other than for operation using the broadcast capability of the data link layer.
118
(05/98)
The call reference contained in all messages exchanged across the user-network interface shall contain the call reference value specified in the SETUP message delivered by the network. In selecting a call reference, the dummy call reference shall not be used in association with the basic call. 5.2.1 Incoming call
The network will indicate the arrival of a call at the user-network interface by transferring a SETUP message across the interface. This message is sent if the network can select an idle B-channel. In some circumstances (e.g. provision of other bearer services, see 6.1), the SETUP message may also be sent when no B-channel is idle. The number of calls presented in these circumstances may be limited. In addition to the mandatory information elements, the SETUP message may include, as required, the information elements described in 3.1.14 (e.g. Display, Low layer compatibility). If a multipoint terminal configuration exists at the user-network interface, this message shall be sent using a broadcast capability at the data link layer. In this case, the SETUP message should contain the appropriate part of the called party number as required and/or subaddress if provided. However, if the network has knowledge that a single-point configuration exists at the interface, a point-to-point data link shall be used to carry the SETUP message. The knowledge that a point-to-point configuration exists may be based on information entered at the time of configuration of the access. After sending the SETUP message, the network starts timer T303. If the SETUP message is sent via a broadcast data link, timer T312 shall also be started. (The values of timers T303 and T312 are specified in 9.1.) The network then enters the call present state.
NOTE 1 Timer T312 is used to supervise the retention of the call reference when the SETUP message was transmitted by a broadcast data link. The value of timer T312 is such that if a network disconnect indication is received during the call establishment phase, it maximizes the probability that all responding users will be released prior to release of the call reference. Refer to 5.3.2 e) and 5.2.5.3 (Case 1) for procedures to be followed on expiry of timer T312.
If en bloc receiving is used, the SETUP message shall contain all the information required by the called user to process the call. In this case, the SETUP message may contain the Sending complete information element. Upon receipt of a SETUP message, the user will enter the Call present state. Depending on the contents of the received message, either en bloc receiving procedure (see 5.2.5.1) or overlap receiving procedure (see 5.2.4) follows. However, if the SETUP message includes the Sending complete information element, en bloc receiving procedure shall follow. Therefore, those users who support overlap receiving procedure shall recognize the Sending complete information element.
NOTE 2 Users supporting only the en bloc receiving procedure need not recognize the Sending complete information element and may directly analyze the received SETUP message on the assumption that all the call information is contained in the message.
If no response to the SETUP message is received by the network before the first expiry of timer T303, the SETUP message will be retransmitted and timers T303 and T312 restarted.
NOTE 3 In the case of overlap sending within the network, the appropriate part of the called party number as required (e.g. for supplementary services) may also be conveyed by means of INFORMATION messages to the called user on a point-to-point data link (see 5.2.4).
(05/98)
119
5.2.2
Compatibility checking
A user receiving a SETUP message shall perform compatibility checking before responding to that SETUP message. Any reference to user in 5.2.3 through 5.2.7 implicitly refers to a compatible user equipment. Annex B defines compatibility checking to be performed by users upon receiving a SETUP message. When the SETUP message is delivered via a broadcast data link, an incompatible user shall either: a) b) ignore the incoming call; or respond by sending a RELEASE COMPLETE message with cause No. 88, incompatible destination, and enter the Null state. The network processes this RELEASE COMPLETE message in accordance with 5.2.5.3.
When the SETUP message is delivered via a point-to-point data link, an incompatible user shall respond with RELEASE COMPLETE message with cause No. 88, incompatible destination, and enter the Null state. The network shall process this RELEASE COMPLETE message in accordance with 5.2.5.3. 5.2.3 5.2.3.1 B-channel selection Destination SETUP message delivered by point-to-point data link
When the SETUP message is delivered by a point-to-point data link, negotiation for the selection of a B-channel will be permitted between the network and the user. Only B-channels controlled by the same D-channel will be the subject of the selection procedure. The selection procedure is as follows: a) In the SETUP message, the network will indicate one of the following: 1) channel is indicated, no acceptable alternative [i.e. channel is indicated by the information channel selection field of octet 3 (bits 2-1) and, if applicable, octet 3.3, and the preferred/exclusive field (bit 4 of octet 3) is set to "1" in the Channel identification information element]; or 2) channel is indicated, any alternative is acceptable [i.e. channel is indicated by the information channel selection field of octet 3 (bits 2-1) and, if applicable, octet 3.3, and the preferred/exclusive field (bit 4 of octet 3) is set to "0" in the Channel identification information element]; or 3) any channel is acceptable [i.e. either the information channel selection field of octet 3 (bits 2-1) of the Channel identification information element indicate "any channel" or the Channel identification information element is not present]; or 4) no B-channel available [i.e. the information channel field (bits 2 and 1 of octet 3) of the Channel identification information element set to "00"].
NOTE Not all networks will support the no B-channel available condition.
b)
In cases 1) and 2), if the indicated channel is acceptable and available, the user selects it for the call. In case 2), if the user cannot grant the indicated channel, it selects any other available B-channel associated with the D-channel and identifies that channel in the Channel identification information element as "channel is indicated, no acceptable alternative" in the first message sent in response to the SETUP message. In case 3), the user selects any available B-channel associated with the D-channel and identifies that channel in the first message sent in response to the SETUP message. If in case 1), the B-channel indicated in the first response message is not the channel offered by the network, or in cases 2) and 3) the B-channel indicated in the first response message is
120
(05/98)
unacceptable to the network, it will clear the call by sending a RELEASE message with cause No. 6, channel unacceptable. In case 4), the user rejects the call by sending RELEASE COMPLETE message with cause No. 34, no circuit/channel available, unless it is able to proceed with the call. Unless the procedures of the Call Waiting supplementary service (see Q.953-series Recommendations [84]) are followed, the user wishing to re-use a B-channel it has already allocated to another call (e.g. by multiplexing packet calls) shall send the appropriate message containing the channel identification information element, coded as channel is indicated, no alternative acceptable. c) d) e) If no Channel identification information element is present in the first response message, the B-channel indicated in the SETUP message will be assumed. When a B-channel has been selected by the user, that channel may be connected by the user. In case 1) if the indicated B-channel is not available, or in cases 2), 3), and 4) if no B-channel is available and the user cannot proceed with the offered call, the user returns a RELEASE COMPLETE message with cause No. 44, requested circuit/channel not available, or No. 34, no circuit/channel available, respectively, and returns to the Null state.
See 5.2.4 and 5.2.5 for the appropriate first response to the SETUP message. 5.2.3.2 SETUP message delivered by broadcast data link
When the SETUP message is delivered by a broadcast data link, the channel selection procedure, provided in 5.2.3.1, is not applicable. The network sends a SETUP message with the Channel identification information element indicating one of the following: a) channel indicated, no alternative is acceptable [i.e. channel is indicated by the information channel selection field of octet 3 (bits 2-1) and, if applicable, octet 3.3, and the preferred/exclusive field (bit 4 of octet 3) is set to "1" in the Channel identification information element]; or no channel available [i.e. the information channel field (bits 2 and 1 of octet 3) of the Channel identification information element set to "00"].
b)
In case a), if the user can accept the call on the indicated channel, the user shall send the appropriate message (see 5.2.4 and 5.2.5). If the user cannot accept the call on the indicated channel, the user shall send a RELEASE COMPLETE message with cause No. 44, requested circuit/channel not available. The user, in any case, must not connect to the channel until a CONNECT ACKNOWLEDGE message has been received. In case b), the user not controlling any channel shall send a RELEASE COMPLETE message with cause No. 34, no circuit/channel available. Unless the procedures of the Call Waiting supplementary service (see Q.953-series Recommendations [84]) are followed, the user wishing to reuse a B-channel it has already allocated to another call (e.g. by multiplexing packet calls) shall send the appropriate message containing the Channel identification information element, coded as, channel is indicated, no alternative acceptable. 5.2.4 a) b) c) Overlap receiving no called number information; or incomplete called number information; or called number information which the user cannot determine to be complete; and
When a user determines that a received SETUP message contains either:
(05/98)
121
when the user: d) e) is compatible with other call characteristics (see Annex B); and implements overlap receiving,
the user shall start timer T302; send a SETUP ACKNOWLEDGE message to the network and enter the Overlap receiving state. When the SETUP ACKNOWLEDGE message is received, the network shall: stop timer T303; start timer T304; enter the Overlap receiving state; and send the remainder of the call information (if any) in one or more INFORMATION messages, starting timer T304 when each INFORMATION message is sent. The called party number information is provided in the Called party number information element. The call address information may contain a sending complete indication (e.g. No. or, as a network option, the Sending complete information element) appropriate to the dialling plan being used.
NOTE 1 If the network can determine that sufficient call set-up information will be received by the called user by sending the next INFORMATION message, it is recommended that the INFORMATION message contains the Sending complete information element.
The user shall start timer T302 on receipt of every INFORMATION message not containing a sending complete indication. Following the receipt of a sending complete indication which the user understands, or the determination that sufficient call information has been received, the user shall stop timer T302 (if implemented) and send a CALL PROCEEDING message to the network. Alternatively, depending on internal events, the user may send an ALERTING or a CONNECT message to the network.
NOTE 2 The CALL PROCEEDING message in this case will cause the originating exchange to send a CALL PROCEEDING message to the originating user, if not already sent.
At the expiration of timer T302, the user shall: a) b) initiate clearing in accordance with 5.3, with cause No. 28, invalid number format (address incomplete) if it determines that the call information is definitely incomplete; or if sufficient information has been received, send a CALL PROCEEDING, ALERTING or CONNECT message as appropriate.
At the expiration of timer T304 the network initiates call clearing in accordance with 5.3, with cause No. 28, invalid number format (address incomplete), sent to the calling user, and cause No. 102, recovery on timers expiry, sent to the called user. If, following the receipt of a SETUP message or during overlap receiving, the user determines that the received call information is invalid (e.g. invalid called party number), it shall initiate call clearing in accordance with 5.3 with a cause such as one of the following: No. 1 Unallocated (unassigned) number; No. 3 No route to destination; No. 22 Number changed; No. 28 Invalid number format (incomplete number). Upon receipt of the complete call information, the user may further perform some compatibility checking functions, as outlined in Annex B. When the call is offered on a point-to-point data link, only one SETUP ACKNOWLEDGE message can be received in response to the call offering.
122
(05/98)
When the call is offered to the user on a broadcast data link, multiple SETUP ACKNOWLEDGE messages may be received by the network which shall then complete as many overlap receiving procedures as these SETUP ACKNOWLEDGE messages are received. It is the network responsibility to limit the number of overlap receiving procedures to be completed for a given call. The default maximum is fixed to eight. Some networks will limit the call offering completion in overlap receiving to single data link and will therefore clear the subsequent responding users after the first SETUP ACKNOWLEDGE message has been received, in accordance with the non-selected user clearing procedures described in 5.2.9. 5.2.5 5.2.5.1 Call confirmation Response to en bloc SETUP or completion of overlap receiving
When the user determines that sufficient call set-up information has been received and compatibility requirements (see Annex B) have been satisfied, the user responds with either a CALL PROCEEDING, ALERTING, or CONNECT message (see Note), and enters the Incoming Call Proceeding, Call Received, or Connect Request state respectively.
NOTE A Progress indicator information element may be included in CALL PROCEEDING, ALERTING and CONNECT messages (e.g. when an analogue terminal is connected to an ISDN PABX). The CALL PROCEEDING message may be sent by the user which cannot respond to a SETUP message with an ALERTING, CONNECT, or RELEASE COMPLETE message before expiration of timer T303.
When the SETUP message was delivered via a broadcast data link, an incompatible user shall either: a) b) ignore the incoming call; or respond by sending a RELEASE COMPLETE message with cause No. 88, incompatible destination, and enter the Null state. The network processes this RELEASE COMPLETE message in accordance with 5.2.5.3.
When the SETUP message was delivered via a point-to-point data link, an incompatible user shall respond with a RELEASE COMPLETE message with cause No. 88, incompatible destination. The network processes this RELEASE COMPLETE message in accordance with 5.2.5.3. A busy user which satisfies the compatibility requirements indicated in the SETUP message shall respond with a RELEASE COMPLETE message with cause No. 17, user busy. The network processes this RELEASE COMPLETE message in accordance with 5.2.5.3. If the user wishes to refuse the call, a RELEASE COMPLETE message shall be sent with the cause No. 21, call rejected, and the user returns to the Null state. The network processes this RELEASE COMPLETE message in accordance with 5.2.5.3. 5.2.5.2 Receipt of CALL PROCEEDING and ALERTING
When the SETUP message is delivered on a broadcast data link, the network shall maintain a state machine that tracks the overall progression of the incoming call. The network shall also maintain an associated call state for each responding user as determined by the data link on which a message is received. Upon receipt of the first CALL PROCEEDING message from a user (assuming no other user had previously responded with an ALERTING or CONNECT message when the SETUP message has been delivered on a broadcast data link), the network shall stop timer T303 (or, in the case of overlap receiving, timer T304 for that user); start timer T310, and enter the incoming call proceeding state, Timer T310 shall not be restarted upon receipt of subsequent CALL PROCEEDING messages. When the SETUP message has been delivered on a broadcast data link, the network shall (at a minimum) associate the incoming call proceeding state with each called user that sends a CALL
(05/98)
123
PROCEEDING message as a first response to the broadcast SETUP message prior to expiration of timer T312. Actions to be taken when a user sends a first response to an incoming call after the expiration of timer T312 are described in 5.2.5.4. Upon receipt of the first ALERTING message from a user (assuming no other user has previously responded with a CONNECT message when the SETUP message has been delivered on a broadcast data link), the network shall stop timer T304 for that user (in the case of overlap receiving); stop timer T303 or T310 (if running); start timer T301 (unless another internal alerting supervision timer function exists, e.g. incorporated in call control); enter the call received state, and send a corresponding ALERTING message to the calling user. Timer T301 shall not be restarted upon receipt of subsequent CALL PROCEEDING messages. When the SETUP message has been delivered on a broadcast data link, the network shall (at a minimum) associate the call received state with each called user that sends an ALERTING message either as a first response to the broadcast SETUP message or following a CALL PROCEEDING message. 5.2.5.3 Called user clearing during incoming call establishment
If the SETUP message has been delivered on a point-to-point data link and a RELEASE COMPLETE or DISCONNECT message is received before a CONNECT message has been received, the network shall stop timer T303, T304, T310 or T301 (if running); continue to clear the user as described in 5.3.3, and clear the call to the calling user with the cause received in the RELEASE COMPLETE or DISCONNECT message. If the SETUP message has been delivered on a broadcast data link and a RELEASE COMPLETE message is received whilst timer T303 is running, the cause value received in the RELEASE COMPLETE message shall be retained by the network. If timer T303 expires (i.e. if no valid message such as CALL PROCEEDING, ALERTING or CONNECT has been received), the cause previously retained when a RELEASE COMPLETE message was received is sent back to the calling user in a DISCONNECT message and the network shall enter the Call Abort state. When multiple RELEASE COMPLETE messages are received with different causes, the network shall: 1) 2) ignore any cause No. 88, incompatible destination; and give preference to the following causes (if received) in the order listed below: (highest) 3) No. 17 user busy; No. 21 call rejected; any other received cause may also be included in the clearing message sent to the originating user (see 5.3).
If the SETUP message has been delivered on a broadcast data link and a user which has previously sent a SETUP ACKNOWLEDGE, CALL PROCEEDING or ALERTING message sends a DISCONNECT message to the network, the actions taken by the network depend on whether timer T312 is running and whether other called users have responded to the SETUP message. Case 1 DISCONNECT received prior to expiry of timer T312 If timer T312 is running and the network receives a DISCONNECT message after having received a SETUP ACKNOWLEDGE, CALL PROCEEDING or ALERTING message from a called user (but before receiving a CONNECT message), timer T312, as well as timer T310 or T301 (if running), should continue to run. The network shall retain the cause in the DISCONNECT message and shall continue to clear the user as described in 5.3.3. The network shall stop timer T304 (if running) for this user.
124
(05/98)
Upon expiration of timer T312, if either: a) b) no other users have responded to the incoming call; or all users that have responded to the incoming call have been cleared or are in the process of being cleared,
the network shall stop timer T310 or T301 (if running) and shall clear the call to the calling user. If an ALERTING message has been received, the cause sent to the calling user shall be a cause received from the called user, giving preference to (in order of priority): No. 21, call rejected; any other cause sent by a called user. If only SETUP ACKNOWLEDGE, or CALL PROCEEDING messages have been received, the cause sent to the calling user shall be a cause received from the called user, giving preference to (in order of priority): No. 17, user busy; No. 21, call rejected; any other appropriate cause sent by a called user. Case 2 DISCONNECT received after expiry of timer T312 If timer T312 has expired and the network receives a DISCONNECT message from the called user after having received a SETUP ACKNOWLEDGE, CALL PROCEEDING or ALERTING message (but before receiving a CONNECT message), the network shall continue to clear the user as described in 5.3.3. The network shall stop timer T304 (if running) for this user. If other called users have responded to the SETUP message with a SETUP ACKNOWLEDGE, CALL PROCEEDING or ALERTING message, and still have the opportunity to accept the call by sending a CONNECT message, the network shall retain the cause in the DISCONNECT message. The network shall continue to process the incoming call for the remaining responding users (T310 or T301, if running, shall continue to run). If either: a) b) no other users have responded to the incoming call; or all users that have responded to the incoming call have been cleared or are in the process of being cleared,
the network shall stop timer T310 or T301 (if running) and shall clear the call to the calling user. If an ALERTING message has been received, the cause sent to the calling user shall be a cause received from the called user, giving preference to (in order of priority): No. 21, call rejected; or any other cause sent by a called user. If only SETUP ACKNOWLEDGE, or CALL PROCEEDING message have been received, the cause sent to the calling user shall be a cause received from the called user, giving preference to (in order of priority): No. 17, user busy; No. 21, call rejected; any other appropriate cause sent by a called user. 5.2.5.4 Call failure
If the network does not receive any response to the retransmitted SETUP message prior to the expiration of timer T303, then the network shall initiate clearing procedures towards the calling user with cause No. 18, no user responding. a) b) If the SETUP message was delivered by a broadcast data link, the network shall enter the Call Abort state. If the SETUP message was delivered on a point-to-point data link, the network shall also initiate clearing procedures towards the called user in accordance with 5.3.4, using cause No. 102, recovery on timer expiry.
If the network receives a user's first response to SETUP when in the Call Abort state but before timer T312 has expired, the network shall initiate clearing to the called user as described in 5.3.2 b), except that the cause No. 102, recovery on timer expiry, shall be sent. If the network receives a message that
(05/98)
125
is a user's first response to an incoming call after timer T312 has expired, the network will interpret this message as a message received with an invalid call reference value, as described in 5.8.3.2. If the network has received a CALL PROCEEDING message, but does not receive an ALERTING, CONNECT, or DISCONNECT message prior to the expiration of timer T310, then the network shall initiate clearing procedures towards the calling user with cause No. 18, no user responding, and initiate clearing procedures towards the called user. 1) If the SETUP message is delivered by a broadcast data link, the called user shall be cleared in accordance with 5.3.2 e), except that cause No. 102, recovery on timer expiry, shall be sent. If the SETUP message was delivered on a point-to-point data link, the called user shall be cleared in accordance with 5.3.4 using cause No. 102, recovery on timer expiry.
2)
If the network has received an ALERTING message, but does not receive a CONNECT or DISCONNECT message prior to the expiry of timer T301 (or a corresponding internal alerting supervision timing function), then the network shall initiate clearing procedures towards the calling user with cause No. 19, No answer from user (user alerted), and initiate clearing procedures towards the called user. i) If the SETUP message was delivered by a broadcast data link, the called user shall be cleared in accordance with 5.3.2 e), except that cause No. 102, recovery on timer expiry, shall be sent. If the SETUP message was delivered on a point-to-point data link, the called user shall be cleared in accordance with 5.3.4, using cause No. 102, recovery on timer expiry. Notification of interworking at the terminating interface
ii) 5.2.6
During call establishment the call may enter an ISDN environment, e.g. because of interworking with another network, with a non-ISDN user, or with non-ISDN equipment within the calling or called user's premises. When this occurs, the point at which the call enters an ISDN environment shall cause a Progress indicator information element to be included in the SETUP message to be sent to the called user: a) No. 1 Call is not end-to-end ISDN, further call progress information may be available inband;
NOTE On receipt of progress indicator No. 1, the called user shall connect to the B-channel in accordance with the procedures of 5.2.8.
b)
No. 3 Origination address is non-ISDN.
In addition, the user shall notify the calling party if the call has left the ISDN environment within the called user's premises, or upon the availability of in-band information/patterns. When such situations occur, a progress indication shall be sent by the user to the network either: a) b) in an appropriate call control message when a state change is required (SETUP ACKNOWLEDGE, CALL PROCEEDING, ALERTING, or CONNECT); or in the PROGRESS message when no state change is appropriate.
One of the following progress description values shall be included in the Progress indicator information element in the message sent to the network (for further information, see Annex G): i) ii) iii) No. 1 Call is not end-to-end ISDN, further call progress information may be available inband. No. 2 Destination address is non-ISDN. No. 4 Call has returned to the ISDN.
126
(05/98)
If the Progress indicator information element is included in a call control message, the procedures as described in the rest of 5.2 apply. If the Progress indicator information element is included in the PROGRESS message, no state change will occur and all supervisory timers running shall be continued.
NOTE If progress description No. 8 is received, it has no impact on any supervisory timers and shall be ignored by the network except when the Annex K procedures are applied.
5.2.7
Call accept
A user indicates acceptance of an incoming call by sending a CONNECT message to the network. Upon sending the CONNECT message, the user shall start timer T313 (specified in 9.2) and enter the Connect Request state. If an ALERTING message had previously been sent to the network, the CONNECT message may contain only the call reference. If a call can be accepted using the B-channel indicated in the SETUP message, and no user alerting is required, a CONNECT message may be sent without a previous ALERTING message. 5.2.8 Active indication
On receipt of the first CONNECT message, the network shall stop (if running) timers T301, T303, T304 and T310; complete the circuit-switched path to the selected B-channel; send a CONNECT ACKNOWLEDGE message to the user which first accepted the call; initiate procedures to send a CONNECT message towards the calling user and enter the active state. The CONNECT ACKNOWLEDGE message indicates completion of the circuit-switched connection. There is no guarantee of an end-to-end connection until a CONNECT message is received at the calling user. Upon receipt of the CONNECT ACKNOWLEDGE message, the user shall stop timer T313 and enter the active state. When timer T313 expires prior to receipt of a CONNECT ACKNOWLEDGE message, the user shall initiate clearing in accordance with 5.3.3. A user which has received the SETUP via the broadcast data link, and has been awarded the call, shall connect to the B-channel only after it has received the CONNECT ACKNOWLEDGE message. Only the user that is awarded the call will receive the CONNECT ACKNOWLEDGE message. A user which has received the SETUP via a point-to-point data link may connect to the B-channel as soon as channel selection has been completed. 5.2.9 Non-selected user clearing
In addition to sending the CONNECT ACKNOWLEDGE message to the user selected for the call, the network shall send RELEASE message [as described in 5.3.2 b)] to all other users at the interface that have sent SETUP ACKNOWLEDGE, CALL PROCEEDING, ALERTING or CONNECT messages in response to the SETUP message. These RELEASE messages are used to notify the users that the call is no longer offered to them. The procedures described in 5.3.4 are then followed. Any user which having previously sent a CONNECT message and started timer T313, and which subsequently receives a RELEASE message, shall stop timer T313 and follow the procedures of 5.3.4.
(05/98)
127
5.3 5.3.1
Call clearing Terminology A channel is connected when the channel is part of a circuit-switched ISDN connection established according to this Recommendation. A channel is disconnected when the channel is no longer part of a circuit-switched ISDN connection, but is not yet available for use in a new connection. A channel is released when the channel is not part of a circuit-switched ISDN connection and is available for use in a new connection. Similarly, a call reference that is released is available for reuse. Exception conditions
The following terms are used in this Recommendation in the description of clearing procedures:
5.3.2
Under normal conditions, call clearing is usually initiated when the user or the network sends a DISCONNECT message and follows the procedures defined in 5.3.3 and 5.3.4 respectively. The only exceptions to the above rule are as follows: a) In response to a SETUP message, the user or network can reject a call (e.g. because of the unavailability of a suitable B-channel) by responding with a RELEASE COMPLETE message provided no other response has previously been sent (e.g. the SETUP ACKNOWLEDGE message in the case of overlap sending), by releasing the call reference and entering the Null state. In the case of a multipoint terminal configuration, non-selected user call clearing will be initiated with RELEASE message(s) from the network (see 5.2.9). The RELEASE message shall contain cause No. 26, non-selected user clearing. Clearing of temporary signalling connections will be initiated by sending a RELEASE message as described in 5.3.3 and 5.3.4. Unsuccessful termination of the B-channel selection procedure (see 5.2.3.1 and 5.1.2) by the side offering the call is accomplished by sending a RELEASE message. The RELEASE message shall contain cause No. 6, channel unacceptable. The network and user shall subsequently follow the procedures of 5.3.3 and 5.3.4. In the case of a SETUP message sent via the broadcast data link, if a network disconnect indication is received during call establishment, and prior to the expiry of timer T312, timer T303 is stopped (if running) and the network enters the Call Abort state. Any user which has responded, or subsequently responds before timer T312 expires, will be cleared by a RELEASE message [with the cause code(s) contained in the network disconnect indication] and the procedures of 5.3.4 are then followed for that user. Upon expiry of timer T312, the network shall treat any subsequent responses according to the procedures defined in 5.8.3.2. The network shall enter the Null state upon completion of clearing procedures for all responding users. In the case of a SETUP message sent via the broadcast data link, if a network disconnect indication is received during call establishment after expiry of timer T312, any user which has responded shall be cleared by a RELEASE message [with the cause code(s) contained in the network disconnect indication] and the procedures of 5.3.4 are then followed for that user. The network enters the Null state upon completion of clearing procedures for all responding users.
NOTE A separate state machine exists for each responding user.
b)
c) d)
e1)
e2)
128
(05/98)
f)
When timer T318 expires, the user initiates call clearing by sending a RELEASE message with cause No. 102, recovery on timer expiry starting timer T308 and continuing as described in 5.3.3. Clearing initiated by the user
5.3.3
Apart from the exceptions identified in 5.3.2 and 5.8, the user shall initiate clearing by sending a DISCONNECT message, starting timer T305 (the value of timer T305 is specified in 9.2), disconnecting the B-channel and entering the disconnect request state.
NOTE 1 When a user initiates call clearing by sending a RELEASE message, the procedures described in 5.3.4 are then followed.
The network shall enter the Disconnect Request state upon receipt of a DISCONNECT message. This message then prompts the network to disconnect the B-channel, and to initiate procedures for clearing the network connection to the remote user. Once the B-channel used for the call has been disconnected, the network shall send a RELEASE message to the user; start timer T308 (the value of a timer T.308 is specified in 9.1) and enter the Release Request state.
NOTE 2 The RELEASE message has only local significance and does not imply an acknowledgement of clearing from the remote user.
On receipt of the RELEASE message the user shall cancel timer T305; release the B-channel, send a RELEASE COMPLETE message, release the call reference and return to the Null state. Following the receipt of a RELEASE COMPLETE message from the user, the network shall stop timer T308; release both the B-channel and the call reference and return to the Null state. If timer T305 expires, the user shall send a RELEASE message to the network with the cause number originally contained in the DISCONNECT message; start timer T308 and enter the Release Request state. In addition, the user may indicate a second Cause information element with cause No. 102, recovery on timer expiry. If timer T308 expires for the first time, the network shall retransmit the RELEASE message and timer T308 shall be restarted. In addition, the network may indicate a second Cause information element with cause No. 102, recovery on timer expiry. If no RELEASE COMPLETE message is received from the user before timer T308 expires a second time, the network shall place the B-channel in a maintenance condition, release the call reference and return to the Null state.
NOTE 3 The restart procedures contained in 5.5 may be used on B-channels in the maintenance condition. NOTE 4 Other actions which could be taken by the network upon receipt of a DISCONNECT message are for further study.
The actions to be taken with regard to the maintenance condition are network dependent. 5.3.4 Clearing initiated by the network
Apart from the exception conditions identified in 5.3.2 and 5.8, the network shall initiate clearing by sending a DISCONNECT message, and entering the Disconnect Indication state. The DISCONNECT message is a local invitation to clear and does not imply that the B-channel has been disconnected at the user-network interface.
NOTE When the network initiates clearing by sending a RELEASE message, the procedures described in 5.3.3 are followed.
5.3.4.1
Clearing when tones/announcements provided
When in-band tones/announcements are provided (see 5.4), the DISCONNECT message contains progress indicator No. 8, in-band information or appropriate pattern is now available. The network shall: start timer T306 and enter the Disconnect Indication state.
(05/98)
129
On receipt of the DISCONNECT message with progress indicator No. 8, the user may connect (if not already connected) to the B-channel to receive the in-band tone/announcement; and enter the disconnect indication state. Alternatively, to continue clearing without connecting to the in-band tone/announcement, the user shall disconnect the B-channel; send a RELEASE message, start timer T308 and enter the Release Request state. If the user connects to the provided in-band tone/announcement, the user may subsequently continue clearing (before the receipt of a RELEASE from the network) by disconnecting from the B-channel, sending a RELEASE message, starting timer T308 and entering the Release Request state. On receipt of the RELEASE message, the network shall stop timer T306; disconnect and release the B-channel; send a RELEASE COMPLETE message; release the call reference and return to the Null state. If timer T306 expires, the network shall continue clearing by disconnecting the B-channel, sending a RELEASE message with the cause number originally contained in the DISCONNECT message, starting timer T308 and entering the Release Request state. In addition to the original clearing cause, the RELEASE message may contain a second cause information element with cause No. 102, recovery on timer expiry; this cause may optionally contain a diagnostic field identifying the timer that expired. On receipt of the RELEASE message, the user shall act according to 5.3.3. 5.3.4.2 Clearing when tones/announcements not provided
When in-band tones/announcements are not provided, the DISCONNECT message does not contain progress indicator No. 8, in-band information or appropriate pattern is now available. The network shall initiate clearing by sending the DISCONNECT message; start timer T305; disconnects the B-channel and enters the Disconnect Indication state. On the receipt of the DISCONNECT message without progress indicator No. 8, the user shall disconnect the B-channel; send a RELEASE message; start timer T308 and enter the Release Request state. On receipt of the RELEASE message, the network shall stop timer T305; release the B-channel; send a RELEASE COMPLETE message; release the call reference and return to the Null state. If timer T305 expires, the network shall send a RELEASE message to the user with the cause number originally contained in the DISCONNECT message; start timer T308 and enter the Release Request state. In addition to the original clearing cause, the RELEASE message may contain a second Cause information element with cause No. 102, recovery on timer expiry. 5.3.4.3 Completion of clearing
Following the receipt of a RELEASE COMPLETE message from the network, the user shall stop timer T308; release both the B-channel and the call reference and return to the Null state. If a RELEASE COMPLETE is not received by the user 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 from the network before timer T308 expires a second time, the user may place the B-channel in a maintenance condition, shall release the call reference and return to the Null state.
NOTE The restart procedures contained in 5.5 may be used on B-channels in the maintenance condition.
130
(05/98)
5.3.5
Clear collision
Clear collision occurs when the user and the network simultaneously transfer DISCONNECT messages specifying the same call reference value. When the network receives a DISCONNECT message whilst in the Disconnect Indication state, the network shall stop timer T305 or T306 (whichever is running); disconnect the B-channel (if not disconnected); send a RELEASE message; start timer T308 and enter the Release Request state. Similarly, when the user receives a DISCONNECT message whilst in the Disconnect Request state, the user shall stop timer T305; send a RELEASE message; 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 entity receiving such a RELEASE message whilst within the Release Request state shall stop timer T308; release the call reference and B-channel and enter the Null state (without sending or receiving a RELEASE COMPLETE message). 5.4 In-band tones and announcements
When in-band tones/announcements not associated with a call state change are to be provided by the network before reaching the Active state, a PROGRESS message is returned simultaneously with the application of the in-band tone/announcement. The PROGRESS message contains the progress indicator No. 8, in-band information or appropriate pattern is now available. When tones/announcements have to be provided together with a call state change, then the appropriate message [e.g. for ALERTING, DISCONNECT, etc., (see clause 3)] with progress indicator No. 8, in-band information or appropriate pattern is now available, is sent simultaneously with the application of the in-band tone/announcement.
NOTE 1 When the network provides ITU-T standardized telecommunications services, the service requirement for provision of in-band tones/announcements is as indicated in the I.200-series Recommendations. NOTE 2 When the PROGRESS message is used, the user may initiate call clearing as a result of the applied in-band tone/announcement, according to the procedures specified in 5.3.3.
5.5
Restart procedure
The restart procedure is used to return calls to the Null state or the interface to an idle condition. The procedure is usually invoked when the other side of the interface does not respond to other call control messages or a failure has occurred (e.g. following a data link failure, when a backup D-channel can be used, or following the expiry of timer T308 due to the absence of response to a clearing message). It may also be initiated as a result of local failure, maintenance action or mis-operation.
NOTE 1 Layer 3 procedures and resources associated with those data links with SAPI = "0000 000" should be initialized by the restart procedures. NOTE 2 The call reference flag of the global call reference applies to restart procedures. In the case when both sides of the interface initiate simultaneous restart requests, they shall be handled independently. In the case when the same channel(s) or interface(s) are specified, they shall not be considered free for reuse until all the relevant restart procedures are completed.
When: a) b) c) both the user and the network are aware of the configuration of the interface; and the interface is a basic access (Recommendation I.431 [27]) where a point-to-point configuration exists; or the interface is a primary rate access (Recommendation I.430 [46]),
(05/98)
131
then the user and the network shall implement the procedures of 5.5. In all other cases, the procedures of 5.5 are optional. 5.5.1 Sending RESTART message
A RESTART message is sent by the network or user equipment in order to return channels or interfaces to the Null state. The Restart indicator information element shall be present in the RESTART message to indicate whether an Indicated channel, Single interface or All interfaces are to be restarted. If the Restart indicator information element is coded as "Indicated channel", or "Single interface" and the interface is one other than the one containing the D-channel, then the Channel identification information element shall be present to indicate which channel or interface is to be returned to the idle condition. If the Restart indicator information element is coded as "Single interface" and the interface is the one containing the D-channel, then the Channel identification information element may be omitted. If the Restart indicator information element is coded as "All interfaces", then the Channel identification information element shall not be included. Upon transmitting the RESTART message the sender enters the Restart Request state, starts timer T316 and waits for a RESTART ACKNOWLEDGE message. Also, no further RESTART messages shall be sent until a RESTART ACKNOWLEDGE is received or timer T316 expires. Receipt of a RESTART ACKNOWLEDGE message stops timer T316, frees the channels and call reference values for reuse and enters the Null state. If a RESTART ACKNOWLEDGE message is not received prior to the expiry of timer T316, one or more subsequent RESTART messages may be sent until a RESTART ACKNOWLEDGE message is returned. Meanwhile, no calls shall be placed or accepted over the channel or interface by the originator of the RESTART message. A network shall limit the number of consecutive unsuccessful restart attempts to a default limit of two. When this limit is reached, the network shall make no further restart attempts. An indication will be provided to the appropriate maintenance entity. The channel or interface is considered to be in an out-of-service condition until maintenance action has been taken.
NOTE If a RESTART ACKNOWLEDGE message is received indicating only a subset of the specified channels, an indication shall be given to the maintenance entity. It is the responsibility of the maintenance entity to determine what actions shall be taken on the channel(s) which have not been returned to the idle condition.
The RESTART and RESTART ACKNOWLEDGE message shall contain the global call reference value (all zeros) to which the Restart Request state is associated. These messages are transferred via the appropriate point-to-point data link in the multiple frame mode using the DL-DATA request primitive. 5.5.2 Receipt of RESTART message
Upon receiving a RESTART message, the recipient shall enter the Restart state associated to the global call reference and start timer T317; it shall then initiate the appropriate internal actions to return the specified channels to the idle condition and call references to the Null state. Upon completion of internal clearing, timer T317 shall be stopped and a RESTART ACKNOWLEDGE message transmitted to the originator and the Null state entered.
NOTE 1 If only a subset of the specified channels have been returned to the idle condition when timer T317 expires, a RESTART ACKNOWLEDGE message should be transmitted to the originator, containing a Channel identification information element indicating the channel(s) that have been returned to the idle condition.
If timer T317 expires prior to completion of internal clearing, an indication shall be sent to the maintenance entity (i.e. a primitive should be transmitted to the system management entity).
132
(05/98)
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 upon receiving a RESTART message. If the Restart indicator information element is coded as "all interfaces", then all calls on all interfaces associated with the D-channel shall be cleared. If the Restart indicator information element is coded as "all interfaces" and a Channel identification information element is included, the Channel identification information element is treated as described in 5.8.7.3. If the Restart indicator information element is coded as "indicated channel" and the Channel indication information element is not included, then the procedures in 5.8.6.1 shall be followed. If the Restart indicator information element is coded as "single interface" and that interface includes the D-channel, then only those calls associated with the D-channel on that interface shall be cleared. The receiving DSS1 protocol control entity for the global call reference shall indicate a restart request to only those DSS1 protocol control entities for specific call references which: a) are supported by the same Data Link Connection Endpoint Identifier (DLCI) (see Recommendation Q.920) as the DSS1 protocol control entity for the global call reference which received the RESTART message; and correspond to the specified channel(s) or interface(s), or (if the D-channel was implicitly specified) are not associated with any channel, including calls in the call establishment phase for which a channel has not yet been allocated. B- and H-channels established by Q.931 messages including channels used for packet access (case B) [consequently all virtual calls carried in the released channel(s) will be handled as described in 6.4.1]; user signalling bearer service connections; other resources associated with a call reference, where specified in other DSS1 Recommendations.
NOTE 2 Application to the Register procedures in Recommendation Q.932 requires further study.
b)
The following entities shall be released: a)
b) c)
The following entities shall not be released: a) b) semi-permanent connections that are established by man-machine commands; calls associated with DSS1 protocol control entities supported by any DLCI other than the one supporting the DSS1 protocol entity for the global call reference which received the RESTART message; X.25 virtual calls and permanent virtual circuits using SAPI = 16; TID and USID values established using terminal initialization procedures (see Annex A/Q.932).
c) d)
If semi-permanent connections established by man-machine command are implicitly specified (by specifying "single interface or "all interfaces"), no action shall be taken on these channels, but a RESTART ACKNOWLEDGE message shall be returned containing the appropriate indications (i.e. "single interface" or "all interfaces"). If semi-permanent connections established by man-machine command are explicitly specified (by including a Channel identification information element in the RESTART message), no action shall be taken on these channels and a STATUS message should be returned with cause No. 82, identified channel does not exist, optionally indicating in the diagnostic field the channel(s) that could not be handled.
(05/98)
133
5.6
Call rearrangements
The elements of procedure in this subclause provide for physical layer and/or data link layer rearrangements after a call has entered the Active state as defined in 2.2.1.8. The procedure is restricted to use on the same interface structure, and resumption on the same B-channel. The use of call rearrangement procedure is restricted to basic access, i.e. it will not be available for primary rate access. For call rearrangements controlled by an NT2, see 5.6.7. The activation of this procedure at a user-network interface may correspond to a number of possible events such as the following: a) b) c) d) physical disconnection of user equipment and reconnection; physical replacement of one user equipment by another; the human user moves from one equipment to another; suspension of call and its subsequent reactivation at the same user equipment.
These procedures have only local significance, i.e. the invocation of call rearrangement affects only states at the originating end, and it does not affect any terminating states. The procedures in this subclause are described in terms of functional messages and information elements. If the procedures for call suspension in this subclause are not followed prior to the physical disconnection of the terminal from the interface, then the integrity of the call cannot be guaranteed by the network. 5.6.1 Call suspension
The procedure is initiated by the user, who shall send a SUSPEND message containing the current call reference; start timer T319 and enter the Suspend Request state. The user may optionally include in this message a bit sequence (e.g. IA5 characters) to be known by the application or human user, and by the network, as the call identity for subsequent reconnection. Where no call identity information is included by the user (e.g. the Call identity information element is absent or empty), the network shall store this fact so that resumption is possible only by a procedure conveying no call identity information.
NOTE If the Call identity information element is present with a null length, the message shall be handled as if it was absent.
The default maximum length of the call identity value within the Call identity information element is eight octets. If the network receives a call identity value longer than the maximum length supported, the network shall truncate the call identity value to the maximum length; take the action specified in 5.8.7 and continue processing. 5.6.2 Call suspended
Following the receipt of a SUSPEND message, the network enters the Suspend Request state. After a positive validation of the received call identity, the network shall send a SUSPEND ACKNOWLEDGE message and start timer T307. (The value of T307 is specified in 9.1.) At this time, the network shall consider the call reference to be released and enter the Null state for that call reference. The call identity associated with the suspended call has to be stored by the network and cannot be accepted for another suspension until it is released. The B-channel involved in the connection will be reserved by the network until reconnection of the call (or until a clearing cause occurs, e.g. expiry of timer T307). A NOTIFY message with notification indicator No. 0, user suspended is sent to the other user.
134
(05/98)
When the user receives the SUSPEND ACKNOWLEDGE message, the user shall stop timer T319, release the B-channel and call reference and enter the Null state. Following the receipt of the SUSPEND ACKNOWLEDGE message, the user may disconnect the underlying data link connection. In any case, if the user physically disconnects from the interface without having disconnected the data link connection, standard data link layer procedures are started by the network side of the data link layer supervision, resulting in the release of the data link layer connection. 5.6.3 Call suspend error
If the network does not support the call rearrangement procedures, it shall reject a SUSPEND message according to the error handling procedures of 5.8.4. If the network supports the call rearrangement procedures on a subscription basis, but the user does not subscribe to the service, the network shall reject a SUSPEND message with cause No. 50, requested facility not subscribed; the Cause information element shall not contain a diagnostic field under these circumstances. On receipt of a SUSPEND message, the network will respond by sending a SUSPEND REJECT message with cause No. 84, call identity in use, if the information contained in the SUSPEND message is not sufficient to avoid ambiguities on subsequent call re-establishment. This will apply, in particular, when at a given user-network interface, a SUSPEND message is received with a call identity sequence already in use, or when the SUSPEND message does not contain any call identity sequence and the null-value call identity is already allocated for that interface. On receipt of the SUSPEND REJECT message, the user shall stop timer T319 and return to the active state. If timer T319 expires, the user shall notify the user application and return to the Active state. In these cases, the state of the call is not altered within the network (i.e. it remains in the Active state). 5.6.4 Call re-establishment
At the connection end where suspension was initiated, the user may request re-establishment of a call after physical reconnection of a terminal by sending a RESUME message containing the call identity exactly as that used at the time of call suspension, starting timer T318 and entering the Resume Request state. If the SUSPEND message did not include a Call identity information element, then the corresponding RESUME message shall also not include a Call identity information element. The call reference included in the RESUME message is chosen by the user according to the normal allocation of outgoing call reference (see 4.3). On receipt of a RESUME message, the network enters the Resume Request state. After a positive validation of the call identity that relates to the suspended call containing a valid identity that relates to a currently suspended call, the network shall send a RESUME ACKNOWLEDGE message to the user, release the call identity, stop timer T307 and enter the Active state. The RESUME ACKNOWLEDGE message shall specify the B-channel reserved to the call by the network by means of the channel identification element, coded B-channel is indicated, no alternative is acceptable. The network shall also send a NOTIFY message with the notification indicated user resumed to the other user. No memory of the previously received call identity sequence is kept by the network after sending the RESUME ACKNOWLEDGE message. This call identity is now available for another suspension. On receipt of the RESUME ACKNOWLEDGE message, the user shall stop timer T318 and enter the Active state. No compatibility is performed during the call arrangement phase.
(05/98)
135
5.6.5
Call resume errors
If the network does not support the call rearrangement procedures, it shall reject a RESUME message according to the error handling procedures of 5.8.3.2 a). For this purpose, the RESUME message would be deemed to be an unrecognized message. If a received RESUME message cannot be actioned by the network (e.g. as a result of an unknown call identity a RESUME REJECT message shall be returned to the requesting user indicating one of the following causes: a) b) c) No. 83 A suspended call exists, but this call identity does not; No. 85 No call suspended; or No. 86 Call having the requested call identity has been cleared.
The call identity remains unknown. The call reference contained in the RESUME message is released by both the user and network side. Upon receipt of the RESUME REJECT message, the user shall stop timer T318 and enter the Null state. If timer T307 expires the network shall initiate clearing of the network connection with cause No. 102, recovery on timer expiry, discard the call identity and release the reserved B-channel. On release, the call identity can then be used for subsequent call suspension. If before the expiry of timer T307 the call is cleared by the remote user, the B-channel reservation is released but the call identity may be preserved by some networks along with a clearing cause (e.g. cause No. 16, normal call clearing). If timer T318 expires, the user shall initiate call clearing in accordance with 5.3.2 f). 5.6.6 Double suspension
Simultaneous suspension of the call at both ends is possible. The procedures do not prevent this from occurring. If double suspensions are not desired the users must protect against this by other means, e.g. higher layer negotiation protocols. 5.6.7 Call rearrangement notification controlled by an NT2
When the call rearrangement is controlled by the NT2, the procedures shall be applied by the NT2 at reference point S. The NT2 shall inform the remote user by sending a NOTIFY message described in 5.6.2 and 5.6.4 across reference point T. 5.7 Call collisions
Call collisions as such cannot occur at the network. Any simultaneous incoming or outgoing calls are dealt with separately and assigned different call references. Channel selection conflicts may occur if an incoming call and outgoing call select the same channel. This is resolved by the network through channel selection mechanisms described in 5.1.2 and 5.2.2. In the case of such conflicts, the network shall give priority to the incoming call over the call request received from the user. It shall clear the outgoing call whenever the B-channel cannot be allocated by the network or accepted by the user originating the call.
NOTE Some terminal adaptors supporting existing non-voice terminals (e.g. Recommendation X.21) may need to resolve double channel selection by clearing the incoming call and re-attempting the outgoing call setup in order to satisfy the requirements of the interface at reference point R.
136
(05/98)
5.8
Handling of error conditions
All procedures transferring signalling information by using the protocol discriminator of Q.931 usernetwork call control messages are applicable only to those messages which pass the checks described in 5.8.1 through 5.8.7. The error handling procedures of 5.8.1 through 5.8.7 apply to messages using an ordinary call reference or the global call reference, except where otherwise noted. Detailed error handling procedures are implementation dependent and may vary from network-tonetwork. However, capabilities facilitating the orderly treatment of error conditions are provided for in this subclause and shall be provided in each implementation. Subclauses 5.8.1 through 5.8.7 are listed in order of precedence. 5.8.1 Protocol discrimination error
When a message is received with a protocol discriminator coded other than Q.931 user-network call control message, that message shall be ignored. Ignore means to do nothing, as if the message had never been received. 5.8.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. 5.8.3 5.8.3.1 Call reference error 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 the Call reference information element octet 1, bits 1 through 4 indicate a length greater than the maximum length supported by the receiving equipment (see 4.3), then the message shall be ignored. When a message is received with the dummy call reference, it shall be ignored unless it is required for a supplementary service (see Recommendation Q.932 [4]). 5.8.3.2 a) Call reference procedural errors Whenever any message except SETUP, RELEASE, RELEASE COMPLETE, STATUS, STATUS ENQUIRY or (for networks supporting the call rearrangement procedures of 5.6) RESUME is received specifying a call reference which it does not recognize as relating to an active call or a call in progress, clearing is initiated by sending a RELEASE message with cause No. 81, invalid call reference value, and following the procedures in 5.3, specifying the call reference in the received message. Alternatively, the receiving entity may send a RELEASE COMPLETE message with cause No. 81, invalid call reference value, and remain in the Null state. b) When a RELEASE message is received that specified a call reference which is not recognized as relating to an active call or a call in progress, a RELEASE COMPLETE message with cause No. 81, invalid call reference value, is returned, specifying the call reference in the received message. When a RELEASE COMPLETE message is received specifying a call reference which it does not recognize as relating to an active call or a call in progress, no action should be taken.
Only item f) applies to messages using the global call reference.
c)
(05/98)
137
d) e) f)
When a SETUP or RESUME message is received specifying a call reference with a call reference flag incorrectly set to "1", that message shall be ignored. When a SETUP message is received specifying a call reference which is recognized as relating to an active call, or a call in progress, this SETUP message shall be ignored. When any message except RESTART, RESTART ACKNOWLEDGE, or STATUS is received using the global call reference, no action should be taken on this message and a STATUS message using the global call reference with a call state indicating the current state associated with the global call reference and cause No. 81, invalid call reference value, shall be returned. When a STATUS message is received specifying a call reference which is not recognized as relating to an active call or to a call in progress, the procedures of 5.8.11 shall apply. When a STATUS ENQUIRY message is received specifying a call reference which is not recognized as relating to an active call or to a call in progress, the procedures of 5.8.10 shall apply.
NOTE Some implementations conforming to Recommendation Q.931 (1988) may choose to initiate clearing by sending a RELEASE message with cause No. 81, invalid call reference value, and continue to follow the procedures in 5.3, specifying the call reference in the received message, or respond with a RELEASE COMPLETE message with cause No. 81, invalid call reference value, and remain in the Null state.
g) h)
i) 5.8.4
When a RESTART message is received specifying a global call reference with a call reference flag set to "1", that message shall be ignored. Message type or message sequence errors
Whenever an unexpected message, except RELEASE or RELEASE COMPLETE, or unrecognized message is received in any state other than the Null state, a STATUS message shall be returned with cause No. 98, message not compatible with call state or message type non-existent or not implemented, and the corresponding diagnostic. If a network or user can distinguish between unimplemented (or non-existent) message types and implemented message types which are incompatible with the call state, then a STATUS message may be sent with one of the following causes: a) b) No. 97 Message type non-existent or not implemented; or No. 101 Message not compatible with call state.
Alternatively, a STATUS ENQUIRY message may be sent requesting the call state of the entity (see 5.8.10). No change in state shall be made in either case at this time. This alternative is not applicable to messages using the global call reference. However, two exceptions to this procedure exist. The first exception is when the network or the user receives an unexpected RELEASE message (e.g. if the DISCONNECT message was corrupted by undetected transmission errors). In this case, no STATUS or STATUS ENQUIRY message is sent. Whenever the network receives an unexpected RELEASE message, the network shall disconnect and release the B-channel; clear the network connection and the call to the remote user with the cause in the RELEASE message sent by the user or, if not included, cause No. 31, normal, unspecified, return a RELEASE COMPLETE message to the user; release the call reference, stop all timers and enter the Null state. Whenever the user receives an unexpected RELEASE message, the user shall disconnect and release the B-channel, return a RELEASE COMPLETE message to the network, release the call reference; stop all timers and enter the Null state. The second exception is when the network or the user receives an unexpected RELEASE COMPLETE message. Whenever the network receives an unexpected RELEASE COMPLETE
138
(05/98)
message, the network shall disconnect and release the B-channel, clear the network connection and the call to the remote user with the cause indicated by the user or, if not included, cause No. 111, protocol error, unspecified; release the call reference; stop all timers and enter the Null state. Whenever the user receives an unexpected RELEASE COMPLETE message, the user shall disconnect and release the B-channel; release the call reference; stop all timers and enter the Null state. 5.8.5 General information element errors
The general information element error procedures may also apply to information elements in codesets other than 0. In that case, the diagnostics in the cause information element may indicate information elements other than those in codeset 0 by applying the locking or non-locking shift procedures as described in 4.5. 5.8.5.1 Information element out of sequence
A variable length information element which has a code value lower than the code value of the variable length information element preceding it shall be considered as an out of sequence information element. If the network or user receives a message containing an out of sequence information element, it may ignore this information element and continue to process the message. If this information is mandatory, and the network or user chooses to ignore this out of sequence information element, then the error handling procedure for missing mandatory information elements as described in 5.8.6.1 shall be followed. If the ignored information element is non-mandatory, the receiver continues to process the message.
NOTE Some implementations may choose to process all the information elements received in a message regardless of the order in which they are placed.
5.8.5.2
Duplicated information elements
If an information element is repeated in a message in which repetition of the information element is not permitted, only the contents of information element appearing first shall be handled and all subsequent repetitions of the information element shall be ignored. When repetition of information elements is permitted, only the contents of permitted information elements shall be handled. If the limit on repetition of information elements is exceeded, the contents of information elements appearing first up to the limit of repetitions shall be handled and all subsequent repetitions of the information element shall be ignored. 5.8.6 5.8.6.1 Mandatory information element errors 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 should be taken on the message and no state change should occur. A STATUS message is then returned with cause No. 96, mandatory information element is missing. When a SETUP or RELEASE message is received which has one or more mandatory information elements missing, a RELEASE COMPLETE message with cause No. 96, mandatory information element is missing, shall be returned. When a DISCONNECT message is received with the cause information element missing, the actions taken shall be the same as if a DISCONNECT message with cause No. 31, normal, unspecified, was received (see 5.3), with the exception that the RELEASE message sent on the local interface contains cause No. 96, mandatory information element is missing.
(05/98)
139
When a RELEASE COMPLETE message is received with a cause information element missing, it will be assumed that a RELEASE COMPLETE message was received with cause No. 31, normal, unspecified. Information elements with a length indication of zero shall be treated as a missing information element. 5.8.6.2 Mandatory information element content error
If the Bearer capability information element is coded as circuit-mode, and the network cannot interpret octets 5b, 5c, 5d, 6 and 7, the network may accept these octets without declaring a protocol error and pass these octets on without change. 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 should be taken on the message and no state change should occur. A STATUS message is then returned with cause No. 100, invalid information element contents. When a SETUP or RELEASE message is received which has one or more mandatory information elements with invalid content, a RELEASE COMPLETE message with cause No. 100, invalid information element contents, shall be returned. When a DISCONNECT message is received with invalid content of the Cause information element, the actions shall be the same as if a DISCONNECT message with cause No. 31, normal, unspecified, was received (see 5.3), with the exception that the RELEASE message sent on the local interface contains cause No. 100, invalid information element contents. When a RELEASE COMPLETE message is received with invalid content of the Cause information element, it will be assumed that a RELEASE COMPLETE message was received with cause No. 31, normal, unspecified. Information elements with a length exceeding the maximum length (given in [3]) shall be treated as an information element with content error.
NOTE As an option of the user equipment (e.g. NT2), cause values, location codes, and diagnostics which are not understood by the NT2 may be passed on to another entity (e.g. user or NT2) instead of treating the cause value as if it were cause No. 31, normal, unspecified, and sending cause No. 100, invalid information element contents, with the RELEASE message. This option is intended to aid user equipment to be compatible with future additions of cause values, location codes and diagnostics to the Recommendation.
5.8.7
Non-mandatory information element errors
The following subclauses identify actions on information elements not recognized as mandatory. 5.8.7.1 Unrecognized information element
When a message is received which has one or more unrecognized information elements, the receiving entity shall check whether any are encoded to indicate "comprehension required" (refer to Table 4-3 for information element identifiers reserved with this meaning). If any unrecognized information element is encoded to indicate "comprehension required", then the procedures in 5.8.6.1 are followed, i.e. as if a "missing mandatory information element" error condition had occurred. If all unrecognized information elements are not encoded to indicate "comprehension required", then the receiving entity shall proceed as follows: Action shall be taken on the message and those information elements which are recognized and have valid content. When the received message is other than DISCONNECT, RELEASE or RELEASE COMPLETE, a STATUS message may be returned containing one cause information element. The STATUS message indicates the call state of the receiver after taking action on the message. The
140
(05/98)
Cause information element shall contain cause No. 99, information element/parameter non-existent or not implemented, and the diagnostic field, if present, shall contain the information element identifier for each information element which was unrecognized. Subsequent actions are determined by the sender of the unrecognized information elements. If a clearing message contains one or more unrecognized information elements, the error is reported to the local user in the following manner: a) When a DISCONNECT message is received which has one or more unrecognized information elements, a RELEASE message with cause No. 99, information element/parameter non-existent or not implemented, shall be returned. The Cause information element diagnostic field, if present, shall contain the information element identifier for each information element which was unrecognized. When a RELEASE message is received which has one or more unrecognized information elements, a RELEASE COMPLETE message with cause No. 99 information element/parameter non-existent or not implemented, shall be returned. The Cause information element diagnostic field, if present, shall contain the information element identifier for each information element which was unrecognized. When a RELEASE COMPLETE message is received which has one or more unrecognized information elements, no action shall be taken on the unrecognized information.
b)
c)
NOTE The diagnostic(s) of cause No. 99 facilitates the decision in selecting an appropriate recovery procedure at the reception of a STATUS message. Therefore, it is recommended to provide cause No. 99 with diagnostic(s) if a layer 3 entity expects the peer to take an appropriate action at the receipt of a STATUS message, although inclusion of diagnostic(s) is optional.
5.8.7.2
Non-mandatory information element content error
When a message 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 recognized and have valid content. A STATUS message may be returned containing one Cause information element. The STATUS message indicates the call state of the receiver after taking action on the message. The Cause information element shall contain cause No. 100, invalid information element contents, and the diagnostic field, if present, shall contain the information element identifier for each information element which has invalid contents. Information elements with a length exceeding the maximum length (given in [3]) will be treated as an information element with content error. But for access information elements (e.g. User-user information element, Called party subaddress information element), cause No. 43, access information discarded, is used instead of cause No. 100, invalid information element contents. However, in some networks, access information elements may be truncated and processed. The Call identity information element shall have a special treatment and shall be truncated and processed in the case that it exceeds the maximum length implemented. As an option of user equipment (e.g. NT2), cause values, location codes, and diagnostics which are not understood by the NT2 may be accepted, or in the case of an NT2, passed on to another entity (e.g. user or NT2) instead of ignoring the cause information element contents and optionally sending a STATUS message with cause No. 100, invalid information element contents. This option is intended to aid user equipment to be compatible with future additions of cause values, location codes and diagnostics to the Recommendation. If the network cannot interpret the Low layer compatibility or the High layer compatibility information elements, it may accept these information elements without declaring a protocol error.
(05/98)
141
5.8.7.3
Unexpected recognized information element
When a message is received with a recognized information element that is not marked as comprehension required and is not defined to be contained in that message, the receiving entity shall (except as noted below) treat the information element as an unrecognized information element and follow the procedures defined in 5.8.7.1. When a message is received with a recognized information element that is marked as comprehension required and is not defined to be contained in that message, the receiving entity shall follow the procedures of 5.8.6.1.
NOTE Some implementations may choose to process unexpected recognized information elements when the procedure for processing the information element is independent of the message in which it is received.
5.8.8
Data link reset
Whenever a Q.931 entity is informed of a spontaneous data link layer reset by means of the DL-ESTABLISH indication primitive, the following procedures apply: a) For calls in the Overlap Sending and Overlap Receiving states, the entity shall initiate clearing by sending a DISCONNECT message with cause No. 41, temporary failure, and following the procedures of 5.3. For calls in the disestablishment phase (states N11, N12, N19, N22, U11, U12 and U19), no action shall be taken. Calls in the establishment phase (states N1, N3, N4, N6, N7, N8, N9, U1, U3, U4, U6, U7, U8 and U9) and in the Active, Suspend Request, and Resume Request states shall be maintained according to the procedures contained in other parts of clause 5. Data link failure
b) c)
5.8.9
Whenever the network layer entity is notified by its data link layer entity via the DL-RELEASE indication primitive that there is a data link layer malfunction, the following procedure shall apply: a) b) Any calls not in the Active state shall be cleared internally. For any call in the Active state, a timer T309 shall be started (if implemented). If timer T309 is already running, it shall not be restarted. The Q.931 entity shall request layer 2 re-establishment by sending a DL-ESTABLISH request primitive. When informed of layer 2 re-establishment by means of the DL-ESTABLISH confirmation primitive, the following procedure shall apply: the Q.931 entity shall stop timer T309, and either: the Q.931 entity shall send a STATUS message with cause No. 31, normal, unspecified, to report the current state to the peer entity; or the Q.931 entity shall perform the status enquiry procedure according to 5.8.10 to verify the call state of the peer entity.
If timer T309 expires prior to data link re-establishment, the network shall clear the network connection and call to the remote user with cause No. 27, destination out of order; disconnect and release the B-channel; release the call reference and enter the Null state. If timer T309 expires prior to data link re-establishment, the user shall clear the attached connection (if any) with cause No. 27, destination out of order; disconnect and release the Bchannel; release the call reference and enter the Null state. When a backup D-channel is available, the procedures in Annex F may be used. The implementation of timer T309 in the user side is optional and in the network side is mandatory.
142
(05/98)
When a Q.931 entity internally clears the call as a result of data link failure, as an option, it may request the re-establishment of the data link in order to attempt to send a DISCONNECT message across the interface. 5.8.10 Status enquiry procedure Whenever an entity wishes to check the correctness of a call state at a peer entity, a STATUS ENQUIRY message may be sent requesting the call state. This may, in particular, apply to procedural error conditions described in 5.8.8 and 5.8.9. 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 call state information 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 call clearing shall continue. Upon receipt of a STATUS ENQUIRY message, the receiver shall respond with a STATUS message, reporting the current call state (the current state of an active call or a call in progress, or the Null state if the call reference does not relate to an active call or to a call in progress) and cause No. 30, response to STATUS ENQUIRY; No. 97, message type non-existent or not implemented, or No. 98, message not compatible with call state or message type non-existent or not implemented (see 5.8.4). Receipt of the STATUS ENQUIRY message does not result in a state change. The sending or receipt of the STATUS message in such a situation will not directly affect the call state of either the sender or receiver. The side having received the STATUS message shall inspect the Cause information element. If the STATUS message contains cause No. 97, message type nonexistent or not implemented, or No. 98, message not compatible with call state or message type nonexistent or not implemented, timer T322 shall continue to time for an explicit response to the STATUS ENQUIRY message. If a STATUS message is received that contains cause No. 30, response to STATUS ENQUIRY, timer T322 shall be stopped and the appropriate action taken, based on the information in that STATUS message, relative to the current state of the receiver. If timer T322 expires and a STATUS message with cause No. 97, message type non-existent or not implemented or No. 98, message not compatible with call state or message type non-existent or not implemented was received, the appropriate action shall be taken, based on the information in that STATUS message, relative to the current call state of the receiver. These further appropriate actions are implementation dependent. However, the actions prescribed in the following subclause shall apply. If timer T322 expires, and no STATUS message was received, the STATUS ENQUIRY message may be retransmitted one or more times until a response is received. The number of times the STATUS ENQUIRY message is retransmitted as an implementation dependent value. The call shall be cleared to the local interface with cause No. 41, temporary failure, if the STATUS ENQUIRY is retransmitted the maximum number of times. If appropriate, the network shall also clear the network connection, using cause No. 41, temporary failure. 5.8.11 Receiving a STATUS message On receipt of a STATUS message reporting an incompatible state, the receiving entity shall: a) b) clear the call by sending the appropriate clearing message with cause No. 101, message not compatible with call state; or take other actions which attempt to cover from a mismatch and which are an implementation option.
(05/98)
143
Except for the following rules, the determination of which states are incompatible is left as an implementation decision: a) If a STATUS message indicating any call state except the Null state is received in the Null state, then the receiving entity shall either: 1) send a RELEASE message with cause No. 101, message not compatible with call state, and then follow the procedures of 5.3; or 2) send a RELEASE COMPLETE message with cause No. 101, message not compatible with call state, and remain in the Null state. b) c) If a STATUS message indicating any call 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. If appropriate, the network shall also clear the network connection, using cause No. 41, temporary failure.
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. A STATUS message may be received indicating a compatible call state but containing one of the following causes: i) ii) iii) iv) v) No. 96 Mandatory information element is missing; No. 97 Message type non-existent or not implemented; No. 98 Message not compatible with call state or message type non-existent or not implemented; No. 99 Information element/parameter non-existent or not implemented; or No. 100 Invalid information element contents.
In this case, the actions to be taken are an implementation option. If other procedures are not defined, the receiver shall clear the call with the appropriate procedure defined in 5.3, using the cause specified in the received STATUS message. On receipt of a STATUS message specifying the global call reference and reporting an incompatible state in the restart request or restart state, the receiving Q.931 entity shall inform layer management and take no further action on this message. When in the Null state, then on receipt of a STATUS message with the global call reference no action shall be taken.
NOTE Further actions, as a result of higher layer activity (e.g. system or layer management) are implementation dependent (including the retransmission of RESTART).
Except for the above case, the error handling procedures when receiving a STATUS message specifying the global call reference are an implementation option. 5.9 User notification procedure
This procedure allows the network to notify a user of any appropriate call-related event during the active state of a call. It also allows a user to notify the remote user of any appropriate call-related event during the active state of a call by sending a NOTIFY message containing a notify indicator to the network; upon receipt of this message, the network must send a NOTIFY message containing the same notify indicator to the other user involved in the call. No state change occurs at any of the interface sides following the sending or the receipt of this message.
144
(05/98)
5.10
Basic telecommunication service identification and selection
5.10.1 Additional procedures at the coincident S and T reference point 5.10.1.1 Normal operation Procedures for bearer capability selection are described in subclauses 5.11.1 and 5.11.2. Procedures for high layer compatibility selection are described in subclauses 5.12.1 and 5.12.2. Each basic telecommunications service has the required bearer capability information element encodings, and if applicable the required High layer compatibility information element encodings, defined for that service (e.g. see Recommendation Q.939). The destination user shall identify the requested teleservice by taking the presented Bearer capability and High layer compatibility information elements in all combinations. Where a permutation is not identified as a defined teleservice, that combination shall be ignored. Where a combination is identified as a defined teleservice, that combination may be considered for the purposes of service provision. If there are no valid combinations, the presented Bearer capability information elements shall be considered in order to identify a bearer service. The destination user shall identify the requested bearer services from the values of the presented Bearer capability information elements.
NOTE These requirements do not preclude the user performing compatibility checking on all compatibility information according to Annex B.
The originating network shall optionally perform subscription checks for all valid combinations in the order defined for the particular service. If the user has not subscribed to the prime service, the network shall check for the next following basic service and so on. If the user has not subscribed to any of the basic services, the call shall be released with cause No. 57, Bearer capability not authorized. If a fallback occurs as a result of these checks, the procedures of 5.11.1 and 5.12.1 shall apply. The destination network shall optionally perform subscription checks for all valid combinations in the order defined for the particular service. If the user has not subscribed to the prime service, the network shall check for the next following basic service and so on. The subscription check may then result in one of the following four possibilities: a) The user has subscribed to the prime service The call shall be offered to the called user without any modification following the procedures in 5.11.2 or 5.11.3 "bearer capability selection", and 5.12.2 or 5.12.3 "high layer compatibility selection". b) The user has not subscribed to the prime service, but to one of the valid combinations, different to the lowest basic service The call shall be offered to the called user, with the highest subscribed basic service including the fallback possibility. The procedures in 5.11.2 or 5.11.3 "bearer capability selection", and 5.12.2 or 5.12.3 "high layer compatibility selection" will then apply. No indication of the fallback will be sent towards the calling user before a bearer has been established, unless the called user indicates fallback prior to the bearer establishment. The user has subscribed to the lowest basic service among the valid combinations The call shall be offered to the called user containing the subscribed basic service and an indication of fallback shall be sent towards the calling user in the next message to be sent.
c)
(05/98)
145
d)
The user has not subscribed to any service The call shall be cleared.
5.10.1.2 Exceptional procedures Not applicable. 5.10.2 Procedures for interworking with private ISDNs 5.10.2.1 Normal operation Procedures for bearer capability selection are described in 5.11.3. Procedures for high layer compatibility selection are described in subclause 5.12.3. Each basic telecommunications service has the required Bearer capability information element encodings, and if applicable the required High layer compatibility information element encodings, defined for that service (e.g. see Recommendation Q.939). The user (the private ISDN) shall identify the requested teleservices by taking the presented Bearer capability and High layer compatibility information elements in all combinations. Where a combination is not identified as a defined teleservice, that combination shall be ignored. Where a combination is identified as a defined teleservice, that combination may be considered for the purposes of service provision. The user (the private ISDN) shall identify the requested bearer services from the values of the requested Bearer capability information elements. 5.10.2.2 Exceptional procedures Not applicable. 5.11 Signalling procedures for bearer capability selection
The procedures in this subclause form an optional part of this Recommendation, but are a mandatory requirement for the provision of certain bearer services or teleservices. Provision of these procedures between the originating user and the originating network, and also between the destination network and the destination user, is thus subject to bilateral agreement, e.g. a subscription arrangement for the provision of that bearer service or teleservice to each user. The support of such basic services may require the ability to support transmission and reception of either two or three bearer capability information elements. These procedures shall apply only in the case where the call, or call request, as currently routed, is entirely within the ISDN. It will not apply to situations involving interworking with non-ISDNs.
NOTE The use of the Low layer compatibility information element in conjunction with these procedures requires further study and the interpretation of any received Low layer compatibility information element is not defined.
5.11.1 Procedures for the originating user to indicate bearer capability selection is allowed 5.11.1.1 Normal operation For some bearer services or teleservices, the originating user can indicate that: fallback to an alternative bearer capability is allowed; or fallback to an alternative bearer capability is not allowed.
146
(05/98)
If the calling user allows fallback to occur to an alternative bearer capability, then the user shall indicate this to the network by including repeated Bearer capability information elements within the SETUP message sent to indicate the presence of a call request. This procedure allows a maximum of three Bearer capability information elements in the SETUP message. When two or three Bearer capability information elements are present, their order shall indicate the priority of the bearer capabilities. Bearer capability information elements shall be in ascending order of priority, i.e. a subsequent Bearer capability information element shall indicate a bearer capability with higher priority. If fallback allowed is indicated in the SETUP message as described above, and fallback occurs at the destination user, or fallback does not occur, the originating network shall include in the CONNECT message sent to the calling user the Bearer capability information element of the resultant bearer service or teleservice. If fallback allowed is indicated in the SETUP message as described above, and fallback occurs within the ISDN (e.g. bearer capability selection is not supported or the selected route does not support the preferred bearer capability), the originating network shall include in a PROGRESS message or other appropriate call control message sent to the calling user a Progress indicator information element with the progress description No. 5, interworking has occurred and has resulted in a telecommunication service change. The originating network shall include the Bearer capability information element of the resultant bearer service or teleservice. When a PROGRESS message is sent containing a Progress indicator information element with progress description No. 5, interworking has occurred and has resulted in a telecommunication service change, neither the user nor the network shall stop timers described in 5.1.6 as a result of this action. 5.11.1.2 Exceptional procedures The procedures of 5.8 shall apply, with the addition that: a) If the calling user receives no Bearer capability information element in the CONNECT message, or prior to the CONNECT message in some other call control message, the user shall assume that the bearer service or teleservice corresponds to the first Bearer capability information element that the user included in the SETUP message. If the calling user receives a Progress indicator information element with a progress description No. 1, call is not end-to-end ISDN; further call progress information may be available in-band, or progress description No. 2, destination address is non-ISDN, subsequent to a Progress indicator information element with a progress description No. 5, interworking has occurred and has resulted in a telecommunication service change, then the last received Progress indicator information element shall be taken account of. Where the progress description is No. 1, call is not end-to-end ISDN; further call progress information may be available in-band or progress description is No. 2, destination address is non-ISDN, the user shall assume a bearer service category of circuit-mode 64 kbit/s 8 kHz structured usable for 3.1 kHz audio information transfer. If the calling user includes a Low layer compatibility information element in a SETUP message containing a repeated Bearer compatibility information element, even though this is an error condition, the network shall continue normal call handling, i.e. transport the Low layer compatibility information element transparently across the network. If the calling user receives a call control message other than the CONNECT message containing a Bearer capability information element but without a Progress indicator information element, with progress description No. 5, interworking has occurred and has
b)
c)
d)
(05/98)
147
resulted in a telecommunication service change, the calling user shall handle the call in the normal manner. e) If the calling user receives no Bearer capability information element in a call control message other than CONNECT but the Progress indicator information element, with progress description No. 5, interworking has occurred and has resulted in a telecommunication service change, present, the calling user shall assume that the bearer service or teleservice corresponds to the first Bearer capability information element that was included in the SETUP message.
5.11.2 Procedures for bearer capability selection at the destination side 5.11.2.1 Normal operation If the calling user and the network operator allow fallback to occur to an alternative bearer capability, then the destination network shall indicate this to the destination user by including repeated Bearer capability information elements within the SETUP message sent to indicate the presence of a call request. When two or three Bearer capability information elements are present, their order shall indicate the priority of the bearer capabilities. Bearer capability information elements shall be in ascending order of priority, i.e. a subsequent Bearer capability information element shall indicate a bearer capability with higher priority. If fallback allowed is indicated in the SETUP message as described above, and the user wishes to accept the call without having fallback occur, the user shall include in the CONNECT message sent to the network the Bearer capability information element of the requested bearer service or teleservice. If fallback allowed is indicated in the SETUP message as described above, and the user wishes to accept the call with having fallback occur to the lowest priority alternative bearer capability, the user may, but need not, include in the CONNECT message sent to the network the Bearer capability information element of the alternative bearer service or teleservice. If no Bearer capability information element is indicated by the called user, the network shall assume that the lowest priority bearer capability is selected. If fallback allowed is indicated in the call request, and no interworking has been encountered (i.e. a progress description No. 1, call is not end-to-end ISDN; further call progress information may be available in-band, or progress description No. 2, destination address is non-ISDN; has not been sent), the destination network shall indicate the resultant bearer capability and connection type to the originating network at the time the bearer is established, even if no Bearer capability information element is received from the destination user. 5.11.2.2 Exceptional procedures The procedures of 5.8 shall apply, with the addition that: a) If a low layer compatibility information is received from the originating network for a connection request for which bearer capability selection is indicated, even though this is an error condition, the network shall include the low layer compatibility information in the Low layer compatibility information element in the SETUP message sent to the destination user. If a Low layer compatibility information element is included in the received SETUP message containing a repeated Bearer capability information element, the destination user may ignore the received Low layer compatibility information element.
b)
148
(05/98)
c)
If the called user sends a Bearer capability information element in the CONNECT message that contains an information transfer capability which is not that requested or the nominated alternative, the destination network shall clear the call using normal clearing procedures with clearing cause No. 111, protocol error unspecified.
5.11.3 Procedures for interworking with private ISDNs 5.11.3.1 Procedures for the originating user to indicate bearer capability selection is allowed The procedures of 5.11.1 shall apply. 5.11.3.2 Procedures for bearer capability selection at the destination side of a public ISDN 5.11.3.2.1 Normal operation If a private ISDN is attached to the access at the destination interface, the following procedures are applicable at call request. The private ISDN acts as the called user. If the calling user allows fallback to occur to an alternative bearer capability, then the network shall indicate this to the called user by means of repeated Bearer capability information elements within the SETUP message sent to indicate the presence of a call request. When two or three Bearer capability information elements are present, their order shall indicate the priority of the bearer capabilities. Bearer capability information elements shall be in ascending order of priority, i.e. a subsequent Bearer capability information element shall indicate a bearer capability with higher priority. If fallback allowed is indicated in the SETUP message as described above, and fallback occurs at the destination user (beyond the private ISDN) or fallback does not occur, the user shall include in the CONNECT message sent to the network the Bearer capability information element of the resultant bearer service or teleservice. If fallback allowed is indicated in the SETUP message as described above, and fallback occurs within the private ISDN, the user shall include in a PROGRESS message or other appropriate call control message sent to the network a Progress indicator information element with a progress description No. 5, interworking has occurred and has resulted in a telecommunication service change. The user shall include the Bearer capability information element of the resultant bearer service or teleservice. When a PROGRESS message is sent containing a Progress indicator information element with progress description No. 5, interworking has occurred and has resulted in a telecommunication service change, neither the user nor the network shall stop timers described in 5.2.6 as a result of this action. 5.11.3.2.2 Exceptional procedures The procedures of 5.8 shall apply, with the addition that: a) If the network receives no Bearer capability information element in the CONNECT message, or prior to the CONNECT message in some other call control message, the network shall assume that the bearer service or teleservice corresponds to the first Bearer capability information element that the network included in the SETUP message. If the network receives a Progress indicator information element with a progress description No. 1, call is not end-to-end ISDN; further call progress information may be available inband, or progress description No. 2, destination address is non-ISDN, subsequent to a Progress indicator information element with a progress description No. 5, interworking has occurred and has resulted in a telecommunication service change, then the last received
b)
(05/98)
149
Progress indicator information element shall be taken account of. Where the progress description is No. 1, call is not end-to-end ISDN; further call progress information may be available in-band or the progress description is No. 2, destination address is non-ISDN, the network shall assume a bearer service category of circuit-mode 64 kbit/s 8 kHz structured usable for 3.1 kHz audio information transfer. c) If a low layer compatibility information is received from the originating network for a connection request for which bearer capability selection is indicated, even though this is an error condition, the network shall include the low layer compatibility information in the Low layer compatibility information element in the SETUP message sent to the destination user. If the network includes a Low layer compatibility information element in a SETUP message containing a repeated Bearer compatibility information element, even though this is an error condition, the user shall continue normal call handling, i.e. transport the Low layer compatibility information element transparently across the private network. If the called user sends a Bearer capability information element in any call control message that contains an information transfer capability which is not that requested or the nominated alternative, the destination network shall clear the call using normal clearing procedures with clearing cause No. 111, protocol error, unspecified. If the network receives a call control message other than a CONNECT message containing a Bearer capability information element, but without a Progress indicator information element with progress description No. 5, interworking has occurred and has resulted in a bearer service change, the network shall act as if the Progress indicator information element, with progress description No. 5, interworking has occurred and has resulted in a telecommunication service change, was present and handle the call in the normal manner. If the network receives no Bearer capability information element in a call control message other than CONNECT but the Progress indicator information element, with progress description No. 5, interworking has occurred and has resulted in a telecommunication service change, present, the network shall assume that the bearer service or teleservice corresponds to the first Bearer capability information element that the network included in the SETUP message.
d)
e)
f)
g)
5.11.4 Channel selection When all of the alternative bearers offered by the calling side use the same capacity on the ISDN interface channel, selection procedures in 5.1.2 and 5.2.3 shall apply. When a preferred bearer requires a larger bearer than an allowed alternate fallback, e.g. 6 64 kbit/s to 64 kbit/s, channel selection procedures will follow 5.1.2 and 5.2.3 for the most preferred bearer, i.e. with the largest capacity requirement. If fallback occurs, the fallback bearer will use the lowest available time slot(s) corresponding to the channel selected for the preferred bearer. The remaining time slots will be available for further use after indication of fallback on the interface. For example, if time slots 7 through 12 were selected for a preferred 6 64 kbit/s bearer and later the call falls back to 64 kbit/s or speech, time slot 7 will be used for the call and time slots 8 through 12 will be available for further use after the CONNECT message has been received for the call. If early backward cut through is applicable to any of the bearer capabilities indicated, it will be provided on the lowest numbered time slot within the channel selected.
NOTE These fallback procedures are not permitted if the user explicitly requests H0, H11 or H12.
Optional procedures in Annex N may be used to provide for flexible channel negotiation in conjunction with bearer fallback procedures.
150
(05/98)
5.12
Signalling procedures for high layer compatibility selection
The procedures in this subclause form an optional part of this Recommendation, but are a mandatory requirement for the provision of certain teleservices. Provision of these procedures between the originating user and the originating network, and also between the destination network and the destination user is thus subject to bilateral agreement, e.g. a subscription arrangement for the provision of that teleservice to each user. These procedures shall apply only in the case where the call, or call request, as currently routed, is entirely within the ISDN. It will not apply to situations involving interworking with non-ISDNs. 5.12.1 Procedures for the originating user to indicate high layer compatibility selection is allowed 5.12.1.1 Normal operation In some networks, the originating user can indicate that: fallback to an alternative high layer compatibility is allowed; or fallback to an alternative high layer compatibility is not allowed.
If the calling user allows fallback to occur to an alternative high layer compatibility, then the user shall indicate this to the network by means of repeated High layer compatibility information elements within the SETUP message sent to indicate the presence of a call request. This procedure allows a maximum of two High layer compatibility information elements in the SETUP message. The order of the information elements shall be in ascending order of priority, i.e. a subsequent High layer compatibility information element shall indicate a high layer compatibility with higher priority. If fallback allowed is indicated in the SETUP message as described above, and fallback occurs at the destination user, or fallback does not occur, the originating network shall include in the CONNECT message sent to the calling user the High layer compatibility information element of the resultant high layer compatibility. If fallback allowed is indicated in the SETUP message as described above, and fallback occurs within the ISDN, the originating network shall include in a PROGRESS message or other appropriate call control message sent to the calling user a Progress indicator information element with the progress description No. 5, interworking has occurred and has resulted in a telecommunication service change. The originating network shall include the High layer compatibility information element of the resultant high layer compatibility. When a PROGRESS message is sent containing a Progress indicator information element with progress description No. 5, interworking has occurred and has resulted in a telecommunication service change, neither the user nor the network shall stop timers described in 5.1.6 as a result of this action. 5.12.1.2 Exceptional procedures The procedures of 5.8 shall apply, with the addition that: a) If the calling user receives no High layer compatibility information element in the CONNECT message, or prior to the CONNECT message in some other call control message, the user shall assume that the high layer compatibility is unknown.
NOTE It may be possible to subsequently identify the high layer compatibility from any in-band protocol within the B-channel.
b)
If the calling user receives a Progress indicator information element with a progress description No. 1, call is not end-to-end ISDN; further call progress information may be
(05/98)
151
available in-band or progress description No. 2, destination address is non-ISDN, subsequent to a Progress indicator information element with a progress description No. 5, interworking has occurred and has resulted in a telecommunication service change, then the last received Progress indicator information element shall be taken account of. Where the progress description is No. 1, call is not end-to-end ISDN; further call progress information may be available in-band, or progress description is No. 2, destination address is non-ISDN, the user shall assume a bearer service category of circuit-mode 64 kbit/s 8 kHz structured usable for 3.1 kHz audio information transfer. 5.12.2 Procedures for high layer compatibility selection at the destination side 5.12.2.1 Normal operation If the calling user and the network operator allow high layer compatibility selection, then the destination network shall indicate this to the destination user by including multiple High layer compatibility information elements within the SETUP message sent to indicate the presence of a call request. The order of the information elements shall be in ascending order of priority, i.e. a subsequent High layer compatibility information element shall indicate a high layer compatibility with higher priority. If fallback allowed is indicated in the SETUP message as described above, and the user wishes to accept the call without having fallback occur, the user shall include in the CONNECT message sent to the network the High layer compatibility information element of the requested high layer compatibility. If fallback allowed is indicated in the SETUP message as described above, and the user wishes to accept the call with having fallback occur to the lowest priority alternative high layer compatibility, the user may, but need not, include in the CONNECT message sent to the network the High layer compatibility information element of the alternative high layer compatibility. If no High layer compatibility information element is indicated by the called user, the network shall assume that the lowest priority high layer compatibility is selected. If fallback allowed is indicated in the call request, and no interworking has been encountered (i.e. a progress description No. 1, call is not end-to-end ISDN, further call progress information may be available in-band, or progress description No. 2, destination address is non-ISDN has not been sent), then the destination network shall indicate the resultant high layer compatibility to the originating network at the time the bearer is established, even if no High layer compatibility information element is received from the destination user. 5.12.2.2 Exceptional procedures The procedures of 5.8 shall apply, with the addition that if the called user sends a High layer compatibility information element in the CONNECT message that is not as requested or the nominated alternative, the destination network shall pass this transparently towards the calling user. 5.12.3 Procedures for interworking with private ISDNs 5.12.3.1 Procedures for the originating user to indicate high layer compatibility selection is allowed The procedures of 5.12.1 shall apply.
152
(05/98)
5.12.3.2 Procedures for high layer compatibility selection at the destination side of a public ISDN 5.12.3.2.1 Normal operation If a private ISDN is attached to the access at the destination interface, the following procedures are applicable at call request. The private ISDN acts as the called user. If the calling user allows fallback to occur to an alternative high layer compatibility, then the network shall indicate this to the called user by including multiple High layer compatibility information elements within the SETUP message sent to indicate the presence of a call request. The order of the information elements shall be in ascending order of priority, i.e. a subsequent High layer compatibility information element shall indicate a high layer compatibility with higher priority. If fallback allowed is indicated in the SETUP message as described above, and fallback occurs at the destination user (beyond the private ISDN) or fallback does not occur, the user shall include in the CONNECT message sent to the network the High layer compatibility information element of the resultant high layer compatibility. If fallback allowed is indicated in the SETUP message as described above, and fallback occurs within the private ISDN, the user shall include in a PROGRESS message or other appropriate call control message sent to the network a Progress indicator information element with a progress description No. 5, interworking has occurred and has resulted in a telecommunication service change. The user shall include the High layer compatibility information element of the resultant high layer compatibility. When a PROGRESS message is sent containing a Progress indicator information element with progress No. 5, interworking has occurred and has resulted in a telecommunication service change, neither the user nor the network shall stop timers described in 5.2.6 as a result of this action. 5.12.3.2.2 Exceptional procedures The procedures of 5.8 shall apply, with the addition that: a) If the network receives no High layer compatibility information element in the CONNECT message, or prior to the CONNECT message in some other call control message, the network shall assume that the high layer compatibility is unknown.
NOTE It may be possible to subsequently identify the high layer compatibility from any in-band protocol within the B-channel.
b)
If the network receives a Progress indicator information element with a progress description No. 1, call is not end-to-end ISDN; further call progress information may be available inband, or progress description No. 2, destination address is non-ISDN subsequent to a Progress indicator information element with a progress description No. 5, interworking has occurred and has resulted in a telecommunication service change, then the last received Progress indicator information element shall be taken account of. Where the progress description is No. 1, call is not end-to-end ISDN; further call progress information may be available in-band, or progress description is No. 2, destination address is non-ISDN, the network shall assume a bearer service category of circuit-mode 64 kbit/s 8 kHz structured usable for 3.1 kHz audio information transfer. Packet communication procedures
This clause is intended to explain the role of the D-channel signalling procedures in the support of packet communications in an ISDN. A complete description of terminal adaptor functions can be found in Recommendation X.31 [14].
(05/98)
153
According to Recommendation X.31, the user may access packet facilities by means of one of the following alternatives: a) Circuit-switched access to PSPDN services (Case A) by establishing a transparent circuit-switched access connection through the ISDN to the access port of a public network (e.g. PSPDN) referred to as "Access Unit (AU)" in the following subclauses. This connection may be initiated by the user or the AU. From the ISDN point of view, the circuit-switched call control procedures of clause 5 apply. Only the B-channel is used in this case. b) Packet-switched access to an ISDN virtual circuit service (Case B) by establishing a packet-mode access connection to the Packet Handler (PH) of an ISDN. This connection may be initiated by the user or the ISDN. Both B- and D-channels may be used in this case. A more detailed description of the protocol and text of 6.1 to 6.5 is in Recommendation X.31. Appendix II/Q.931 and Appendix III/X.31 are essentially the same. The term "user" refers to the user equipment which may consist of an ISDN packet-mode terminal (TE1) or a combination of an existing data terminating equipment (DTE/TE2) attached to a Terminal Adaptor (TA). A DTE may not receive all of the information provided in Q.931 signalling messages at the user-network interface. The ISDN TA/TE1 presents an S/T interface towards the network and therefore the TA/TE1 implementation should embody the procedures described in Recommendation Q.921 and this Recommendation for B- and D-channel connection establishment and control. For demand access connections, subclauses 6.1 through 6.4 apply. Example message flows for demand access connections are shown in Appendix II. Two physical types of semi-permanent connections on B- and D-channels are covered in this clause: 1) physical layer semi-permanently established between the terminal and the PH/AU, i.e. the I.430 and I.431 physical layer remains activated and the physical path through the ISDN is connected semi-permanently; and X.25 data link and physical layers semi-permanently established between the terminal and the PH/AU (in this type, both the user and the network shall keep the X.25 data link layer in the established state).
2)
When a PVC is used, there must exist a type 2 semi-permanent connection. In semi-permanent connection type 1, the procedures of 6.3 are followed for X.25 call establishment and release. In semi-permanent connection type 2, only the procedures of 6.3.2 are followed for X.25 call establishment and release. When semi-permanent connection type 2 is used for PVCs, none of the following procedures apply. Semi-permanent connections are established via a provisioning process without Q.931 procedures. 6.1 Outgoing access
If the user selects an already established channel for the outgoing X.25 virtual call, then the procedures described in 6.3 apply. If the selected channel is not established to the AU/PH, then the procedures for activating a channel described in the following subclauses are to be used before establishing the virtual call using the procedures of 6.3.
154
(05/98)
For outgoing X.25 data calls, the user first must decide whether circuit-switched (Case A) or packetswitched services (Case B) are desired from the network. For outgoing circuit calls, the user follows the procedures of 6.1.1. For outgoing packet calls, the user decides whether the B-channel or D-channel is to be used for the packet call. If the user decides to use the B-channel, then the procedures described in 6.1.2.1 are used. If the user decides to use the D-channel, then the procedures described in 6.1.2.2 are used.
NOTE Some networks may not support every type of access. In the case of B-channel access, the network will clear a request for unsupported services by sending a RELEASE COMPLETE message with cause No. 65, bearer capability not implemented. In the case of a request for D-channel access (an SABME with SAPI = 16), on a network port which does not support the service, no response is required of the network.
6.1.1
Circuit-switched access to PSPDN services (Case A)
The B-channel connection between the user and the AU shall be controlled using the D-channel signalling procedures for call establishment described in 5.1. The specific B-channel to be used as a switched connection is selected using the channel selection procedures described in 5.1.2 and summarized in Table 6-1. Table 6-1/Q.931 User requested channel and network response, Outgoing access to either an AU or PH
Channel indicated in the SETUP message user-to-network direction Information channel selection Bi Any Bi Bi Preferred or exclusive Exclusive Preferred (Ignore) (Absent) The indicated (idle) B-channel Any (other) idle B-channel D-channel indicator (Note 1) No No No Allowable network response (network-user) Bi Bi, Bi Bi Bi
NOTE 1 D-channel indicator shall be encoded "0" to indicate No and "1" to indicate Yes. NOTE 2 All other encodings are invalid. NOTE 3 All columns under the heading "Channel indicated in the SETUP message" indicate possible user codings of the Channel identification information element contained in the SETUP message sent by the user to the network requesting a connection to an AU or PH (see 4.5.13). The column under "Allowable network response" refers to the allowable responses by the network to the user.
On the basis of the call set-up information (e.g. called party number identifying an AU, transit network selection, etc.) and/or a subscription time agreement, the network provides a connection to the appropriate AU. The Bearer capability information element included in the SETUP message shall be encoded with: information transfer capability set to either: a) unrestricted digital information; or b) restricted digital information; transfer mode set to circuit mode; information rate set to 64 kbit/s.
(05/98)
155
The user may also specify the layer 1 (e.g. rate adaption), layer 2 (i.e. LAPB), and layer 3 (i.e. X.25) information transfer protocols in the Low layer compatibility information element in the SETUP message (see Annex I). 6.1.2 6.1.2.1 Access to the ISDN virtual circuit service (Case B) B-channel
Demand access B-channel connections are controlled using the D-channel signalling procedures for call establishment described in 5.1 using the messages defined in 3.2 with the following exceptions: a) b) c) d) e) the procedures for overlap sending specified in 5.1.3 do not apply; the procedures for call proceeding and overlap sending specified in 5.1.5.2 do not apply; the procedures for notification of interworking at the origination interface specified in 5.1.6 do not apply; the procedures for call confirmation indication specified in 5.1.7 do not apply; the procedures for call connection specified in 5.1.8 apply as follows: upon accepting the access connection, the network shall send a CONNECT message across the user-network interface to the calling user and enter the Active state; this message indicates to the calling user that an access connection to the packet handler has been established; on receipt of the CONNECT message, the calling user shall stop timer T310, if running, may optionally send a CONNECT ACKNOWLEDGE message, and shall enter the Active state; when unable to accept the access connection, the network shall initiate ISDN access connection clearing at the originating user-network interface as described in 5.3;
f)
the procedures for call rejection specified in 5.1.9 apply as follows:
g)
the procedures for transit network selection specified in 5.1.10 do not apply.
The specific B-channel to be used as a demand connection is selected using the channel selection procedures described in 5.1.2 and summarized in Table 6-1. For a demand connection to an ISDN PH, the Bearer capability information element included in the SETUP message shall be coded with: information transfer capability set to unrestricted digital information; transfer mode set to packet mode; information transfer rate set to 00000; user information layer 2 protocol set to Recommendation X.25, link layer; user information layer 3 protocol set to Recommendation X.25, packet layer.
NOTE Octets 5a, 5b, 5c and 5d shall not be included.
The demand access connection can then be used to support packet communications according to X.25 link layer and X.25 packet layer procedures as specified in 6.3. Some ISDNs may require the Calling party number and the Calling party subaddress information elements to be included in the SETUP message to select a specific user profile. 6.1.2.2 D-channel
The D-channel provides a connection which enables the ISDN user terminal to access a PH function within the ISDN by establishing a link layer connection (SAPI = 16) to that function which can then
156
(05/98)
be used to support packet communications according to X.25 layer 3 procedures as defined in 6.3. The X.25 packet layer uses the acknowledged information transfer service (i.e. I-frames) provided by LAPD (see Recommendation Q.920 [45]). Consequently, Q.931 procedures are not required to provide D-channel access. A number of packet mode user equipment can operate simultaneously over the D-channel, each using a separate ISDN layer 2 data link identified by an appropriate address (see Recommendation Q.921) in frames transferred between the user and the PH. 6.2 6.2.1 Incoming access Access from PSPDN services (Case A)
The ISDN signals the establishment of the circuit-mode connection using the procedures described in 5.2. The X.25 virtual calls are signalled between the user and the AU using the procedures described in 6.3. 6.2.1.1 General
The general procedures performed by the AU are those defined in Recommendation X.32. 6.2.1.2 Channel selection
If the ISDN physical circuit desired by the AU does not exist between the terminal and the AU, the procedures for physical channel establishment described in the following subclauses apply. The format of the SETUP message sent by the network to the user is in accordance with 3.1. The Bearer capability information element included in the SETUP message shall be encoded with: information transfer capability set to either: a) unrestricted digital information; or b) restricted digital information; transfer mode set to circuit mode; information rate set to 64 kbit/s.
The Channel identification information element shall be encoded according to Table 6-2. The B-channel connection to the called user shall be established by the network using the signalling procedures described in 5.2. The call is offered by sending the SETUP message on a point-to-point data link or on the broadcast data link. The user responds to the SETUP as defined in clause 5.
(05/98)
157
Table 6-2/Q.931 Network requested channel and user response, Incoming access from an AU
Channel indicated in the SETUP message network-to-user direction Information channel selection Bi Bi Bi Bi Indicated (idle) B-channel Any other idle B-channel (not permitted for broadcast call offering) Preferred or exclusive Exclusive Preferred D-channel indicator (Note 1) No No Allowable network response (user-network) Bi Bi, Bi (Note 2)
NOTE 1 D-channel indicator shall be encoded "0" to indicate No and "1" to indicate Yes. NOTE 2 This encoding is not used for broadcast call offering. NOTE 3 All other encodings are invalid.
6.2.2 1)
Access from the ISDN virtual circuit service (Case B) Channel selection The physical channel/logical link to be used for the incoming call must be identified. The network may use customer profile information, network resources, etc., to choose the channel or the procedures of Step 2 below. Physical channel/logical link establishment If the physical B-channel or the logical link of the D-channel has not been determined by Step 1, the network may use the procedures in 6.2.2.3. The network may then proceed with Step 3. X.25 virtual call establishment The network establishes the virtual call using the procedures described in 6.3.
To offer an incoming X.25 call, the network must perform the following steps in sequence:
2)
3)
In the configuration for the ISDN virtual circuit bearer service, the choice of channel type to be used for the delivery of a new incoming call packet shall be made by the network as described below. a) A new incoming call packet may be indicated to the ISDN customer by a call offering procedure between the network and all user packet-mode terminals (see 3.2.3.2/X.31 and 3.2.3.3/X.31 [14]). An incoming virtual call directed to a terminal with an established connection to the PH may be offered directly to the terminal over the established access connection without the use of Q.931 call offering procedures (see 3.2.3.1/X.31 and 3.2.3.2/X.31 [14]). B-channel
b)
6.2.2.1
When X.25 calls are to be offered on the B-channels without channel negotiation, the procedures described in 5.2 using the messages of 3.2 apply with the following exceptions: a) b) The procedures for overlap receiving specified in 5.2.4 do not apply. The procedures for receipt of CALL PROCEEDING and ALERTING specified in 5.2.5.2 apply with the following exception: c) The receipt of an ALERTING message shall not cause the network to send a corresponding ALERTING message to the calling user. The network clears the incoming X.25 virtual call towards the calling X.25 DTE using the appropriate cause from Table 6-5.
The procedures for call failure specified in 5.2.5.4 apply with the following remark:
158
(05/98)
d)
The procedures for notification of interworking at the terminating interface specified in 5.2.6 apply with the following exceptions: The case of the call entering an ISDN environment during call establishment is not applicable. In the case of a call leaving the ISDN environment within the called user's premises, no notification is sent to the calling party. The case of in-band information/patterns is not applicable. The network shall not initiate procedures to send a CONNECT message towards the calling user.
e)
The procedures for active indication specified in 5.2.8 apply with the following exception:
f)
The procedures for user notification specified in 5.9 do not apply.
Where an established B-channel connection is to be used, the incoming call packet will be delivered in accordance with 6.3. Where a new B-channel connection is to be established, the identity of the selected user will be associated with the Connection Endpoint Suffix (CES) from which the first CONNECT message has been received. 6.2.2.2 D-channel
The D-channel provides a connection which enables the ISDN PH to access an ISDN user terminal or vice versa. This access is accomplished by establishing an ISDN link layer connection (SAPI = 16) to the terminal or network which can then be used to support packet communications according to X.25 [5] layer 3 procedures as defined in 6.3. The layer 2 procedures shall be in accordance with Recommendation Q.921 [3]. The D-channel provides a semi-permanent connection for packet access since all D-channel layer 2 frames containing a packet-mode SAPI (16) are routed automatically between the user and the PH function. When an incoming call is offered to packet-mode user equipment at the user interface, the channel selection procedures described in 6.2.2.3 shall be used. A number of packet mode terminals can operate simultaneously over the D-channel, each using a separate layer 2 link identified by an appropriate TEI (see Recommendation Q.921) in frames transferred between the terminal and the network. 6.2.2.3 6.2.2.3.1 Call offering Channel selection through call offering
The call offering procedure is performed using the layer 3 messages and procedures of clause 5. The call offering procedure is integrated into the circuit-switched call control procedures, signalled on the D-channel, with the channel selection being accomplished by means of the channel selection procedure if offered as a network option. As described in clause 5, the network selects the first user which responds to the call offering with a CONNECT message. When the selected user has requested that the X.25 call be set up over a new Bchannel, the network will indicate that the channel is acceptable by returning a CONNECT ACKNOWLEDGE message to the user. If multiple terminals have responded positively to the SETUP message, the network shall clear each of the non-selected terminals with a RELEASE message containing cause No. 26, non-selected user clearing. When the selected user has requested that the X.25 call be set up over an established B-channel or the D-channel, the network shall respond to the CONNECT message with a RELEASE message
(05/98)
159
containing cause No. 7, call awarded and being delivered in an established channel. The network shall also return a RELEASE message containing cause No. 26, non-selected user clearing, to any other positively responding terminals. The network will then deliver the X.25 virtual call over the selected channel.
NOTE 1 There is no time significance between the delivery of the RELEASE message and the incoming call packet, i.e. either may occur first. NOTE 2 The network shall send the RELEASE message(s) and the user(s) shall respond with RELEASE COMPLETE.
If the channel indicated by the first positively responding user is not available, the network will use Q.931 call clearing procedures to clear the call with cause No. 6, channel unacceptable. If the channel indicated in the SETUP message is not acceptable to the user, the user will clear the call with a RELEASE COMPLETE message containing cause No. 34, no circuit/channel available, or cause No. 44, requested circuit/channel not available. On the basis of a network option or subscription agreement, the network may choose the access channel or access channel type (e.g. B or D) for a particular incoming packet call. When the Channel indication information element indicates Channel indication = No channel, Exclusive, and D-channel indication Yes, then the Bearer capability information element should be coded as follows: information transfer capability set to unrestricted digital information; transfer mode set to packet mode; information rate set to packet mode (00000); layer 2 protocol set to Recommendation Q.921; layer 3 protocol set to Recommendation X.25, packet layer. information transfer capability set to either: a) unrestricted digital information; or b) restricted digital information; transfer mode set to packet mode; information rate set to packet mode (00000); layer 2 protocol set to Recommendation X.25, link layer; layer 3 protocol set to Recommendation X.25, packet layer.
In all other cases, the Bearer capability information element should be encoded as follows:
There exists an understanding that if the terminal responds with D-channel indication set (see Table 6-3), the Layer 2 protocol to be used is Recommendation Q.921 (LAPD).
160
(05/98)
Table 6-3/Q.931 Network requested channel and user response, Incoming access for packet-mode
Channel indicated in the SETUP message network-to-user direction Information channel selection Bi Bi Preferred or exclusive Exclusive Preferred Preferred No channel Exclusive Bi Bi Bj D Indicated (idle) B-channel Any other idle B-channel (not permitted in response to broadcast call offering) An established B-channel under the user's control (a semi-permanent B-channel which is allocated to the user may be indicated if the user subscribes to the unconditional notification class) The D-channel D-channel indicator (Note 1) No Yes No Yes No Yes Yes Allowable network response (network-user) Bi Bi, D Bi, Bi, Bj Bi, Bi, Bj, D Bj Bj, D D
NOTE 1 D-channel indicator shall be encoded "0" to indicate No and "1" to indicate Yes. NOTE 2 All other encodings are invalid.
The channel selection procedure for incoming calls is independent of the type of channel selected at the calling end. In this respect, any combination of channel type used at each end is possible, provided the user rates and available bandwidth are compatible. The channel selection principle to be used in the procedure is shown in Table 6-3.
NOTE 3 When the incoming SETUP message is sent on a broadcast data link with a Channel identification information element which indicates an idle B-channel and preferred, the called user is not permitted to respond with a different idle B-channel in the response. The option to respond with a different idle channel is restricted to point-to-point call offerings. NOTE 4 Networks providing packet-mode call offering shall provide Q.931 signalling procedures for packet-mode calls on SAPI = 0. For an interim period, some networks, by subscription agreement, may offer SAPI = 16 broadcast call offering procedures for providing Q.931 signalling. This option shall use all Q.931 procedures for packet-mode calls with the following restriction: All calls will be offered as D-channel exclusive and will not provide channel selection procedures. Terminals implementing SAPI = 16 procedures should also implement SAPI = 0 procedures for portability.
6.2.2.3.2
Information element mapping
Some networks may choose to provide a service of mapping some or all of the information from the incoming call packet into the SETUP message (see 3.2.3/X.31). Table 6-4 shows the mapping of the X.25 incoming call elements to Q.931 information elements. The incoming call packet will still contain these fields when it is delivered. See 3.2.3/X.31 for mapping requirements.
(05/98)
161
Table 6-4/Q.931 Mapping of X.25 information elements to corresponding Q.931 SETUP message information elements in packet-mode incoming calla)
Information elements in X.25 incoming call packet Calling DTE address Called DTE address User data (UD) A-bit (Note 2) D-bit Modulus Flow control parameter negotiation Throughput class negotiation Fast select Reverse charging X.25 user facility Closed user group selection Closed user group with outgoing access selection Bilateral closed user group Transit delay selection and indication Call redirection and deflection notification Calling address extension Called address extension End-to-end transit delay DTE facility Minimum throughput class Expedited data negotiation Priority Protection Corresponding information element in Q.931 SETUP message Calling party number (Note 6) Called party number User-user information (Note 1) For further study Packet layer binary parameters Packet layer binary parameters Packet size, Packet layer window size Information rate (Note 4) Packet layer binary parameters Reverse charging indication Closed user group Closed user group For further study Transit delay selection and indication Redirecting number Calling party subaddress Called party subaddress (Note 5) End-to-end transit delay Information rate (Note 3) Packet layer binary parameters For further study For further study
162
(05/98)
Table 6-4/Q.931 Mapping of X.25 information elements to corresponding Q.931 SETUP message information elements in packet-mode incoming calla) (concluded)
a)
Mapping is optional or required as indicated in 8.2.3/X.31.
NOTE 1 The maximum length of the user data within the User-user information element is network dependent and is either 32 or 128 octets. NOTE 2 The need and procedures for A-bit mapping is for further study. NOTE 3 This information is not always present even when the "Information rate" is provided in the Q.931 SETUP message. NOTE 4 When the "Throughput class negotiation" is not set in the X.25 incoming call packet, this information shall be provided as the default throughput values applying to the virtual call. NOTE 5 The network will map bits 8 and 7 of the first octet of the called address extension facility parameter field in X.25 incoming call packet to type of subaddress field in octet 3 of the Called party subaddress information element in the Q.931 SETUP message, assuming that the X.25 incoming call packet is coded based on the 1988 version of X.25. Therefore, the called user should notice that the received type of subaddress may not be correct when the X.25 incoming call packet is coded based on the 1984 version of X.25. NOTE 6 This mapping is mandatory and octet 3a shall be set with Presentation indicator set to presentation allowed and Screening indicator set to network provided.
6.2.2.3.3
Channel selection without call offering
Where the network and user have agreed beforehand, the network may route an incoming call to the called user over an established B-channel connection or D-channel link without the need for any signalling for channel selection. 6.3 X.25 virtual call establishment and release
In all cases, once the physical channel has been selected and, if necessary, connected to the PH or AU, the virtual call is established according to the procedures below. Some networks may require some of the terminal identification procedures of Recommendation X.32 as well. 6.3.1 6.3.2 Link layer establishment and release the calling terminal in the case of outgoing calls; the AU in the case of incoming calls in Case A; or the PH in the case of incoming calls in Case B. the terminal; the AU in Case A; or the PH in Case B. Packet layer virtual call set-up and release
Link layer (LAPB on the B-channel or LAPD on the D-channel) establishment shall be initiated by:
Link layer release may be initiated by:
The packet layer procedures of Recommendation X.25 will be used for layer 3 call setup and release. The packet layer procedures will additionally be able to control and monitor the established or released state of the link layer.
(05/98)
163
In Case B, the PH may maintain a timer T320 (defined in this Recommendation). T320, if implemented, is started: a) b) c) d) 1) 2) 3) upon clearance of the last virtual call; or upon transmission of a CONNECT message by the network in case of an outgoing Bchannel access connection; or upon transmission of a CONNECT ACKNOWLEDGE message by the network in case of an incoming B-channel access connection; or upon establishment of the link layer for D-channel access connections. establishment of the first (next) virtual call; or receipt of a Q.931 clearing message from the user; or disconnection of the SAPI = 16 link on the D-channel.
T320 is cancelled upon:
Upon expiry of timer T320, the PH will release the link layer and, in the case of B-channel access, initiate clearing of the B-channel. X.25 logical channels are associated with their underlying logical link. Specifically, in the case of the use of the B-channel for packet communication, there is an association between the logical channels and the LAPB logical link below them. Thus, the same logical channel number may be used simultaneously on each different B-channel. 6.4 6.4.1 Call clearing B-channel access
The clearing of the switched connection shall be effected by using the D-channel signalling procedures for call clearing as specified in 5.3. For access to PSPDN services, no exceptions apply. For the ISDN virtual circuit service, the messages of 3.2 are used, and the following exceptions apply: The terms defined in 5.3.1 (Terminology) apply by replacing "circuit-switched ISDN connection" with "demand packet mode access connection". The exception condition f) specified in 5.3.2 does not apply. The procedures for clearing with tones and announcements provided in 5.3.4.1 do not apply.
The B-channel may be cleared at any time by the user though, in general, it will be cleared following the clearing of the last virtual call over that B-channel. In the ISDN virtual circuit service, if the user clears the B-channel access connection using a Q.931 clearing message while X.25 virtual calls still exist on the B-channel, the network shall clear the X.25 virtual call(s) with cause No. 17, remote procedure error, and diagnostic No. 64, call set-up, call clearing or registration problem. In Case B, if a Q.931 restart indication is received by the PH during the X.25 data transfer phase, the X.25 virtual calls shall be treated as follows: For switched virtual circuits which are established on a demand connection to the packet handler, an X.25 clear indication packet shall be sent with cause No. 9, out of order, and diagnostic No. 0, no additional information. For any virtual calls which are established on a semi-permanent connection to the packet handler, no action shall be taken.
164
(05/98)
At the expiration of timer T320, the network may disconnect the X.25 link layer and the access connection. B-channel clearing is as described in 5.3 with the exceptions above, with cause No. 102, recovery on timer expiry. 6.4.2 6.4.3 D-channel access Additional error handling information D-channel access connections are cleared using the disconnect procedures as defined in 6.3. When an ISDN access connection failure occurs, or the X.25 virtual call is cleared prematurely, the rules of 5.8 shall apply. In addition, the following rules for determining the appropriate cause to be used shall apply in order of decreasing priority: 1) 2) If a Q.931 clearing message or RESTART message is received by the PH during the X.25 data transfer phase, 6.4.1 applies. In general, if an ISDN access connection is rejected by the destination user using Q.931 messages, the X.25 virtual call shall be cleared using a clear indication packet and cause No. 0, DTE originated, with diagnostic No. 0, no additional information. Some networks may map some Q.931 causes to the corresponding X.25 causes according to Table 6-5. If a condition exists that prevents the Q.931 SETUP message from being delivered at the user-network interface, the X.25 virtual call shall be cleared using a clear indication packet and a cause shall be selected appropriate to the condition. Table 6-5 shall serve as a guide to selecting an appropriate cause, i.e. the X.25 mapping of the Q.931 cause describing the interface condition shall be used. If the Q.931 SETUP message is sent across the user-network interface, but no response is received prior to the second expiry of timer T303, rule No. 3 applies. If the Q.931 SETUP message is sent across the user-network interface, and a response other than a call rejection is received from a user which results in the clearing of the ISDN access connection at the user-network interface, the X.25 virtual call shall be cleared using a clear indication packet containing cause No. 17, remote procedure error, with diagnostic No. 64, call set-up, call clearing or registration problem. If an X.25 clear request packet is received from the originating user prior to the delivery of the X.25 incoming call packet to the called user (premature clearing), the PH shall send a clear confirmation packet to the calling user and the access connection shall be treated as follows: If the Q.931 SETUP message was associated with the Unconditional notification class of service (see 3.2.3/X.31), the access connection, when and if established, shall be cleared. The Q.931 clearing message shall contain the appropriate cause as described in Table 6-6. If the Q.931 SETUP message was associated with the Conditional notification class of service (see 3.2.3/X.31) and there exists at least one terminal which responds positively to the Q.931 SETUP message, then two options are allowed: a) the access connection is cleared as described for the Unconditional class of service; or b) the access connection is established and timer T320 is started. Upon expiry of timer T320, the access connection is cleared with cause No. 102, recovery on timer expiry, and diagnostic indicating timer T320.
3)
4) 5)
6)
(05/98)
165
6.4.4 6.4.4.1
Cause mappings Access to/from PSPDN services (Case A)
The AU may choose to follow the procedures in 6.4.4.2 when mapping between causes delivered by the ISDN or the PSPDN. 6.4.4.2 Access to/from the ISDN virtual circuit service (Case B)
There are several cases where it is necessary to map causes between this Recommendation and Recommendation X.25. ISDN networks shall use Tables 6-5 and 6-6 to map the causes between Q.931 and X.25 messages. The figures in Appendix II describe some example situations. Table 6-5/Q.931 Mapping of Q.931 cause fields to X.25 cause field
Item 1 Q.931 cause Unallocated (unassigned) number No route to destination Code 1 Q.931 diagnostic Condition: unknown, transient, permanent Condition: unknown, transient, permanent (None) X.25 cause Not obtainable Code 13 X.25 diagnostic Invalid called address Code 67
Not obtainable
13
Invalid called address
67
Channel unacceptable
Remote procedure error DTE originated
17
Call set-up, call clearing or registration problem No additional information
64
Normal call clearing
16
Condition: unknown, transient, permanent (None) (None)
5 6
User busy No user responding
17 18
Number busy Remote procedure error Remote procedure error DTE originated
1 17
No logical channel available Call set-up, call clearing or registration problem Call set-up, call clearing or registration problem No additional information
71 64
No answer from user (user alerted)
19
(None)
17
64
Call rejected
21
Condition: unknown, transient, permanent + user applied diagnostics New destination address (None)
9 10
Number changed Destination out of order
22 27
Not obtainable Out of order
13 9
Invalid called address No additional information
67 0
166
(05/98)
Table 6-5/Q.931 Mapping of Q.931 cause fields to X.25 cause field (continued)
Item 11 Q.931 cause Invalid number format (address incomplete) Normal, unspecified No circuit/channel available Network out of order Temporary failure Switching equipment congestion Requested circuit/channel not available Resource unavailable, unspecified Quality of service not available Code 28 Q.931 diagnostic (None) X.25 cause Local procedure error DTE originated Number busy Out of order Out of order Network congestion Number busy Code 19 X.25 diagnostic Invalid called address No additional information No logical channel available No additional information No additional information No additional information No logical channel available No additional information No additional information Code 67
12 13 14 15 16
31 34 38 41 42
(None) (None) (None) (None) Network identity
0 1 9 9 5
0 71 0 0 0
17
44
(None)
71
18
47
(None)
Network congestion Network congestion
19
49
Condition: unknown, transient, permanent Attribute number Attribute number
20 21
Bearer capability not authorized Bearer capability not presently available Service or option not available, unspecified Bearer capability not implemented Channel type not implemented
57 58
Incompatible destination Remote procedure error Remote procedure error Incompatible destination Remote procedure error Remote procedure error Remote procedure error
33 17
No additional information Call set-up, call clearing or registration problem Call set-up, call clearing or registration problem No additional information Call set-up, call clearing or registration problem Call set-up, call clearing or registration problem Call set-up, call clearing or registration problem
0 64
22
63
(None)
17
64
23 24
65 66
Attribute numbers Channel type
33 17
0 64
25
Service or option not implemented, unspecified Valid call reference value
79
(None)
17
64
26
81
(None)
17
64
(05/98)
167
Table 6-5/Q.931 Mapping of Q.931 cause fields to X.25 cause field (continued)
Item 27 Q.931 cause Identified channel does not exist Code 82 Q.931 diagnostic Channel identity X.25 cause Remote procedure error Incompatible destination Remote procedure error Remote procedure error Remote procedure error Remote procedure error Code 17 X.25 diagnostic Call set-up, call clearing or registration problem No additional information Call set-up, call clearing or registration problem Call set-up, call clearing or registration problem Call set-up, call clearing or registration problem Call set-up, call clearing or registration problem Call set-up, call clearing or registration problem Call set-up, call clearing or registration problem Call set-up, call clearing or registration problem Call set-up, call clearing or registration problem Call set-up, call clearing or registration problem Call set-up, call clearing or registration problem Code 64
28 29
Incompatible destination Invalid message, unspecified
88 95
Incompatible parameter (None)
33 17
0 64
30
Mandatory information element is missing Message type nonexistent or not implemented Message not compatible with call state or message type non-existent or not implemented Information element/parameter non-existent or not implemented Invalid information element contents
96
Information element identifier(s) Message type
17
64
31
97
17
64
32
98
Message type
17
64
33
99
Information element identifier(s) Information element identifier(s) Message type
Remote procedure error Remote procedure error Remote procedure error Remote procedure error Remote procedure error Remote procedure error
17
64
34
100
17
64
35
Message not compatible with call state Recovery on timer expiry
101
17
64
36
102
Timer number
17
64
37
Protocol error, unspecified
111
(None)
17
64
38
Interworking, unspecified
127
(None)
17
64
168
(05/98)
Table 6-5/Q.931 Mapping of Q.931 cause fields to X.25 cause field (concluded)
NOTE 1 When clearing occurs during the X.25 data transfer phase, the procedure described in 6.4.1 should be used. NOTE 2 When a Q.931 RESTART message is received during the X.25 data transfer phase, switched virtual circuits shall be cleared with a clear indication packet containing cause No. 9, out of order, with diagnostic No. 0, no additional information. Permanent virtual circuits shall have an X.25 reset packet sent with the same cause and diagnostic.
6.5
Access collision
When the network offers a packet-mode call at the interface simultaneously with the user requesting a packet-mode call, the network shall give priority to the completion of the incoming call. If the user determines that accepting the incoming call would meet the needs of its own outgoing call request, the user may clear the call request and accept the incoming call. 7 7.1 User signalling bearer service call control procedures General characteristics
This feature allows the users to communicate by means of user-to-user signalling without setting up a circuit-switched connection. A temporary signalling connection is established and cleared in a manner similar to the control of a circuit-switched connection. Table 6-6/Q.931 Mapping of X.25 cause to Q.931 cause for premature clearing of the incoming call
X.25 cause in clear indication packet Item 1 X.25/X.96 cause DTE originated Code 0 1XX 2 Network congestion Out of order Remote procedure error 5 Diagnostic No additional information DTE specified No additional information No additional information (Any allowed) Code 0 XX 0 Switching equipment congestion Destination out of order Protocol error, unspecified 42 (None) Q.931 error condition Q.931 cause Normal call clearing Code 16 Diagnostic (None)
3 4
9 17
27 111
(None) (None)
NOTE Instead of providing the above mapping of X.25 to Q.931, the PH, as a network option, may code the Q.931 Cause information element to indicate ITU-T Coding Standard in octet 3, X.25 in octet 3a, and code octets 4 and 5 according to Recommendation X.25, copying the cause from the X.25 clear indication packet rather than mapping it to a Q.931 cause.
(05/98)
169
7.2
Call establishment
Procedures for call establishment are as described in 5.1 and 5.2 with the following modifications. On call request, the calling user sends a SETUP message identifying, within the Bearer capability and Channel identification information elements, a temporary signalling connection to be established on SAPI = 0. The SETUP message is encoded to indicate: i) Bearer capability information element ii) Unrestricted digital information in the information transfer capability field; Packet mode in the transfer mode field; User information layer 2 protocol is Recommendation Q.921 and user information layer 3 protocol is this Recommendation in the layer and protocol identification field. Exclusive in the preferred/exclusive field; D-channel in the D-channel indicator field; no channel in the channel selection field.
Channel identification information element
If the network determines that the requested temporary signalling connection service is not authorized or is not available, the network shall initiate call clearing in accordance with 5.3.2 a) or 5.3.2 c) with one of the following causes: a) b) c) d) No. 57 Bearer capability not authorized; No. 58 Bearer capability not presently available; No. 63 Service or option not available, unspecified; or No. 65 Bearer capability not implemented.
The called user accepts the temporary signalling connection request by sending a CONNECT message towards the calling user. After the called user has received a CONNECT ACKNOWLEDGE message, it may begin sending USER INFORMATION messages. Once the calling user receives a CONNECT message, it can begin sending USER INFORMATION messages. 7.3 Transfer of USER INFORMATION messages
Once a temporary signalling connection is established, both users can transfer information between themselves by transferring USER INFORMATION messages across the user-network interface. The network provides for the transfer of such messages from the called to the calling side and vice versa. The USER INFORMATION message includes the Call reference, the Protocol discriminator, and the User-to-user information elements as defined in 3.3.13. The More data information element may also be sent by the source user to indicate to the remote user that another USER INFORMATION message will follow, containing information belonging to the same block. The use of the More data information element is not supervised by the network. 7.4 Congestion control of USER INFORMATION messages
The network or user will flow-control, when needed, the transfer of USER INFORMATION messages from a user or network by means of a CONGESTION CONTROL message containing a congestion level information element. Two indications of congestion level are specified: "receive not ready" and "receive ready". On receipt of the former, the user or network should suspend sending USER INFORMATION messages; on receipt of the latter, sending may recommence. After having sent a "receive not ready" indication, the network or user shall discard USER INFORMATION messages which are subsequently received. The network or user will send a CONGESTION
170
(05/98)
CONTROL message with a "receive not ready" indication whenever a USER INFORMATION message is locally discarded, if it is possible. The CONGESTION CONTROL message shall also include a cause No. 43, access information discarded. The network shall notify the user that flow control restriction has been removed by sending a CONGESTION CONTROL message with the congestion level specified as "receive ready" to indicate that further messages may be sent. This message may be sent, as an implementation option: a) b) c) immediately upon removal of the flow control restriction; in response to the first USER INFORMATION message received following the removal of the flow control restriction; or in both cases.
The receipt of the "receive ready" indication shall be interpreted as an indication that no more than n USER INFORMATION messages may be sent before another receive ready indication is received. In each direction a Burst Capability of sending n messages is immediately available where n initially equals the value of the Burst parameter x. The value of n shall be decremented by one for every message sent by the user and incremented by y at regular intervals of T (T = 10 seconds) subject to the limitation that n may not exceed x, i.e. n + y x. The Burst parameter x is a variable which shall be set to a value of x = 16. The replenishment parameter y shall be capable of taking a value y = 8.
NOTE While some networks may support higher values of x and y, the value of x and y across international interfaces shall be set as above. It is up to the network using higher values to take the appropriate actions, unless bilateral agreements exist.
If USER INFORMATION messages are received at a rate which exceeds the flow control limit set by the network, the network shall discard the messages that cannot be handled and respond to the first discarded message with a control indication. The network shall also respond to the first USER INFORMATION message received following the removal of flow control restriction by returning an indication that further messages may be sent. The Congestion control procedure should be regarded as local. Congestion control procedure for remote applications is for further study. 7.5 Call clearing
The clearing of an established temporary signalling connection can be initiated by the user or network by sending a RELEASE message towards the far end user. The clearing procedure followed and the timers involved are the same as those for clearing a circuit-switched connection as described in 5.3.3 and 5.3.4. 7.6 Handling of error conditions
In the event of a data link reset or failure, all temporary signalling connections on the D-channel shall be released as in 7.5. For data link resets, the clearing messages shall indicate cause No. 41, temporary failure, to both local and remote users. For data link failures, the clearing message to the remote user shall indicate cause No. 27, destination out of order, and the local temporary signalling connection shall be cleared internally.
(05/98)
171
7.7
Restart procedures
Handling of restart for temporary signalling connections shall be as described in 5.5.2. If a RESTART message is received with the Restart indicator information element coded as "all interfaces", or coded as "single interface" and the indicated interface includes the D-channel, then all temporary signalling connections on the D-channel shall be released. During restart the clearing message to the remote users shall include cause No. 41, temporary failure. 8 Circuit-mode multirate (64 kbit/s base rate) procedures
This clause provides the D-channel signalling procedures in support of circuit-mode multirate (64 kbit/s base rate) bearer capability. These procedures are mandatory when a supported bearer capability or teleservice requires a multirate (64 kbit/s base rate) bearer capability, else they are not required. The procedures of clause 5 shall apply except as identified in the following subclauses. 8.1 8.1.1 Call establishment at the originating interface Compatibility information
The Bearer capability information element shall be encoded as in 4.5.5 (Bearer capability) with the following exceptions: 1) 2) Octet 3 shall be coded unrestricted digital information. Octet 4 shall be coded circuit-mode and the information transfer rate (bits 5 to 1) shall be encoded:
Bits 54321 11000 Circuit-mode Multirate (64 kbit/s base rare)
3)
Octet 4.1 (Rate multiplier) shall be included. Bit 8 is for extension and set to 1. Bits 7-1 contain the binary coding of the multiplier that applies to the multirate codepoint contained in the information transfer rate subfield. Bit 1 is least significant. The multiplier value range is 2-30, all other values are reserved. Octet 4.1 shall be included if and only if the transfer rate is coded for multirate.
NOTE When the information transfer rate is 384 kbit/s, 1536 kbit/s, or 1920 kbit/s the information transfer rate in the Bearer capability information element may also be coded as 384 kbit/s (10011), 1536 kbit/s (10101), or 1920 kbit/s (10111) respectively instead of using the multirate (64 kbit/s base rate) codepoint and the associated rate multiplier field.
8.1.2
Channel selection
The channels selected for the multirate call shall be on one interface and shall be indicated in the SETUP message. The procedures in 5.1.2 and 5.2.3.1 shall be followed to complete the channel selection. The Channel identification information element is coded as per 4.5.13. The number of channels identified shall provide the information transfer rate identified in the Bearer capability information element. If the information transfer rate implied by the channel(s) or interface indicated in the Channel identification information element does not match the information transfer rate in the Bearer capability information element, the procedures in 5.8.6.2 shall apply.
172
(05/98)
Channel selection conflict occurs when the channels selected for an incoming and outgoing call do not constitute two disjoint sets of time slots. When channel selection conflict occurs, the procedures in 5.7 shall apply. Some networks may offer on access: 1) contiguous channel assignment (channels must be adjacent within a single interface); and/or
NOTE 1 On a 2048 kbit/s interface (containing a D-channel), channels 15 and 17 shall be considered contiguous.
2)
non-contiguous channel assignment (channels may be either adjacent or non-adjacent within a single interface).
Some networks may require that 384 kbit/s and/or 1536 kbit/s (in a 2048 kbit/s interface) occupy specified contiguous time slots (see Annex A/I.431). If the entire interface of a primary rate interface is used (i.e. 24 B-channels on a 1544 kbit/s interface or 30 B-channels on a 2048 kbit/s interface), octets 3.2 and 3.3 of the Channel identification information element shall not be included. If the entire interface of a basic access interface is used (i.e. 2 B-channels), octets 3.2 and 3.3 of the Channel identification information element shall not be included and the "information channel selection" shall be coded "11", any channel. In cases a) and b) of 5.1.2, if all the indicated B-channels are available, the network shall select them for the call. In case b) of 5.1.2, if the network cannot grant any preferred B-channel, it shall select any other available B-channels associated with the D-channel and on the same access, to replace the unavailable preferred B-channel, or select all the B-channels on another interface controlled by the D-channel.
NOTE 2 Whether only the B-channels that cannot be provided should be changed, or if all the B-channels can then be changed, is for further study.
In case c) of 5.1.2, the network shall select any available suitable B-channels. In case a) of 5.1.2, if any specified B-channel is not available, and in cases b) and c) of 5.1.2 if insufficient B-channels are available, the network shall send a RELEASE COMPLETE message with cause No. 44, requested circuit/channel not available or No. 34, no circuit/channel available, respectively, as described in 5.3. The following recommendations are made on the use of cause values: 1) When the calling user or called user is not an authorized subscriber of the multirate circuitmode bearer capability, cause No. 57, bearer capability not authorized, shall be returned to the calling user. When a network (public or private) cannot support the specified transfer rate or bearer capability, cause No. 65, bearer capability not implemented, shall be returned to the calling user. When there are insufficient channels on a single interface to support the information transfer rate requested, cause No. 34, no circuit/channel available, or cause No. 17, user busy, shall be returned to the calling user (see Recommendation Q.850 which is also reproduced in Appendix I).
2)
3)
(05/98)
173
8.1.3 1)
Interworking A user who has subscribed to the multirate circuit-mode bearer capability and a user who has subscribed to the 64 kbit/s unrestricted circuit-mode service when the information transfer rate is 64 kbit/s. A user who has subscribed to the multirate circuit-mode bearer capability and a user who has subscribed to the 384 kbit/s unrestricted circuit-mode service when the information transfer rate is 384 kbit/s. A user who has subscribed to the multirate circuit-mode bearer capability and a user who has subscribed to the 1536 kbit/s unrestricted circuit-mode service when the information transfer rate is 1536 kbit/s. A user who has subscribed to the multirate circuit-mode bearer capability and a user who has subscribed to the 1920 kbit/s unrestricted circuit-mode service when the information transfer rate is 1920 kbit/s.
Interworking is possible between:
2)
3)
4)
When any other information transfer rate is specified, interworking is not possible between the multirate circuit-mode bearer capability and other services. 8.2 8.2.1 Call establishment at the destination interface Compatibility information
The Bearer capability information element shall be encoded as in 4.5.5 (Bearer capability) with the following exceptions: 1) 2) Octet 3 shall be coded unrestricted digital information. Octet 4 shall be coded circuit-mode and the information transfer rate (bits 5 to 1) shall be encoded:
Bits 54321 11000 Circuit-mode Multirate (64 kbit/s base rare)
3)
Octet 4.1 (Rate multiplier) shall be included. Bit 8 is for extension and set to 1. Bits 7-1 contain the binary coding of the multiplier that applies to the multirate codepoint contained in the information transfer rate subfield. Bit 1 is least significant. The multiplier value range is 2-30, all other values are reserved. Octet 4.1 shall be included if and only if the transfer rate is coded for multirate.
NOTE When the information transfer rate is 384 kbit/s, 1536 kbit/s, or 1920 kbit/s the information transfer rate in the Bearer capability information element may also be coded as 384 kbit/s (10011), 1536 kbit/s (10101), or 1920 kbit/s (10111) respectively instead of using the multirate (64 kbit/s base rate) codepoint and the associated rate multiplier field.
8.2.2
Channel selection
The channels selected for the multirate call shall be on one interface and shall be indicated in the SETUP message. The procedures in 5.1.2 and 5.2.3.1 shall be followed to complete the channel selection. The Channel identification information element is coded as per 4.5.13. The number of channels identified shall provide the information transfer rate identified in the Bearer capability information element. If the information transfer rate implied by the channel(s) or interface
174
(05/98)
indicated in the Channel identification information element does not match the information transfer rate in the Bearer capability information element, the procedures in 5.8.6.2 shall apply. Channel selection conflict occurs when the channels selected for an incoming and outgoing call do not constitute two disjoint sets of time slots. When channel selection conflict occurs, the procedures in 5.7 shall apply. Some networks may offer on access: 1) contiguous channel assignment (channels must be adjacent within a single interface); and/or
NOTE On a 2048 kbit/s interface (containing a D-channel), channels 15 and 17 shall be considered contiguous.
2)
non-contiguous channel assignment (channels may be either adjacent or non-adjacent within a single interface).
Some networks may require that 384 kbit/s and/or 1536 kbit/s (in a 2048 kbit/s interface) occupy specified contiguous time slots (see Annex A/I.431). If the entire interface of a primary rate interface is used (i.e. 24 B-channels on a 1544 kbit/s interface or 30 B-channels on a 2048 kbit/s interface), octets 3.2 and 3.3 of the Channel identification information element shall not be included. If the entire interface of a basic access interface is used (i.e. 2 B-channels), octets 3.2 and 3.3 of the Channel identification information element shall not be included and the "information channel selection" shall be coded "11", any channel. The following recommendations are made on the use of cause values: 1) When a network (public or private) cannot support the specified transfer rate or bearer capability, cause No. 65, bearer capability not implemented, shall be returned to the calling user. When the calling user attempts to set up call to a user who has not subscribed to the multirate service, the network will initiate call clearing and return cause No. 57, bearer capability not authorized to the calling user. When the number of channels subscribed to on a single interface is sufficient to support the call as requested, but there are insufficient free channels, cause No. 17, user busy, is returned to the calling user. However, if the number of channels subscribed to on a single interface is insufficient to support the call as requested, cause No. 65, bearer capability not implemented, is returned to the calling user. Point-to-point configuration
2)
3)
8.2.2.1
In cases 1) and 2) of 5.2.3.1 if all the indicated traffic channels are available, the user shall select them for the call. In case 2), if the user cannot grant any referred access channel, it shall select any other available access channels associated with the D-channel and on the same access, to replace the unavailable preferred access channel, or select all the channels on another interface controlled by the D-channel.
NOTE Whether only the B-channels that cannot be provided should be changed, or if all the channels can then be changed, is for further study.
In case 3) of 5.2.3.1 the user shall select any available suitable access channels. In case 1) of 5.2.3.1 if any specified access channel is not available, and in cases 2) and 3) if insufficient access channels are available, the user shall send a RELEASE COMPLETE message with cause No. 44, requested circuit/channel not available, or No. 34, no circuit/channel available, respectively, as described in 5.3.
(05/98)
175
8.2.2.2
Point-to-multipoint configuration
In case a) of 5.2.3.2, if all the indicated traffic channels are available, the user shall select them for the call. 8.2.3 1) Interworking A user who has subscribed to the multirate circuit-mode bearer capability and a user who has subscribed to the 64 kbit/s unrestricted circuit-mode service when the information transfer rate is 64 kbit/s. A user who has subscribed to the multirate circuit-mode bearer capability and a user who has subscribed to the 384 kbit/s unrestricted circuit-mode service when the information transfer rate is 384 kbit/s. A user who has subscribed to the multirate circuit-mode bearer capability and a user who has subscribed to the 1536 kbit/s unrestricted circuit-mode service when the information transfer rate is 1536 kbit/s. A user who has subscribed to the multirate circuit-mode bearer capability and a user who has subscribed to the 1920 kbit/s unrestricted circuit-mode service when the information transfer rate is 1920 kbit/s.
Interworking is possible between:
2)
3)
4)
When any other information transfer rate is specified, interworking is not possible between the multirate circuit-mode bearer capability and other services. 8.3 Call clearing
When the call is cleared, by the user or by the network, all channels associated with the call shall be cleared. 8.4 Restart procedures
B-channels can be restarted irrespective of their usage within a multirate bearer capability. If a single B-channel is restarted, the Q.931 entity shall clear the call. 8.5 Call rearrangements
The procedures of 5.6 do not apply. 9 List of system parameters
The description of timers in the following tables should be considered a brief summary. The precise details are found in clauses 5 and 6, which should be considered the definitive descriptions. 9.1 Timers in the network side
The timers specified in Table 9-1 are maintained in the network side of the interface. 9.2 Timers in the user side
The timers specified in Table 9-2 are maintained in the user side of the interface. Timers T305, T308 and T313 are mandatory for all user side implementations.
176
(05/98)
Table 9-1/Q.931 Timers in the network side

Timer number T301 T302 Default time-out value Minimum 3 min 10-15 s (Note 5) State of call Call received Overlap sending Cause for start ALERT received SETUP ACK sent Receipt of INFO, restarts T302 Normal stop CONNECT received With sending complete indication, or network alert, or connect request received ALERT, CONNECT CALL PROC or SETUP ACK received, REL COMPLETE received if SETUP sent on point-point data link At the first expiry Clear call Clear if call information determined to be definitely incomplete; else send CALL PROC Retransmit SETUP; restart T303. If REL COMPLETE has been received, clear the call At the second expiry Timer is not restarted Timer is not restarted Cross-reference (Note 2) Mandatory
T303
4s (Note 1)
Call present
SETUP sent
Clear network connection. Enter call abort state
Mandatory
T304
20 s (provisional value)
Overlap receiving
Send INFO; receive SETUP ACK received. Sending of CALL PROC, INFO restarts T304 ALERT or CONNECT DISC without progress indicator No. 8 sent DISC with progress indicator No. 8 sent
Clear the call
Timer is not restarted
Mandatory only if 5.2.4 implemented
T305
30 s
Disconnect indication Disconnect indication
REL or DISC received Network sends REL
Timer is not restarted Timer is not restarted
Mandatory
T306
30 s (Note 6)
REL or DISC received Stop the tone/announcement. Send REL
Mandatory when inband tones/announcements are provided; see 5.4, 5.3.4.1, and Recs. I.300-series Mandatory
T307
3 min
Null
SUSPEND ACK sent
RES ACK sent
Clear the network connection. Release call identity
177
(05/98)
Table 9-1/Q.931 Timers in the network side (continued)

Timer number T308 Default time-out value 4s (Note 1) State of call Release request Cause for start REL sent Normal stop REL COMPLETE or REL received At the first expiry Retransmit REL and restart T308 At the second expiry Place B-channel in maintenance condition. Release call reference (Note 9) Timer is not restarted Cross-reference Mandatory
T309
6-90 s (Note 10)
Any stable state
Data link disconnection. Calls in stable states are not lost CALL PROC received
Data link reconnected
Clear network connection. Release B-channel and call reference Clear call in accordance with 5.2.5.3 (Note 4)
Mandatory
T310
10 s (Note 7)
Incoming Call Proceeding
ALERT, CONNECT or DISC received. If DISC, retain cause and continue timing Timeout
Mandatory
T312
T303 + 2 s
Call Present, Call Abort, etc. Receiving segmented message Restart request
SETUP sent or resent on broadcast data link Message segment received RESTART sent
Timer is not restarted Timer is not restarted RESTART may be retransmitted several times Timer is not restarted Timer is not restarted
Mandatory
T314 T316
4s 2 min
Last message segment received RESTART ACK received Internal clearing of call references Call request packet received; or incoming call packet delivered; or DISC received; or for D-channel access DL-RELEASE indication received
Discard message RESTART may be retransmitted several times Maintenance notification a) For B-channel access: disconnect link layer and initiate clearing b) For D-channel access: send DL-RELEASE request
Mandatory, see Annex H Mandatory when 5.5 is implemented Mandatory when 5.5 is implemented Optional. See 6.3
T317 T320
(Note 3) 30 s (Note 8)
Restart a) For B-channel access: active b) For D-channel access: null
RESTART received
a) For B-channel access: connection b) For D-channel access: DL-ESTABLISH Confirmation or DL-ESTABLISH indication received c) Last logical channel, cleared received
178
(05/98)
Table 9-1/Q.931 Timers in the network side (concluded)

Timer number T321 Default time-out value 30 s State of call Any call state Cause for start D-channel failure Normal stop Response to layer 3 message received At the first expiry Send DL-ESTABLISH request on both D-channels STATUS ENQ may be retransmitted several times At the second expiry Timer is not restarted Cross-reference Mandatory when Annex F is implemented Mandatory when 5.8.10 is implemented
T322
4s
Any all state
STATUS ENQ sent
STATUS DISC REL or REL COMPLETE received
STATUS ENQ may be retransmitted several times
NOTE 1 This default value assumes the use of default values at layer 2, i.e. [N200 + 1] times T200. Whether these values should be modified when layer 2 default values are modified by an automatic negotiation procedure is for further study. NOTE 2 The network may already have applied an internal alerting supervision timing function, e.g. incorporated within call control. If such a function is known to be operating on the call, then timer T301 is not used. NOTE 3 The value of this timer is implementation dependent but should be less than the value of T316. NOTE 4 If in the call abort state, the call reference is released. Otherwise, no action is taken on expiry of timer T312. NOTE 5 The value of timer T302 may vary beyond these limits, e.g. as a result of called party number analysis. NOTE 6 The value of this timer T306 is network dependent. NOTE 7 The value of timer T310 may be different in order to take into account the characteristics of a private network. NOTE 8 This value may vary by network-user agreement. NOTE 9 The restart procedures contained in 5.5 may be used on B-channels in the maintenance condition. NOTE 10 The value of this timer is network dependent.
179
(05/98)
Table 9-2/Q.931 Timers in the user side

Timer number T301 Default time-out value Minimum 3 min. State of call Call Delivered Cause for start ALERT received Normal stop CONNECT received At the first expiry Clear call At the second expiry Cross-reference
T302
15 s
Overlap receiving
T303
4s (Note 1)
Call Initiated
T304
30 s
Overlap Sending
T305 T308
30 s 4s (Note 1)
Disconnect Request Release request
INFO received with sending complete indication; or internal alerting; or internal connection; or a determination that sufficient information has been received SETUP sent ALERT (Annex D), CONNECT (Annex D), SETUP ACK, CALL PROC or REL COMPLETE received INFO sent Restarted CALL PROC, ALERT, CONNECT, DISC or when INFO sent prog. ind. 1 or 2 again received DISC sent REL or DISC received REL sent REL COMPLETE or REL received SETUP ACK sent Restart when INFO received
Clear if call information determined to be incomplete; else send CALL PROC
Timer is not restarted Mandatory when Annex D is implemented (Note 3) Timer is not restarted Mandatory only if 5.2.4 is implemented
Retransmit SETUP; restart T303. If REL COMPLETE was received, clear the call (Annex D) DISC sent
Clear internal connection. Send REL COMPLETE. Enter Null state
Mandatory when Annex D is implemented; otherwise optional
Timer is not restarted Optional
T309
6-90 s (Note 6)
Any stable state
T310 (Note 4) T313
30-120 s
Outgoing Call Proceeding Connect request
Data link disconnection. Calls in stable states are not lost CALL PROC received CONNECT sent
Data link reconnected
4s (Note 1)
ALERT, CONNECT, DISC, or PROGRESS received CONNECT ACK received
REL sent Timer is not restarted Retransmit REL; and B-channel is placed restart T308 in maintenance condition. Call reference released (Note 5) Timer is not restarted Clear internal connection. Release B-channel and call reference Send DISC Timer is not restarted
Mandatory Mandatory
Optional
Send DISC
Mandatory when Annex D is implemented Timer is not restarted Mandatory
180
(05/98)
Table 9-2/Q.931 Timers in the user side (concluded)

Timer number T314 T316 Default time-out value 4s 2 min State of call Cause for start Normal stop Last message segment received RESTART ACK received At the first expiry Discard message At the second expiry Cross-reference
Receiving Segmented Message segment Message received Restart Request RESTART sent
Timer is not restarted Not initially required Mandatory when 5.5 RESTART may be retransmitted several is implemented times Timer is not restarted Mandatory when 5.5 is implemented Timer is not restarted Mandatory when 5.6 is implemented Timer is not restarted Timer is not restarted Mandatory when 5.6 is implemented Mandatory when Annex F is implemented Mandatory when 5.8.10 is implemented
T317 T318
(Note 2) 4s
Restart Resume Request
T319
4s
Suspend Request
T321
30 s
Any call state
T322
4s
Any call state
RESTART may be retransmitted several times RESTART received Internal clearing of call Maintenance reference notification RES sent RES ACK or RES REJ Send RELEASE received message with cause No. 102 SUSPEND sent SUSPEND ACK or Enter Active state. SUSP REJ received Notify user application D-channel failure Response to layer 3 Send message received DL-ESTABLISH request on both D-channels STATUS ENQ may STATUS ENQ sent STATUS, DISC, be retransmitted REL, REL several times COMPLETE received
STATUS ENQ may be retransmitted several times
NOTE 1 This default value assumes the use of default values at layer 2, i.e. [N200 + 1] times T200. Whether these values should be modified when layer 2 default values are modified by an automatic negotiation procedure is for further study. NOTE 2 The value of this timer is implementation dependent, but should be less than the value of T316. NOTE 3 The user may already have applied an internal alerting supervision timing function, e.g. incorporated within call control. If such a function is known to be operating on the call, then timer T301 is not used. NOTE 4 T310 is not started if progress indicator 1 or 2 has been delivered in the CALL PROCEEDING message or in a previous PROGRESS message. NOTE 5 The restart procedures contained in 5.5 may be used on B-channels in the maintenance conditions. NOTE 6 The value of this timer is implementation dependent.
181
(05/98)
ANNEX A User side and network side SDL diagrams This Annex includes overview and detailed SDL diagrams which show Q.931 protocol control for circuits-switched basic calls. In the event of conflict between these diagrams and the text of clause 5, the text should be the prime source. Similarly, in the event of conflict between overview SDL and detailed SDL diagrams, the detailed SDL diagrams should be the prime source. Figure A.1 shows key to Q.931 protocol control SDL diagrams for both user side and network side. Figures A.2 and A.3 show overview and detailed protocol control SDL diagrams for the user side. Figures A.5 and A.6 show overview and detailed protocol control SDL diagrams for network side. Only procedures for the point-to-point configuration are described in the network side SDL diagrams.
NOTE Network side SDL diagrams for the point-to-multipoint configuration are left for further study.
Figure A.4 shows detailed SDL diagrams for the global call reference to be applied to both user and network sides. Although Figure A.4 shows SDL diagrams in the user-side only, the same diagrams can be applied to the network side by just changing the direction of input and output symbols.
182
(05/98)
Call control Primitives
a)
Resource management Procedure call
Q.931 protocol control Messages to/from network side Data link layer Physical layer
Block described by the SDL diagrams
User-network interface Network
T1140820-92
State Primitive from call control
Procedure call Decision Alternative Save Process description (Task)
Primitive to call control Message from network side
Message to network side
a) Not described in the SDL diagrams.
Figure A.1/Q.931 Key to Q.931 protocol control SDL diagrams (user side) (sheet 1 of 2)
(05/98)
183
a) Call control Primitives Block described by the SDL diagrams Messages to/from user side Data link layer User-network interface User Physical layer
Resource management Procedure call
Q.931 protocol control
T1140830-92
State Primitive from call control Primitive to call control Message from user side Message to user side
Procedure call Decision Alternative Save Process description (Task)
a) Not described in the SDL diagrams.
Figure A.1/Q.931 Key to protocol control SDL diagrams (network side) (sheet 2 of 2)
184
(05/98)
0 Null
Setup request
SETUP
Call initiated
SETUP ACKNOWLEDGE
CALL PROCEEDING
More information indication 2 Overlap sending
Proceeding indication
Info request
CALL PROCEEDING
INFORMATION
Outgoing call proceeding

T1160720-94
a) Outgoing set-up procedure (1 of 2)
Figure A.2/Q.931 Overview protocol control (user side) (sheet 1 of 7)
(05/98)
185
ALERTING
CONNECT
Alerting indication
Call delivered
CONNECT
Setup confirm
Ack option
CONNECT ACKNOWLEDGE
10 Active
T1160730-94
186
(05/98)
0 Null
SETUP
Setup indication
Call present
Proceeding request
Alerting request
Setup response
Reject request
CALL PROCEEDING
ALERTING
CONNECT
Reject option
Incoming call proceeding
RELEASE COMPLETE
Setup response
Alerting request
Null
CONNECT
ALERTING
Call received
Connect request
T1140840-92
b) Incoming set-up procedure (1 of 2)
(05/98)
187
7 Call received
Setup response
CONNECT
Connect request
CONNECT ACKNOWLEDGE
Setup complete indication 10 Active
T1160740-94
188
(05/98)
Call present
More info request
SETUP ACKNOWLEDGE
25
Overlap receiving
INFORMATION
Proceeding request
Alerting request
Setup response
Info indication
CALL PROCEEDING
ALERTING
CONNECT
9 Incoming call proceeding
Call received
Connect request
T1160750-94
c) Overlap receiving procedure
(05/98)
189
xx Any state except 0, 1, 6, 11, 12, 15, 17, 19
RELEASE
DISCONNECT
Disc request
Release indication
Disconnect indication
DISCONNECT
RELEASE COMPLETE
12
11
Disconnect request
RELEASE
Release request
DISCONNECT
RELEASE
Release indication
RELEASE
RELEASE
Release indication
RELEASE COMPLETE
19
Release request
RELEASE COMPLETE
RELEASE COMPLETE
Release conf
0 Null
T1160760-94
d) Clearing procedure
190
(05/98)
10 Active
Suspend request
NOTIFY
0 SUSPEND Notify indication Null
15 Suspend request
Resume request
SUSPEND ACKNOWLEDGE
SUSPEND REJECT
RESUME
Suspend confirm
Suspend reject indication 10
17
Resume request
0 Null
Active
RESUME ACKNOWLEDGE
RESUME REJECT
e) Suspend procedure
Resume confirm
Resume reject indication 0
10 Active
Null
T1160770-94
f) Resume procedure
(05/98)
191
192
0 Null
Recommendation Q.931 (05/98)

17
5.6.4
5.2.1
5.1.1
5.8.11
5.8.11
Resume request (call id)
SETUP (Bn chan)
(Note 4)(Note 5)
Setup request (Bu chan) 0
STATUS (cs = 0)
STATUS (cs 0)
Call reference selection 6 RESUME (call id)
Setup indication
Call reference selection
Null
Rel option
Call present
SETUP (Bu chan) (Note 5)
RELEASE (cause No. 101)
RELEASE COMPLETE (cause No. 101) 0
Start T318 (Note 3)
Start T303 (Note 3)
Start T308
Null
Resume request
Call initiated
19
T1140850-92
Release request
NOTE 1 In the event of conflict between these diagrams and the text of clause 5, the text should be the prime source. NOTE 2 These diagrams show Q.931 protocol control for circuit-switched calls. NOTE 3 T303 and T318 are optional (see 9.2). NOTE 4 "Bn chan" is a B-channel selected by the network. NOTE 5 "Bu chan" is a B-channel selected by the user.
Figure A.3/Q.931 Detailed protocol control (user side) (sheet 1 of 25)
0 Null 5.8.3.2 a) 5.8.3.2 a) Continued 5.8.3.2 b) 5.8.3.2 c)
Unrecognized message
Unexpected message
RELEASE
RELEASE COMPLETE
Rel option
RELEASE COMPLETE
0 Null
T1140860-92
0 RELEASE COMPLETE (cause No. 81) 0 Null Start T308 Null RELEASE (cause No. 81)
19
Release request
(05/98)
193
Call initiated 5.1.3 5.1.1, 5.1.2 5.3.2
5.1.3
5.3.3 Disconnect request
A 4
Info request
SETUP ACKNOWLEDGE (B chan)
RELEASE COMPLETE
(Note 2) DISCONNECT (cause) Stop T303 Stop T303
Stop T303
More info indication
Reject indication
Start T305
Start T304
Release call reference
11
Disconnect request
Overlap sending
0 Null
T1160780-94
NOTE 1 T303, T304 and T310 are optional (see 9.2). NOTE 2 "B chan" is a B-channel negotiated by the network and the user.
194
(05/98)
(Note 2) 5.1.5.1 A 3 CALL PROCEEDING (B chan) Time out T303 ALERTING CONNECT
Stop T303
First time out? Yes
No
Stop T303
Stop T303
Start T310
SETUP (Bu channel)
Setup confirm (error)
Alerting indication
Setup confirm
Start T303
Ack option
Recommendation Q.931 (05/98) 195
Call initiated
0 Null
Call delivered
CONNECT ACKNOWLEDGE
10 Active NOTE 1 T303, T304 and T310 are optional (see 9.2). NOTE 2 Only applicable for the procedure defined in Annex D. NOTE 3 "B chan" is a B-channel negotiated by the network and the user. NOTE 4 T.310 is not started if Progress Indicator 1 or 2 has been delivered in the CALL PROCEEDING MESSAGE.
T1160790-94
196 Recommendation Q.931 (05/98)

T304 running? No Start T304 Restart T304 Yes 5.1.3 Info request INFORMATION 2 Overlap sending NOTE 1 T304 and T310 are optional (see 9.2).
2 Overlap sending 5.1.5.2 5.1.5.2 5.1.6 5.1.5.2
CALL PROCEEDING
ALERTING
PROGRESS (interworking)
CONNECT
Stop T304
Stop T304
Stop T304
Stop T304
Start T310
Alerting indication
Progress indication
Setup confirm
Ack option (Note 2) 4 Call delivered 2 Overlap sending
CONNECT ACKNOWLEDGE
10 Active
T1160800-94
NOTE 2 This option is used when the procedure in Annex D is implemented.
Overlap sending
Continued
5.3.2 d) Release request Time out T304
5.1.5.2 PROGRESS (tone)
RELEASE (cause No. 6)
DISCONNECT
Progress indication
Stop T304
Start T305
Start T308
Setup confirm (error) 11 2 Overlap sending

T1160810-94
19
Release request
Disconnect request
NOTE T304 is optional (see 9.2).
(05/98)
197
Outgoing call proceeding 5.4 5.1.6 5.1.7 5.1.8 (Note 2) Timeout T310 5.3.2 d) Release request
4 Call delivered 5.1.8
PROGRESS
ALERTING
CONNECT
CONNECT
Stop T310
Stop T310
Stop T310
DISCONNECT
Stop T310
Setup confirm
Progress indication
Start T301
Setup confirm
Start T305
RELEASE (cause No. 6) (Note 3)
Ack option
3 Outgoing call proceeding 4
Alerting indication
Ack option 11
Setup confirm (error) 19
Start T308
CONNECT ACKNOWLEDGE
Call delivered
CONNECT ACKNOWLEDGE
Disconnect request
Release request
10 Active
T11101030-99
10 Active
NOTE 1 T301 and T.310 are optional (see 9.2). NOTE 2 Only applicable for the procedure defined in Annex D. NOTE 3 This option is used when the procedure in Annex D is implemented.
6 Call present 5.2.4 5.2.5 5.2.7 5.2.5.1 5.2.5.1 5.2.3 5.2.2
5.2.5.1
5.3.2
5.3.4
More info request
Alerting request (B chan) (Note 2)
Setup response (B chan) (Note 2) CONNECT (B chan)
Reject request
Proceeding request (B chan) (Note 2) CALL PROCEEDING (B chan) 9
RELEASE (cause)
DISCONNECT (cause)
SETUP ACKNOWLEDGE (B chan)
ALERTING (B chan)
Release indication
Disc indication
7 Start T302 (FS)
Call received
Start T313
Reject option, also see 5.2.5.1 RELEASE COMPLETE (cause)
RELEASE COMPLETE
12
T1140870-92
25
Overlap receiving
Connect request
Release call reference 0
0 Null NOTE 1 T302 is optional (see 9.2). NOTE 2 "B chan" is a B-channel negotiated by the network and the user.
Null

CONNECT DISCONNECT Stop T313 CONNECT ALERTING PROGRESS Start T313 Start T305 Setup complete indication 10 Active 8 Start T313 8 Connect request Setup complete indication (error) 11 Disconnect request 7 Connect request Call received 9 Incoming call proceeding
T1160830-94
Call received
8 Connect request 5.2.8 5.2.8 5.2.7 5.2.5.1
Incoming call proceeding 5.2.5.1 5.2.6
5.2.7 5.2.5.1 Setup response
Time out T313
CONNECT ACKNOWLEDGE
Setup response
Alerting request
Progress request
10 5.9 5.6.4 5.6.2 Active 5.6.7 5.9
5.6.1
Suspend request (call id)
NOTIFY
Notify request
SUSPEND (call id)
Notify indication
NOTIFY
10 Start T319 Active
10 Active
T1140880-92
15
Suspend request
(05/98)
201
11
Disc request
5.3.3
5.3.5 DISCONNECT (cause)
5.3.3 Time out T305
RELEASE
NOTIFY
FS Stop T305 Stop T305 RELEASE (cause)
(Note) Release indication RELEASE Start T308
RELEASE COMPLETE
19 Start T308
Release request
T1160840-94
Release call reference 0 Null
19
Release request
NOTE After receiving this primitive, call control process should release B-channel.
202
(05/98)
12
Disc indication 5.3.4 Release request
5.8.4
RELEASE
(Note) Release indication RELEASE
RELEASE COMPLETE
Start T308
19
Release request
T1160850-94
(05/98)
203
204
15 Suspend request 5.6.2 5.6.3 5.3.5 5.8.4 5.6.3
SUSPEND ACKNOWLEDGE
SUSPEND REJECT
DISCONNECT (cause)
RELEASE (cause)
Time out T319
Stop T319
Stop T319
Stop T319
Stop T319 (Note)
Suspend confirm (to error) 10 Active
(Note) Suspend confirm
Suspend confirm (error) 10 Active 12
Disc indication
Release indication
T1140890-92
RELEASE COMPLETE
17
Resume request 5.6.5 5.6.5
5.6.4
RESUME ACKNOWLEDGE (B chan)
RESUME REJECT
Time out T318
Stop T318
Stop T318
Resume confirm (to error)
(Note 1) Resume confirm
Resume confirm (error)
RELEASE (cause)
10 Active
Start T308
0 Null
19
Release request
T1140900-92
NOTE 1 After receiving this primitive, call control process should connect B-channel. NOTE 2 Open issue: Handling of disconnect request primitive.
(05/98)
205
206
19 Release request 5.3.4 RELEASE COMPLETE 5.3.5 5.3.4 Time out T308 5.8.11 STATUS (cs 0) 5.8.11 STATUS (cs = 0)
RELEASE
Stop T308
Stop T308
First time out? Yes
No Place B-channel in maintenance (user's option)
19
Release request
Status indication (error)
(Note) Release confirm
(Note) Release confirm RELEASE
Release confirm (error)
Release call reference 0 Null 0
Restart T308
T1160860-94
Release request
25 Overlap receiving 5.2.4 5.2.4 Proceeding request 5.2.4 Alerting request 5.2.7 5.2.4 Setup response 5.2.4 Time out T302 5.2.6 Progress request
INFORMATION
Info indication
Stop T302
Stop T302
Stop T302
Time out indication
PROGRESS
Start T302 (FS)
CALL PROCEEDING
25 ALERTING CONNECT
Overlap receiving
25
Overlap receiving
T1160870-94
25 Overlap receiving
(Note 1) Call received Start T313
8 Connect request
NOTE 1 It is assumed that the decision whether complete information has been received or not, at the expiry of T302, will be made by the call control. NOTE 2 T302 is optional (see 9.2).
** Any state 5.8.10 STATUS ENQUIRY
** Any state except 0, 19 5.8.11 STATUS (cs = m)
STATUS
m = 0? No
Yes
Remain in current state
Compatible state? No Status indication (error)
Yes (Note)
Status indication
DISCONNECT (cause)
0 Null
T1140910-92
Start T305
11
Disconnect request
NOTE Action on receipt of STATUS indicating a compatible call state is implementation dependent (see 5.8.11).
208
(05/98)
* * Any state
* * Any state
except 0, 1, 6, 17, 19
except 0, 1, 6, 17, 19, 25
Information request
INFORMATION
INFORMATION
Information indication

T1160880-94
(05/98)
209
** Any state except 0, 1, 19 5.8.4 RELEASE COMPLETE 5.8.4
* * state Any except 0, 1, 6 11, 12, 15, 17, 19 5.3.4 5.3.3
RELEASE (cause)
DISCONNECT (cause)
Disconnect request
Stop all timers
Stop all timers
Stop all timers
DISCONNECT (cause)
(Note) Release indication Release indication Disc indication Start T305
RELEASE COMPLETE
12
11
Disconnect request
0 Null
T1140920-92/d28
0 Null
210
(05/98)
**
Any state except 0 5.8.4 Unexpected message (Note) Status enq. option Status enq. option Remain in current state 5.8.4 5.8.3.2 e)
Unrecognized message
SETUP
Cause option
Cause option
STATUS ENQUIRY
STATUS (cause No. 101)
STATUS ENQUIRY

T1160890-94
NOTE Except RELEASE or RELEASE COMPLETE.
0 Null 5.8.6.2 SETUP with mandatory IE error RELEASE COMPLETE (cause No. 100) 0 Null Null RELEASE COMPLETE (cause No. 96) STATUS (cause No. 96) Disc indication RELEASE COMPLETE (cause No. 100) STATUS (cause No. 100) 5.8.6.1 5.8.6.1 5.8.6.1 (Note 1) RELEASE w/o cause IE Message w/o mandatory IE DISCONNECT with cause IE error RELEASE with cause IE error
5.8.6.1 SETUP w/o mandatory IE RELEASE COMPLETE (cause No. 96) 0
**
Specific state
(Note 2) (Note 3) 5.8.6.2 5.8.6.2 5.8.6.2 (Note 1) Message with mandatory IE error
DISCONNECT w/o cause IE
Release indication
12
Release indication

T1140930-92
Disc indication
Release CR
Release CR
12
0 Null
0 Null
NOTE 1 Except SETUP, RELEASE, RELEASE COMPLETE and DISCONNECT. NOTE 2 These messages are recognized by the user as expected messages in the state. [See Figure A.3 (sheet 15 of 25)]. NOTE 3 See 5.8.6 procedures for specific states.
**
Any state 5.5.2 From global call reference control Restart request
Stop all timers
Release indication
To global call reference control
Restart confirm
0 Null
T1160900-94/d31
(05/98)
213
Relevant states (Note 1) 5.8.8 DL-ESTABLISH indication
Overlap sending 5.8.8
25
Overlap receiving 5.8.8
DL-ESTABLISH indication
Error indication
(Note 2)
Error indication
(Note 2)
Overlap sending
25
Overlap receiving
T1160910-94
NOTE 1 The relevant states are as follows: U1, U3, U4, U6 to U12, U15, U17, U19. NOTE 2 At the reception of this primitive, the call control should clear the call by sending disconnect request primitives.
214
(05/98)
0 Null No text DL-RELEASE indication
25
Overlap receiving
** Any states except 0, 2, 25 5.8.9
DL-RELEASE indication
DL-RELEASE indication
DL-PRIMITIVE indication
0 Null
Release indication (error) (Note 1)
Stop T304
Stop T302
Stop all timers
Timer running? No
Yes
Start T309
0 Null
0 Null
0 Null
DL-ESTABLISHrequest

T1160920-94
NOTE 1 Any timers including T309. NOTE 2 T309 is optional (see 9.2).
(05/98)
215
** Any states 5.8.9 DL-ESTABLISH confirmation 5.8.9
Time out T309
Stop T309
Data link failure indication
STATUS
STATUS ENQUIRY
0 Null
T1140940-92
216
(05/98)
Global call reference Rest 0 Null 5.5.2 STATUS (cs = 0) STATUS (cs 0) From system management All flags (e.g. "Rest ack", "Rest resp") cleared All timers stopped 5.5.1 Management restart request 5.8.3.2 f) Unexpected message
Rest 0
Rest 0
RESTART
N=0
Translate into individual call reference
RESTART
Rest 0
T1160930-94
Start T316
To Q.931 protocol control (related call references)
Restart request
Restart request
To Q.931 protocol control (specified call reference)
Start T317 (FS)
Start T317 (Note 2)
Rest 2
Rest 1
NOTE 1 T316 and T317 are optional (see 9.2). NOTE 2 The value of T317 is implementation dependent.
Figure A.4/Q.931 Detailed protocol control for the global call reference (user side) (sheet 1 of 4)
(05/98)
217
Global call reference Rest 1 Restart request 5.5.1 5.5.1 5.8.3.2 f)
STATUS
Time out T316
RESTART ACKNOWLEDGE
Unexpected message
Rest 1
N=N+1
Stop T316
Rest 1
N = 2? Yes
No
Rest resp on? RESTART Yes
No
Maintenance action
Start T316
Rest resp off
Rest ack on
Rest 1
Rest 0
Rest 1
T1160940-94
218
(05/98)
Global call reference Rest 1 Restart request Continued
Time out T317
Restart confirm
From Q.931 protocol control (each call reference)
Maintenance action
All response? Yes Stop T317
No
Rest 1
Rest ack on? Yes Rest ack off
No
Rest resp on
Rest 0
Rest 1
T1160950-94
(05/98)
219
Global call reference
Rest 2 Restart
5.5.2 5.5.2
5.8.3.2 f)
STATUS
Time out T317
Restart confirm
From Q.931 protocol control (each call reference)
Unexpected message
Rest 2
Maintenance action
No All response? Yes Stop T317 Rest 2
Rest 2
T1160960-94
RESTART ACKNOWLEDGE
Rest 0
220
(05/98)
0 Null
SETUP
Setup indication 5.1.1 1 Call initiation 5.1.3 More info request 5.3.2 a) Reject request
5.1.5 Proceeding request
CALL PROCEEDING
SETUP ACKNOWLEDGE
RELEASE COMPLETE
Overlap sending 5.1.3 Info request
0 Null
5.1.5 Proceeding request
5.1.3
INFORMATION
CALL PROCEEDING
INFORMATION
Info indication
3 Outgoing call proceeding
Overlap sending
Overlap sending
T1160970-94
Figure A.5/Q.931 Overview protocol control (network side) point-point (sheet 1 of 8)
(05/98)
221
3 Outgoing call proceeding 5.1.6 Setup response Progress request 5.1.7 Alerting request
PROGRESS
ALERTING
Call delivered
Setup response
T1160980-94/d40
CONNECT
10 Active
222
(05/98)
0 Null
Setup request
SETUP 5.2.1 6 Call present 5.2.5.2 5.2.5.2 CALL PROCEEDING 5.2.2 RELEASE COMPLETE
5.2.7
CONNECT
ALERTING
Setup confirm
Alerting indication
Proc indication
Reject indication
0 Null 5.2.7 5.2.6
5.2.5.2 ALERTING
CONNECT
PROGRESS
Alerting indication
Setup confirm
Progress indication
Call received

T1160990-94/d41
Connect request
(05/98)
223
Call received 5.2.7 CONNECT
Connect request 5.2.8 Setup comp request
Setup confirm
CONNECT ACKNOWLEDGE
Connect request
10 Active
T1161000-94
224
(05/98)
Any state except 0, 11, 12, 19, 22 5.3.3 5.3.4 Disconnect request
DISCONNECT
Disconnect B-chan
Tone management
(Note 1)
Disconnect B-chan
(Note 2)
11
Disconnect request
DISCONNECT
12 Release request NR RELEASE 5.2.5.2
Disconnect indication 5.2.6
DISCONNECT
RELEASE
19
Release request
NR
Release B-chan
NOTE 1 Optional (for in-band tones). NOTE 2 Dependent on tone management.
Release indication
RELEASE COMPLETE
Release CR
0 Null
T1161010-94
c) Clearing procedure (1 of 2)
(05/98)
225
19
Release request
RELEASE COMPLETE
Release B-chan and CR
Release confirm
0 Null
T1161020-94
c) Clearing procedure (2 of 2)
226
(05/98)
0 Null
RESUME [call id]
Resume indication
17
Resume release
Resume response
Resume reject request
RESUME ACKNOWLEDGE
RESUME REJECT [call id] 0
10 Active
Null
T1161030-94
d) Resume procedure
(05/98)
227
10 Active
SUSPEND
Notify request
Suspend indication
NOTIFY
15
Suspend request
10 Active
Suspend response
Suspend reject request
SUSPEND ACKNOWLEDGE
SUSPEND REJECT
0 Null
10 Active
T1161040-94
e) Suspend procedure
228
(05/98)
0 Null 5.6.2 5.2.1 5.1.1 5.8.3.2 c)
Time out T307 Note Clear Call ID
Setup request
SETUP
RELEASE COMPLETE
CR selection
Setup indication
0 Null
T1140950-92
Release B-channel
SETUP (PT-PT)
Call initiated
0 Null Start T303
Call present
NOTE No call reference is associated with T307.
Figure A.6/Q.931 Detailed protocol control (network side) point-point (sheet 1 of 28)
(05/98)
229

0 Null 0 Null 5.8.3.2 b) 5.6.4 5.8.11 Continued 5.8.3 5.8.11 RELEASE RESUME [call id] STATUS (cs = 0) Unknown or unexpected message STATUS (cs not 0) 0 RELEASE COMPLETE Resume indication Null Release option 17 Resume request RELEASE COMPLETE (cause No. 81) RELEASE (cause No. 81) RELEASE (cause No. 101) RELEASE COMPLETE (cause No. 101) 0 Null Start T308 Start T308 0 Null
T1140960-92
19 Release request
19
Release request
Call initiated 5.3.2 a) Reject request 5.3.3 DISCONNECT (cause)
5.1.3 More info request
5.1.5.1 Proceeding request
Start T302
Connect B-channel
Release B-channel
Stop all timers
SETUP ACKNOWLEDGE (B-chan)
CALL PROCEEDING (B-chan)
RELEASE COMPLETE (cause)
Connect B-channel
11 Release CR
Disconnect request
T1161050-94
Overlap sending
0 Null
(05/98)
231
2 Overlap sending 5.1.3 5.1.5.2 5.1.5.2
INFORMATION
Proceeding request
Timeout T302
Info indication
Stop T302
Timeout indication
2 Yes T302 running? No CALL PROCEEDING Overlap sending (Note)

T1140970-92
3 Restart T302 Start T302
2 Overlap sending
NOTE It is assumed that the CC functional block will carry out the functions of 5.1.5.2 and 5.1.7.
232
(05/98)
Overlap sending 5.1.8 Setup response
Continued
5.1.7 Alerting request
5.1.6 Progress request (interworking)
Stop T302
Stop T302
ALERTING
CONNECT
Stop T302
Call delivered
10 Active
Overlap sending
T1161060-94
5.1.6 Progress request
5.1.7 Alerting request
5.1.8 Setup response
PROGRESS
ALERTING
CONNECT
Call delivered
10 Active
T1161070-94
(05/98)
233
Call delivered 5.1.6 Progress request
5.1.8 Setup response
CONNECT
PROGRESS
10 Active
Call delivered
T1161080-94
234
(05/98)
Call present 5.2.5.2 5.2.5.2 5.2.5.4 5.2.1
5.2.7
5.2.2
5.2.4
5.2.4
CONNECT
RELEASE COMPLETE (cause)
SETUP ACK (B-channel)
ALERTING
CALL PROCEEDING
Release request
Timeout T303
INF REQ
NC 22
F 9
T1140980-92
Stop T303
Stop T303
Stop T303
Stop T303
Stop T303
Setup confirm
Reject indication
Start T304 (Note)
Alerting indication
Start T310
Connect request
Release B-channel and CR 0 Null
More info indication 25 7
Start T301 (Note)
Overlap receiving
Call received
NOTE T301 and T304 are optional (see 9.1).
8 F
5.2.1 No
First timeout? Yes
Release indication
SETUP
Release CR
Start T303
0 Null
Call present
T1161090-94
Call received 5.2.7 5.3.4 Disconnect request
5.3.3
Timeout T301
DISCONNECT (cause)
CONNECT
Timeout indication
ND
22
Stop T301
NC
22
T1161100-94
Call received
Setup confirm
Connect request
NOTE T301 est facultatif (voir 9.1).
236
(05/98)
Connect request 5.2.8 Setup comp request 5.3.4 Disconnect request
5.3.3 DISCONNECT (cause)
ND
22
CONNECT ACKNOWLEDGE
NC
22
10 Active
T1161110-94
(05/98)
237
9 Incoming call proceeding 5.2.6 5.3.3 5.2.5.1 5.2.5.2 5.3.4 5.2.5.3
ALERTING
CONNECT
Timeout T310
DISCONNECT (cause)
Disconnect request
Progress indication
ND
22
Stop T310
Stop T310
NC
22
T1161120-94
Alerting indication
Setup confirm
Start T301
Call received
Connect request
238
(05/98)
10 Active
5.1.8
CONNECT ACKNOWLEDGE
5.6.2
5.6.4, 5.6.2, 5.9 Notify request
5.6.4, 5.6.2, 5.9
SUSPEND
NOTIFY
Suspend indication
NOTIFY
Notify indication
10 Active
15
Suspend request
10 Active
10 Active
T1161130-94
11 Disconnect request
Release request NR 15 RELEASE
Start T308
19 Release request
T1140990-92
(05/98)
239
12 Disconnect indication 5.3.4 5.3.5 5.3.4
RELEASE
DISCONNECT
TIMEOUT T305 or T306
Release indication
Stop T305 or T306
NR
14
T1141000-92
Stop T305 or T306
NR
14
Release B-channel
RELEASE COMPLETE
Release CR
0 Null
240
(05/98)
15
Suspend request 5.6.3 Suspend reject request
5.6.2 Suspend response
SUSPEND ACKNOWLEDGE
SUSPEND REJECT
10 Start T307 Active

T1161140-94
Release CR
0 Null
(05/98)
241
17 Resume request 5.6.4 5.6.5 Resume reject request
Resume response
RESUME ACKNOWLEDGE
RESUME REJECT
Stop T307
Release CR
Release call ID
0 Null
T1161150-94
10 Active
242
(05/98)
19 Release request 5.8.11 5.8.11 5.3.5 5.3.3 5.3.4.3
STATUS cs 0
STATUS (cs = 0)
RELEASE
RELEASE COMPLETE
Timeout T308
19
Release request
Status indication (error)
Stop T308
First timeout? Yes
No
Stop T308
Release B-channel and CR
RELEASE
Place B-channel in maintenance
Release B-channel and CR 0 Null 0
Release confirm
Start T308
Release CR
19 Null Release request
Release confirm error 0 Null

T1141020-92
244
25

25
Overlap receiving 5.2.5.1 5.2.5.2 CALL PROCEEDING 5.2.6
5.2.4 More info request
5.2.4
5.2.5.1
Timeout T304
ALERTING
CONNECT
INFORMATION
Timeout indication
Stop T304
Stop T304
Stop T304
T304 running? (Note) Yes
No
Overlap receiving
Alerting indication
Setup confirm
Proc indication
Progress indication (interworking)
8 Restart T304 Start T304 Start T301
Connect request
25 Start T310
Overlap receiving
T1141010-92
7 Overlap receiving
Call received
Any state 5.8.10 STATUS ENQUIRY
Any state except 0, 19 5.8.11 STATUS (cs = M)
No STATUS M = 0? Yes Remain in current state 5.8.11 c) Compatible state? No Status indication Status indication (error) Yes (Note)
Release CR and resources
0 Null
T1141030-92
NC 22
NOTE Action on receipt of STATUS indicating a compatible call state is implementation dependent. (See 5.8.11.)
Any state except 0, 1, 6, 17, 19
Any state except 0, 1, 6, 17, 19, 25
Information request
INFORMATION
INFORMATION
Information indication

T1161160-94
(05/98)
245
Any state except 0, 11, 12, 19, 22 5.3.3 DISCONNECT
Any state except 0, 6, 9, 11, 12, 19, 22 5.3.4 Disconnect request ND 10, 11, 12 NC 8, 10, 11, 12, 20 Stop all timers
Stop all timers
Disconnect B-channel
TONE OPTION? No
Yes
Disconnect B-channel
Start tone
11
Disconnect request
DISCONNECT
Start T306 (Note)
Start T305
DISCONNECT (PI)
12
12
T1141040-92
NOTE See 9.1 for default values of T306.
246
(05/98)
Any state except 0 5.8.3.2 e) 5.8.4 Unexpected message (Note) Status enquiry option 5.8.4 Unrecognized message
SETUP
Cause option
STATUS ENQUIRY
STATUS (Cause No. 101)
Remain in current state a) Error handling SDL diagram (1 of 2) NOTE Except RELEASE or REALEASE COMPLETE.
T1198150-97
(05/98)
247
248
** Specific state 5.8.6.2 DISCONNECT with cause IE error 5.8.6.2 RELEASE with cause IE error 5.8.6.2 (Note)

0 Null 5.8.6.1 SETUP w/o mandatory IE RELEASE COMPLETE (cause No. 96) 0 Null 0
5.8.6.1 DISCONNECT w/o cause IE
5.8.6.1 RELEASE w/o cause IE
5.8.6.1 MESSAGE w/o mandatory IE
Message with mandatory IE error
RELEASE COMPLETE (cause No. 96)
11
Disconnect request
Release indication
11
Disconnect request
Release indication
5.8.6.2 SETUP with mandatory IE error 0
Release CR
Release CR
T1161180-94
0 Null Null
NOTE Except SETUP, RELEASE and DISCONNECT.
Null a) Error handling SDL diagram (2 of 2)
Relevant states (Note 1) 5.8.8


25
Overlap receiving 5.8.8

Remain in current state 2
(Note 2) Error indication Error indication
(Note 2)
Overlap sending
25
Overlap receiving
T1161190-94
NOTE 1 The relevant states are as follows: N1, N3, N6 to N12, N15, N17, N19. NOTE 2 At the reception of this primitive, the call control should clear the call by sending disconnect request primitives.
(05/98)
249
250
0 Null No text DL-RELEASE indication 2 Overlap sending 5.8.9 DL-RELEASE indication 25 Overlap receiving 5.8.9 DL-RELEASE indication ** Any states except 0, 2, 25 5.8.9 DL-RELEASE indication
0 Null
Release indication (error)
Stop T304 (Note 2)
Stop T302
Stop all timers
Timer running? No
(Note 1) Yes
Release call reference 0 Null 0
Start T309
Null
DL-ESTABLISH request
NOTE 1 Any timers including T309. NOTE 2 T304 is optional (see 9.1).

T1141060-92
** Any states 5.8.9 5.8.9
DL-ESTABLISH confirm
Timeout T309
Stop T309
Data link failure indication
STATUS
STATUS ENQUIRY
0 Null
T1141050-92
(05/98)
251
Any state except 0, 12, 19 5.8.4 RELEASE
Any state except 0, 19 5.8.4 RELEASE COMPLETE
Stop all timers
Release Indication
Release Indication
Release CR and B-channel 0 Null

T1198160-97
Release B-channel
RELEASE COMPLETE
Release CR
0 Null
ANNEX B Compatibility and address checking B.1 Introduction
This Annex describes the various compatibility and address checks which should be carried out to ensure that best match of user and network capabilities is achieved on a call within an ISDN. This Annex also covers interworking with existing networks. Three different processes of checking shall be performed: i) ii) iii) at the user-to-network interface on the calling side (see B.2); at the network-to-user interface on the called side (see B.3.2); and user-to-user (see B.3.3).
252
(05/98)
NOTE In this context and throughout this Annex, the term "called user" is the endpoint entity which is explicitly addressed. This may be an addressed Interworking Unit (IWU); see the I.500-series Recommendations.
For details on the coding of the information required for compatibility checking, see Annex I. B.2 Calling side compatibility checking
At the calling side, the network shall check that the bearer service requested by the calling user in the Bearer capability information element matches with the bearer services provided to that user by the network. If a mismatch is detected, then the network shall reject the call using one of the causes listed in 5.1.5.2. Network services are described in Recommendations I.230 [47] and I.240 [48] as bearer services and teleservices, respectively. B.3 Called side compatibility and address checking
In this subclause, the word "check" means that the user examines the contents of the specified information element. B.3.1 Checking of addressing information
If an incoming SETUP message is offered with addressing information (i.e. either DDI or subaddressing or the appropriate part of the called party number), the following actions will occur: a) If a number or subaddress is assigned to a user, then the information in a Called party number or Called party subaddress information element of the incoming call shall be checked by the user against the corresponding part of the number assigned to the user or the user's own subaddress. In case of a mismatch, the user shall ignore the call. In the case of match, the compatibility checking described in B.3.2 and B.3.3 will follow. If a user has no assigned number or subaddress, then the Called party number and Called party subaddress information element shall be ignored. Then, compatibility checking described in B.3.2 and B.3.3 will follow.
b)
NOTE 1 According to user's requirements, compatibility checking can be performed in various ways from the viewpoint of execution order and information to be checked, e.g. first assigned number/subaddress and then compatibility or vice versa. NOTE 2 If an incoming call, offered with addressing information, is always to be awarded to the addressed user, all users connected to the same passive bus should have an assigned number or subaddress.
B.3.2
Network-to-user compatibility checking
When the network is providing a bearer service at the called side, the user shall check that the bearer service offered by the network in the Bearer capability information element matches the bearer services that the user is able to support. If a mismatch is detected, then the user shall either ignore or reject the offered call using cause No. 88, incompatible destination, (see 5.2.2). B.3.3 User-to-user compatibility checking The called side terminal equipment shall check that the content of the Low layer compatibility information element is compatible with the functions it supports. The Low layer compatibility information element (if available) shall be used to check compatibility of low layers (e.g. from layer 1 to layer 3, if layered according to the OSI model).
(05/98)
253
NOTE The Bearer capability information element is also checked (see B.3.2). Therefore, if any conflict from duplication of information in the Bearer capability and the Low layer compatibility information elements is detected, this conflict shall be resolved according to Annex I, e.g. the conflicting information in the Low layer compatibility information element shall be ignored.
If the Low layer compatibility information element is not included in an incoming SETUP message, the Bearer capability information element shall be used to check the compatibility of low layers. The called terminal equipment may check the High layer compatibility information element (if present) as part of user-to-user compatibility checking procedures, even if the network only supports bearer services. If a mismatch is detected in checking any of the information elements above, then the terminal equipment shall either ignore or reject the offered call using cause No. 88, incompatible destination, (see 5.2.2). B.3.3.1 User-to-user compatibility checking and bearer service selection
If the called side terminal does not support the semantics of bearer service selection, it will respond as if the fallback bearer capability were only the offered bearer capability in applying B.3.3. If the called side terminal does support the semantics of bearer service selection, and if it is able to accept the call using either of the bearer capabilities (the fallback bearer capability or the preferred bearer capability), then it shall follow B.3.3 procedures in separately evaluating its compatibility with the offered call for each of the offered bearer capabilities (the fallback bearer capability and the preferred bearer capability). a) b) If evaluations show the terminal to be compatible with the call, it shall respond to the call using the preferred bearer capability. If the evaluations show the terminal to be incompatible with the call for one of the two offered bearer capabilities (either the fallback bearer capability or the preferred bearer capability), it shall not answer the call using that bearer capability. If both evaluations show the terminal to be incompatible with the call, it shall follow B.3.3 procedures for incompatible calls. User action tables
c) B.3.4
Tables B.1, B.2 and B.3 show the action which shall be carried out as a result of compatibility checking with the calling user's request for a bearer service and/or teleservice. B.4 Interworking with existing networks
Limitations in network or distant user signalling (e.g. in the case of an incoming call from a PSTN or a call from an analogue terminal) may restrict the information available to the called user in the incoming SETUP message. A called user should accept limited compatibility checking (e.g. without the High layer compatibility information element) if a call is routed from an existing network which does not support High layer compatibility information element transfer. In cases where the network cannot provide all incoming call information, or where the network is not aware of the existence or absence of some service information (such as a compatibility information), the incoming SETUP message includes a Progress indicator information element, containing progress indicator No. 1, call is not end-to-end ISDN; further call progress information may be available in band, or No. 3, origination address is non-ISDN (see Annex G). The terminal equipment receiving a SETUP with a Progress indicator information element shall modify its compatibility checking, the terminal equipment should regard the compatibility as successful if it is compatible with the included information, which as a minimum, will be the Bearer
254
(05/98)
capability information element. A terminal equipment expecting information in addition to the Bearer capability information element in a full ISDN environment need not reject the call if such information is absent but a Progress indicator information element is included. Table B.1/Q.931 Bearer capability compatibility checking
BC mandatory info element Compatible Incompatible Point-to-point data link (Note 1) Proceed Reject (5.2.5.1) Ignore [5.2.5.1 a)] (Note 2) Broadcast data link (Note 1) Proceed Reject [5.2.5.1 b)] (Note 2)
Table B.2/Q.931 Low layer and high layer compatibility checking Compatibility assured with the available description of the call
LLC/HLC Compatibility assured Compatible Incompatible Reject (5.2.5.1) Point-to-point data link (Note 1) Accept Attempt low layer compatibility negotiation (Annex J) Ignore [5.2.5.1 a)] (Note 2) Broadcast data link (Note 1) Accept Reject [5.2.5.1 b)] (Note 2) Attempt low layer compatibility negotiation (Annex J)
Table B.3/Q.931 Low layer and high layer compatibility checking Compatibility not assured with the available description of the call
LLC/HLC Compatibility not assured HLC or LLC Present Point-to-point data link (Note 1) Accept or reject (Note 3) Broadcast data link (Note 1) Attempt low layer compatibility negotiation (Annex J)
Attempt low layer Accept or reject compatibility (Note 3) negotiation (Annex J)
NOTES to Tables B.1, B.2 and B.3

NOTE 1 For broadcast data link terminal equipment which is explicitly addressed using subaddressing or the appropriate part of the called party number, the point-to-point column in the above table shall be used. NOTE 2 When a terminal equipment on a broadcast data link is incompatible, an option of "ignore or reject" is permitted (see 5.2.2). NOTE 3 Some terminal equipment on this interface may understand the High layer compatibility or Low layer compatibility information elements and would reject the call if incompatible.
(05/98)
255
ANNEX C Transit network selection This Annex describes the processing of the Transit network selection information element. C.1 Selection not supported
Some networks may not support transit network selection. In this case, when a Transit network selection information element is received, that information element is processed according to the rules for unimplemented non-mandatory information elements (see 5.8.7.1). C.2 Selection supported
When transit network selection is supported, the user identifies the selected transit network(s) in the SETUP message. One Transit network selection information element is used to convey a single network identification. The user may specify more than one transit network. Each identification is placed in a separate information element. The call would then be routed through the specified transit networks in the order listed in the SETUP. For example, a user lists networks A and B, in that order, in two Transit network selection information elements within a SETUP message. The call is first routed to network A (either directly or indirectly), and then to network B (either directly or indirectly), before being delivered. As the call is delivered to each selected network, the corresponding transit selection may be stripped from the call establishment signalling, in accordance with the relevant internetwork signalling arrangement. The Transit network selection information element(s) is (are) not delivered to the destination user. No more than four Transit network selection information elements may be used in a single SETUP message. When a network cannot route the call because the route is busy, the network shall initiate call clearing in accordance with 5.3 with cause No. 34, no circuit/channel available. If a network does not recognize the specified transit network, the network shall initiate call clearing in accordance with 5.3, with cause No. 2, no route to specified transit network. The diagnostic field shall contain a copy of the contents of the Transit network selection information element identifying the unreachable network. A network may screen all remaining Transit network selection information elements to: a) b) c) avoid routing loops; or ensure that an appropriate business relationship exists between selected networks; or ensure compliance with national and local regulations.
If the transit network selection is of an incorrect format, or fails to meet criteria a), b) or c), the network shall initiate call clearing in accordance with 5.3, with cause No. 91, invalid transit network selection. When a user includes the Transit network selection information element, pre-subscribed default Transit network selection information (if any) is overridden.
256
(05/98)
ANNEX D Extensions for symmetric call operation D.1 Additional message handling
In symmetric applications, the SETUP message will contain a Channel Identification information element indicating a particular B-channel to be used for the call. A point-to-point data link shall be used to carry the SETUP message. The procedure described in clause 5 for the user side should normally be followed. Where additional procedures are required, they are detailed below. D.1.1 B-channel selection Symmetric interface
Only B-channels controlled by the same D-channel will be the subject of the selection procedure. The selection procedure is as follows: a) The SETUP message will indicate one of the following: 1) channel is indicated, no acceptable alternative; or 2) channel is indicated, any alternative is acceptable. b) In cases 1) and 2), if the indicated channel is acceptable and available, the recipient of the SETUP message reserves it for the call. In case 2), if the recipient of the SETUP message cannot grant the indicated channel, it reserves any other available B-channel associated with the D-channel. If the SETUP message included all information required to establish the call, the recipient of SETUP message indicates the selected B-channel in a CALL PROCEEDING message transferred across the interface and enters the Incoming Call Proceeding state. If the SETUP message did not include all the information required to establish the call, B-channel is indicated in a SETUP ACKNOWLEDGE message sent across the interface. The additional call establishment information, if any, is sent in one or more INFORMATION messages transferred across the interface in the same direction as the SETUP message. When all call establishment information is received, a CALL PROCEEDING, ALERTING or CONNECT message, as appropriate, is transferred across the interface. In case 1) if the indicated B-channel is not available, or in case 2) if no B-channel is available, a RELEASE COMPLETE message with a cause value of No. 44, requested circuit/channel not available, or No. 34, no circuit/channel available, respectively, is returned to the initiator of the call. The sender of this message remains in the Null state. If the channel indicated in the CALL PROCEEDING or SETUP ACKNOWLEDGE message is unacceptable to the initiator of the call, it clears the call in accordance with 5.3. Call confirmation
c)
d)
e)
f) D.1.2
Upon receipt of a SETUP message, the equipment enters the Call Present state. Valid responses to the SETUP message are a SETUP ACKNOWLEDGE, an ALERTING, a CALL PROCEEDING, a CONNECT or a RELEASE COMPLETE message. If the indicated channel is acceptable to the initiator of the call, the initiator shall attach to the indicated B-channel.
(05/98)
257
D.1.3
Clearing by the called user employing user-provided tones/announcements
In addition to the procedures described in 5.3.3, if the bearer capability is either audio or speech, the called user or private network may apply in-band tones/announcements in the clearing phase. When in-band tones/announcements are provided, the DISCONNECT message contains progress indicator No. 8, in-band information or appropriate pattern is now available, and the called user or private network proceeds similarly as stipulated in 5.3.4.1 for the network. D.1.4 Active indication
Upon receipt of a CONNECT message, the initiator of the call shall respond with a CONNECT ACKNOWLEDGE message and enter the Active state. D.2 Timers for call establishment
User endpoints implement the network side timers T301, T303 and T310 along with the corresponding network side procedures for actions taken upon expiration of these timers. See Table 9-2 for the call establishment user-side timers and procedures. D.3 Call collisions
In symmetric arrangements, call collisions can occur when both sides simultaneously transfer a SETUP message indicating the same channel. In the absence of administrative procedures for assignment of channels to each side of the interface, the following procedure is employed. First, one side of the interface will be designated the network and the other side of the interface will be designated the user. Second, for the three possible scenarios where the same channel is indicated by combinations of preferred and exclusive from the user and network sides, the following procedure is used: a) Network preferred, user preferred The network preferred channel is awarded and an alternate channel is indicated in the first response to the user SETUP message. b) Network exclusive, user exclusive The network exclusive channel is awarded and the user SETUP message is cleared with a RELEASE COMPLETE message with cause No. 34, no circuit/channel available. c) Network preferred, user exclusive, or network exclusive, user preferred The side of the interface with an exclusive indicator in a SETUP message is awarded the channel and an alternate channel is indicated in the first response to the side using a preferred indicator in the SETUP message. Channel identification is allowed in both directions for ALERTING and CONNECT.
258
(05/98)
ANNEX E Network-specific facility selection This Annex describes the processing of the Network-specific facilities information element. The purpose of this information element is to indicate which network facilities are being invoked. E.1 Default provider
When the length of the network identification field is set to zero in the Network-specific facilities information element, then the services identified in this information element are to be provided by the network side of the interface receiving the information element (default provider). If the Network-specific facilities information element is recognized but the network facilities are not understood, then this information element is processed according to rules for non-mandatory information element content error (see 5.8.7.2). E.2 Routing not supported
Some networks may not support the routing to the remote network of the contents of the Networkspecific facilities information element. In this case, when a Network-specific facilities information element is received, that information element is processed according to the rules for unrecognized information elements (see 5.8.7.1). E.3 Routing supported
When Network-specific facility information element routing is supported, the user identifies the network provider in this information element in the Q.931 SETUP message. One Network-specific facility information element is used to identify a network provider. The user may specify more than one network provider by repeating the Network-specific facilities information element. Each identification is placed in a separate information element. The information is routed to the indicated network provider as long as the call is also handled by the network provider (see Annex C, Transit network selection). For example, if the user lists network providers A and B in separate Network-specific facilities information elements in a call control message, there must be corresponding Transit network selection information elements in the SETUP message identifying those networks (or default call routing via A and B that was established prior to call establishment). As the signalling messages containing Network-specific facilities information elements are delivered to the indicated remote network, they may be stripped from the signalling messages, in accordance with the relevant internetworking signalling arrangement. The Network-specific facilities information elements may be delivered to the identified user. No more than four Network-specific facilities information elements may be used in a SETUP message. When the information element is repeated, the order of presentation of the elements in a message is not significant. Further, there does not have to be a one-to-one correspondence between Network-specific facilities information elements and Transit network selection information elements. If a network cannot pass the information to the indicated network provider, either due to: the network indicated is not part of the call path; or no mechanism exists for passing the information to identified network,
(05/98)
259
the network shall initiate call clearing in accordance with 5.3, with cause No. 2, no route to specified transit network. The diagnostic field may optionally contain a copy of the first 5 octets of the Network-specific facilities information element. When the user includes the Network-specific facilities information element in the SETUP message, pre-subscribed default service treatment (if any) is overridden. ANNEX F D-channel backup procedures F.0 Foreword
The procedure defined in this Annex can be used when non-associated signalling is applied to multiple primary rate access arrangements. This feature can be provided on a subscription basis and is network dependent. F.1 General
In associated signalling, the D-channel signalling entity can only assign calls to channels on the interface containing the D-channel. When the D-channel signalling entity can assign calls to channels on more than one interface (including the one containing the D-channel), this is called non-associated signalling. Figure F.1 is an example of associated signalling used on each of the three interfaces between a user (e.g. a PABX) and a network. Replacing associated signalling with non-associated signalling on these interfaces results in the example shown in Figure F.2. When non-associated signalling is employed, the reliability of the signalling performance for the ISDN interfaces controlled by the D-channel may be unacceptable. To improve the reliability, a Dchannel backup procedure employing a standby D-channel is necessary. The next subclause describes the backup procedure which is optional for endpoints that use non-associated signalling.
Primary rate interfaces
PBX
Network
D-channels
T1161370-94
Figure F.1/Q.931 Example of associated signalling on each of the three primary rate interfaces
260
(05/98)
Three primary rate interfaces controlled by D-channel PBX Network
T1161380-94
D-channels
Figure F.2/Q.931 Example of non-associated signalling controlling three primary rate interfaces
F.2 F.2.1
D-channel backup procedure Role of each D-channel
When two or more interfaces connect a network and a user, a primary D-channel (labelled "one") is always present on one interface. On a different interface, a secondary D-channel (labelled "two") is present that can also send signalling packets. Figure F.3 shows the addition of a secondary (i.e. backup) D-channel to the arrangement shown in Figure F.2. D-channel one is used to send signalling packets across the user-network interface for multiple interfaces including the interface containing D-channel two. D-channel two is in a standby role and is active at layer 2 only. All SAPI groups (e.g. 0, 16 and 63) are alive and can send packets. At periodic intervals determined by the appropriate layer 2 timer associated with SAPI 0, a link audit frame will be sent on the point-to-point signalling link with DLCI = 0 of D-channel two. Since D-channel two is in a standby role, load sharing between D-channels one and two is not possible. Furthermore, D-channel two cannot serve as a B-channel when it is in a standby role. Lastly, D-channel two can only back up the signalling functions provided by D-channel one and not some other D-channel on a different interface.
Three primary rate interfaces controlled by D-channel Network
PBX
T1161390-94
Backup D-channel
Primary D-channel
Figure F.3/Q.931 Example of non-associated signalling with backup D-channel controlling three primary rate interfaces
(05/98)
261
F.2.2
Switch-over of D-channels
Failure of D-channel one is determined by the receipt of a DL-RELEASE indication primitive from the data link layer. At this point, optionally additional attempts to re-establish this D-channel may be initiated. Otherwise, it is assumed that D-channel one has failed. Two states are defined for any D-channel in a backup arrangement. A D-channel is termed out-ofservice when layer 2 remains in the TEI-assigned state, after being periodically requested by layer 3 to establish multiple-frame operation. A D-channel is termed maintenance busy when layer 2 is held in the TEI-assigned state by layer 3. While in the maintenance busy condition, the response to an invitation for link establishment is met with the transmission of a DM (Disconnected Mode). When the D-channel one has failed and if D-channel two is not in an out-of-service condition, the layer 3 shall place D-channel one in a maintenance busy condition, start timer T321 and then issue a DL-ESTABLISH request primitive to re-initialize SAPI 0 link 0 of D-channel two. Upon receipt of this primitive, the data link layer issues an SABME command. Timer T200 is started. The end receiving the SABME command on D-channel two follows the remainder of the Q.921 procedures for establishing logical link with DLCI = 0. Once the logical link with DLCI = 0 in D-channel two is in the Link Established state, the procedure to establish layer 3 call control signalling can begin on the link. To establish the backup D-channel for carrying call control signalling, layer 3 should issue an appropriate layer 3 message (e.g. a STATUS ENQUIRY on stable call reference numbers). Once a response to that layer 3 message is received, D-channel two is declared to be the active D-channel, normal layer 3 call control signalling may proceed, timer T321 is stopped, and D-channel one is moved to the out-of-service condition. If the maintenance busy timer T321 expires before a response is received to the layer 3 message, D-channel one is moved to the out-of-service condition and an attempt is made to establish the logical link with DLCI = 0 on D-channel one and D-channel two. If the logical link with DLCI = 0 of both D-channel one and D-channel two are initialized simultaneously, the designated primary shall be chosen as the D-channel for carrying call control signalling. The designated primary D-channel is agreed upon at subscription time by both sides of the interface. After a switch-over, old D-channel two becomes the new D-channel one and old D-channel one becomes the new D-channel two. Upon completion of appropriate maintenance activity to D-channel two, the logical links for SAPI = 0 and 63 are made active at layer 2 and the D-channel is removed from the out-of-service condition. D-channels may only be switched again by a failure of D-channel one or a routing or maintenance request from a peer entity. ANNEX G Use of progress indicators This Annex describes the use of the different progress indicator values defined in 4.5.22. Examples of use are given. Progress indicator No. 1 Indicates that interworking with a non-ISDN has occurred within the network or networks through which the call has traversed. Progress indicator No. 2 Indicates that the destination user is not ISDN.
262
(05/98)
Progress indicator No. 3 Indicates that the origination user is not ISDN. Progress indicator No. 4 Indicates that a call which had left the ISDN has returned to the ISDN at the same point it had left due to redirection within the non-ISDN. This progress indicator would be employed when a prior Q.931 message resulted in a progress indicator No. 1 (call is not end-to-end ISDN), being delivered to the calling user.
The use of progress indicators Nos. 1, 2 and 3 is exemplified in the following. Four interworking situations are identified in Figure G.1: a) b) c) d) interworking with another network; interworking with a non-ISDN user connected to ISDN; interworking with non-ISDN equipment within the calling or called user's premises; interworking with another network behind the T reference point.
B
b A
S/T
c ISDN
T
TE a
NT2
Non ISDN
PSTN
T11101050-99
Figure G.1/Q.931
As regards calls from A the following applies: case a) progress indicator No. 1 sent to A; case b) progress indicator No. 2 sent to A; case c) progress indicator No. 2 sent to A (location sub-field = private network); case d) progress indicator No. 1 sent to A (location sub-field = private network). case a) progress indicator No. 1 sent to A; case b) progress indicator No. 3 sent to A; case c) progress indicator No. 3 sent to A (location sub-field = private network); case d) progress indicator No. 1 sent to A (location sub-field = private network).
As regards calls towards A the following applies:
The use of progress indicator No. 4 is exemplified in the following scenarios associated with the Call Forwarding supplementary service. If a call is originated from user A to user B, then as stated above, in the interworking cases b) and c) (see Figure G.1), progress indicator No. 2 shall be sent to user A to indicate that interworking has occurred. If subsequently the call is forwarded from user B to user C, and user C is an ISDN user, progress indicator No. 4 shall be sent to user A.
(05/98)
263
The use of progress indicator No. 8, in-band information or appropriate pattern is now available, is described in clause 5. ANNEX H Message segmentation procedures This optional procedure is used on the basis of bilateral agreement between the user and the network. H.1 Introduction
Layer 3 messages that are longer than the length of frames that the data link layer can support may be partitioned into several segments. Message segmentation shall only be used when the message length exceeds N201 (defined in Recommendation Q.921 [3]). The architectural relationship to other Q.931 functions is shown in Figure H.1. These procedures apply only within a specific data link connection and do not impact the procedures in operation on other parallel data link connections. In order to support expressed needs for applications requiring message lengths of 10 000 octets, or greater, procedures to support those applications are under study. These procedures will consider backward compatibility and methods to allow information on other call references to be interleaved with segments of a long message. The specifics of these procedures are for further study.
Q.931 protocol control
Integrated CEI-call reference multiplexer/demultiplexer
Layer 3 Layer 2
Optional Q.931 segmenter
Protocol discriminator filters CEI No. 1 CEI No. 2 Broadcast CEI
T1161410-94
Figure H.1/Q.931 Logical architecture containing segmentation function
264
(05/98)
H.2 a) b)
Message segmentation The default maximum number of message segments is 8. If the message is too long to be segmented, then a local maintenance activity shall be notified. 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 data link layer information field. 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 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 data link layer information field. The first segment indicator field of the Segmented message information element shall be set to indicate the first segment of a segmented message, and not set in any other segment. 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, see Figure H.2. The Message type information element shall be coded to indicate a segment message, and the Segmented message information element shall indicate the message type of the original message. Once the first segment has been transmitted on a particular data link 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 data link connection, i.e. a segmented message cannot be interleaved with any other messages. In exceptional circumstances, the transmission of a segmented message may be aborted by sending a message or message segment containing a different call reference; sending a message with the message type not coded "segment message", or stopping the transmission of subsequent message segments pertaining to the same message. The octet order for the segmented message shall be preserved regardless of segment boundary.
The following rules apply when Q.931 messages are to be segmented for transmission:
c)
d) e) f)
g)
h)
i)
(05/98)
265
Before segmentation Protocol discriminator Call reference Message type = A octet No. 1 . . octet No. k octet No. k + 1 . . octet No. z octet No. z + 1 . . octet No. m
After segmentation Protocol discriminator Call reference Message type = segment Segmented message (1 st, N 1, A) octet No. 1 . . octet No. k
Protocol discriminator Call reference Message type = segment Segmented message (Subsequent, N 2, A) octet No. k + 1 . . octet No. z . . Protocol discriminator Call reference Message type = segment Segmented message (subsequent, O, A) octet No. z + 1 . . octet No. m
T1161420-94
NOTE Segmentation may occur at any octet boundary.
Figure H.2/Q.931 Relation between message and segments
H.3 a)
Reassembly of segmented messages A reassembly function, on receiving a message segment containing the Segmented message information element with the first segment indicator indicating "first message", and containing the call reference and message type (coded as "segment message") shall enter the Receiving Segmented Message state and accumulate message segments.
The following rules apply to the receipt and reassembly of segmented Q.931 messages:
266
b)
Timer T314 shall be initialized or re-initialized upon receipt of a message segment containing the Segmented message information element with a non-zero number of segments remaining field. Timer T314 shall be stopped upon receipt of the last segment, i.e. a message segment containing the Segmented message information element with the number of segments remaining field coded zero. Timer T314 shall not be initialized or re-initialized if error procedures as identified in rules below are initiated. A reassembly function receiving a message segment with a Segmented message information element should wait for receipt of the last message segment pertaining to the same message, i.e. containing the Segmented message information element with the number of segments remaining field coded zero before delivering the message for further Q.931 processing as specified in 5.8. The reassembly function shall enter the Null state. Upon expiry of timer T314, the reassembly function shall discard all segments of this message so far received, notify the layer 3 management entity for the data link connection that message segments have been lost and enter the Null state.
NOTE 1 Subsequent message segments relating to the same message shall be discarded according to rule f).
c)
d)
e)
A reassembly function, upon receiving eight message segments of the same segmented message without receiving a message segment with a number of segments remaining field of the Segmented message information element coded zero, shall discard all message segments so far received, notify the layer 3 management entity for the data link connection that messages have been discarded and enter the Null state.
f)
A reassembly function, on receiving a message segment containing a Segmented message information element, but with no call reference or Message type information element, while in the Null state shall discard that message segment and remain in the Null state. A reassembly function, on receiving a message segment containing a Segmented message information element, while in the Receiving Segmented Message state with the number of segments remaining field that is not decremented from the number of segments remaining field in the Segmented message information element of the previous message segment, shall discard all segments of this message so far received and enter the Null state.
g)
h)
If there is a DL-RELEASE indication primitive or DL-ESTABLISH indication primitive received while in the Receiving Segmented Message state, the reassembly function shall discard all received message segments so far received, forward the DL-RELEASE indication primitive or DL-ESTABLISH indication primitive for further Q.931 processing and enter the Null state. A reassembly function, upon receiving a message segment with the first segment indicator of the Segmented message information element indicating "subsequent", while in the Null state, shall discard that message segment and remain in the Null state. A receiving entity, on receiving a message with a different call reference while in the Receiving Segmented Message state, shall discard all segments of the segmented message so far received and enter the Null state. The message received with the new call reference shall receive normal processing.
i)
j)
(05/98)
267
Block diagram Management Layer 3 (Error) [see H.2 a)] Layer 3 (DL-DATA request DL-UNITDATA request) Management Layer 3 (Error) (see H.3) Layer 3 (DL-DATA indication DL-UNITDATA indication DL-ESTABLISH indication DL-RELEASE indication)
Segmentation process (DL-DATA request DL-UNITDATA request)
Reassembly process (DL-DATA indication DL-UNITDATA indication DL-ESTABLISH indication DL-RELEASE indication)
T1145290-92
Figure H.3/Q.931 Segmentation functional interaction diagram
268
(05/98)
0 Null
All other DL primitives
DL-(UNIT) DATA request: (message)
Message > N201 octets? Yes
No
Divide message at octet boundaries
DL-(UNIT) DATA request: (message segment)
0 Yes > 8 segments?
No Insert segmented message information element after message type Notify layer 3 manager
DL-(UNIT) DATA request: (message segment)
0
T1145300-92
Last segment sent? Yes
No
Figure H.4/Q.931 Message segmenter SDL
(05/98)
269
0 Null
DL-(UNIT) DATA indication (message or message segment)
All other DL primitives A B 2 No 2 All other DL primitives
Call reference and message type (with value = segment) found after protocol discriminator?
0 Yes
Segmented message IE immediately following?
No
DL = (UNIT) DATA indication (message)
T1161430-94
Yes First segment indicator = First? Yes Number of segments remaining < 8? Yes Accumulate first segment Discard No No
Store call ref.
Number of segments remaining
Set T314 (now + 4 s)
Figure H.5/Q.931 Message reassembler SDL (sheet 1 of 3)
270
(05/98)
1 Receiving segmented message

DL = (UNIT)DATA indication (message or message segment)
T314 expiry
Call reference = saved called reference? Yes
No
Stop T314
Discard
Message type = SEGMENT?
No
Discard
Null No
Yes Segmented message IE next element?
Stop T314
B 1 No
Discard Yes First segment indicator = sub? Yes No Number of segments remaining = N 1? Yes Number of segments remaining = 0? Yes Stop T314 Stop T314 assemble message
Set (T314, now + 4 s) accumulate segment
A 1
No
Discard
DL-(UNIT) DATA indication (assembled message)
N1
1
T1161440-94
(05/98)
271
Discard
Discard call accumulated segments
Notify layer 3 manager
T1161450-94
ANNEX I Low layer information coding principles I.1 Purpose
This Annex describes principles that shall be used when the calling user specifies information during call set-up regarding low layer capabilities required in the network and by the destination terminal.
NOTE In this context and throughout this Annex, the term "called user" is the endpoint entity which is explicitly addressed. This may be an addressed Interworking Unit (IWU) (see I.500-series Recommendations and Recommendation X.31 [14] case A).
I.2 I.2.1
Principles Definitions of types of information
There are three different types of information that the calling ISDN user may specify during call setup to identify low layer capabilities needed in the network and by the destination terminal: a) Type I information is information about the calling terminal which is only used at the destination end to allow a decision regarding terminal compatibility. An example would be modem type. This information is encoded in octets 5 to 7 of the Low layer compatibility information element. Type II information is the selection of bearer capability from the choices of bearer capabilities offered by the network to which the calling user is connected. This type of information is present even if no interworking occurs. An example is Unrestricted Digital Information (UDI). This information is coded in i) octets 3 and 4 of the Bearer capability information element when the transfer mode required by the calling user is circuit mode;
b)
ii) octets 3, 4, 6 and 7 of the Bearer capability information element when the transfer mode required by the calling user is packet mode.
272
(05/98)
c)
Type III information is information about the terminal or intended call which is used to decide destination terminal compatibility and possibly to facilitate interworking with other ISDNs or other dedicated networks. An example is A-law encoding. Type III information is encoded in octet 5, 6 and 7 of the Bearer capability information element. Examination by network
I.2.2
Type I information is user-to-user (i.e. not examined by network) while both types II and III should be available for examination by the destination user and the network. The Low layer compatibility information element is an information element which is not examined by the network while the Bearer capability information element is an information element which is examined by the user and the network. I.2.3 Location of type I information
Type I information (i.e. terminal information only significant to the called user) shall, when used, be included in the Low layer compatibility information element. I.2.4 Location of type II and III information
Type II (i.e. bearer selection) information shall be included in the Bearer capability information element. Type III information, when used, is included in the Bearer capability information element. The network may use and modify the information (e.g. to provide interworking). The rationale for the user including some terminal related information in the type III information (interworking related) is shown by the following example. Normally with UDI, the rate adaption technique chosen is related to the terminal. The specification of a particular rate adaption scheme with a UDI bearer service could allow a compatibility decision by the destination terminal in a purely ISDN situation. However, it could also conceivably be used to allow interworking with a PSTN, assuming that the appropriate functions (i.e. data extraction, modem pool) are available at the interworking unit. If the rate adaption information is carried in the Low layer compatibility information element, and not in the Bearer capability information element, then interworking by the network providing the bearer capability would not be possible. However, if the rate adaption information is carried in the Bearer capability information element, interworking would be possible. Hence, there is some terminal related information which may be considered interworking related. The consequence for the calling user of not including such terminal related information in the Bearer capability information element is that the call may not be completed if an interworking situation is encountered. When type III information is included for any user protocol layer, the following network involvement is permitted within the indicated user protocol: layer 1: mapping of the user protocol to other protocols, and encapsulation of the user protocol within another protocol; layer 2: relaying of layer 2 PDUs across different layer 1 environments, and encapsulation of the user protocol within another protocol. Full termination of the user protocol is not provided, and in particular routing or destination identification information within the user protocol is not analysed until the entity addressed by the Called party number information element is reached; layer 3: relaying of layer 3 PDUs across different layer 2 environments, and encapsulation of the user protocol within another protocol. Full termination of the user protocol is not provided, and in particular routing or destination identification information within the user
(05/98)
273
protocol is not analysed until the entity addressed by the Called party number information element is reached. When type II information is included for any user protocol layer, and in addition to the identification of the telecommunication service requested by the user, the following network involvement is permitted within the indicated user protocol: layer 1: mapping of the user protocol to another protocol, and encapsulation of the user protocol within other protocols; layer 2: relaying of layer 2 PDUs across different layer 1 environments, and encapsulation of the user protocol within another protocol. Full termination of the user protocol can be provided, and in particular routing or destination identification information within the user protocol is analysed and utilised to reach the destination entity. When the user protocol is terminated, the Called party number information element (if included) is ignored at this point; layer 3: relaying of layer 3 PDUs across different layer 2 environments, and encapsulation of the user protocol within another protocol. Full termination of the user protocol can be provided, and in particular routing or destination identification information within the user protocol is analysed and utilised to reach the destination entity. When the user protocol is terminated, the Called party number information element (if included) is ignored at this point.
For both type II and type III information, if the network involvement modifies (interworks) the user protocols described by the bearer capability, the bearer capability relayed to the destination is modified appropriately. If no network involvement occurs, the bearer capability relayed to the destination is not modified. The interworking arrangements with other appropriate bearer capabilities (e.g. packet mode, frame mode) or other networks (e.g. PSTN, B-ISDN) which may be accommodated by some networks are beyond the scope of this Recommendation. I.2.5 Relationship between Bearer capability and Low layer capability information elements
There shall be no contradiction of information between the Low layer compatibility and the Bearer capability at the originating side. However, as some Bearer capability codepoints may be modified during the transport of the call, this principle implies that there should be minimal duplication of information between Bearer capability information element and Low layer compatibility information element.
NOTE If as a result of duplication, a contradiction occurs between the Bearer capability information element and the Low layer compatibility information element at the terminating side, the receiving entity shall ignore the conflicting information in the Low layer compatibility information element.
The following example, dealing with the specification of the encoding scheme used by the terminal for the speech or 3.1 kHz audio bearer services, shows the consequences of duplication. It is expected that some ISDNs will support only A-law and some only -law, with conversion provided by the -law network. (See Recommendation G.711). If the encoding scheme is specified in both the Bearer capability information element and the Low layer compatibility information element, interworking between two ISDNs might require a change of the user information layer 1 protocol in the Bearer capability information element (e.g. from A-law to -law), while the encoding scheme specified in the Low layer compatibility information element would presumably be forwarded to the destination unchanged. Since, to determine compatibility, the destination terminal examines both the Bearer capability information element and the Low layer compatibility information element, it would receive conflicting information regarding the encoding scheme used.
274
(05/98)
I.3
Information classification
The following are the examples of classifying low layer information currently identified. This information is provided to facilitate understanding of the characteristics of types II and III information. I.3.1 a) Examples for speech and 3.1 kHz audio bearer services Type II information (common to all applications using these bearer services) b) information transfer capability = speech or 3.1 kHz audio; information transfer mode = circuit; information transfer rate = 64 kbit/s; user information layer 1 protocol = A-/-law.
Type III information for interworking with CSPDN (3.1 kHz audio applications are assumed) Figure I.1 user information layer 1 protocol = rate adaption + user rate (see Note);
NOTE Only those profiles conforming to ITU-T standardized rate adaption are allowed when only the above information is provided.
c)
Type III information for interworking with PSTN i) voice applications Figure I.2: user information layer 1 protocol = A-/-law; user information layer 1 protocol = A-/-law.
ii) voice band data applications Figure I.3: I.3.2 a) Examples for 64 kbit/s UDI circuit mode bearer service Type II information (common) b) c) i) information transfer capability = unrestricted digital information; information transfer mode = circuit; information transfer rate = 64 kbit/s. no type III information is required. voice applications Figure I.5: d) no type III information is required; no type III information is required.
Type III information for interworking with PSPDN (packet applications) Figure I.4 Type III information for interworking with PSTN
ii) rate-adapted data applications Figure I.6: Type III information for interworking with PSTN with end-to-end digital connectivity (data applications) Figure I.7 user information layer 1 protocol = rate adaption + user rate (see Note).
NOTE The profile described in Recommendation I.463 [52] is allowed.
(05/98)
275
TA
S/T
ISDN PCM (A-/- law) <Modem>
IWF
CSPDN e.g. 2.4 kbit/s
X.21
Analogue (V-series)
T1161460-94
<Modem
X.1 rate>
NOTE Is user rate sufficient to specify the type of modem at IWF?
Figure I.1/Q.931 BC = 3.1 kHz audio Voice CSPDN
TA
S/T
ISDN PCM (A-/-law) <Voice>
IWF
PSTN Analogue <Voice> Analogue
Analogue <D A>
T1161470-94
Figure I.2/Q.931 BC = 3.1 kHz audio Voice PSTN
TA
S/T
ISDN PCM (A-/-law) <Modem>
IWF
PSTN Analogue <Modem> Analogue
Analogue (V-series)
<D
A>
T1161480-94
Figure I.3/Q.931 BC = 3.1 kHz audio Voice PSTN
X.25 [5]
TA
S/T
ISDN 64 kbit/s UDI
IWF
PSPDN X.25 packet
X.25
T1161490-94
Figure I.4/Q.931 BC = 64 kbit/s UDI Packet application PSPDN
TA
S/T
ISDN 64 kbit/s UDI
IWF
PSTN Analogue <Voice> Analogue
Analogue
T1161500-94
Figure I.5/Q.931 BC = 64 kbit/s UDI Voice PSTN
276
(05/98)
TA
S/T
ISDN 64 kbit/s UDI
IWF
PSTN Analogue <Voice band data>
Analogue
e.g. V-series
Rate adaption
Modem
T1161510-94
Figure I.6/Q.931 BC = 64 kbit/s UDI Rate adapter data PSTN
56 kbit/s
TA
S/T
ISDN 64 kbit/s UDI Rate adapt (I.463)
IWF
Existing DN Restricted DI
T1161520-94
Figure I.7/Q.931 BC = 64 kbit/s UDI Existing digital network
I.3.3 a)
Examples for ISDN virtual-circuit bearer service Type II information (common) information transfer capability = unrestricted digital information; information transfer mode = packet; information transfer rate = -- -- --; user information layer 1 protocol = rate adaption + user rate (see Note 1); user information layer 2 protocol = LAPB (see Note 2); user information layer 3 protocol = X.25 [5] packet layer protocol (see Note 2).
NOTE 1 This parameter is included only when user packet information flow is rate adapted. Only those profiles conforming to Recommendation X.31 are allowed when only the above information is provided for layer 1 protocol. NOTE 2 Only those profiles conforming to Recommendation X.31 are used. See Figures I.8 to I.10.
b)
Type III information for interworking with PSPDN, CSPDN, PSTN no type III information is necessary.
X.25 [5] TA S/T ISDN ISDN-VC IWF PSPDN X.25 VC (No conversion)
T1161530-94
X.25
Figure I.8/Q.931 BC = ISDN Virtual Circuit (VC) PSPDN
(05/98)
277
X.25 [5]
TA
S/T
ISDN ISDN-VC
IWF
CSPDN X.21 <Packet>
X.21 [26]
T1161540-94
Packet switched
Circuit switched
Figure I.9/Q.931 BC = ISDN Virtual Circuit (VC) CSPDN
X.25 [5]
TA
S/T
ISDN ISDN-VC
IWF
PSTN Analogue <Modem> <Packet>

T1161550-94
Packet switched
Modem
Figure I.10/Q.931 BC = ISDN Virtual Circuit (VC) PSTN
I.4 I.4.1 a)
Scenarios outside the scope of ISDN standardization Examples for speech and 3.1 kHz audio bearer services Type II information (common) information transfer capability = speech or 3.1 kHz audio; information transfer mode = circuit; information transfer rate = 64 kbit/s; user information layer 1 protocol = A-/-law.
b)
Type III information for interworking with PSTN Voice band data applications Modem type conversion occurs Figure I.11 user information layer 1 protocol = rate adaption + user rate + other attributes (if required).
TA S/T ISDN PCM (A-/-law) <Modem> Analogue Modem Modem' IWF Analogue <Modem'> Analogue
T1161560-94
NOTE This scenario seems to be a part of PSTN services.
Figure I.11/Q.931 BC = 3.1 kHz audio Voice band data PSTN
278
(05/98)
I.4.2 a)
Examples for 64 kbit/s UDI circuit-mode bearer services Type II information (common) information transfer capability = unrestricted digital information; information transfer mode = circuit; information transfer rate = 64 kbit/s.
b)
Type III information for interworking with PSTN Voice band data applications Figure I.12 no type III information is required.
TA S/T ISDN 64 kbit/s UDI PSTN Analogue <Modem'> Analogue Modem Modem' Analogue
T1161570-94
IWF
NOTE This scenario seems to be a combination of interworking with PSTN and a part of PSTN services.
Figure I.12/Q.931 BC = 64 kbit/s UDI Voice band data PSTN
ANNEX J Low layer compatibility negotiation This Annex describes an additional low layer compatibility checking procedure that may be applied by the user. J.1 General
The purpose of the Low layer compatibility information element is to provide a means which should be used for compatibility checking by an addressed entity (e.g. a remote user or an interworking unit or high layer function network node addressed by the calling user). The Low layer compatibility information element is transferred transparently by an ISDN between the call originating entity (e.g. the calling user) and the addressed entity. The user information protocol fields of the Low layer compatibility information element indicate the low layer attributes at the call originating entity and the addressed entity. This information is not interpreted by the ISDN, and therefore the bearer capability provided by the ISDN is not affected by this information. The call originating entity and the addressed entity may modify the low layer attributes by the negotiation described below if that can be supported by the bearer capability actually provided by the ISDN. The Low layer compatibility information element is coded according to 4.5.19. J.2 Low layer capability notification to the called user
When the calling user wishes to notify the called user of its information transfer attributes (type II information octets 3 and 4) or any low layer protocol (type I information octets 5 to 7) to be used during the call and not already identified in the Bearer capability information element, then the
(05/98)
279
calling user shall include a Low layer compatibility information element in the SETUP message; this element is conveyed by the network and delivered to the called user. However, if the network is unable to convey this information element, it shall act as described in 5.8.7.1 (unrecognized information element). J.3 Low layer compatibility negotiation between users
If the negotiation indicator (see 4.5) of the Low layer compatibility information element included in the SETUP message is set to "Out-band negotiation is possible (octet 3a, bit 7)", then one or more of the low layer protocol attribute(s) may be negotiated. In this case, the called user responding positively to the call may include a Low layer compatibility information element in the CONNECT message. This element will be conveyed transparently by the network and delivered to the calling user in the CONNECT message.
NOTE Only the low layer protocol attributes may be negotiated and therefore the information transfer attributes (octets 3 to 4), if returned by the called user in the CONNECT message, will be identical to the ones received in the Low layer compatibility information element contained in the SETUP message.
If, for any reason, the network is unable to convey this information element, it shall act as described in 5.8.7.1 (unrecognized information element). Users are advised not to include in the Low layer compatibility information element sent from the called user to the calling user, attributes which would have the same value as the ones contained in the Low layer compatibility information element received from the calling party. If bearer capability selection applies, and if a Low layer compatibility information element is returned by the called user in the CONNECT message, then the called user shall ensure that the information transfer attributes in that returned Low layer compatibility information element is the same as the information transfer attributes of the selected bearer capability. J.4 Low layer compatibility negotiation options
The Low layer compatibility information element contains a negotiation indicator which may have one of the following values: a) b) c) Out-band negotiation not possible (default) Then the called user shall not invoke negotiation, according to J.3. Out-band negotiation possible The called user may then invoke low layer compatibility negotiation, as needed, according to J.3. In-band negotiation possible The called user may then invoke low layer compatibility negotiation using the supported in-band negotiation, according to service or application requirements. Either in-band or out-band negotiation allowed The called user may invoke one or the other low layer compatibility negotiation procedures according to its requirements. If the call is end-to-end ISDN, and the out-band low layer compatibility negotiation is supported by both parties, then this method of negotiation is preferred. Alternate requested values
d)
J.5
If the user wishes to indicate alternative values of low layer compatibility parameters (e.g. alternative protocol suites or protocol parameters), the Low layer compatibility information element is repeated in the SETUP message. Up to four Low layer compatibility information elements may be included in a SETUP message. The first Low layer compatibility information element in the message is preceded by the Repeat indicator information element specifying "priority list for selection". The order of
280
(05/98)
appearance of the Low layer compatibility information elements indicates the order of preference of end-to-end low layer parameters. Alternatively, the network may discard the lower priority Low layer compatibility information element(s) depending on the signalling capability of the network. If the network or called user does not support repeating of the Low layer compatibility information element, and therefore discards the Repeat indicator information element and the subsequent Low layer compatibility information elements, only the first Low layer compatibility information element is used in the negotiation. The called user indicates a single choice from among the options offered in the SETUP message by including the Low layer compatibility information element in the CONNECT message. Absence of a Low layer compatibility information element in the CONNECT message indicates acceptance of the first Low layer compatibility information element in the SETUP message. If bearer capability selection applies, then for each individual Low layer compatibility information element included in the SETUP message, the user shall ensure that there is no contradiction between the information contained in that Low layer compatibility information element and the information contained in at least one of the included Bearer capability information elements, either the fallback bearer capability, the preferred bearer capability, or both. ANNEX K Procedures for establishment of bearer connection prior to call acceptance K.1 General
For some applications, it is desirable to allow the completion of the transmission path associated with a bearer service prior to receiving call acceptance. In particular, the completion of the backward direction of the transmission path prior to receipt of a CONNECT message from the called user may be desirable to: a) b) allow the called user to provide internally-generated tones and announcements that are sent in-band to the calling user prior to answer by the called user; or avoid speech clipping on connections involving an NT2 where delays may occur in relaying the answer indication within the called user equipment.
The procedures described in this Annex are only applicable to the speech and 3.1 kHz audio bearer services.
NOTE The definition of necessary mechanisms (if any) with Signalling System No. 7 to avoid any potential undesirable charging implications remains for further study.
K.2
Procedures
As a network option, completion of the transmission path prior to receipt of a call acceptance indication may be provided in one of three ways: a) b) c) on completion of successful channel negotiation at the destination interface; or on receipt of a message containing an indication that in-band information is being provided; or not at all, i.e. this option is not supported by the network.
(05/98)
281
When criteria a) is used to determine that transmission path should be established, the network shall connect, as a minimum, the backward side of the transmission path upon receipt of either a CALL PROCEEDING message or an ALERTING message containing an acceptable B-channel indication. When criteria b) is used to establish the transmission path, the network shall connect, as a minimum, the backward side of the transmission path upon receipt of either an ALERTING message or a PROGRESS message containing progress indicator No. 8, in-band information or appropriate pattern is now available, or progress indicator No. 1, call is not end-to-end ISDN; further call progress information may be available in-band, respectively. The network providing the early completion of the transmission path in the backward direction may choose to support only one of methods a) or b) above. The network may choose to further restrict which message(s) will result in establishment of the transmission path. These restrictions may be imposed on a per interface basis to provide an administrative means for limiting potential misuse of the early connection capabilities. ANNEX L Optional procedures for bearer service change The procedure for bearer service change may not be provided on all networks. On those networks that support it, a user may use this procedure after making a suitable subscription-time arrangement. When a bearer service requested in an originator's SETUP message cannot be provided by the network, the network would reject the call or, under some circumstances, the network may change the bearer service and provide bearer service change notification. These procedures are currently applicable only to a change from 64 kbit/s unrestricted to 64 kbit/s restricted, and from 64 kbit/s restricted to 64 kbit/s restricted with rate adaption.
NOTE During an interim period some networks may only support restricted 64 kbit/s digital information transfer capability, i.e. information transfer capability solely restricted by the requirement that the all-zero octet is not allowed. For interworking, the values given in Appendix I/I.340 should apply. The interworking functions have to be provided in the network restricted capability. The ISDN with 64 kbit/s transfer capabilities will not be offered by this interworking, other than by conveying the appropriate signalling message to or from the ISDN terminal.
Up to two Bearer capability information elements may be present in the SETUP message from the originating user, corresponding to the allowed bearer service modifications given above. The Bearer capability information element shall be immediately preceded by the Repeat indicator information element with the meaning field specifying Prioritized list for selecting one possibility. Hence, the order of Bearer capability information elements would indicate order of bearer service preference. If the SETUP message contains Bearer capability information elements not agreeing with any of the permissible ordered combinations listed above, the network will reject the call attempt. After sending a CALL PROCEEDING message, when the originating network or terminating premises equipment determines that the preferred bearer service cannot be provided, it sends a NOTIFY message toward the call originator. The NOTIFY message contains a Notification indicator information element with a coding which indicates to the originating party the change in bearer service and also contains a Bearer capability information element specifying the attributes of the new bearer service. Receipt of the NOTIFY message is not acknowledged. The call originator may allow the call to continue or may initiate call clearing in accordance with clause 5.
282
(05/98)
ANNEX M Additional basic call signalling requirements for the support of private network interconnection for Virtual Private Network applications M.1 Introduction
This Annex covers the application of a public ISDN providing Virtual Private Network (VPN) services to Private Integrated Services Network Exchanges (PINX). This Annex contains only additional requirements to those in the main body of this Recommendation. This Annex specifies additional protocol elements and call control procedures for the handling of calls in a VPN context at the T reference point of a public ISDN. The functionality provided by the public network may be: the emulation of an Originating PINX; the emulation of a Terminating PINX; the emulation of a Transit PINX; the emulation of a Relay Node; the emulation of an Incoming Gateway PINX; the emulation of an Outgoing Gateway PINX; the emulation of a combination of two or more of the above.
The support of these capabilities is a network option. The public network can support the coexistence of multiple CNs in parallel, i.e. the resources of the public network are shared by multiple CNs. Each CN should be considered as a separate network. The minimum requirement of the virtual Transit PINX and the virtual Gateway PINX is to be able to uniquely identify the CN to which a particular attached PINX belongs in order to ensure correct routeing of a particular call. In addition, a physical PINX may support multiple CNs. Thus the mechanism for identifying a CN needs to be conveyed between a physical PINX and the public network. This Annex does not cover the requirements for providing VPN services to terminals directly connected to the public network. The specification included in this Annex does not imply any specific implementation technology or platform. M.2 Scope
This Annex specifies the extensions required to the basic call control signalling protocol defined in the main body of this Recommendation to support calls within a Corporate telecommunications Network (CN) and to support calls which enter or exit the CN via Gateway PINX functionality performed by the public network. The protocol is applicable at the T reference points to which VPN services are provided. The support of these additional signalling capabilities is a network option. These DSS1 extensions are made available to PINXs on the basis of bilateral agreements at subscription time. The additional basic call signalling capabilities identified in this Annex are to provide information flows that are functionally identical to the information flows provided by the PSS1 basic call control protocol (as defined by ISO/IEC 11572).
(05/98)
283
In the context of this Annex, the public network (providing VPN services) can be seen, from the private network perspective, as providing an interconnection between a PINX supporting DSS1 extensions for VPN and another PINX supporting PSS1 information flows. This second PINX may be a physical PINX connected to the public network or may be an emulation of an end PINX function provided by the public network. An emulation of Originating PINX functionality by the public network should, as a minimum, meet the requirements of an Originating PINX Call Control as defined in ISO/IEC 11572 for the circuitswitched call control and the ISO supplementary services associated with the basic call (CLIP, CLIR, COLP, COLR, SUB). In addition, the Transit counter ANF (defined in ISO/IEC 15056) may be supported by these DSS1 extensions. An emulation of Terminating PINX functionality by the public network should, as a minimum, meet the requirements of a Terminating PINX Call Control as defined in ISO/IEC 11572 for the circuitswitched call control and the ISO supplementary services associated with the basic call (CLIP, CLIR, COLP, COLR, SUB). In addition, the Transit counter ANF (defined in ISO/IEC 15056) may be supported by these DSS1 extensions. An emulation of Transit PINX functionality by the public network should, as a minimum, meet the requirements of a Transit PINX Call Control as defined in ISO/IEC 11572 for the circuit-switched call control and the ISO supplementary services associated with the basic call (CLIP, CLIR, COLP, COLR, SUB). In addition, the Transit counter ANF (defined in ISO/IEC 15056) may be supported by these DSS1 extensions. A Relay Node in a VPN includes the following functions: minimal routing capability; transparent handling of private networking information (e.g. transit counter).
An emulation of Incoming Gateway PINX functionality by the public network should, as a minimum, meet the requirements of an Incoming Gateway PINX Call Control as defined in ISO/IEC 11572 for the circuit-switched call control and the ISO supplementary services associated with the basic call (CLIP, CLIR, COLP, COLR, SUB). In addition, the Transit counter ANF (defined in ISO/IEC 15056) may be supported by these DSS1 extensions. An emulation of Outgoing Gateway PINX functionality by the public network should, as a minimum, meet the requirements of an Outgoing Gateway PINX Call Control as defined in ISO/IEC 11572 for the circuit-switched call control and the ISO supplementary services associated with the basic call (CLIP, CLIR, COLP, COLR, SUB). In addition, the Transit counter ANF (defined in ISO/IEC 15056) may be supported by these DSS1 extensions. The attached PINX acts as the user within the DSS1 protocol defined by this Annex. M.2.1 Acronyms used in this Annex ANF Additional Network Feature BCD CLIP CLIR CN Binary Coded Decimal Calling Line Identification Presentation Calling Line Identification Restriction Corporate telecommunications Network
COLP Connected Line identification Presentation COLR Connected Line identification Restriction CPE CPN Customer Premises Equipment Customer Premises Network
284
(05/98)
PINX Private Integrated services Network eXchange PISN PSS1 SUB VPN Private Integrated Services Network Private Signalling System No. 1 Sub-addressing Virtual Private Network
M.2.2 References ISO/IEC 11572:1997, Information technology Telecommunications and information exchange between systems Private Integrated Services Network Circuit mode bearer services Inter-exchange signalling procedures and protocol. ISO/IEC 11571:1994, Information technology Telecommunications and information exchange between systems Numbering and sub-addressing in private integrated services networks. ISO/IEC 15056:1997, Information technology Telecommunications and information exchange between systems Private Integrated Services Network Inter-exchange signalling protocol Transit counter additional network feature.
M.2.3 Definitions M.2.3.1 Virtual Private Network (VPN): Is that part of a CN that provides corporate networking using shared switched network infrastructures. This is split into VPN architecture and VPN services. The VPN architecture is that part of a CN that provides corporate networking between customer equipment where: the shared switch network infrastructure takes the place of the traditional analogue or digital leased lines and the function of the transit node irrespective of the network type, e.g. the Public Switched Telephone Network (PSTN), ISDN or a separate network; the customer premises may be served in terms of end node functionality with any combination of PBX, Centrex, Local Area Network (LAN) router, or multiplexer; the CN user may also be served by terminal equipment connected to end node functionality residing on customer premises, or provided by public network equipment; and the VPN architecture in one network, or multiple networks, comprise a part of the total national or international CN. VPN end-user services to CN users; VPN networking services to support the interconnection of PINXs; service interworking functionality; inter-VPN services to provide co-operation between the VPN services of two networks; and VPN management services to enable service subscribers to control and manage their VPN resources and capabilities.
VPN services offered by the switched network infrastructure provide:
M.2.3.2 Private Integrated services Network eXchange (PINX): A PISN nodal entity that provides automatic switching and call handling functions used for the provision of telecommunication services. The nodal entity can be implemented by one or more pieces of equipment located on the premises of the private network administrator or by equipment co-located with, or physically part of, a public network.
(05/98)
285
NOTE If applicable, a PINX provides to users of the same and/or other private integrated services network exchanges: telecommunication services within its own area; and/or telecommunication services from the public ISDN; and/or telecommunication services from other public or private networks; and/or within the context of a PISN, telecommunication services from other PINXs.
M.2.3.3 end PINX functionality: Within the context of a call, the functionality of a PINX required to provide attachment and servicing of terminals. M.2.3.4 originating PINX functionality: End PINX functionality providing support of the calling user. M.2.3.5 terminating PINX functionality: End PINX functionality providing support of the called user. M.2.3.6 transit PINX functionality: Within the context of a call, the functionality of a PINX, emulated in the public network, required to interconnect a pair of PINXs. M.2.3.7 gateway PINX functionality: Within the context of a call, the functionality of a PINX required to interconnect End PINXs or Transit PINXs with nodes of other public or private networks, or with nodes supporting different signalling capabilities. M.2.3.8 outgoing gateway PINX functionality: Gateway PINX functionality providing support of calls from the Corporate Network to other networks. M.2.3.9 incoming gateway PINX functionality: Gateway PINX functionality providing support of calls incoming to the Corporate Network. M.2.3.10 relay node functionality: Within the context of a call, the functionality that identifies calls in a VPN context, and relays such calls to designated PINX functionality emulated by public network equipment, or to a designated physical PINX. This may be via other Relay Nodes. Relay Node functionality includes transparent handling of private networking information (e.g. transit counter). M.2.3.11 preceding PINX: In the context of a call, an entity with PINX functionality located in the direction towards the calling user. M.2.3.12 subsequent PINX: In the context of a call, an entity with PINX functionality located in the direction towards the called user. M.2.3.13 Corporate telecommunications Network (CN): Consists of sets of equipment [Customer Premises Equipment (CPE) and/or Customer Premises Network (CPN) and/or public network providing VPN services] which are located at geographically dispersed locations and are interconnected to provide networking services to a defined group of users.
NOTE 1 The ownership of the equipment is not relevant to this definition. NOTE 2 Even equipment which is not geographically dispersed (e.g. a single PINX or a Centrex providing service to users at a single location) may form a CN.
M.3
Basic call states
The call states apply unchanged, as defined in 2.1/Q.931 and 2.4/Q.931.
286
(05/98)
M.4
Additional messages and content
No additional messages are defined. However, the content of some messages has additional requirements. M.4.1 SETUP message The Called party number information element is mandatory in both the user-network and the network-user directions. The Transit counter information element may be included in the SETUP message, for use in both user-to-network and network-to-user directions. The inclusion of the VPN indicator information element is mandatory in both the user-network and the network-user directions. M.4.2 CONNECT message The Connected number information element and the Connected subaddress information element may be included in the CONNECT message for use in both user-to-network and network-to-user directions. M.5 Additional information elements and coding
M.5.1 Called party number Subclause 4.5.8/Q.931 shall apply with the exception that Table 4-9/Q.931 is replaced by Table M.1: Table M.1/Q.931
Numbering plan identification (octet 3) Bits 4321 0 0 0 0 Unknown (Note 1) 0 0 0 1 ISDN/telephony numbering plan (Recommendation E.164) 1 0 0 1 Private numbering plan (ISO/IEC 11571) All other values are reserved. NOTE 1 The numbering plan "unknown" is used when the user or network has no knowledge of the numbering plan. In this case, the number digits field is organized according to the network dialling plan, e.g. prefix or escape digits might be present. Type of number (octet 3) when Numbering Plan identification is ISDN/telephony numbering plan (Recommendation E.164) (Note 2) Bits 765 000 Unknown (Note 3) 001 International number (Note 4) 010 National number (Note 4) 100 Subscriber number (Note 4) All others values are reserved. NOTE 2 For the definition of international, national and subscriber number, see Recommendation I.330. 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 organized according to the network dialling plan; e.g. prefix or escape digits might be present. NOTE 4 Prefix or escape digits shall not be included.
(05/98)
287
Table M.1/Q.931 (concluded)

Type of number (octet 3) when Numbering Plan identification is Unknown Bits 765 000 Unknown (Note 5) All others values are reserved. NOTE 5 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 organized according to the network dialling plan; e.g. prefix or escape digits might be present. Type of number (octet 3) when Numbering Plan identification is Private numbering plan (Note 6) Bits 765 000 Unknown (Note 7) 001 Level 2 Regional Number 010 Level 1 Regional Number 011 PISN specific number 100 Level 0 Regional Number All others values are reserved. NOTE 6 For the definition of Level 2 Regional Number, Level 1 Regional Number, Level 0 Regional Number and PISN specific number, see ISO/IEC 11571. NOTE 7 The type of number "unknown" is used when the user or the network has no knowledge of the type of number, e.g. Level 2, Level 1, etc. In this case, the number digits field is organized according to the network dialling plan; e.g. prefix or escape digits might be present. Number digits (octets 4, etc.) This field is coded with IA5 characters, according to the formats specified in the appropriate numbering/dialling plan.
M.5.2 Calling party number Subclause 4.5.10/Q.931 shall apply with the exception that Table 4.11/Q.931 is replaced by Table M.2: Table M.2/Q.931
Numbering plan identification (octet 3) Bits 4321 0 0 0 0 Unknown (Note 1) 0 0 0 1 ISDN/telephony numbering plan (Recommendation E.164) 1 0 0 1 Private numbering plan (ISO/IEC 11571) All other values are reserved. NOTE 1 The numbering plan "unknown" is used when the user or network has no knowledge of the numbering plan. In this case, the number digits field is organized according to the network dialling plan, e.g. prefix or escape digits might be present.
288
(05/98)
Table M.2/Q.931 (continued)

Type of number (octet 3) when Numbering Plan identification is ISDN/telephony numbering plan (Recommendation E.164) (Note 2) Bits 765 000 Unknown (Note 3) 001 International number (Note 4) 010 National number (Note 4) 100 Subscriber number (Note 4) All others values are reserved. NOTE 2 For the definition of international, national and subscriber number, see Recommendation I.330. 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 organized according to the network dialling plan; e.g. prefix or escape digits might be present. NOTE 4 Prefix or escape digits shall not be included. Type of number (octet 3) when Numbering Plan identification is Unknown Bits 765 000 Unknown (Note 5) All others values are reserved. NOTE 5 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 organized according to the network dialling plan; e.g. prefix or escape digits might be present. Type of number (octet 3) when Numbering Plan identification is Private numbering plan (Note 6) Bits 765 000 Unknown (Note 7) 001 Level 2 Regional Number 010 Level 1 Regional Number 011 PISN specific number 100 Level 0 Regional Number All others values are reserved. NOTE 6 For the definition of Level 2 Regional Number, Level 1 Regional Number, Level 0 Regional Number and PISN specific number, see ISO/IEC 11571. NOTE 7 The type of number "unknown" is used when the user or the network has no knowledge of the type of number, e.g. Level 2, Level 1, etc. In this case, the number digits field is organized according to the network dialling plan; e.g. prefix or escape digits might be present. Presentation indicator (octet 3a) Bits 76 0 0 Presentation allowed 0 1 Presentation restricted 1 0 Number not available due to interworking 1 1 Reserved
(05/98)
289
Table M.2/Q.931 (concluded)

Screening indicator (octet 3a) Bits 21 0 0 User-provided, not screened 0 1 User-provided, verified and passed 1 0 Reserved 1 1 Network provided Number digits (octets 4, etc.) This field is coded with IA5 characters, according to the formats specified in the appropriate numbering/dialling plan.
M.5.3 Connected number The coding of the Connected number information element is defined in 5.4/Q.951, with the exception that the content of this information element is coded as defined in M.5.2. M.5.4 Connected subaddress The coding of the Connected subaddress information element is defined in 5.4/Q.951. M.5.5 Progress indicator The following additional progress description values are defined in the ISO/IEC coding standard: Bits 7654321 0010000 0010001 0010010 0010011 No. 16 17 18 19
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.
M.5.6 Transit counter The Transit counter information element may, optionally, be included in the SETUP message to indicate the number of private network transit exchanges which intervene in the requested connection. The Transit counter information element has a maximum length of 3 octets. The Transit counter information element is defined in codeset 4.
8 0 ext. 1 7 6 5 4 3 2 Transit counter information element identifier 0 1 1 0 0 0 Length of Transit counter Reserved Transit count (binary value) 0 0 1 1 Octet 1 2 3
M.5.7 VPN indicator The VPN indicator information element shall be included in the SETUP message to indicate that the call is in VPN context. The VPN indicator information element may, optionally, include a CN identifier to distinguish between CNs in the VPN. The VPN indicator information element has a maximum length of 15 octets. The VPN indicator information element is defined in codeset 0.
290
(05/98)
8 0 1
7 0
6 5 4 3 2 VPN indicator information element identifier 0 0 0 1 0 Length of VPN indicator Spare CN indicator CN identifier
1 1
Octet 1 2 3 3.1* ... 3.12*
CN indicator (octet 3) Bits 321 000 001 010
No indication (Note 1) Network specific (Note 2) Global (Note 3)
All others values are reserved.

NOTE 1 When the CN indicator "no indication" is used, the call belongs to the assigned default CN. NOTE 2 When the CN indicator "network specific" is used, the CN identifier is contained in the following octets. NOTE 3 When the CN indicator "global" is used, the CN identifier in the following octets contains a globally unique value.
CN identifier (octets 3.1 to 3.12) The CN identifier indicated "Network specific" is a network provider matter. When the CN indicator is set to "global", the CN identifier contains the binary representation of the CN identifier. The CN identifier starts with the BCD (Binary Coded Decimal) representation of the E.164 country code digits of the country where the CN was initially assigned. The remainder of the CN identifier is country specific. M.6 Additional basic call control procedures
M.6.1 Distinction between public network and VPN context If an entity sends a message that establishes a call reference in a VPN context, that entity shall include a VPN indicator information element in this message.
NOTE As a network option, the Network-specific facilities information element may be used instead of the VPN indicator information element (see Appendix I to Annex M).
If an entity receives a message that establishes a call reference, and this message does not contain a VPN indicator information element, then the procedures for signalling in a public network context for all messages that use this call reference shall apply. If an entity receives a message that establishes a call reference, and this message contains a VPN indicator information element, then the procedures for signalling in a VPN context for all messages that use this call reference shall apply. M.6.2 Procedures applicable for signalling in a public network For a call which is not identified as a call in a VPN context (see M.4.1), clause 5 shall apply.
(05/98)
291
M.6.3 Procedures applicable for signalling in a VPN context For a call which is identified as a call in a VPN context (see M.4.1), clause 5 shall apply with the additions described in M.6.3.1 and M.6.3.2. M.6.3.1 Call establishment from a physical PINX M.6.3.1.1 Call Request
The physical PINX at the originating interface shall include the VPN indicator information element in the SETUP message. If the VPN indicator information element does not contain a CN identifier and a CN identifier is registered as a default for the access, then the default CN identifier shall be used. If the VPN indicator information element does not contain a CN identifier and there is no CN identifier registered as a default for the access, then the call shall be rejected with cause No. 50, Requested facility not subscribed. If the VPN indicator information element contains a CN indicator value and/or a CN identifier which is not associated with the access, then the call shall be rejected with cause No. 50, Requested facility not subscribed. The physical PINX at the originating interface shall include the Called party number information element in the SETUP message. If received from the physical PINX at the originating interface, the Calling party number information element and the Calling party subaddress information element shall be handled as follows: a Transit PINX shall transfer the information elements to the subsequent PINX regardless of any supplementary service subscription information; a Relay Node shall transfer the information elements to the subsequent PINX regardless of any supplementary service subscription information; an Outgoing Gateway PINX may transfer the information to the other network;
NOTE The handling of numbers, e.g. translations, presentation indications, is outside the scope of this Annex.
a Terminating PINX may transfer the information to the called user, depending on any restrictions (e.g. interface type or service).
The physical PINX at the originating interface may include the Transit counter information element in the SETUP message. Whilst the handling by the public network is outside the scope of this Recommendation, it shall be transferred as follows: a Transit PINX shall transfer the information element to the subsequent PINX; a Relay Node shall transfer the information element to the subsequent PINX; an Outgoing Gateway PINX may transfer the information to the other network. Notification of interworking at the interface between a physical PINX and the public network
M.6.3.1.2
When the public network receives a specific private network Progress description value from the subsequent PINX, it shall transfer it to the physical PINX at the originating interface, without acting upon it. Outgoing Gateway PINX functionality shall provide Progress indicator information elements as specified below and this information shall be transferred to the physical PINX. A Progress indicator information element shall be transmitted in a PROGRESS message, an ALERTING message or a
292
(05/98)
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. If one of the following progress descriptions has been received on a call exiting the CN, that information shall be passed on: No. 1 Call is not end-to-end ISDN; further call progress information may be available inband. No. 2 Destination address is non-ISDN. No. 4 Call has returned to the ISDN. No. 8 In-band information or appropriate pattern is now available.
If the call is to enter another network (public or private) which is not ISDN, a Progress indicator information element may be sent containing progress description No. 1, Call is not end-to-end ISDN; further call progress information may be available in-band. The physical PINX at the originating interface may, optionally, include any of the specific private network Progress description values in the SETUP message, to enable indication of particular situations at the originating side to the subsequent PINX. The public network shall transfer it to the subsequent PINX. Up to three Progress indicator information elements may be included in a SETUP, ALERTING, PROGRESS and CONNECT message. M.6.3.1.3 In-band information provided to the physical PINX at the originating interface
Any progress indications shall be conveyed towards the physical PINX at the originating interface. On receipt of the Progress description No. 1 or No. 8 in the PROGRESS or ALERTING message, the physical PINX at the originating interface shall switch through in the backward direction to the allocated B-channel in order to enable transfer of in-band tones/information, and stop timer T310, if running. M.6.3.1.4 Call confirmation
The public network shall include the Connected number information element and the Connected subaddress information element in the CONNECT message as follows: if received from a subsequent PINX, a Transit PINX shall transfer the information elements to the physical PINX at the originating interface regardless of any supplementary service subscription information; if received from a subsequent PINX, a Relay Node shall transfer the information elements to the physical PINX at the originating interface regardless of any supplementary service subscription information; an Outgoing Gateway PINX may transfer the information from the other network;
a Terminating PINX shall provide the Connected number information element to the physical PINX regardless of any possible supplementary service subscription information. Furthermore, a Terminating PINX shall transfer the Connected subaddress information element if received from the connected user regardless of any possible service subscription information.
(05/98)
293
M.6.3.2 Call establishment towards a physical PINX M.6.3.2.1 Incoming call
For calls in a VPN context, the public network shall include the VPN indicator information element in the SETUP message. Incoming Gateway PINX functionality and Originating PINX functionality shall identify the call as a call in a VPN context. The public network shall include the Calling party number information element and the Calling party subaddress information element in the SETUP message as follows: if received from a preceding PINX, a Transit PINX shall transfer the information elements to the physical PINX at the destination interface regardless of any supplementary service subscription information; if received from a preceding PINX, a Relay Node shall transfer the information elements to the physical PINX at the destination interface regardless of any possible supplementary service subscription information; an Incoming Gateway PINX may transfer the information from the other network;
an Originating PINX shall provide the Calling party number information element to the physical PINX at the destination interface regardless of any possible supplementary service subscription information. Furthermore, an Originating PINX shall transfer the Calling party subaddress information element if received from the calling user regardless of any possible supplementary service subscription information.
The public network shall include the Transit counter information element in the SETUP message if received from the preceding PINX. M.6.3.2.2 Notification of interworking at the interface between a physical PINX and the public network
The PINX at the destination interface may, optionally, include any of the specific private network Progress description values in the ALERTING, PROGRESS or CONNECT message returned to the public network, to enable notification of particular situations at the destination side. The public network shall then transfer the information as follows: a Transit PINX shall transfer the information elements to the preceding PINX; a Relay Node shall transfer the information elements to the preceding PINX; an Incoming Gateway PINX may transfer the information to the other network; an Originating PINX may convey the information to the calling user.
Incoming Gateway PINX functionality shall provide Progress indicator information elements in the SETUP message as specified below, and this information shall be transferred to the physical PINX. If none of the specified conditions apply, no Progress indicator information element shall be included. If one of the following progress descriptions has been received on a call entering the CN, that information shall be passed on: No. 1 Call is not end-to-end ISDN, further call progress information may be available inband. No. 3 Origination address is non-ISDN.
294
(05/98)
If the call has entered the Corporate Network from a network (public or private) which is not ISDN, a Progress indicator information element may be sent containing progress description No. 1, Call is not end-to-end ISDN; further call progress information may be available in-band. When the public network receives a specific private network Progress description value from the preceding PINX, it shall transfer it to the physical PINX at the destination interface, without acting upon it. Up to three Progress indicator information elements may be included in a SETUP, ALERTING, PROGRESS and CONNECT message. M.6.3.2.3 In-band information provided by the physical PINX at the destination interface
During call establishment, after the first message received in response to the SETUP message, on receipt of a Progress indicator information element with a Progress description No. 1 or No. 8 in the PROGRESS or ALERTING message, the public network shall switch through in the backward direction to the allocated B channel in order to enable in-band tones/information provided from the physical PINX at the destination interface to the calling user, stop timer T310, if running, and if progress description No. 1 or No. 8 was received in the PROGRESS message while T310 was running, restart timer T310. The public network shall transfer the Progress indicator information element towards the preceding PINX. M.6.3.2.4 Call confirmation
The physical PINX at the destination interface may include the Connected number and the Connected subaddress information elements in the CONNECT message. The Connected number information element and the Connected subaddress information element, when received from the physical PINX at the destination interface in the CONNECT message, shall be transferred by the public network as follows: a Transit PINX shall transfer the information elements towards the preceding PINX, regardless of any supplementary service subscription information; a Relay Node shall transfer the information elements to the preceding PINX, regardless of any possible supplementary service subscription information; an Incoming Gateway PINX may transfer the information to the other network;
an Originating PINX may transfer the information to the calling user, depending on any restrictions. System parameters
M.7
T310: the value of this timer when started or restarted upon receipt of progress description No. 1 or No. 8 has a standard default value of 2 minutes (can have different values in a range from 1 to 7 minutes).
(05/98)
295
APPENDIX M.I (to Annex M) Discrimination of calls in a VPN context by means of the Network-specific facilities information element As a network option, subject to user and network service provider bilateral agreement, the Networkspecific facilities information element may be used to discriminate calls in a VPN context. The coding of this information element is shown in Figure 4-27. Some networks are known to have assigned the following network-specific coding for the field "Network-specific facility specification".
8 ext. 1 Spare 0 7 6 5 4 3 Facility coding value 2 1 Octet 4 5, etc.
Service parameters (IA5 characters)
Figure M.I.1/Q.931 Example of Network-specific facilities information element coding to discriminate calls in a VPN context Facility coding value (octet 4) Bits 7 6 5 4 3 2 1 1 1 1 1 0 0 1 VPN service selection Service parameters (octet 5) Service parameters (e.g. CN identifier) may be encoded in octet(s) 5 according to the network service provider specifications. ANNEX N Flexible channel selection It is a network option to support the procedures in this Annex. When a preferred bearer requires a larger bandwidth than an allowed alternate fallback, e.g. 6 64 kbit/s to 64 kbit/s, multiple channel identifications may be present in the SETUP message. In this case, one Channel identification information element will be included for each Bearer capability information element in the SETUP message. If the bandwidth required for two of the bearers is the same, then the same channel shall be indicated for the two bearers. Channel selection procedures for each bearer will follow 5.1.2 and 5.2.3 independently, except that the selection of the same channel for more than one of the bearer alternatives will be allowed and will not constitute a conflict. The bearer capability selected for the call will determine the final selection of the channel for the call. Procedures for early cut through, the use of the Repeat indicator information element for the channel identifications and the confirmed release of unused channels are for further study.
296
(05/98)
APPENDIX I Definition of causes values Table I.2 indicates the usage of cause values within this Recommendation. Other usage may be provided within other Recommendations, e.g. Q.700-series and Q.699. Other causes may also be used by Q.931 entities where this is not precluded by the procedures defined elsewhere in this Recommendation. Table I.1 defines the key for the location of generation in Table I.2. For more precise usage of the location codes in the cause information element, see Recommendation Q.850. Table I.1/Q.931 Key to the location in Table I.2
LU LN TN RN RU LPE Local User Local Network Transit Network Remote Network Remote User Local Peer Entity (for symmetrical operation, see Annex D)
The following abbreviations to message types are used in Table I.2 CON CON CONGESTION CONTROL DISC REL RES REJ STAT DISCONNECT RELEASE RESUME REJECT STATUS
REL COM RELEASE COMPLETE
SUSP REJ SUSPEND REJECT
(05/98)
297
Table I.2/Q.931 Usage of cause values

Typical location Cause No. 1 Class 000 Value 0001 Cause name Unassigned (unallocated) number Diagnostics Condition Reference 5.1.4 5.2.4 2 000 0010 No route to specified transit network Transit network identity/network specific facilities info. Elements Condition C.2 of generation LN RU TN REL COM DISC DISC Typical carrying message as identified by receiving side At remote interface At local interface REL COM DISC
E.3 3 000 0011 No route to destination 5.1.4 5.2.4 6 000 0110 Channel unacceptable 5.2.3.1 c) 5.3.2 d) 6.2.2.3.1 6.2.2.3.1
LN LN RU LN REL COM DISC
REL COM DISC REL COM DISC REL
000
0111
Call awarded and being delivered in an established channel Normal call clearing
LN
REL
16
001
0000
Condition
RU
DISC
DISC
298
(05/98)
Table I.2/Q.931 Usage of cause values (continued)

Typical location Cause No. 17 Class 001 Value 0001 Cause name User busy Diagnostics Reference 5.2.5.1 5.2.5.4 b) No procedure 18 19 21 001 001 001 0010 0011 0101 No user responding User alerting, no answer Call rejected Condition: user supplied diagnostic New destination number 5.2.5.3 5.2.5.3 5.2.5.1 5.2.5.4 b) 5.1.4 5.2.4 26 27 28 001 001 001 1010 1011 1100 Non-selected user clearing Destination out of order Invalid number format (incomplete number) 5.2.4 5.3.2 b) 6.2.2.3.1 5.8.9 of generation RU RN RN RN RU REL COM Typical carrying message as identified by receiving side At remote interface REL COM At local interface DISC DISC DISC DISC DISC
22
001
0110
Number changed
LN RU LN RN LN RU DISC REL COM REL COM DISC
DISC REL COM DISC REL DISC DISC REL COM DISC
299
(05/98)

Typical location Cause No. Class Value Cause name Diagnostics Reference 5.1.5.2 5.2.4 5.1.4 29 011 1101 Facility rejected Facility identification No procedure in Q.931 of generation LN RN LN LN RN RU 30 31 34 001 001 010 1110 1111 0010 Response to STATUS ENQUIRY Normal, unspecified No circuit/channel available 5.8.10 5.8.4 5.1.1 5.1.2 5.1.5.1 5.1.5.2 5.2.3.1 b) 5.2.3.1 e) 5.2.3.2 6.2.2.3.1 C.2 LU, LN RN LN REL COM DISC STAT REL COM DISC REL COM Typical carrying message as identified by receiving side At remote interface At local interface DISC DISC DISC REL COM REL COM DISC DISC
RU
REL COM
DISC
LN
REL COM DISC
REL COM DISC
300
(05/98)

Typical location Cause No. Class Value Cause name Diagnostics Reference C.2 D.1.1 e) D.3 b) 38 41 42 43 010 010 010 010 0110 1001 1010 1011 Network out of order Temporary failure Switching equipment congestion Access information discarded Requested circuit/channel not available Discarded into element identifier(s) No procedure 5.8.8 5.8.10 No procedure 7.1.5.7 5.8.7.2 44 010 1100 5.1.2 5.1.5.1 5.1.5.2 5.2.3.1 e) 5.2.3.2 6.2.2.3.1 D.1.1 e) 47 010 1111 Resource unavailable, unspecified No procedure RU, LN, RU LN, LU LN LU, LN LN, RU, RN DISC DISC DISC REL REL COM CON CON STAT REL COM of generation TN LPE Typical carrying message as identified by receiving side At remote interface At local interface DISC REL COM
RU
REL COM
DISC
REL COM
301
(05/98)

Typical location Cause No. 57 Class 011 Value 1001 Cause name Bearer capability not authorized Diagnostics Attributes of bearer capability Reference 5.1.5.2 7.2 58 011 1010 Bearer capability not presently available Attributes of bearer capability 5.1.5.2 7.2 63 65 011 100 1111 0001 Service or option not available, unspecified Bearer capability not implemented Channel type not implemented Requested facility not implemented Attributes of bearer capability Channel type Facility identification 5.1.5.2 5.1.5.2 6.1 66 69 100 100 0010 0101 No procedure 7.1.3.6 7.1.4.3 7.1.5.3 7.3 RU RN LN DISC REL COM DISC REL DISC REL REL COM of generation LN LN LN LN LN LN LN Typical carrying message as identified by receiving side At remote interface At local interface DISC REL COM REL REL COM DISC REL COM REL REL COM DISC REL COM DISC REL COM REL COM
302
(05/98)

Typical location Cause No. 70 Class 100 Value 0110 Cause name Only restricted digital information bearer capability is available Service or option not implemented, unspecified Invalid call reference value 5.8.3.2 a) 5.8.3.2 b) 5.8.3.2 f) 82 101 0010 Identified channel does not exist A suspended call exists, but this call identity does not Call identity in use No call suspended Call having the requested call identity has been cleared Channel identity 5.1.4 LU, LN LU, LN LU, LN LN REL REL COM REL COM STAT DISC REL COM RES REJ Diagnostics Reference No procedure (network dependent option) of generation Typical carrying message as identified by receiving side At remote interface At local interface
79
100
1111
81
101
0001
83
101
0011
5.6.5
LN
84 85 86
101 101 101
0100 0101 0110
5.6.3 5.6.5 5.6.5
LN LN LN
SUSP REJ RES REJ RES REJ
303
(05/98)

Typical location Cause No. 88 Class 101 Value 1000 Cause name Incompatible destination Diagnostics Incompatible parameter Reference 5.2.2 5.2.5.1 5.2.5.3 a) B.3.2 B.3.3 C.2 of generation RU Typical carrying message as identified by receiving side At remote interface REL COM At local interface DISC
91
101
1011
Invalid transit network selection
TN LN
DISC DISC REL REL COM REL COM STAT REL REL COM STAT STAT STAT
95 96
101 110
1111 0000
Invalid message, unspecified Mandatory information element is missing Message type non-existent or not implemented Message not compatible with call state or message type non-existent or not implemented
Message type Information element identifier(s)
5.8 5.8.6.1
LN LN, LU
5.8.11 97 110 0001 Message type 5.8.4 5.8.10 5.8.11 5.8.4
LN, LU LU, LN
98
110
0010
Message type
LU, LN
STAT
304
(05/98)

Typical location Cause No. 99 Class 110 Value 0011 Cause name Information element non-existent or not implemented Diagnostics Information element identifier(s) Reference 5.8.7.1 5.8.11 5.8.7.1 100 110 0100 Invalid information element contents Information element identifier(s) 5.8.6.2 of generation LU, LN Typical carrying message as identified by receiving side At remote interface At local interface STAT
LN LU, LN
REL REL COM STAT REL REL COM STAT STAT
5.8.7.2 5.8.11 101 110 0101 Message not compatible with call state Message type 5.8.4
LU, LN LN, LU
5.8.11
LN, LU
DISC REL REL COM DISC
102
110
0110
Recovery on time expiry
Timer number
5.2.4 5.2.5.3 5.6.5 5.3.3 5.3.4 5.3.2 f) 5.3.3 5.6.5
LN
LN LU
REL REL
305
(05/98)
Table I.2/Q.931 Usage of cause values (concluded)

Typical location Cause No. 111 127 Class 110 111 Value 1111 1111 Cause name Protocol error, unspecified Interworking, unspecified Diagnostics Reference 5.8.4 No explicit procedure of generation RN Typical carrying message as identified by receiving side At remote interface At local interface DISC
306
(05/98)
APPENDIX II Example message flow diagrams and example conditions for cause mapping II.1 Example message flow diagrams
Examples of the procedures for the use of the B- and D-channel network connection types and the selection of the appropriate channel types are summarized in Figures II.1 to II.7. These figures are intended to complement the description in the preceding text and do not illustrate all possible situations.
NOTE Not all frames that may be sent across the TA interface may be represented in the following figures.
II.1.1 [] C CA CP D R RC S
Key to the figures Layer 3 CONNECT CONNECT ACKNOWLEDGE CALL PROCEEDING DISCONNECT RELEASE RELEASE COMPLETE SETUP
Q.931 messages
X.25 layer 3 messages Any layer 3 message preceded by X.25 indicates an X.25 layer 3 packet (e.g. X.25 CR means X.25 call request). CA CC CLC CLI CLR CR IC RSR RSC () GTEI A.B SABM SABME Call accepted Call connected Clear confirmation Clear indication Clear request Call request Incoming call Restart request Restart confirmation Layer 2 Group TEI (127) X.25 layer 2 addresses (includes command and response) Set Asynchronous Balanced Mode Set Asynchronous Balanced Mode Extended
Layer 2 frames
(05/98)
307
UA UI I DISC
Unnumbered acknowledgement frame Unnumbered information frame (i.e. using unacknowledged information transfer at layer 2) Information frame Disconnect frame
Layer 2 addresses marked (x, p) indicate that the SAPI element of the frame address is coded for packet type (SAPI = 16) information as described in Recommendation Q.921. Layer 2 addresses marked (x, s) refer to signalling type (SAPI = 0) information. II.2 Example conditions for cause mapping
Figures II.8 through II.16 show example conditions when cause mappings would be utilized between Q.931 and X.25 messages and utilize the specific mappings of Tables 6-5 and 6-6 as shown below. Q.931 failures during call establishment Figure II.8 Figure II.9 Figure II.10 Figure II.11 Figure II.12 Figure II.13 Figure II.14 Figure II.15 Figure II.16 Table 6-5 Table 6-5 Table 6-5 Table 6-5 Table 6-5 Table 6-5 (Note 1) Table 6-5 (Note 2) Table 6-6 Table 6-6
User side failures during X.25 data transfer phase
Network side premature clearing
NOTE 1 This mapping is only needed in the case of the Q.931 message arriving prior to the clearing of the last virtual call. NOTE 2 This situation always results in either an X.25 clear indication packet with cause No. 9, out of order, for switched virtual calls, or an X.25 reset packet with cause No. 9, out of order, for permanent virtual circuits.
308
(05/98)
TE1 X.25 terminal TA SABME(x,s) UA(x,s) These D-channel signalling procedures are not required for semipermanent connections I(x,s)[S, X.25] I(x,s)[CP] I(x,s)[C] I(x,s)[CA] (Note 4) (Note 5) (Note 2) Network Network TA
TE1 X.25 terminal
SABM(B) UA(B) I(B)[X.25 SQ] I(A)[X.25 SF] I(B)[X.25 CR] (Note 1) (Note 6) SABM(A) (Note 7) UA(A) I(A)[X.25 SI] I(B)[X.25 SF] (Note 6) IA[X.25 CC] I(A)[X.25 IC] I(B)[X.25 CA] X.25 procedure over B-channel as specified in 6.3
X.25 procedures over B-channel as specified in 6.3
Data transfer phase

T1137000-91
NOTE 1 When the called side establishes the call using D-channel access, the message sequence will continue as from point <3> in Figure II.3. NOTE 2 If signalling link is not already established. NOTE 3 For packet call offering, the incoming call may be offered to the TA and a B-channel established using the procedure shown in Figures II.5 and II.7. NOTE 4 The network starts timer T320, if implemented. NOTE 5 This message is optional. NOTE 6 The network cancels timer T320, if implemented and running. NOTE 7 The network establishes the Link Layer on the B-channel, if it is not already established as specified in 6.3.
Figure II.1/Q.931 Example message sequence for the ISDN virtual circuit service B-channel access First virtual call set-up in this channel
(05/98)
309
TE1 X.25 [5] terminal Network Network
TE1 X.25 terminal
TA
TA
Data transfer phase I(B)[X.25 CLR] I(A)[X.25 CLC] DISC(B) UA(B) I(A)[X.25 CLI] I(B)[X.25 CLC] DISC(B) UA(B) X.25 procedures over the B-channel
X.25 procedures over the B-channel
(Note 3) <2> (Note 2) (Note 1)
I(x,s)[D] I(x,s)[R] Q.931 procedures (not required for semi-permanent connections) I(x,s)[RC] DISC(x,s) UA(x,s)
(Note 4)
I(y,s)[D] I(y,s)[R] I(y,s)[RC] DISC(y,s)
(Note 5)
UA(y,s)
T1161250-94
NOTE 1 When the cleared side has set up the call using D-channel access, the message sequence at the cleared side will be as from point <4> in Figure II.4. NOTE 2 Clearing of the B-channel may be initiated by the network upon expiry of Timer T320, if implemented (see 6.4). NOTE 3 The network starts Timer T320, if implemented. NOTE 4 The network cancels Timer T320, if implemented and running. NOTE 5 This sequence is only required if the terminal does not wish to continue with further communication.
Figure II.2/Q.931 Example message sequence for the ISDN virtual circuit service B-channel access Last virtual call cleared in this channel
310
(05/98)
TE1 X.25 terminal SABM(B) UA(B) I(B)[X.25 SQ] I(A)[X.25 SF] I(B)[X.25 CR]
TE1 X.25 terminal
TA
Network SABME(x, p) UA(x, p) I(x,p)[X.25 SQ] I(x,p)[X.25 SF] I(x,p)[X.25 SF] (Notes 1, 5) (Note 4) (Note 2)
Network
TA
<3> (Note 3)
X.25 procedures over the D-channel (Note 2)
SABME(y,p) UA(y,p) I(y,p)[X.25 SI] I(y,p)[X.25 SF] (Note 5) I(y,p)[X.25 IC] I(y,p)[X.25 CA]
SABM(A) UA(A) I(A)[X.25 SI] I(B)[X.25 SF] I(A)[X.25 IC] I(B)[X.25 CA] X.25 procedures over the D-channel
I(A)[X.25 CC]
I(x,p)[ X.25 CC]
Data transfer phase
T1137010-91
NOTE 1 When the called side establishes the call using B-channel access, the message sequence will continue as from point <1> in Figure II.1. NOTE 2 If SAPI 16 link is not already established. NOTE 3 The incoming call may be offered to the TA using the procedures shown in Figures II.5 and II.7. NOTE 4 The network starts timer T320, if implemented. NOTE 5 The network cancels timer T320, if implemented and running. NOTE 6 Not shown in the diagram; it is a possible X.25 restart procedure performed after link set-up.
Figure II.3/Q.931 Example message sequence for the ISDN virtual circuit service D-channel access First virtual call set-up in this SAPI = 16 link
(05/98)
311
TE1 X.25 [5] terminal
TE1
TA
Network
Network
TA
X.25 terminal
Data transfer phase I (B) [X.25 CLR] I (x,p) [X.25 CLR] (Note 1) (Note 3) I (A) [X.25 CLC] I (x,p) [X.25 CLC] DISC(B) UA(B) DISC(x,p) UA(x,p) (Note 4) (Note 2) (Note 5) <4> I (y,p) [X.25CLI] I (y,p) [X.25CLC] DISC(y,p) UA(y,p) I (A) [X.25 CLI] I (B) [X.25 CLC] DISC(B) UA(B) X.25 procedures over the D-channel
X.25 procedures over the D-channel
T1161260-94
NOTE 1 When the cleared side has set up the call using B-channel access, the message sequence at the cleared side will be as from point <2> in Figure II.2. NOTE 2 This sequence is only required if the X.25 DTE does not wish to continue with further communications. NOTE 3 The network starts timer T320, if implemented. NOTE 4 The network cancels timer T320, if implemented and running. NOTE 5 Link layer release may be initiated by the network upon expiry of Timer T320, if implemented (see 6.4).
Figure II.4/Q.931 Example message sequence for the ISDN virtual circuit service D-channel access Last virtual call cleared in this SAPI = 16 link
312
(05/98)
TE1 Network UI(GTEI,S) [SETUP, channel (B,D,B/D)] These signalling procedures are over the D-channel I(x,s) [CONNECT, new B]
(Note 1) I(x,s) [CONNECT ACKNOWLEDGE]
TA
X.25 terminal
SABM(A) UA(A) I(A) [X.25 SI] I(B) [X.25 SF] (Note 2) I(A) [X.25 IC] I(B) [X.25 CA]
X.25 procedures over a new B-channel as specified in 6.3
Data Transfer Phase

T1137020-91
NOTE 1 The network starts Timer T320, if implemented. NOTE 2 The network cancels Timer T320, if implemented and running.
Figure II.5/Q.931 Example of incoming call offering procedures using signalling on SAPI = 0 link Terminal accepts call on a new B-channel
(05/98)
313
TE1 Network UI(GTEI,S) [SETUP, channel (B,D,B/D)] These Q.931 procedures are over the D-channel I(x,s) [CONNECT, established B] I(x,s) [RELEASE, Cause No.7 ] I(x,s) [RELEASE COMPLETE ] (Note 1) SABM(A) UA(A) I(A) [X.25 SI] X.25 [5] procedures over an established B-channel as specified in 6.3 I(B) [X.25 SF] (Note 2) (A) [X.25 IC] I(B) [X.25 CA] TA X.25 terminal
Data Transfer Phase

T1161270-94
NOTE 1 The network establishes the link layer in the B-channel if it is not already established (see 6.3). NOTE 2 The network cancels Timer T320, if implemented and running.
Figure II.6/Q.931 Example of incoming call offering procedures using signalling on SAPI = 0 link Terminal accepts call on a established B-channel
314
(05/98)
TE1 Network UI(GTEI,S) [SETUP, channel (B,D,B/D)] These Q.931 procedures are over the D-channel I(x,s) [CONNECT, D] I(x,s) [RELEASE, Cause No. 7 ] I(x,s) [RELEASE COMPLETE ] (Note 1) SABME (y,p) UA(y,p) I(x,p) [X.25 SI] X.25 [5] procedures over an established B-channel as specified in 6.3 I(x,p) [X.25 SF] (Note 2) I(x,p) [X.25 IC] I(x,p) [X.25 CA] SABM(A) UA(A) IA(A) [X.25 SI] I(B) [X.25 SF] TA X.25 terminal
Data Transfer Phase
T1145310-92
NOTE 1 The network establishes the link layer in the B-channel if it is not already established (see 6.3). The network starts Timer T320, if implemented. NOTE 2 The network cancels Timer T320, if implemented and running.
Figure II.7/Q.931 Example of incoming call offering procedures using signalling on SAPI = 0 link Terminal accepts call on the D-channel
Called user e.g. user busy, no channel available (includes no LCN available or throughput unavailable)
ET/PH X.25 IC X.25 CLI (Cause)
T1161280-94
Figure II.8/Q.931 Undeliverable call
(05/98)
315
Called user Q.931 SETUP Erroneous message (Note 1) Q.931 clearing message (Cause)
ET/PH X.25 IC
X.25 CLI (Cause)
(Note 2)
These causes are related as in Table 6-5

T1161290-94
NOTE 1 This figure only applies to the case where the erroneous message results in a Q.931 clearing message. See 6.4.3 for more information. NOTE 2 This message would be sent after the expiry of timer T303 on a multipoint interface.
Figure II.9/Q.931 Erroneous message (e.g. format error)
Called user Q.931 SETUP Q.931 SETUP
ET/PH X.25 IC
X.25 CLI (Cause)
(Note)
T1161300-94
NOTE This message is sent after the second expiry of timer T303.
Figure II.10/Q.931 No responding user
316
(05/98)
Called user Q.931 SETUP Q.931 ALERTING
ET/PH X.25 IC
T301 expiry
Q.931 RELEASE (Cause)
X.25 CLI (Cause)
(Note)
These causes are related as in Table 6-5 NOTE This message is sent after the expiry of timer T301.
T1161310-94
Figure II.11/Q.931 Expiry of timer T301
Called user Q.931 SETUP Q.931 RELEASE COMPLETE (Cause)
ET/PH X.25 IC
X.25 CLI (Cause)
(Note)

T1161320-94
NOTE This message would be sent after the expiry of T303 when on a multipoint interface.
Figure II.12/Q.931 Call rejection by called party
(05/98)
317
Called user
ET/PH
X.25 [5] data transfer phase Q.931 clearing message (Cause) X.25 CLI (Cause)

T1161330-94
Figure II.13/Q.931 Q.931 clearing during X.25 data transfer phase
Called user
ET/PH
X.25 data transfer phase Q.931 RESTART X.25 CLI (Note 1) (Cause) -orX.25 RESET INDICATION (Cause) (Notes 1, 2)
T1161340-94
NOTE 1 This cause parameter in the X.25 packet will indicate out of order with diagnostic value 0. NOTE 2 For permanent virtual circuits only.
Figure II.14/Q.931 Q.931 RESTART during X.25 data transfer phase
318
(05/98)
Called user
ET/PH X.25 IC Q.931 SETUP Q.931 CONNECT Q.931 DISCONNECT (Cause) X.25 CLI (Cause)

T1161350-94
Figure II.15/Q.931 Premature clearing of the virtual call (e.g. expiry of X.25 timer T21)
Called user
ET/PH X.25 IC Q.931 SETUP Q.931 CONNECT
Q.931 CONNECT ACKNOWLEDGE Q.931 DISCONNECT (Cause) X.25 CLI (Cause)

T1161360-94
NOTE This is the case when an X.25 incoming call packet has NOT been delivered.
Figure II.16/Q.931 Premature clearing of the virtual call
(05/98)
319
APPENDIX III Summary of assigned information element identifier and message type code points for the Q.93x-series and Q.95x-series of Recommendations Table III.1/Q.931 Information element codepoints
Recommendation reference Bits 8 7 6 5 4 3 2 1 1 : : : - - - 0 0 0 0 0 1 0 : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 1 1 0 : 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 1 0 0 1 1 : 0 0 0 0 0 1 1 1 1 1 1 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 0 : 0 0 1 1 1 0 0 1 1 1 1 0 0 0 1 1 1 0 0 0 0 1 1 1 1 0 0 0 : 0 1 0 1 1 0 1 0 0 1 1 0 1 1 0 0 1 0 0 1 1 0 0 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 1 0 0 1 : 0 0 0 0 1 0 0 0 1 0 0 0 0 1 0 1 0 0 0 0 0 0 1 0 1 0
Single octet information elements: Reserved Shift More data Sending complete Congestion level Repeat indicator Variable length information elements: Segmented message Bearer capability Cause Connected address Extended facility Call identity Call state Channel identification Data link connection identifier Facility Progress indicator Network-specific facilities Terminal capabilities Notification indicator Display Date/time Keypad facility Keypad echo Information request Signal Switchhook Feature activation Feature indication Service profile identification Endpoint identifier Information rate Q.931 Q.931 Q.931 Q.931 Q.931 Q.931 Q.931 Q.931 Q.931 (Note 1) Q.932 Q.931 Q.931 Q.931 Q.933 Q.932 Q.931 Q.931 (Note 1) Q.931 Q.931 Q.931 Q.931 (Note 1) Q.932 [4] Q.931 (Note 1) Q.932 Q.932 Q.932 Q.932 Q.931
320
(05/98)
Table III.1/Q.931 Information element codepoints (concluded)

Recommendation reference Bits 8 7 1 1 1 1 1 0 : 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 6 0 0 0 0 0 : 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 5 0 0 0 0 0 : 0 0 0 0 0 0 0 1 1 1 1 0 0 1 1 1 1 1 1 1 1 1 1 4 0 0 0 0 0 : 0 0 1 1 1 1 1 0 0 0 0 1 1 0 0 0 0 1 1 1 1 1 1 3 0 0 0 1 1 : 1 1 0 0 0 1 1 0 0 0 1 1 1 0 0 1 1 0 0 1 1 1 1 2 0 1 1 0 0 : 1 1 0 0 1 0 0 0 0 1 1 0 0 0 0 0 1 0 0 0 0 1 1 1 1 0 1 0 1 : 0 1 0 1 0 0 1 0 1 1 1 0 1 0 1 0 0 0 1 0 1 0 1
Precedence level End-to-end transit delay Transit delay selection and indication Packet layer binary parameters Packet layer window size Variable length information elements: Packet size Closed user group Link layer core parameters Link layer protocol parameters Reverse charging indication Connected number Connected subaddress X.213 priority Report type Link integrity verification PVC status Calling party number Calling party subaddress Called party number Called party subaddress Redirecting number Redirection number Transit network selection Restart indicator Low layer compatibility High layer compatibility User-user Escape for extension
Q.955 (clause 3) Q.931 Q.931 Q.931 Q.931 Q.931 Q.931 Q.933 Q.933 Q.931 Q.951-series [85] Q.951 Q.933 Q.933 Q.933 Q.933 Q.931 Q.931 Q.931 Q.931 Q.931, Q.952 [86] Q.952 Q.931 Q.931 Q.931 Q.931 Q.931 Q.931
NOTE 1 These codepoints are reserved to ensure backward compatibility with earlier versions of this Recommendation. NOTE 2 All reserved values with bits 5-8 coded "0000" are for future information elements for which comprehension by the user is required (see 5.8.7.1).
(05/98)
321
Table III.2/Q.931 Message type codepoints

Recommendation reference Bits 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 0 0 0 - - - - 0 0 0 0 1 0 0 0 1 0 0 0 0 1 1 0 0 1 0 1 0 0 1 1 1 0 1 1 0 1 0 1 1 1 1 0 0 1 - - - - 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 0 1 0 0 1 1 0 0 1 0 0 0 0 1 1 0 1 0 1 1 1 0 1 0 0 0 0 1 0 0 0 1 1 0 0 1 1 1 0 1 1 1 0 1 0 - - - - 0 0 0 0 0 0 0 1 0 1 0 0 1 1 0 0 1 0 0 0 0 1 1 0 1 0 1 1 1 0 1 1 0 1 0 0 1 1 - - - - 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0
Escape to nationally specific message types Call establishment messages: ALERTING CALL PROCEEDING PROGRESS SETUP CONNECT SETUP ACKNOWLEDGE CONNECT ACKNOWLEDGE Call information phase messages: USER INFORMATION SUSPEND REJECT RESUME REJECT HOLD SUSPEND RESUME HOLD ACKNOWLEDGE SUSPEND ACKNOWLEDGE RESUME ACKNOWLEDGE HOLD REJECT RETRIEVE RETRIEVE ACKNOWLEDGE RETRIEVE REJECT Call clearing messages: DETACH DISCONNECT RESTART DETACH ACKNOWLEDGE RELEASE RESTART ACKNOWLEDGE RELEASE COMPLETE Miscellaneous messages: SEGMENT FACILITY REGISTER
Q.931 Q.931 Q.931 Q.931 Q.931 Q.931 Q.931 Q.931 Q.931 Q.931 Q.931 Q.932 [4] Q.931 Q.931 Q.932 Q.931 Q.931 Q.932 Q.932 Q.932 Q.932 (Note) Q.931 Q.931 (Note) Q.931 Q.931 Q.931 Q.931 Q.932 [4] Q.932
322
(05/98)
Table III.2/Q.931 Message type codepoints (concluded)

Recommendation reference Bits 8 7 6 5 4 3 2 1 0 1 0 0 0 0 1 0 1 0 0 1 1 0 0 0 1 1 1 0 1 0 0 0 0 1 0 0 1 0 1 0 1 0 0 1 0 1 0 1 1 1 0 0 1 1 1 0 1 1 1 1 1 0 1
CANCEL ACKNOWLEDGE FACILITY ACKNOWLEDGE REGISTER ACKNOWLEDGE NOTIFY CANCEL REJECT FACILITY REJECT REGISTER REJECT STATUS ENQUIRY CONGESTION CONTROL INFORMATION STATUS
(Note) (Note) (Note) Q.931 (Note) (Note) (Note) Q.931 Q.931 Q.931 Q.931
NOTE These codepoints are reserved to ensure backward compatibility with earlier versions of this Recommendation.
III.1 ABM ACK
Acronyms used in this Recommendation Asynchronous Balanced Mode (of HDLC) Acknowledgement Adaptive Differential Pulse Code Modulation Authority and Format Identifier Asynchronous Response Mode (of HDLC) Access Unit Bearer Capability Binary Coded Decimal Indicated B-channel An idle B-channel Bi A B-Channel in use Connection Endpoint Identifier Connection Endpoint Suffix Circuit Switched Public Data Network The D-channel Direct-Dialling-In Data Link Connection Identifier (see Recommendations Q.920 and Q.921) Domain Specific Part
ADPCM AFI ARM AU BC BCD Bi Bi` Bj CEI CES CSPDN D DDI DLCI DSP
(05/98)
323
DTE HDLC HLC I IA5 IDI IE IEC ISDN ISO IWF IWU LAN LAPB LAPD LLC LLI NACK NIC NRM NSAP NT2 OSI PABX PCM PH PSPDN PSTN PVC RDTD RSC RSI RSR SABME SAPI SDL
Data Terminal Equipment High Level Data Link Control (procedures) High Layer Compatibility Information (frame) International Alphabet No. 5 (defined by ITU-T) Initial Domain Identifier Information Element International Electrotechnical Commission Integrated Services Digital Network International Organization for Standardization Interworking Function Interworking Unit Local Area Network Link Access Protocol-Balanced Link Access Protocol on the D-channel Low Layer Compatibility Logical Link Identifier (see Recommendation Q.921) Negative Acknowledgement Network Independent Clock Normal Response Mode (of HDLC) Network Service Access Point Network Termination of type two Open Systems Interconnection Private Automatic Branch Exchange Pulse Code Modulation Packet Handler Packet Switched Public Data Network Public Switched Telephone Network Permanent Virtual Circuit Restricted Differential Time Delay Restart confirmation Restart indication Restart request Set Asynchronous Balanced Mode Extended (frame) Service Access Point Identifier (see Recommendation Q.921) Specification and Description Language
324
(05/98)
TA TE1 TE2 TEI TID UDI UDI-TA UI USID VC III.2 [1] [2] [3] [4] [5]
Terminal Adaptor (see Recommendation I.411) Terminal Equipment of type 1 (see Recommendation I.411) Terminal Equipment of type 2 (see Recommendation I.411) Terminal Endpoint Identifier (see Recommendations Q.920 and Q.921) Terminal identifier Unrestricted Digital Information Unrestricted Digital Information with Tones/Announcements Unnumbered Information (frame) User Service Identificator (Switched) Virtual Circuit References ITU-T Recommendation Q.930/I.450 (1993), ISDN user-network interface layer 3 General aspects. CCITT Recommendation I.412 (1988), ISDN user-network interfaces Interface structures and access capabilities. ITU-T Recommendation Q.921/I.441 (1997), ISDN user-network interface Data link layer specification. ITU-T Recommendation Q.932 (1998), Digital subscriber signalling system No. 1 Generic procedures for the control of ISDN supplementary services. ITU-T Recommendation X.25 (1996), Interface between Data Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated circuit. ITU-T Recommendations I.231 series, Circuit mode bearer service categories. ITU-T Recommendation V.110/I.463 (1996), Support of data terminal equipments with V-series type interfaces by an integrated services digital network. ITU-T Recommendation X.30/I.461 (1993), Support of X.21, X.21 bis and X.20 bis based Data Terminal Equipments (DTEs) by an Integrated Services Digital Network (ISDN). ITU-T Recommendation V.120/I.465 (1996), Support by an ISDN of data terminal equipment with V-series type interfaces with provision for statistical multiplexing. CCITT Recommendation G.711 (1988), Pulse Code Modulation (PCM) of voice frequencies. CCITT Recommendation G.721 (1988 Withdrawn, replaced by G.726), 32 kbit/s adaptive differential pulse code modulation (ADPCM). CCITT Recommendation G.722 (1988), 7 kHz audio-coding within 64 kbit/s. ITU-T Recommendation H.261 (1993), Video codec for audiovisual services at p 64 kbit/s. ITU-T Recommendation X.31/I.462 (1995), Support of packet mode terminal equipment by an ISDN. CCITT Recommendation I.460 (1988), Multiplexing, rate adaption and support of existing interfaces.
[6] [7] [8] [9] [10] [11] [12] [13] [14] [15]
(05/98)
325
[16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26]
CCITT Recommendation V.6 (1988 Withdrawn), Standardization of data signalling rates for synchronous data transmission on leased telephone-type circuits. ITU-T Recommendation X.1 (1996), International user classes of service in, and categories of access to public data networks and Integrated Services Digital Networks (ISDNs). CCITT Recommendation I.330 (1988), ISDN numbering and addressing principles. ITU-T Recommendation E.164 (1997), The international public telecommunication numbering plan. CCITT Recommendation E.163 (1988 Now superseded by E.164), Numbering plan for the international telephone service. ITU-T Recommendation X.121 (1996), International numbering plan for public data networks. ITU-T Recommendation F.69 (1994), The international telex service Service and operational provisions of telex destination codes and telex network identification codes. ITU-T Recommendation X.213 (1995) | ISO/IEC 8348:1996, Information technology Open Systems Interconnection Network service definition. ISO/IEC 8348:1988, Information processing systems Data communications Network service definition Addendum 2: Network layer addressing. CCITT Recommendation I.334 (1988), Principles relating ISDN numbers/sub-addresses to the OSI reference model network layer addresses. CCITT Recommendation X.21 (1992), Interface between Data Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for synchronous operation on public data networks. ITU-T Recommendation I.431 (1993), Primary rate user-network interface Layer 1 specification. ITU-T Recommendation T.62 (1993), Control procedures for teletex and Group 4 facsimile services. CCITT Recommendation T.503 (1991), A document application profile for the interchange of Group 4 facsimile documents. ITU-T Recommendation T.501 (1993), Document application profile MM for the interchange of formatted mixed mode documents. ITU-T Recommendation T.502 (1994), Document application profile PM-11 for the interchange of simple structure, character content documents in processable and formatted forms. ITU-T Recommendation T.70 (1993), Network-independent basic transport service for the telematic services. ITU-T Recommendation T.504 (1993), Document application profile for videotex interworking. ITU-T Recommendations I.241-series, Teleservices supported by an ISDN. CCITT Recommendation G.725 (1988), System aspects for the use of the 7 kHz audio codec within 64 kbit/s. ISO 1745:1975, Information processing Basic mode control procedures for data communication systems.
[27] [28] [29] [30] [31]
[32] [33] [34] [35] [36]
326
(05/98)
[37] [38]
CCITT Recommendation T.71 (1988), Link Access Protocol Balanced (LAPB) extended for half-duplex physical level facility. ISO/IEC 4335:1993, Information technology Telecommunications and information exchange between systems High-level Data Link Control (HDLC) procedures Elements of procedures. ISO/IEC 8802-2:1998, Information technology Telecommunications and information exchange between systems Local and metropolitan area networks Specific requirements Part 2: Logical link control. ITU-T Recommendation X.75 (1996), Packet-switched signalling system between public networks providing data transmission services. ISO/IEC 8208:1995, Information technology Data communications X.25 Packet Layer Protocol for Data Terminal Equipment. ISO/IEC 8348:1987, Information processing systems Data communications Network service definition. ISO/IEC 8473:1988, Information processing systems Data communications Protocol for providing the connectionless-mode network service. CCITT Recommendation X.244 (1988 Withdrawn), Procedure for the exchange of protocol identification during virtual call establishment on packet switched public data networks. ITU-T Recommendation Q.920/I.440 (1993), ISDN user-network interface data link layer General aspects. ITU-T Recommendation I.430 (1995), Basic user-network interface Layer 1 specification. CCITT Recommendation I.230 (1988), Definition of bearer service categories. CCITT Recommendation I.240 (1988), Definition of teleservices. CCITT Recommendation T.50 (1992), International Reference Alphabet (IRA) (Formerly International Alphabet No. 5 or IA5) Information technology 7-bit coded character set for information exchange. ISO/IEC 646:1991, Information technology ISO 7-bit coded character set for information interchange. ITU-T Recommendations on Integrated services digital network (ISDN). ITU-T Recommendation V.110/I.463 (1996), Support of data terminal equipments with V-series type interfaces by an integrated services digital network (ISDN). CCITT Recommendation Q.931 (1988), ISDN user-network interface layer 3 specification for basic call control. ITU-T Recommendation Q.957, Stage 3 description for additional information transfer supplementary services using DSS1. CCITT Recommendation V.21 (1984), 300 bits per second duplex modem standardized for use in the general switched telephone network. CCITT Recommendation V.22 (1988), 1200 bits per second duplex modem standardized for use in the general switched telephone network and on point-to-point 2-wire leased telephone-type circuits.
[39]
[40] [41] [42] [43] [44]
[45] [46] [47] [48] [49]
[50] [51] [52] [53] [54] [55] [56]
(05/98)
327
[57]
CCITT Recommendation V.22 bis (1988), 2400 bits per second duplex modem using frequency division technique standardized for use in the general switched telephone network and on point-to-point 2-wire leased telephone-type circuits. CCITT Recommendation V.23 (1988), 600/1200-baud modem standardized for use in the general switched telephone network. CCITT Recommendation V.26 (1984), 2400 bits per second modem standardized for use on 4-wire leased telephone-type circuits. CCITT Recommendation V.26 bis (1984), 2400/1200 bits per second modem standardized for use in the general switched telephone network. CCITT Recommendation V.26 ter (1988), 2400 bits per second duplex modem using the echo cancellation technique standardized for use on the general switched telephone network and on point-to-point 2-wire leased telephone type circuits. CCITT Recommendation V.27 (1984), 4800 bits per second modem with manual equalizer standardized for use on leased telephone-type circuits. CCITT Recommendation V.27 bis (1984), 4800/2400 bits per second modem with automatic equalizer standardized for use on leased telephone-type circuits. CCITT Recommendation V.27 ter (1984), 4800/2400 bits per second modem standardized for use in the general switched telephone network. CCITT Recommendation V.29 (1988), 9600 bits per second modem standardized for use on point-to-point 4-wire leased telephone-type circuits. ITU-T Recommendation V.32 (1993), A family of 2-wire, duplex modems operating at data signalling rates of up to 9600 bit/s for use on the general switched telephone network and on leased telephone-type circuits. ITU-T Recommendation Q.850 (1998), Usage of cause and location in the digital subscriber signalling system No. 1 and the Signalling System No. 7 ISDN user part. ITU-T Recommendation F.182 (1996), Operational provisions for the international public facsimile service between subscribers with Group 3 facsimile machines (Telefax 3). ITU-T Recommendation F.184 (1996), Operational provisions for the international public facsimile service between subscribers stations with Group 4 facsimile machines (Telefax 4). CCITT Recommendation F.230 (1988 Withdrawn), Service requirements unique to Mixed Mode (MM) used within the teletex service. ITU-T Recommendation F.220 (1993 Withdrawn), Service requirements unique to the processable mode number eleven (PM11) used within the teletex service. CCITT Recommendation F.200 (1992 Withdrawn), Teletex service. ITU-T Recommendation F.300 (1993), Videotex service. ITU-T Recommendation T.102 (1993), Syntax-based videotex end-to-end protocols for the circuit mode ISDN. ITU-T Recommendation T.101 (1994), International interworking for videotex services. CCITT Recommendation F.60 (1992), Operational provisions for the international telex service. ITU-T Recommendations X.400-series, Message Handling Systems (MHS).
[58] [59] [60] [61]
[62] [63] [64] [65] [66]
[67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77]
328
(05/98)
[78] [79] [80] [81]
ITU-T Recommendations X.200-series, Open Systems Interconnection (OSI): Model and notation. CCITT Recommendation F.721 (1992), Videotelephony teleservice for ISDN. ITU-T Recommendations F.700-series, Audiovisual services. ISO/IEC 8878:1992, Information technology Telecommunications and information exchange between systems Use of X.25 to provide the OSI Connection-mode Network Service. ISO/IEC TR 9577:1996, Information technology Protocol identification in the network layer. ITU-T Recommendation Q.95x-series, Stage 3 description for number identification supplementary services using DSS1. ITU-T Recommendations Q.953-series, Stage 3 description for call completion supplementary services using DSS1. CCITT Recommendation Q.951-series, Stage 3 description for number identification supplementary services using DSS1. ITU-T Recommendation Q.952 (1993), Stage 3 service description for call offering supplementary services using DSS1. ITU-T Recommendation V.110 (1996), Support of data terminal equipments with V-series type interfaces by an integrated services digital network (in relation to 38.4 kbit/s). ITU-T Recommendation V.14 (1993), Transmission of start-stop characters over synchronous bearer channels. ITU-T Recommendation V.110 (1996), Support of data terminal equipments with V-series type interfaces by an integrated services digital network (in relation to 28.8 kbit/s and 24 kbit/s). ITU-T Recommendation V.34 (1998), A modem operating at data signalling rates of up to 33 600 bit/s for use on the general switched telephone network and on leased point-to-point 2-wire telephone-type circuits. CCITT Recommendation F.720 (1992), Videotelephony services General. ITU-T Recommendation H.223 (1996), Multiplexing protocol for low bit rate multimedia communication. ITU-T Recommendation H.245 (1998), Control protocol for multimedia communication. ITU-T Recommendation F.702 (1996), Multimedia conference services. ITU-T Recommendation F.700 (1996), Framework Recommendation for audiovisual multimedia services. ITU-T Recommendation X.223 (1993), Use of X.25 to provide the OSI connection-mode network service for ITU-T applications.. ITU-T Recommendation F.731 (1997), Multimedia conference services in the ISDN.
[82] [83] [84] [85] [86] [87] [88] [89]
[90]
[91] [92] [93] [94] [95] [96] [97]
(05/98)
329
ITU-T RECOMMENDATIONS SERIES

Series A Series B Series C Series D Series E Series F Series G Series H Series I Series J Series K Series L Series M Series N Series O Series P Series Q Series R Series S Series T Series U Series V Series X Series Y Series Z Organization of the work of the ITU-T Means of expression: definitions, symbols, classification General telecommunication statistics General tariff principles Overall network operation, telephone service, service operation and human factors Non-telephone telecommunication services Transmission systems and media, digital systems and networks Audiovisual and multimedia systems Integrated services digital network Transmission of television, sound programme and other multimedia signals Protection against interference Construction, installation and protection of cables and other elements of outside plant TMN and network maintenance: international transmission systems, telephone circuits, telegraphy, facsimile and leased circuits Maintenance: international sound programme and television transmission circuits Specifications of measuring equipment Telephone transmission quality, telephone installations, local line networks Switching and signalling Telegraph transmission Telegraph services terminal equipment Terminals for telematic services Telegraph switching Data communication over the telephone network Data networks and open system communications Global information infrastructure Programming languages

T-Rec-Q 931-199805-I!!pdf-E

Uploaded by

Copyright:

Available Formats

T-Rec-Q 931-199805-I!!pdf-E

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

T-Rec-Q 931-199805-I!!pdf-E

Uploaded by

Copyright:

Available Formats

INTERNATIONAL TELECOMMUNICATION UNION

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

ITU-T Recommendation Q.931

ITU-T Q-SERIES RECOMMENDATIONS SWITCHING AND SIGNALLING

For further details, please refer to ITU-T List of Recommendations.

Packet-mode access connections ................................................................................

Temporary signalling connections ..............................................................................

States associated with the global call reference ..........................................................

4.6.7 4.6.8 4.6.9 5 5.1

Call rearrangements .................................................................................................... 5.6.1 5.6.2

5.6.3 5.6.4 5.6.5 5.6.6 5.6.7 5.7 5.8

X.25 virtual call establishment and release.................................................................

Call establishment at the destination interface............................................................ 8.2.1 8.2.2 8.2.3

8.3 8.4 8.5 9 9.1 9.2

Interworking with existing networks ..........................................................................

Timers for call establishment...................................................................................... Call collisions .............................................................................................................

Annex G Use of progress indicators .....................................................................................

Information classification ........................................................................................... I.3.1 I.3.2 I.3.3

Scenarios outside the scope of ISDN standardization ................................................ I.4.1 I.4.2

Application to interface structures

Call states at the user side of the interface

further explanatory Notes, as necessary.

Messages for circuit-mode connection control

Table 3-15/Q.931 SETUP message content (concluded)

Messages for packet-mode connection control

NOTE Included by the called user to provide additional information.

Table 3-31/Q.931 SETUP message content (concluded)

Messages for user signalling bearer service control

Table 3-40/Q.931 INFORMATION message content (concluded)

Table 3-42/Q.931 RELEASE COMPLETE message content

Table 3-43/Q.931 SETUP message content (concluded)

Messages with the global call reference

General message format and information elements coding

Figure 4-1/Q.931 General message organization example

Figure 4-2/Q.931 Protocol discriminator

Table 4-1/Q.931 Protocol discriminator

Figure 4-3/Q.931 Call reference information element

Figure 4-4/Q.931 Dummy call reference

Figure 4-5/Q.931 Examples of the encoding for global call reference

Figure 4-6/Q.931 Message type

Table 4-2/Q.931 Message types

Other information elements Coding rules

7 6 5 Information element identifier a)

3 2 1 Contents of information element

Figure 4-7/Q.931 Formats of information elements

Table 4-3/Q.931 Information element identifier coding (concluded)

34 3 6 11 5 3 4 4 7 3 (Note 4) 23 (Note 4) 23 (Note 4) (Note 4) 3 18 5 35/131

Figure 4-8/Q.931 Information element format using escape for extension

New codeset identification

"0" in this position indicates locking shift

Figure 4-9/Q.931 Locking Shift information element

Table 4-4/Q.931 Locking Shift information element

"1" in this position indicates non-locking shift

Figure 4-10/Q.931 Non-locking Shift information element

Table 4-5/Q.931 Non-locking Shift information element

Coding standard Transfer mode

Number of data bits Modem type

Figure 4-11/Q.931 Bearer capability information element

Table 4-6/Q.931 Bearer capability information element