InfoMagic Standards 1993 July

home *** CD-ROM | disk | FTP | other *** search

/ InfoMagic Standards 1993 July / Disc.iso / ccitt / 1988 / ascii / 6_11_08.txt < prev next >

Wrap

Text File | 1991-12-22 | 606.9 KB | 14,100 lines

5i' 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 net- work 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 S B.2); ii) at the network-user interface on the called side (see S B.3.2); and iii) user-to-user (see S 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 com- patibility 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 net- work shall reject the call using one of the causes listed in S 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 infor- mation (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 SS 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 SS 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 infor- mation, 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 con- tent of the Low layer compatibility information element is compati- ble 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 S B.3.2. Therefore, if any conflict from duplication of information in the Bearer capability and the Low layer compati- bility 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 infor- mation element shall be used to check the compatibility of low layers. The called terminal equipment may check the High layer compa- tibility information element (if present) as part of user-to-user compatibility checking procedures, even if the network only sup- ports 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 destina- tion . With regard to the presence or absence of the High layer com- patibility 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 confi- guration 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 ele- ments. 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 infor- mation 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 Tables B-1/Q.931, B-2/Q.931 and B-3/Q.931 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. H.T. [T177.931] TABLE B-1/Q.931 Bearer capability compatibility checking _____________________________________________________________________________ BC mandatory info element { Point-to-point data link (Note 1) } Broadcast data link (Note 1) _____________________________________________________________________________ Compatible Proceed Proceed _____________________________________________________________________________ Incompatible Reject (S 5.2.5.1) { Ignore (S 5.2.5.1 | )) (Note 2) } { Reject (S 5.2.5.1 | )) (Note 2) } _____________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table B-1/Q.931 [T177.931], p. H.T. [T178.931] 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 { Point-to-point data link (Note 1) } Broadcast data link (Note 1) __________________________________________________________________________________ Compatible Accept Accept __________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | ______________________________________________________________________________________________________ Incompatible Reject (S 5.2.5.1) { Attempt low layer compatibility negotiation (Annex M) } { Ignore (S 5.2.5.1 | )) (Note 2) } { Reject (S 5.2.5.1 | )) (Note 2) } { Attempt low layer compatibility negotiation (Annex M) } ______________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table B-2/Q.931 [T178.931], p. H.T. [T179.931] 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 } { Point-to-point data link (Note 1) } Broadcast data link (Note 1) _________________________________________________________________________________________________________________ HLC or LLC present Accept or reject (Note 3) { Attempt low layer compatibility negotiation (Annex M) } Accept or reject (Note 3) { Attempt low layer compatibility negotiation } _________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (Annex M) Note 1 - For broadcast data link terminal equipment which are explicity addressed using sub-addressing or DDI, the point-to-point column in Tables B-1/Q.931, B-2/Q.931 and B-3/Q.931 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 S 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. Table B-3/Q.931 [T179.931], p. 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 informa- tion), 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 indi- cator information element shall modify its compatibility checking, the terminal equipment should regard the compatibility as success- ful if it is compatible with the included information, which as a minimum, will be the bearer capability information element. A ter- minal 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 indi- cator 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 S 5.8.7.1). C.2 Selection supported When transit network selection is supported, the user identi- fies 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 iden- tification 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 internet- work signalling arrangement. The Transit network selection informa- tion element(s) is/are not delivered to the destination user. No more than four Transit network selection information ele- ments 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 S 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 S 5.3, with cause No. 2, no route to specified transit network . The diag- nostic 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 regu- lations. 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 S 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 informa- tion (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 S 5 for the user side should nor- mally 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 fol- lowing: 1) channel is indicated, no acceptable alternative, or 2) channel is indicated, any alternative is accept- able. 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 addi- tional 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 S 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 S 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 clear- ing 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 S 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 net- work | nd 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 mes- sage; 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 indi- cator 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 pro- vided by the network side of the interface receiving the informa- tion 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 accord- ing to rules for non-mandatory information element content error (see S 5.8.7.1). E.2 Routing not supported Some networks may not support the routing to the remote net- work of the contents of the Network-specific facilities information element. In this case, when a Network-specific facilities informa- tion element is received, that information element is processed according to the rules for unimplemented non-mandatory information elements (see S 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 infor- mation element in the Q.931 SETUP message. One Network-specific facility information element is used to identify a network pro- vider. The user may specify more than one network provider by repeat- ing 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 informa- tion elements in a call control message, there must be correspond- ing 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 facili- ties information elements are delivered to the indicated remote network, they may be stripped from the signalling messages, in accordance with the relevant internetworking signalling arrange- ment. The Network-specific facilities information elements may be delivered to the identified user. No more than four Network-specific facilities information ele- ments 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 ele- ments and Transit network selection information elements. If a network cannot pass the information to the indicated net- work 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 S 5.3, with cause No. 2, no route to specified transit network . The diag- nostic 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 infor- mation 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.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/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 sig- nalling 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 neces- sary. The next section describes the backup procedure which is optional for end-points that use non-associated signalling. Figure F-1/Q.931, p. Figure F-2/Q.931, p. F.2 D-channel backup procedure F.2.1 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 inter- face. On a different interface, a secondary D-channel (labelled "two") is present that can also send signalling packets. Figure F-3/Q.931 shows the addition of a secondary (i.e., backup) D-channel to the arrangement shown in Figure F-2/Q.931. D-channel one is used to send signalling packets across the user-network interface for multiple interfaces including the inter- face 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 can not 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 inter- face. Figure F-3/Q.931, p. F.2.2 Switchover 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 arrange- ment. A D-channel is termed out-of-service 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.931 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 pri- mary shall be chosen as the D-channel for carrying call control signalling. The designated primary D-channel is agreed upon at sub- scription time by both sides of the interface. After a switchover, 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 (to Recommendation Q.931) Cause definitions This Annex provides definitions to the causes in S 4.5.12. A Table is provided in Appendix I to indicate how these causes are used in the call control procedures. G.1 Normal class G.1.1 Cause No. 1: unallocated (unassigned) number This cause indicates that the destination requested by the calling user cannot be reached because, although the number is in a valid format, it is not currently assigned (allocated). G.1.2 Cause No. 2: no route to specified transit network This cause indicates that the equipment sending this cause has received a request to route the call through a particular transit network which it does not recognize. The equipment sending this cause does not recognize the transit network either because the transit network does not exist or because that particular network, while it does exist, does not serve the equipment which is sending this cause. This cause is supported on a network-dependent basis. G.1.3 Cause No. 3: no route to destination This cause indicates that the called user cannot be reached because the network through which the call has been routed does not serve the destination desired. This cause is supported on a network-dependent basis. G.1.4 Cause No. 6: channel unacceptable This cause indicates the channel most recently identified is not acceptable to the sending entity for use in this call. G.1.5 Cause No. 7: call awarded and being delivered in an established channel This cause indicates that the user has been awarded the incom- ing call, and that the incoming call is being connected to a chan- nel already established to that user for similar calls (e.g., packet-mode X.25 virtual calls). G.1.6 Cause No. 16: normal call clearing This cause indicates that the call is being cleared because one of the users involved in the call has requested that the call be cleared. Under normal situations, the source of this cause is not the network. G.1.7 Cause No. 17: user busy This cause is used when the called user has indicated the ina- bility to accept another call. It is noted that the user equipment is compatible with the call. G.1.8 Cause No. 18: no user responding This cause is used when a user does not respond to a call establishment message with either an alerting or connect indication within the prescribed period of time allocated (defined in Recommendation Q.931 by the expiry of either timer T303 or T310). G.1.9 Cause No. 19: no answer from user (user alerted) This cause is used when a user has provided an alerting indi- cation but has not provided a connect indication within a prescribed period of time. Note - This cause is not necessarily generated by Q.931 pro- cedures but may be generated by internal network timers. G.1.10 Cause No. 21: call rejected This cause indicates that the equipment sending this cause does not wish to accept this call, although it could have accepted the call because the equipment sending this cause is neither busy nor incompatible. G.1.11 Cause No. 22: number changed This cause is returned to a calling user when the called party number indicated by the calling user is no longer assigned. The new called party number may optionally be included in the diagnostic field. If a network does not support this capability, cause No. 1, unassigned (unallocated) number shall be used. G.1.12 Cause No. 26: non-selected user clearing This cause indicates that the user has not been awarded the incoming call. G.1.13 Cause No. 27: destination out of order This cause indicates that the destination indicated by the user cannot be reached because the interface to the destination is not functioning correctly. The term "not functioning correctly" indicates that a signalling message was unable to be delivered to the remote user; e.g., a physical layer or data link layer failure at the remote user, user equipment off-line, etc. G.1.14 Cause No. 28: invalid number format (address incomplete) This cause indicates that the called user cannot be reached because the called party number is not a valid format or is not complete. G.1.15 Cause No. 29: facility rejected This cause is returned when a facility requested by the user can not be provided by the network. G.1.16 Cause No. 30: response to STATUS ENQUIRY This cause is included in the STATUS message when the reason for generating the STATUS message was the prior receipt of a STATUS ENQUIRY message. G.1.17 Cause No. 31: normal, unspecified This cause is used to report a normal event only when no other cause in the normal class applies. G.2 Resource unavailable class G.2.1 Cause No. 34: no circuit/channel available This cause indicates that there is no appropriate circuit/channel presently available to handle the call. G.2.2 Cause No. 38: network out of order This cause indicates that the network is not functioning correctly and that the condition is likely to last a relatively long period of time; e.g., immediately re-attempting the call is not likely to be successful. G.2.3 Cause No. 41: temporary failure This cause indicates that the network is not functioning correctly and that the condition is not likely to last a long period of time; e.g., the user may wish to try another call attempt almost immediately. G.2.4 Cause No. 42: switching equipment congestion This cause indicates that the switching equipment generating this cause is experiencing a period of high traffic. G.2.5 Cause No. 43: access information discarded This cause indicates that the network could not deliver access information to the remote user as requested: i.e., a user-to-user information, low layer compatibility, high layer compatibility, or sub-address as indicated in the diagnostic. It is noted that the particular type of access information discarded is optionally included in the diagnostic. G.2.6 Cause No. 44: requested circuit/channel not available This cause is returned when the circuit or channel indicated by the requesting entity can not be provided by the other side of the interface. G.2.7 Cause No. 47: resource unavailable, unspecified This cause is used to report a resource unavailable event only when no other cause in the resource unavailable class applies. G.3 Service or option not available class G.3.1 Cause No. 49: Quality of Service not available This cause is used to report that the requested Quality of Service, as defined in Recommendation X.213, cannot be provided (e.g., throughput or transit delay cannot be supported). G.3.2 Cause No. 50: requested facility not subscribed This cause indicates that the requested supplementary service could not be provided by the network because the user has not completed the necessary administrative arrangements with its sup- porting networks. G.3.3 Cause No. 57: bearer capability not authorized This cause indicates that the user has requested a bearer capability which is implemented by the equipment which generated this cause but the user is not authorized to use. G.3.4 Cause No. 58: bearer capability not presently avail- able This cause indicates that the user has requested a bearer capability which is implemented by the equipment which generated this cause but which is not available at this time. G.3.5 Cause No. 63: service or option not available, unspecified This cause is used to report a service or option not available event only when no other cause in the service or option not avail- able class applies. G.4 Service or option not implemented class G.4.1 Cause No. 65: bearer capability not implemented This cause indicates that the equipment sending this cause does not support the bearer capability requested. G.4.2 Cause No. 66: channel type not implemented This cause indicates that the equipment sending this cause does not support the channel type requested. G.4.3 Cause No. 69: requested facility not implemented This cause indicates that the equipment sending this cause does not support the requested supplementary service. G.4.4 Cause No. 70: only restricted digital information bearer capability is available This cause indicates that one equipment has requested an unrestricted bearer service but that the equipment sending this cause only supports the restricted version of the requested bearer capability. G.4.5 Cause No. 79: service or option not implemented, unspecified This cause is used to report a service or option not imple- mented event only when no other cause in the service or option not implemented class applies. G.5 Invalid message (e.g., parameter out of range) class G.5.1 Cause No. 81: invalid call reference value This cause indicates that the equipment sending this cause has received a message with a call reference which is not currently in use on the user-network interface. G.5.2 Cause No. 82: identified channel does not exist This cause indicates that the equipment sending this cause has received a request to use a channel not activated on the interface for a call. For example, if a user has subscribed to those channels on a primary rate interface numbered from 1 to 12 and the user equipment or the network attempts to use channels 13 through 23, this cause is generated. G.5.3 Cause No. 83: a suspended call exists, but this call identity does not This cause indicates that a call resume has been attempted with a call identity which differs from that in use for any presently suspended call(s). G.5.4 Cause No. 84: call identity in use This cause indicates that the network has received a call suspended request. The call suspend request contained a call iden- tity (including the null call identity) which is already in use for a suspended call within the domain of interfaces over which the call might be resumed. G.5.5 Cause No. 85: no call suspended This cause indicates that the network has received a call resume request. The call resume request contained a Call identity information element which presently does not indicate any suspended call within the domain of interfaces over which calls may be resumed. G.5.6 Cause No. 86: call having the requested call iden- tity has been cleared This cause indicates that the network has received a call resume request. The call resume request contained a Call identity information element which once indicated a suspended call; however, that suspended call was cleared while suspended (either by network timeout or by remote user). G.5.7 Cause No. 88: incompatible destination This cause indicates that the equipment sending this cause has received a request to establish a call which has low layer compati- bility, high layer compatibility, or other compatibility attributes (e.g., data rate) which cannot be accommodated. G.5.8 Cause No. 91: invalid transit network selection This cause indicates that a transit network identification was received which is of an incorrect format as defined in Annex C/Q.931. G.5.9 Cause No. 95: invalid message, unspecified This cause is used to report an invalid message event only when no other cause in the invalid message class applies. G.6 Protocol error (e.g., unknown message) class G.6.1 Cause No. 96: mandatory information element is miss- ing This cause indicates that the equipment sending this cause has received a message which is missing an information element which must be present in the message before that message can be pro- cessed. G.6.2 Cause No. 97: message type non-existent or not imple- mented This cause indicates that the equipment sending this cause has received a message with a message type it does not recognize either because this is a message not defined or defined but not imple- mented by the equipment sending this cause. G.6.3 Cause No. 98: message not compatible with call state or message type non-existent or not implemented This cause indicates that the equipment sending this cause has received a message such that the procedures do not indicate that this is a permissible message to receive while in the call state, or a STATUS message was received indicating an incompatible call state. G.6.4 Cause No. 99: information element non-existent or not implemented This cause indicates that the equipment sending this cause has received a message which includes information elements not recog- nized because the information element identifier is not defined or it is defined but not implemented by the equipment sending the cause. However, the information element is not required to be present in the message in order for the equipment sending the cause to process the message. G.6.5 Cause No. 100: invalid information element contents This cause indicates that the equipment sending this cause has received an information element which it has implemented; however, one or more of the fields in the information element are coded in such a way which has not been implemented by the equipment sending this cause. G.6.6 Cause No. 101: message not compatible with call state This cause indicates that a message has been received which is incompatible with the call state. G.6.7 Cause No. 102: recovery on timer expiry This cause indicates that a procedure has been initiated by the expiry of a timer in association with Q.931 error handling pro- cedures. G.6.8 Cause No. 111: protocol error, unspecified This cause is used to report a protocol error event only when no other cause in the protocol error class applies. G.7 Interworking class G.7.1 Cause No. 127: interworking, unspecified This cause indicates that there has been interworking with a network which does not provide causes for actions it takes, thus, the precise cause for a message which is being sent cannot be ascertained. ANNEX H (to Recommendation Q.931) Examples of information elements coding This Annex gives examples on the detailed coding of the fol- lowing information elements: - bearer capability information element; - channel identification information element; - called/calling party sub-address. H.1 Bearer capability information element H.1.1 Coding for speech H.T. [T180.931] ______________________ Bits ______________________ | | | | _________________________________________________________________________________________________ 8 7 6 | 5 | 4 | 3 | 2 | 1 | Octets Bearer Capability 0 0 0 | 0 | 0 | 1 | 0 | 0 | Octet 1 { Information element identifier } _________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | ______________________ ______________________________________________________ 0 0 0 0 0 0 1 1 Octet 2 ______________________________________________________ | | | | | | | | | | | | | | | | | | | | ____________________________ Length ____________________________ | | | | | | _________________________________________________ | | | | | | Octet 3 { _________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | _________________________________________________ | | | | | | Octet 4 { _________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | __________________________________________________ | | | | | | Octet 5 { __________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau [T180.931], p. 7 BLANC H.1.2 Coding for 3.1 kHz audio H.T. [T181.931] ______________________ Bits ______________________ | | | | ________________________________________________________________________________________________ 8 7 6 | 5 | 4 | 3 | 2 | 1 | Octets Bearer capability 0 0 0 | 0 | 0 | 1 | 0 | 0 | Octet 1 { Information element identifier } 0 0 0 0 0 0 1 1 Octet 2 ________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ____________________________ Length ____________________________ | | | | | | __________________________________________________ | | | | | | Octet 3 { | | | | | | Octet 4 { | | | | | | Octet 5 { __________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table [T181.931], p. H.1.3 Coding for unrestricted digital information Type 1: Synchronous 64 kbit/s working H.T. [T182.931] ______ Bits ______ | | | | ________________________________________________________________________________________________ 8 7 6 | 5 | 4 | 3 | 2 | 1 | Octets Bearer capability 0 0 0 | 0 | 0 | 1 | 0 | 0 | Octet 1 { Information element identifier } 0 0 0 0 0 0 1 0 Octet 2 ________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ____________________________ Length ____________________________ | | | | | | _________________________________________________ | | | | | | Octet 3 { | | | | | | Octet 4 { _________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table [T182.931], p. Type 2: Synchronous rates less than 64 kbit/s with CCITT standardized rate adaption V.110 [7]/X.30 | 8]; in-band negotiation not possible. H.T. [T183.931] ______________________ Bits ______________________ | | | | _________________________________________________________________________________________________ 8 7 6 | 5 | 4 | 3 | 2 | 1 | Octets Bearer capability 0 0 0 | 0 | 0 | 1 | 0 | 0 | Octet 1 { Information element identifier } _________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | ______________________________________________________ 0 0 0 0 0 1 0 0 Octet 2 ______________________________________________________ | | | | | | | | | | | | | | | | | | | | ____________________________ Length ____________________________ | | | | | | _________________________________________________ | | | | | | Octet 3 { | | | | | | Octet 4 { | | | | | | Octet 5 { _________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ____________________________________________________________ 1 Ext. 0 Synch. 0 Negot. User rate Octet 5a ____________________________________________________________ | | | | | | | | | | | | Table [T183.931], p. H.1.4 Coding for case B X.31 packet mode access connections H.T. [T184.931] ______________________ Bits ______________________ | | | | ________________________________________________________________________________________________ 8 7 6 | 5 | 4 | 3 | 2 | 1 | Octets Bearer capability 0 0 0 | 0 | 0 | 1 | 0 | 0 | Octet 1 { Information element identifier } 0 0 0 0 0 1 0 0 Octet 2 ________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ____________________________ Length ____________________________ | | | | | | _________________________________________________ | | | | | | Octet 3 { | | | | | | Octet 4 { | | | | | | Octet 6 { | | | | | | Octet 7 { _________________________________________________ Table [T184.931], p. H.2 Channel identification information element H.2.1 Basic interface, circuit mode, B-channel Example a) H.T. [T185.931] ______________________ Bits ______________________ | | | | ______________________________________________________________________________________________________ 8 7 6 | 5 | 4 | 3 | 2 | 1 | Octets Channel identification 0 0 0 | 1 | 1 | 0 | 0 | 0 | Octets 1 { Information element identifier } 0 0 0 0 0 0 0 1 Octets 2 ______________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ____________________________ Length ____________________________ | | | | | | __________________________________________________________________________________________________________ 1 0 0 0 0 0 0 1 | Octets 3 Ext. Int. id. present Int. type Spare Pref./ Excl. D-ch. id. Ch. sel. __________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | Table [T185.931], p. - Channel B1 preferred. - Channel is located in same interface which includes the D-channel. Example b) H.T. [T186.931] ______________________ Bits ______________________ | | | | ______________________________________________________________________________________________________ 8 7 6 | 5 | 4 | 3 | 2 | 1 | Octets Channel identification 0 0 0 | 1 | 1 | 0 | 0 | 0 | Octets 1 { Information element identifier } 0 0 | | | | | | | 0 | 0 | 0 | 0 | 0 | 1 | Octets 2 Length ______________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | __________________________________________________________________________________________________________ 1 0 0 0 0 0 1 1 | Octets 3 Ext. Int. id. present Int. type Spare Pref./ Excl. D-ch. id. Ch. sel. __________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | Table [T186.931], p. - Any B-channel. H.2.2 Primary rate interface, circuit mode, B-channel Example a) H.T. [T187.931] ______________________ Bits ______________________ | | | | ______________________________________________________________________________________________________ 8 7 6 | 5 | 4 | 3 | 2 | 1 | Octets Channel identification 0 0 0 | 1 | 1 | 0 | 0 | 0 | Octets 1 { Information element identifier } 0 0 0 0 0 0 1 1 Octets 2 ______________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ____________________________ Length ____________________________ | | | | | | _______________________________________________________________________________________________________________________________________ 1 0 1 0 0 0 0 1 | Octets 3 Ext. Int. id. present Int. type Spare Pref./ Excl. D-ch. id. Ch. sel. 1 0 0 0 0 | | | 0 | | | 1 | | | 1 | Octets 3.2 Coding standard No./Map Ch. type/Map type 0 0 | | | | | 0 | | | | | 0 | | | | | 0 | 0 | 0 | 1 | Octets 3.3 Ch. number/Slot map _______________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | Table [T187.931], p. - The channel is a B-channel. - The indicated channel is preferred. - The channel is located in the same interface which includes the D-channel. - The channel is identified by the channel number. BLANC Example b) H.T. [T188.931] ______________________ Bits ______________________ | | | | ______________________________________________________________________________________________________ 8 7 6 | 5 | 4 | 3 | 2 | 1 | Octets Channel identification 0 0 0 | 1 | 1 | 0 | 0 | 0 | Octets 1 { Information element identifier } 0 0 | | | | | | | 0 | 0 | 0 | 1 | 0 | 1 | Octets 2 Length ______________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | ________________________________________________________________________________________________________________________________________ 1 0 1 0 0 0 0 1 | Octets 3 Ext. Int. id. present Int. type Spare Pref./ Excl. D-ch. id. Ch. sel. 1 0 0 1 0 | | | 0 | | | 1 | | | 1 | Octets 3.2 Coding standard No./Map Ch. type/Map type 0 0 0 0 0 0 0 0 Octets 3.3.1 Ch. number/Slot map 0 0 0 0 0 0 0 0 Octets 3.3.2 0 0 0 0 0 0 0 1 Octets 3.3.3 ________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table [T188.931], p. - Same as a) but the channel is identified by slot-map (1544 kbit/s primary rate interface). Example c) H.T. [T189.931] ______________________ Bits ______________________ | | | | ______________________________________________________________________________________________________ 8 7 6 | 5 | 4 | 3 | 2 | 1 | Octets Channel identification 0 0 0 | 1 | 1 | 0 | 0 | 0 | Octets 1 { Information element identifier } 0 0 | | | | | | | 0 | 0 | 0 | 0 | 0 | 1 | Octets 2 Length ______________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | ___________________________________________________________________________________________________________ 1 0 1 0 0 0 1 1 | Octets 3 Ext. Int. id. present Int. type Spare Pref./ Excl. D-ch. id. Ch. sel. ___________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | Table [T189.931], p. - Same as a) but the channel may be any channel. H.2.3 Primary rate interface, circuit mode, H0-channel Example a) H.T. [T190.931] ______________________ Bits ______________________ | | | | ______________________________________________________________________________________________________ 8 7 6 | 5 | 4 | 3 | 2 | 1 | Octets Channel identification 0 0 0 | 1 | 1 | 0 | 0 | 0 | Octets 1 { Information element identifier } 0 0 | | | | | | | 0 | 0 | 0 | 0 | 1 | 1 | Octets 2 Length ______________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | _______________________________________________________________________________________________________________________________________ 1 0 1 0 0 0 0 1 | Octets 3 Ext. Int. id. present Int. type Spare Pref./ Excl. D-ch. id. Ch. sel. 1 0 0 0 0 | | | 1 | | | 1 | | | 0 | Octets 3.2 Coding standard No./Map Ch. type/Map type 0 0 0 0 0 0 0 1 Octets 3.3 Ch. number/Slot map _______________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau [T190.931], p. 17 - The channel is a H0-channel. - The indicated channel is preferred. - The channel is located in the same interface as the D-channel. - The channel is identified by the channel number. BLANC Example b) H.T. [T191.931] ______________________ Bits ______________________ | | | | _______________________________________________________________________________________________________ 8 7 6 | 5 | 4 | 3 | 2 | 1 | Octets Channel identification 0 0 0 | 1 | 1 | 0 | 0 | 0 | Octets 1 { Information element identifier } 0 0 | | | | | | | 0 | 0 | 0 | 0 | 1 | 1 | Octets 2 Length _______________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | ______________________________________________________________________________________________________________________________________ 1 0 1 0 0 0 0 1 | Octets 3 Ext. Int. id. present Int. type Spare Pref./ Excl. D-ch. id. Ch. sel. 1 0 0 1 0 | | | 1 | | | 1 | | | 0 | Octets 3.2 Coding standard No./Map Ch. type/Map type 0 0 | | | | | 0 | | | | | 0 | | | | | 0 | 0 | 1 | 0 | Octets 3.3 Ch. number/Slot map ______________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | Table [T191.931], p. - As for a) but channel indicated by slot map. BLANC Example c) H.T. [T192.931] ______________________ Bits ______________________ | | | | ______________________________________________________________________________________________________ 8 7 6 | 5 | 4 | 3 | 2 | 1 | Octets Channel identification 0 0 0 | 1 | 1 | 0 | 0 | 0 | Octets 1 { Information element identifier } 0 0 | | | | | | | 0 | 0 | 0 | 1 | 0 | 1 | Octets 2 Length ______________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | _________________________________________________________________________________________________________________________________________ 1 0 1 0 0 0 0 1 | Octets 3 Ext. Int. id. present Int. type Spare Pref./ Excl. D-ch. id. Ch. sel. 1 0 0 1 0 | | | 0 | | | 1 | | | 1 | Octets 3.2 Coding standard No./Map Ch. type/Map type 0 0 | | | | | 0 | | | | | 0 | | | | | 0 | 0 | 0 | 1 | Octets 3.3.1 Ch. number/Slot map _________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | ___________________________________________________________ 0 1 1 0 1 0 0 1 Octets 3.3.2 0 1 0 0 0 0 0 0 Octets 3.3.3 ___________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table [T192.931], p. - The channels are B-channels (6 B-channels to form a H0-channel). - Channels indicated by slot-map (1544 kbit/s pri- mary rate system). - Otherwise as for a). BLANC Example d) H.T. [T193.931] ______________________ Bits ______________________ | | | | _______________________________________________________________________________________________________ 8 7 6 | 5 | 4 | 3 | 2 | 1 | Octets Channel identification 0 0 0 | 1 | 1 | 0 | 0 | 0 | Octets 1 { Information element identifier } 0 0 | | | | | | | 0 | 0 | 0 | 0 | 1 | 0 | Octets 2 Length _______________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | ____________________________________________________________________________________________________________________________ 1 1 1 0 0 0 1 1 | Octets 3 Ext. Int. id. present Int. type Spare Pref./ Excl. D-ch. id. Ch. sel. 1 0 | | | 0 | | | 0 | | | 0 | | | 0 | | | 0 | | | 0 | Octets 3.1 Interface identifier ____________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | Tableau [T193.931], p. - Any channel. - Any interface (int. id. present = 1 and interface identifier = all "0". BLANC H.3 Called/calling party sub-address information element H.3.1 Coding of IA5 sub-address digits H.T. [T194.931] ______________________ Bits ______________________ | | | | _______________________________________________________________________________________________ 8 7 6 | 5 | 4 | 3 | 2 | 1 | Octets Called party sub-address 0 1 1 | 1 | 0 | 0 | 0 | 1 | Octets 1 Information element _______________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | _________________________________________________________________________ 0 0 | 0 | 0 | 0 | 1 | 0 | 1 | Octets 2 Length _________________________________________________________________________ | | | | | | | | | ________________________________________________________________________________________________________________________________ 1 0 0 0 0 | 0 | 0 | 0 | Octets 3 Ext. NSAP (X.213/ISO 8348 AD2) | | Odd/even indication (Note 4) | | Spare | | AFI (Note 1) ________________________________________________________________________________________________________________________________ | | | | | | | | | | | | _________________________________________________________________________________ 0 1 | 0 | 1 | 0 | 0 | 0 | 0 | Octets 4 IA5 character (Note 2) Octets 5 IA5 character Octets 6 IA5 character Octets 7 _________________________________________________________________________________ | | | | | | | | | | | | | | | Table [T194.931], p. BLANC ANNEX I (to Recommendation Q.931) Use of progress indicators This Annex describes the use of the different progress indica- tor values defined in S 4.5.22. Examples of use are given. Progress indicator No. 1 | ndicates that interworking with a non-ISDN has occurred within the network or networks through which the call has traversed. Progress indicator No. 2 | ndicates that the destination user is not ISDN. Progress indicator No. 3 | ndicates that the origination user is not ISDN. Progress indicator No. 4 | ndicates 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 indica- tor would be employed when a prior Recommendation 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. Three interworking situations are identified in the figure below: a) interworking with another network; b) interworking with a non-ISDN user connected to ISDN; c) interworking with non-ISDN equipment within the calling or called user's premises. Figure, p. 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). As regards calls towards A the following applies: 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). The use of progress indicator No. 8, in-band information or appropriate pattern now available , is described in S 5. ANNEX J (to Recommendation Q.931) Examples of cause value and location for busy condition This Annex gives examples on the detailed cause value and location to be sent in a Cause information element for the busy condition. Figure J-1/Q.931 shows the reference configuration which iden- tifies nodes where busy condition may occur and therefore a cause should be generated. Table J-1/Q.931 shows: a) a cause value and location to be generated at the point where the busy condition occurs; and b) a cause value and location to be delivered to the user (indicated as A) for each location (B - P) where the busy condition occurs. As is indicated in the Table, the cause value is not changed but the location may be changed in the receiving exchange, when the cause value crosses a network boundary. Figure J-1/Q.931, p. 23 H.T. [T195.931] TABLE J-1/Q.931 Location where busy occurs and the cause codings ____________________________________________________________________________________________ Location where busy occurs { Cause at the point of generation } Cause received by user A ____________________________________________________________________________________________ B incoming circuit No. 34 or No. 44 LPN B outgoing circuit No. 34 LPN C outgoing circuit No. 34 LPN D incoming circuit No. 34 or No. 44 LN D outgoing circuit No. 34 LN E outgoing circuit No. 34 LN The same as left F outgoing circuit No. 34 TN G outgoing circuit No. 34 TN H outgoing circuit No. 34 INTL I outgoing circuit No. 34 INTL J outgoing circuit No. 34 TN No. 34 TN K outgoing circuit No. 34 TN No. 34 TN L outgoing circuit No. 34 LN No. 34 RLN M outgoing circuit No. 17 LN No. 17 RLN N incoming circuit No. 34 or No. 44 LPN No. 34 or No. 44 RPN N outgoing circuit No. 34 LPN No. 34 RPN O outgoing circuit No. 17 LPN No. 17 RPN P incoming circuit No. 34 or No. 44 U No. 34 or No. 44 U P call control No. 17 U No. 17 U ____________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LPN Private network serving the local user LN Public network serving the local user TN Transit network INTL International transit network RLN Public network serving the remote user RPN Private network serving the remote user U User Table J-1/Q.931 is for further study. Tableau J-1/Q.931 [T195.931], p. 24 BLANC ANNEX K (to Recommendation Q.931) Message segmentation procedures K.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 N.201 (defined in Recommendation Q.921 [3]). These procedures are optional and may not be supported by all equipment. The architectural relationship to other Recommendation Q.931 functions is shown in Figure K-1/Q.931. These procedures apply only within a specific data link connection and do not impact the pro- cedures in operation on other parallel data link connections. Figure K-1/Q.931, p. K.2 Message segmentation The following rules apply when Recommendation Q.931 messages are to be segmented for transmission: a) the default maximum number of message segments is eight. If the message is too long to be segmented then a local maintenance activity shall be notified; b) the first message segment shall begin with the protocol discriminator immediately followed by the Call reference, the segment message type, the Segmented message information ele- ment, and one or more other information elements; c) each subsequent message segment shall begin with the protocol discriminator immediately followed by the call refer- ence, the segment message type, the Segmented message information element and one or more other information elements; d) the first segment indicator field of the Seg- mented message information element shall be set to indicate the first segment of a segmented message, and not set in any other seg- ment; e) the number of segments remaining field of the Segmented message information element shall be set to indicate how many more segments are to be sent, see Figure K-2/Q.931; f ) 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; g) the transmission of a segmented message may be aborted by: sending a message or message segment containing a dif- ferent 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; h) 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) messages shall be segmented only at information element boundaries; i.e., no information element shall be separated into two segments; j ) the information element order as a whole is preserved for the Segmented message regardless of segment boundary. K.3 Reassembly of segmented messages The following rules apply to the receipt and reassembly of segmented Q.931 messages: a) a reassembly function, on receiving a message segment containing the Segmented message information element with the first segment indicator indicating "first message", and con- taining the call reference and message type (coded as "segment mes- sage" shall enter the Receiving Segmented Message state and accumu- late message segments; b) timer T314, shall be initialized or reinitial- ized 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 mes- sage information element with the number of segments remaining field coded zero. Timer T314 shall not be initialized or reinitial- ized if error procedures as identified in rules below are ini- tiated; c) a reassembly function receiving a message seg- ment 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 S 5.8. The reassembly function shall enter the Null state; d) 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 - Subsequent message segments relating to the same message shall be discarded according to rule f ). e) a reassembly function, upon receiving eight mes- sage 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 dis- carded; and enter the Null state; Note - Subsequent message segments relating to the same message shall be discarded according to rule f ). 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; Figure K-2/Q.931, p. 26 g) 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 seg- ments remaining field that is not decremented from the number of segments remaining field in the Segmented message information ele- ment of the previous message segment, shall discard all segments of this message so far received; and enter the Null state; Note - Subsequent message segments relating to the same message shall be discarded according to rule f ). 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; i) 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. Figure K-3/Q.931, p. 27 Figure K-4/Q.931, p. 28 Figure K-5/Q.931 (feuillet 1 sur 3), p. 29 Figure K-5/Q.931 (feuillet 2 sur 3), p. 30 Figure K-5/Q.931 (feuillet 3 sur 3), p. 31 ANNEX L (to Recommendation Q.931) Low layer information coding principles L.1 Purpose This Annex describes principles that shall be used when the calling user specifies information during call setup 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 end point entity which is explicitly addressed. This may be an addressed interworking unit (IWU) (see I.500-Series Recommendations [51] and X.31 [14] case A). L.2 Principles L.2.1 Definitions of types of information There are three different types of information that the cal- ling 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 cal- ling 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; b) type II information is the selection of bearer service from the choices of bearer services 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 (including octets 4a and 4b if necessary) of the Bearer capability information element when the transfer mode required by the calling user is circuit mode, ii) octets 3, 4, 6 and 7 (including 4a and 4b if necessary) of the Bearer capability information element when the transfer mode required by the calling user is packet mode; c) type III information is information about the terminal or intended call which is used to decide destination ter- minal compatibility and possibly to facilitate interworking with other ISDNs or other dedicated networks. An example is A-law encod- ing. This information is encoded in octet 5 of the Bearer capabil- ity information element. L.2.2 Examination by network Type I information is user-to-user (i.e. not examined by net- work) while both types II and III should be available for examina- tion by the destination user and the network. The Low layer compa- tibility 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. L.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. L.2.4 Location of types 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 ele- ment. The network may use and modify the information (e.g. to pro- vide interworking). The rationale for the user including some terminal related information in the type III information (inter- working 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 compatibil- ity decision by the destination terminal in a purely ISDN situa- tion. However, it could also conceivably be used to allow inter- working with a PSTN, assuming that the appropriate functions (i.e., data extraction, modem pool) are available at the interwork- ing 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 adap- tion 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. L.2.5 Relationship between Bearer capability and Low layer compatibility 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 code points may be modi- fied 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 informa- tion 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 u-law, with conversion provided by the u-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 u-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 informa- tion element and the Low layer compatibility information element, it would receive conflicting information regarding the encoding scheme used. L.3 Information classification The following are the examples of classifying low layer infor- mation currently identified. This information is provided to facil- itate understanding of the characteristics of types II and III information. L.3.1 Examples for speech and 3.1 kHz audio bearer services a) Type II information (common to all applications using these bearer services): - 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/u law. b) Type III information for interworking with CSPDN (3.1 kHz audio applications are assumed) - Figure L-1/Q.931: - user information layer 1 protocol = rate adaption + user rate (Note); Note - Only those profiles conforming to CCITT standard- ized rate adaption are allowed when only the above information is provided. c) Type III information for interworking with PSTN: i) voice applications: Figure L-2/Q.931: - user information layer 1 protocol = A/u law; ii) voice band data applications: Figure L-3/Q.931: - user information layer 1 protocol = A/u law. Figure L-1/Q.931, p. Figure L-2/Q.931, p. Figure L-3/Q.931, p. L.3.2 Examples for 64 kbit/s UDI circuit mode bearer ser- vice a) 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 PSPDN (packet applications): Figure L-4/Q.931: - no type III information is required. c) Type III information for interworking with PSTN: i) voice applications: Figure L-5/Q.931: - no type III information is required; ii) rate-adapted data applications: Figure L-6/Q.931 - no type III information is required. d) Type III information for interworking with PSTN with end-to-end digital connectivity (data applications) Figure L-7/Q.931: - user information layer 1 protocol = rate adaption + user rate (Note). Note - The profile described in I.463 [52] is allowed. L.3.3 Examples for ISDN virtual-circuit bearer service a) 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 (Note 1); - user information layer 2 protocol = LAPB (Note 2); - user information layer 3 protocol = X.25 [5] packet layer protocol (Note 2). Note 1 - This parameter is included only when user packet information flow is rate adapted. Only those profiles conforming to X.31 are allowed when only the above information is provided for layer 1 protocol. Note 2 - Only those profiles conforming to X.31 are used. See Figures L-8/Q.931, L-9/Q.931 and L-10/Q.931. b) Type III information for interworking with PSPDN, CSPDN, PSTN: - no type III information is necessary. Figure L-4/Q.931, p. Figure L-5/Q.931, p. Figure L-6/Q.931, p. Figure L-7/Q.931, p. Figure L-8/Q.931, p. Figure L-9/Q.931, p. Figure L-10/Q.931, p. L.4 Scenarios outside the scope of ISDN standardization L.4.1 Examples for speech and 3.1 kHz audio bearer services a) 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/u law. b) Type III information for interworking with PSTN - voice band data applications - modem type conversion occurs: Figure L-11/Q.931: - user information layer 1 protocol = rate adaption + user rate + other attributes (if required). L.4.2 Examples for 64 kbit/s UDI circuit mode bearer ser- vices a) 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 L-12/Q.931: - no type III information is required. Figure L-11/Q.931, p. Figure L-12/Q.931, p. ANNEX M (to Recommendation Q.931) Low layer compatibility negotiation This Annex describes an additional low layer compatibility checking procedure that may be applied by the user. However, this is a network option and may not be supported by all networks. M.1 General The purpose of the Low layer compatibility information element is to provide a means which should be used for compatibility check- ing 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 caller user) and the addressed entity. The user information protocol fields of the Low layer compati- bility 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 S 4.5.18. M.2 Low layer compatibility notification to the called user When the calling user wishes to notify the called user of any information transfer attribute (contained octet 3 to 4b) different from the ones contained in the Bearer capability information ele- ment or of any low layer protocol to be used during the call and not already identified in the Bearer capability information ele- ment, then the 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 S 5.8.7.1 (unrecognized information element). M.3 Low layer compatibility negotiation between users If the negotiation indicator (see S 4.5) of the Low layer com- patibility information element included in the SETUP message is set to "Out-band LLC negotiation allowed", 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 nego- tiated 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 S 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 compati- bility information element received from the calling party. M.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) low layer compatibility negotiation not allowed (default): then the called user shall not invoke negotiation; b) out-band low layer compatibility negotiation allowed: the called user may then invoke low layer compatibility negotiation, as needed, according to S M.3; c) in-band negotiation allowed: the called user may then invoke low layer compatibility negotiation using the supported in-band negotiation, according to service or application require- ments; d) 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 nego- tiation is supported by both parties, then this method of negotia- tion is preferred. ANNEX N (to Recommendation Q.931) Procedures for establishment of bearer connection prior to call acceptance N.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) 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 b) 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. N.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) on completion of successful channel negotiation at the destination interface; or b) on receipt of a message containing an indication that in-band information is being provided; or c) not at all: i.e., this option is not supported by the network. 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 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 O (to Recommendation Q.931) 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 arrange- ment. Note 1 - The definition of necessary mechanisms (if any) within Signalling System No. 7 to support this procedure, including any undesirable charging implications, is for further study. When a bearer service requested in an originator's SETUP mes- sage 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 2 - During an interim period some networks may only sup- port 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 interwork- ing the values given in Appendix I of Recommendation I.340 should apply. The interworking functions have to be provided in the net- work restricted capability. The ISDN with 64 kbit/s transfer capa- bilities will not be offered by this interworking, other than by conveying the appropriate signalling message to or from the ISDN terminal. Note 3 - The possibility of changing from 3.1 kHz audio to speech is for further study. Up to three Bearer capability information elements may be present in the SETUP message from the originating user, correspond- ing 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 combina- tions 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 pre- ferred bearer service cannot be provided, it sends a NOTIFY message toward the call orginator. The NOTIFY message contains a Notifica- tion indicator information element with a coding which indicates to the originating party the change in bearer service and also con- tains a Bearer capability information element specifying the attri- butes 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 S 5. BLANC APPENDIX I (to Recommendation Q.931) Usage of cause values Table I-2/Q.931 indicates the usage of cause values within Recommendation Q.931. 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 Q.931. Table I-1/Q.931 defines the key for the location of generation in Table I-2/Q.931. For more precise usage of the location codes in the cause information element, see Annex J/Q.931. H.T. [T196.931] TABLE I-1/Q.931 Key for the location of the generation in Table I-2/Q.931 __________________________________________________________________ LU Local user LN Local network TN Transit network RN Remote network RU Remote user { LPE Local peer entity (for symmetrical operation, see Annex D/Q.931) } { The following abbreviations to message types are used in Table I-2/Q.931 } CON CON CONGESTION CONTROL DISC DISCONNECT REL RELEASE REL COM RELEASE COMPLETE RES REJ RESUME REJECT STAT STATUS SUSP REJ SUSPEND REJECT __________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau I-1/Q.931 [T196.931], p. 44 BLANC H.T. [1T197.931] _________________________________________________ TABLE I-2/Q.931 { Usage of cause values } _________________________________________________ | | | | | | | | | | __________________________________________________________________________________________________________________________________________________________________________________________________________________ Cause No. Class Value Cause name Diagnostics Section cross-reference { At remote interface At local interface __________________________________________________________________________________________________________________________________________________________________________________________________________________ 5.2.4 1 000 0001 { RU REL COM .line DISC __________________________________________________________________________________________________________________________________________________________________________________________________________________ 2 000 0010 { LN REL COM __________________________________________________________________________________________________________________________________________________________________________________________________________________ 5.1.4 LN DISC .line REL COM 5.2.4 3 000 0011 No route to destination Condition RU REL COM .line DISC DISC __________________________________________________________________________________________________________________________________________________________________________________________________________________ 6 000 0110 Channel unacceptable - { 5.2.3.1 | ) 5.3.2 | ) 6.2.2.3.1 } LN REL __________________________________________________________________________________________________________________________________________________________________________________________________________________ 7 000 0111 { Call awarded and being delivered in an established channel } - 6.2.2.3.1 LN REL __________________________________________________________________________________________________________________________________________________________________________________________________________________ 16 001 0000 Normal call clearing Condition RU DISC DISC __________________________________________________________________________________________________________________________________________________________________________________________________________________ 5.2.5.1 5.2.5.4 | ) RU REL COM DISC 17 001 0001 User busy - No procedure RN DISC __________________________________________________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau I-2/Q.931 [1T197.931], p. 45 A L'ITALIENNE H.T. [2T197.931] _________________________________________________ { TABLE I-2/Q.931 (cont.) } _________________________________________________ | | ____________________________________________________________________________________________________________________________________________________________________________________________________________________ Cause No. Class Value Cause name Diagnostics Section cross-reference { At remote interface At local interface ____________________________________________________________________________________________________________________________________________________________________________________________________________________ 18 001 0010 No user responding - 5.2.5.3 RN DISC ____________________________________________________________________________________________________________________________________________________________________________________________________________________ 19 001 0011 User alerting, no answer - 5.2.5.3 RN DISC ____________________________________________________________________________________________________________________________________________________________________________________________________________________ 21 001 0101 Call rejected { Condition: user supplied diagnostic } 5.2.5.1 5.2.5.4 | ) RU REL COM. DISC ____________________________________________________________________________________________________________________________________________________________________________________________________________________ 5.1.4 LN DISC .line REL COM 5.2.4 22 001 0110 Number changed New destination number RU REL COM .line DISC DISC ____________________________________________________________________________________________________________________________________________________________________________________________________________________ 26 001 1010 Non-selected user clearing - 5.3.2 | ) 6.2.2.3.1 LN REL ____________________________________________________________________________________________________________________________________________________________________________________________________________________ 27 001 1011 Destination out of order - 5.8.9 RN DISC ____________________________________________________________________________________________________________________________________________________________________________________________________________________ RU 28 001 1100 { DISC .line REL COM DISC 5.1.5.2 LN ____________________________________________________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau I-2/Q.931 [2T197.931], p. 46 A L'ITALIENNE H.T. [3T197.931] _________________________________________________ { TABLE I-2/Q.931 (cont.) } _________________________________________________ | | | | | | | | ______________________________________________________________________________________________________________________________________________________________________ Cause No. Class Value Cause name Diagnostics Section cross-reference { At remote interface At local interface ______________________________________________________________________________________________________________________________________________________________________ LN REL COM .line DISC RN 29 011 1101 Facility rejected Facility identification No procedure in Q.931 DISC RU REL COM .line DISC ______________________________________________________________________________________________________________________________________________________________________ 30 001 1110 Response to STATUS ENQUIRY - 5.8.10 LU, LN STAT ______________________________________________________________________________________________________________________________________________________________________ 31 001 1111 Normal, unspecified - 5.8.4 RN REL COM .line DISC ______________________________________________________________________________________________________________________________________________________________________ 5.1.1 5.1.2 LN REL COM { 34 010 0010 No circuit/channel available - RU REL COM. DISC C.2 ______________________________________________________________________________________________________________________________________________________________________ 38 010 0110 Network out of order - No procedure ______________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau I-2/Q.931 [3T197.931], p. 47 A L'ITALIENNE H.T. [4T197.931] _________________________________________________ { TABLE I-2/Q.931 (cont.) } _________________________________________________ | | | | | | | | ____________________________________________________________________________________________________________________________________________________________________________________________ Cause No. Class Value Cause name Diagnostics Section cross-reference { At remote interface At local interface ____________________________________________________________________________________________________________________________________________________________________________________________ 5.8.8 LU, LN DISC 5.8.10 41 010 1001 Temporary failure - LN, RU, RN DISC DISC ____________________________________________________________________________________________________________________________________________________________________________________________ 42 010 1010 { Switching equipment congestion } - No procedure REL REL COM ____________________________________________________________________________________________________________________________________________________________________________________________ 43 010 1011 Access information discarded { LN STAT 5.8.7.2 LN, LU ____________________________________________________________________________________________________________________________________________________________________________________________ { 44 010 1100 { RU REL COM. DISC D.1.1 | ) ____________________________________________________________________________________________________________________________________________________________________________________________ 47 010 1111 { Resource unavailable, unspecified } - No procedure ____________________________________________________________________________________________________________________________________________________________________________________________ 49 011 0001 { Quality of service unavailable } Condition 6 REL REL COM ____________________________________________________________________________________________________________________________________________________________________________________________ DISC 50 011 0010 { 7.1.4.3 7.1.5.3 RN DISC 7.1.7.4 ____________________________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau I-2/Q.931 [4T197.931], p. 48 A L'ITALIENNE H.T. [5T197.931] _________________________________________________ { TABLE I-2/Q.931 (cont.) } _________________________________________________ | | | | | | | | ________________________________________________________________________________________________________________________________________________________________________________________________________ Cause No. Class Value Cause name Diagnostics Section cross-reference { At remote interface At local interface ________________________________________________________________________________________________________________________________________________________________________________________________________ 57 011 1001 { LN REL .line REL COM ________________________________________________________________________________________________________________________________________________________________________________________________________ 58 011 1010 { LN REL .line REL COM ________________________________________________________________________________________________________________________________________________________________________________________________________ 63 011 1111 { Service or option not available, unspecified } - 5.1.5.2 LN DISC .line REL COM ________________________________________________________________________________________________________________________________________________________________________________________________________ 65 100 0001 { LN REL COM ________________________________________________________________________________________________________________________________________________________________________________________________________ 66 100 0010 Channel type not implemented Channel type No procedure ________________________________________________________________________________________________________________________________________________________________________________________________________ DISC 69 100 0101 { 7.1.4.3 7.1.5.3 RN REL DISC 7.1.7.4 ________________________________________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau I-2/Q.931 [5T197.931], p. 49 A L'ITALIENNE H.T. [6T197.931] _________________________________________________ { TABLE I-2/Q.931 (cont.) } _________________________________________________ | | | | | | | | __________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Cause No. Class Value Cause name Diagnostics Section cross-reference { At remote interface At local interface __________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 70 100 0110 { Only restricted digital information bearer capability is available } - { No procedure (network dependent option) } __________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 79 100 1111 { Service or option not implemented, unspecified } __________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 5.8.3.2 | ) LU, LN REL .line REL COM 5.8.3.2 | ) LU, LN REL COM 5.8.3.2 | ) LU, LN _______________________________________________________________________________ 81 101 0001 Invalid call reference value - } Channel identity No procedure REL COM __________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 83 101 0011 { A suspended call exists, but this call identity does not } - 5.6.5 LN RES REJ __________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 84 101 0100 Call identity in use - 5.6.3 LN SUSP REJ __________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 85 101 0101 No call suspended - 5.6.5 LN RES REJ __________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 86 101 0110 { Call having the requested call identity has been cleared } 5.6.5 LN RES REJ __________________________________________________________________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau I-2/Q.931 [6T197.931], p. 50 A L'ITALIENNE H.T. [7T197.931] _________________________________________________ { TABLE I-2/Q.931 (cont.) } _________________________________________________ | | | | | | | | __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Cause No. Class Value Cause name Diagnostics Section cross-reference { At remote interface At local interface __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 88 101 0111 Incompatible destination Incompatible parameter { 5.2.2 5.2.5.1 5.2.5.3 | ) B.3.2 B.3.3 } RU REL COM DISC __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 91 101 1011 { DISC .line REL .line REL COM __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 95 101 1111 Invalid message, unspecified Message type 5.8 LN REL COM .line STAT __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 96 110 0000 { LN, LU STAT __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 97 110 0001 { Message type non-existent or not implemented } Message type { 5.8.4 .ta 1632u 1992u 2232u 2976u 3576u 4200u 4944u 5472u 5976u 5.8.10 .ta 1632u 1992u 2232u 2976u 3576u 4200u 4944u 5472u 5976u 5.8.11 } LU, LN STAT __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 98 110 0010 { Message not compatible with call state or message type non-existent or not implemented } Message type 5.8.4 LU, LN STAT __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 99 110 0011 { LN REL .line REL COM __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau I-2/Q.931 [7T197.931], p. 51 A L'ITALIENNE H.T. [8T197.931] _________________________________________________ { TABLE I-2/Q.931 (end) } _________________________________________________ | | | | | | | | _____________________________________________________________________________________________________________________________________________________________________________ Cause No. Class Value Cause name Diagnostics Section cross-reference { At remote interface At local interface _____________________________________________________________________________________________________________________________________________________________________________ .nr #^ 1040u .nr #^ 1120u .nr #^ 1200u 100 110 0100 { LU, LN STAT _____________________________________________________________________________________________________________________________________________________________________________ 5.8.11 101 110 0101 { LN, LU DISC .line REL .line REL COM _____________________________________________________________________________________________________________________________________________________________________________ { .nr #^ 1640u .nr #^ 1720u .nr #^ 1800u LN REL { .nr #^ 2000u .nr #^ 2080u 102 110 0110 Recovery on time expiry Timer number _____________________________________________________________________________________________________________________________________________________________________________ 111 110 1111 Protocol error, unspecified 5.8.4 RN DISC _____________________________________________________________________________________________________________________________________________________________________________ 127 111 1111 Interworking, unspecified No explicit procedure _____________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | Tableau I-2/Q.931 [8T197.931], p. 52 A L'ITALIENNE