ANNEX A (to Recommendation Q.931) User side and network side SDL diagrams ANNEXES B TO O AND APPENDICES I, II AND II OF RECOMMENDATION Q.931 Page Annex B: Compatibility checking .......................................... 7 Annex C: Transit network selection ....................................... 11 Annex D: Extensions for symmetric call operation ......................... 12 Annex E: Network specific facility selection ............................. 15 Annex F: D Channel backup procedures ..................................... 16 Annex G: Cause definitions ............................................... 19 Annex H: Examples of information elements coding ......................... 26 Annex I: Use of progress indicators ...................................... 34 Annex J: Examples of cause value and location for busy condition ......... 35 Annex K: Message segmentation procedures ................................. 38 Annex L: Low layer information coding principles ......................... 48 Annex M: Low layer compatibility negotiation ............................. 57 Annex N: Procedures for establishment of bearer connection prior to call acceptance ................................................. 59 Page Annex O: Optional procedures for bearer service change ................... 60 Appendix I - Use of cause values in call control procedures............... 61 Appendix II - Example message flow diagrams and example conditions for cause mappings in packet communications..................... 73 Appendix III - Summary of assigned information element identifier and message type code points for the Q.93-Series of Recommendations............................................ 87 Annex B (to Recommendation Q.931) Compatibility checking B.1 Introduction This annex describes the various compatibility checks which should be carried out to ensure that the best matched user and network capabilities are achieved on a call within an ISDN. This annex also covers interworking with existing networks. Three different processes of compatibility checking shall be performed: i) at the user-to-network interface on the calling side (see  B.2); ii) at the network-user interface on the called side (see  B.3.2); and iii) user-to-user (see  B.3.3). Note - In this context and throughout this annex the term "called user" is the end point entity which is explicitly addressed. This may be an addressed interworking unit (IWU), see I.500 Series Recommendations. For details on the coding of the information required for compatibility checking, see Annex L. 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 checking In this section, the word "check" means that the user examines the contents of the specified information element. B.3.1 Compatibility checking with addressing information If an incoming SETUP message is offered with addressing information (i.e., either DDI or sub-addressing or the appropriate part of the called party number, e.g., for DDI) the following actions will occur: a) if a number (e.g. for DDI) or sub-address is assigned to a user, then the information in a Called party number or Called party sub-address information element of the incoming call shall be checked by the user against the corresponding part of the number assigned to the user (e.g., for DDI) or the user's own sub-address. In the case of a mismatch, the user shall ignore the call. In the case of match, the compatibility checking described in  B.3.2 to B.3.3 will follow; b) if a user has no DDI number or sub-address, then the Called party number and Called party sub-address information element shall be ignored. The compatibility checking described in  B.3.2 and B.3.3 will follow. Note 1 - According to the 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 DDI number/sub-address 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 a DDI number or sub-address. 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". 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). 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 L, 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". With regard to the presence or absence of the High layer compatibility and Low layer compatibility information elements, two cases arise: a) Compatibility assured with the available description of the call This is when all terminal equipment implement (i.e. understand the contents of) the High layer compatibility and Low layer compatibility information elements. Thus, based on the High layer compatibility and Low layer compatibility information element encoding, they are capable of accepting a call for which they have the requested functionality. b) Compatibility not assured with the available description of the call This is when all or some of the terminal equipment do not recognize (i.e. ignore) either the High layer compatibility or Low layer compatibility information elements. Without careful configuration or administration at the user's installation, there is a danger that a terminal equipment which has incorrect functionality will accept the call. Therefore, in order to assure compatibility with incoming calls, it is recommended that the terminal equipment check the Low layer compatibility and High layer compatibility information elements. Note - Some terminal equipment, upon bilateral agreement with other users or in accordance with other standards (e.g. Recommendation X.213, [23]) may employ the User-user information element for additional compatibility checking. Such terminal equipment shall check the User-user information element in a manner identical to that described here for the High layer compatibility information element "compatibility assured" case. B.3.4 User action tables The following tables 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. TABLE B-1/Q.931 Bearer capability compatibility checking 旼컴컴컴컴컴컴쩡컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴컴컴컴커 � BC � Point-to-point � Broadcast � � mandatory � data link � data link � 쿶nfo element � � (Note 1) � 쳐컴컴컴컴컴컴탠컴컴컴컴컴컴컴컵컴컴컴컴컴컴컴컴컴컴캑 � � � � 쿎ompatible 쿛roceed � Proceed � 쳐컴컴컴컴컴컴탠컴컴컴컴컴컴컴컵컴컴컴컴컴쩡컴컴컴컴캑 쿔ncompatible 쿝eject (5.2.5.1)쿔gnore 쿝eject � � � �(5.2.5.1a)�(5.2.5.1b)� � � �(Note 2) �(Note 2) � 읕컴컴컴컴컴컴좔컴컴컴컴컴컴컴컨컴컴컴컴컴좔컴컴컴컴켸 TABLE B-2/Q.931 Low layer and high layer compatibility checking: compatibility assured with the available description of the call 旼컴컴컴컴컴컴쩡컴컴컴컴컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� 쿗LC/HLC � Point-to-point � Broadcast � 쿬ompatibility� data link � data link � 쿪ssured � (Note 1) � (Note 1) � 쳐컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� 쿎ompatible � Accept � Accept � 쳐컴컴컴컴컴컴탠컴컴컴컴컫컴컴컴컴컴컴컵컴컴컴컴컴쩡컴컴컴컴쩡컴컴컴컴컴컴� 쿔ncompatible � Reject 쿌ttempt low 쿔gnore 쿝eject 쿌ttempt � � � (5.2.5.1)쿹ayer �(5.2.5.1a)�5.2.5.1b)쿹ow layer � � � 쿬ompatibility�(Note 2) �(Note 2) 쿬ompatibility� � � 쿻egotiation � � 쿻egotiation � � � �(Annex M) � � �(Annex M) � 읕컴컴컴컴컴컴좔컴컴컴컴컨컴컴컴컴컴컴컨컴컴컴컴컴좔컴컴컴컴좔컴컴컴컴컴컴� TABLE B-3/Q.931 Low layer and high layer compatibility checking: compatibility not assured with the available description of the call 旼컴컴컴컴컴컴쩡컴컴컴컴컴컴컴컴컴컴컴컴쩡컴컴컴컴컴컴컴컴컴컴컴컴� 쿗LC/HLC � Point-to-point � Broadcast data � 쿬ompatibility� data link � link � 쿻ot assured � (Note 1) � (Note 1) � 쳐컴컴컴컴컴컴탠컴컴컴컴컫컴컴컴컴컴컴컴탠컴컴컴컴컫컴컴컴컴컴컴컴� 쿓LC or LLC � Accept or쿌ttempt low � Accept or쿌ttempt low � 쿾resent � reject 쿹ayer � reject 쿹ayer � � � (Note 3) 쿬ompatibility � (Note 3) 쿬ompatibility � � � 쿻egotiation � 쿻egotiation � � � �(Annex M) � �(Annex M) � 읕컴컴컴컴컴컴좔컴컴컴컴컨컴컴컴컴컴컴컴좔컴컴컴컴컨컴컴컴컴컴컴컴� Note 1 - For broadcast data link terminal equipment which are explicitly addressed using sub-addressing or DDI, 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 element and would reject the call if incompatible. 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 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 I). 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 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. Annex C (to Recommendation Q.931) 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) avoid routing loops, or b) ensure an appropriate business relationship exists between selected networks, or c) 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. Annex D (to Recommendation Q.931) 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  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. c) 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. d) 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. e) 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. f) 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. D.1.2 Call confirmation 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. 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 end points 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/Q.931 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. Annex E (to Recommendation Q.931) 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.1). E.2 Routing not supported Some networks may not support the routing to the remote network of the contents of the Network-specific 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 unimplemented non- mandatory 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. 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 (to Recommendation Q.931) D Channel backup procedures F. 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/Q.931 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/Q.931. 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 D Channel backup procedure employing a standby D Channel is necessary. The next section describes the backup procedure which is optional for end-points that use non-associated signalling. FIGURE F-3/Q.931