WPCL 2BJ|x ` H  > x|@  6'6' ANNEX A A 5(to Recommendation Q.931) A .User side and network side SDL diagramsă A A Aàă  8 ANNEXES B TO O AND APPENDICES I, II AND II OF RECOMMENDATION Q.931 H  Page   Annex B: Compatibility checking .......................................... 7 Annex C: Transit network selection ....................................... 11 Annex D:Extensions for symmetric call operation ......................... 12 Annex E: Network specific facility selection ............................. 15 Annex F: D Channel backup procedures ..................................... 16 Annex G: Cause definitions ............................................... 19 Annex H: Examples of information elements coding ......................... 26 Annex I: Use of progress indicators ...................................... 34 Annex J: Examples of cause value and location for busy condition ......... 35 Annex K: Message segmentation procedures ................................. 38 Annex L: Low layer information coding principles ......................... 48 Annex M: Low layer compatibility negotiation ............................. 57 Annex N: Procedures for establishment of bearer connection prior to Hcall acceptance ................................................. 59 Page Annex O: Optional procedures for bearer service change ................... 60 Appendix I Use of cause values in call control procedures............... 61 Appendix II Example message flow diagrams and example conditions for Hcause mappings in packet communications..................... 73 Appendix III Summary of assigned information element identifier and H message type code points for the Q.93Series of <==>Recommendations............................................ 87 HLAnnex B HO HC(to Recommendation Q.931) HO HDCompatibility checkingă HO B.1HIntroduction HThis annex describes the various compatibility checks which should be carried out to ensure that the best matched user and network capabilities are achieved on a call within an ISDN. HThis annex also covers interworking with existing networks. HThree different processes of compatibility checking shall be performed:   HHi)h  at the usertonetwork interface on the calling side (see HHX  B.2);  `    HHii)  at the networkuser interface on the called side (see B.3.2); and  `  HHX Hiii) usertouser (see  B.3.3).  X 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. HFor details on the coding of the information required for compatibility checking, see Annex L. B.2HCalling side compatibility checking HAt the calling side, the network shall check that the bearer service requested by the calling user in the Bearer capability information element matches with the bearer services provided to that user by the network. If a mismatch is detected, then the network shall reject the call using one of the causes listed in 5.1.5.2. HNetwork services are described in Recommendations I.230 [47] and I.240 [48] as bearer services and teleservices, respectively. B.3HCalled side compatibility checking HIn this section, the word "check" means that the user examines the contents of the specified information element. B.3.1HCompatibility checking with addressing information HIf an incoming SETUP message is offered with addressing information (i.e., either DDI or subaddressing or the appropriate part of the called party number, e.g., for DDI) the following actions will occur: Ha)h  if a number (e.g. for DDI) or subaddress is assigned to a user, then the information in a Called party number or Called party subaddress information element of the incoming call shall be checked by the user against the corresponding part of the number assigned to the user (e.g., for DDI) or the user's own   HHX subaddress. In the case of a mismatch, the user shall ignore the call. In the case of match, the compatibility checking described in B.3.2 to B.3.3 will follow;  `    Hb)h  if a user has no DDI number or subaddress, then the Called party number and Called party subaddress information element shall be ignored. The compatibility checking described in B.3.2 and B.3.3 will follow. Note 1 According to the user's requirements, compatibility checking can be performed in various ways from the viewpoint of execution order and information to be checked, e.g. first DDI number/subaddress and then compatibility or vice versa. Note 2 If an incoming call, offered with addressing information, is always to be awarded to the addressed user, all users connected to the same passive bus should have a DDI number or subaddress. ,Ԍ B.3.2HNetworktouser compatibility checking HWhen 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.3HUsertouser compatibility checking HThe called side terminal equipment shall check that the content of the Low layer compatibility information element is compatible with the functions it supports. HThe Low layer compatibility information element (if available) shall be used to check compatibility of low layers (e.g., from layer 1 to layer3, if layered according to the OSI model). Note The Bearer capability information element is also checked, see B.3.2. Therefore, if any conflict from duplication of information in the Bearer capability and the Low layer compatibility information elements is detected, this conflict shall be resolved according to Annex L, e.g. the conflicting information in the Low layer compatibility information element shall be ignored. HIf the Low layer compatibility information element is not included in an incoming SETUP message, the Bearer capability information element shall be used to check the compatibility of low layers. HThe called terminal equipment may check the High layer compatibility information element (if present) as part of usertouser compatibility checking procedures, even if the network only supports bearer services. HIf a mismatch is detected in checking any of the information elements above, then the terminal equipment shall either ignore or reject the offered call using cause No. 88 "incompatible destination". HWith regard to the presence or absence of the High layer compatibility and Low layer compatibility information elements, two cases arise: Ha)  Compatibility assured with the available description of the call HThis 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. Hb)  Compatibility not assured with the available description of the L$MM$Ncall HThis is when all or some of the terminal equipment do not recognize (i.e. ignore) either the High layer compatibility or Low layer compatibility information elements. Without careful configuration or administration at the user's installation, there is a danger that a terminal equipment which has incorrect functionality will accept the call. HTherefore, in order to assure compatibility with incoming calls, it is recommended that the terminal equipment check the Low layer compatibility and High layer compatibility information elements. Note Some terminal equipment, upon bilateral agreement with other users or in accordance with other standards (e.g. Recommendation X.213, [23]) may employ the Useruser information element for additional compatibility checking. Such terminal equipment shall check the Useruser information element in a manner identical to that described here for the High layer compatibility information element "compatibility assured" case. B.3.4HUser action tables HThe following tables show the action which shall be carried out as a result of compatibility checking with the calling user's request for a bearer service and/or teleservice. HHTABLE B1/Q.931 Bearer capability compatibility checking H4   BC Pointtopoint Broadcast  mandatory data link data link  info element  (Note 1)       Compatible Proceed Proceed   Incompatible Reject(5.2.5.1) Ignore Reject    (5.2.5.1a) (5.2.5.1b)    (Note 2) (Note 2)    HHTABLE B2/Q.931 HO H,Low layer and high layer compatibility checking: compatibility assuredă H:with the available description of the callă H*   H4 LLC/HLC Pointtopoint Broadcast  H2 compatibility data link data link  H6 assured (Note 1) (Note 1)  H* HB Compatible Accept Accept  H* H. Incompatible Reject Attempt low Ignore Reject Attempt  H5  (5.2.5.1) layer (5.2.5.1a) 5.2.5.1b) low layer  H5   compatibility (Note 2) (Note 2) compatibility  H5   negotiation   negotiation  H5   (Annex M)   (Annex M)  H*   HHTABLE B3/Q.931 HO H.Low layer and high layer compatibility checking: compatibility notă H6assured with the available description of the callă H.   H4 LLC/HLC  Pointtopoint Broadcast data  H/ compatibility  data link  link  H/ not assured  (Note 1)  (Note 1)  H. H2 HLC or LLC Accept or Attempt low Accept or Attempt low  H9 present reject layer reject layer  ,ԌH7  (Note 3) compatibility (Note 3) compatibility  H@   negotiation  negotiation  HA   (Annex M)  (Annex M)  H.   Note 1 For broadcast data link terminal equipment which are explicitly addressed using subaddressing or DDI, the pointtopoint column in the above table shall be used. Note 2 When a terminal equipment on a broadcast data link is incompatible, an option of "ignore or reject" is permitted, see 5.2.2.  h Note 3 Some terminal equipment on this interface may understand the High layer compatibility or Low layer compatibility information element and would reject the call if incompatible. B.4HInterworking with existing networks HLimitations 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. HIn cases where the network cannot provide all incoming call information, or where the network is not aware of the existence or absence of some service information (such as compatibility information), the incoming SETUP message includes a Progress indicator information element, containing progress indicator No. 1 "Call is not endtoend ISDN, further call progress information may be available inband" or No. 3 "Origination address is nonISDN" (see AnnexI). HThe terminal equipment receiving a SETUP with a progress indicator information element shall modify its compatibility checking, the terminal equipment should regard the compatibility as successful if it is compatible with the included information, which as a minimum, will be the bearer capability information element. A terminal equipment expecting information in addition to the Bearer capability information element in a full ISDN environment need not reject the call if such information is absent but a Progress indicator information element is included. 8OAnnex C 8R 8F(to Recommendation Q.931) 8R 8FTransit network selectionă 8R 8R HThis annex describes the processing of the transit network selection information element. C.1HSelection not supported HSome networks may not support transit network selection. In this case, when a Transit network selection information element is received, that information element is processed according to the rules for unimplemented non mandatory information elements (see 5.8.7.1). C.2HSelection supported HWhen transit network selection is supported, the user identifies the selected transit network(s) in the SETUP message. One Transit network selection information element is used to convey a single network identification. HThe user may specify more than one transit network. Each identification is placed in a separate information element. The call would then be routed through the specified transit networks in the order listed in the SETUP. For example, a user lists networks A and B, in that order, in two Transit network selection information elements within a SETUP message. The call is first routed to network A (either directly or indirectly), and then to network B (either directly or indirectly), before being delivered. HAs the call is delivered to each selected network, the corresponding transit selection may be stripped from the call establishment signalling, in accordance with the relevant internetwork signalling arrangement. The Transit network selection information element(s) is/are not delivered to the destination user. HNo more than four Transit network selection information elements may be used in a single SETUP message. HWhen a network cannot route the call because the route is busy, the network shall initiate call clearing in accordance with 5.3 with cause No. 34 "no circuit/channel available". HIf a network does not recognize the specified transit network, the network shall initiate call clearing in accordance with 5.3, with cause No.2 "no route to specified transit network". The diagnostic field shall contain a copy of the contents of the Transit network selection information element identifying the unreachable network. HA network may screen all remaining transit network selection information elements to: HHa)h  avoid routing loops, or  `    HHb)h  ensure an appropriate business relationship exists between selected networks, or  `   p HHc)h  ensure compliance with national and local regulations.  `   X HIf the transit network selection is of an incorrect format, or fails to meet criteria a), b) or c), the network shall initiate call clearing in accordance with 5.3, with cause No. 91 "invalid transit network selection". HWhen a user includes the Transit network selection information element, presubscribed default Transit network selection information (if any) is overridden. MAnnex D P D(to Recommendation Q.931) P =Extensions for symmetric call operationă ,ԌP D.1HAdditional message handling HIn symmetric applications, the SETUP message will contain a Channel Identification information element indicating a particular B Channel to be used for the call. A pointtopoint data link shall be used to carry the SETUP message. HThe procedure described in 5 for the user side should normally be followed. Where additional procedures are required, they are detailed below. D.1.1HB Channel selection symmetric interface HOnly B Channels controlled by the same D Channel will be the subject of the selection procedure. The selection procedure is as follows: Ha)  The SETUP message will indicate one of the following:   HH 1)hchannel is indicated, no acceptable alternative, or  `    HH 2)hchannel is indicated, any alternative is acceptable.  `   8 Hb)h  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. Hc)h  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.   Hd)h  If the SETUP message did not include all the information required to establish the call, B Channel is indicated in a SETUP ACKNOWLEDGE message sent across the interface. The additional call establishment information, if any, is sent in one or more INFORMATION messages transferred across the interface in the same direction as the SETUP message. When all call establishment information is received, a CALL PROCEEDING, ALERTING, or CONNECT message, as appropriate, is transferred across the interface. He)h  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. Hf)h  If the channel indicated in the CALL PROCEEDING or SETUP ACKNOWLEDGE message is unacceptable to the initiator of the call, it clears the call in accordance with  5.3. D.1.2HCall confirmation HUpon 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. HIf the indicated channel is acceptable to the initiator of the call, the initiator shall attach to the indicated B Channel. D.1.3HClearing by the called user employing userprovided tones/announcements HIn addition to the procedures described in  5.3.3, if the bearer capability is either audio or speech, the called user or private network may apply inband tones/announcements in the clearing phase. When inband tones/announcements are provided, the DISCONNECT message contains progress indicator No. 8 "inband information or appropriate pattern is now available" and the called user or private network proceeds similarly as stipulated in  5.3.4.1 for the network. D.1.4HActive indication HUpon receipt of a CONNECT message, the initiator of the call shall respond with a CONNECT ACKNOWLEDGE message and enter the Active State. D.2HTimers for call establishment HUser 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 92/Q.931 for the call establishment user side timers and procedures. D.3HCall collisions HIn 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. HFirst, one side of the interface will be designated the "network" and the other side of the interface will be designated the "user". Second, for the three possible scenarios where the same channel is indicated by combinations of preferred and exclusive from the user and network sides, the following procedure is used: Ha)  "network" preferred, "user" preferred: HX the "network" preferred channel is awarded and an alternate channel is indicated in the first response to the "user" SETUP message; Hb)  "network" exclusive, "user" exclusive: HX the "network" exclusive channel is awarded and the "user" SETUP message is cleared with a RELEASE COMPLETE message with cause HHX No. 34 "no circuit/channel available";  `   8 HHc)h  "network" preferred, "user" exclusive; or "network" exclusive, "user" preferred:  `   H HX the side of the interface with an exclusive indicator in a SETUP message is awarded the channel and an alternate channel is indicated in the first response to the side using a preferred indicator in the SETUP message. HChannel identification is allowed in both directions for ALERTING and CONNECT.  ,Ԍ HKAnnex E HN HB(to Recommendation Q.931) HN H=Network specific facility selectionă HThis annex describes the processing of the Networkspecific facilities information element. The purpose of this information element is to indicate which network facilities are being invoked. E.1HDefault provider HWhen the length of the network identification field is set to zero in the Networkspecific facilities information element, then the services identified in this information element are to be provided by the network side of the interface receiving the information element (default provider). If the Networkspecific facilities information element is recognized but the network facilities are not understood, then this information element is processed according to rules for nonmandatory information element content error (see  5.8.7.1). E.2HRouting not supported HSome networks may not support the routing to the remote network of the contents of the Networkspecific facilities information element. In this case, when a Networkspecific facilities information element is received, that information element is processed according to the rules for unimplemented non mandatory information elements (see  5.8.7.1). E.3HRouting supported HWhen Networkspecific facility information element routing is supported, the user identifies the network provider in this information element in the Q.931 SETUP message. One Networkspecific facility information element is used to identify a network provider. HThe user may specify more than one network provider by repeating the Networkspecific 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 Networkspecific facilities information elements in a call control message, there must be corresponding Transit network selection information elements in the SETUP message identifying those networks (or default call routing via A and B that was established prior to call establishment). HAs the signalling messages containing Networkspecific facilities information elements are delivered to the indicated remote network, they may be stripped from the signalling messages, in accordance with the relevant internetworking signalling arrangement. The Networkspecific facilities information elements may be delivered to the identified user. HNo more than four Networkspecific facilities information elements may be used in a SETUP message. When the information element is repeated, the order of presentation of the elements in a message is not significant. Further, there does not have to be a onetoone correspondence between Networkspecific facilities information elements and Transit network selection information elements. HIf a network cannot pass the information to the indicated network provider, either due to: H the network indicated is not part of the call path, or  8 HH© no mechanism exists for passing the information to identified network.  `   X HThe network shall initiate call clearing in accordance with  5.3, with cause No. 2 "no route to specified transit network". The diagnostic field may optionally contain a copy of the first 5 octets of the networkspecific facilities information element. HWhen the user includes the Networkspecific facilities information element in the SETUP message, presubscribed default service treatment (if any) is overridden. MAnnex F P D(to Recommendation Q.931) P CD Channel backup proceduresă F.HForeword HThe procedure defined in this annex can be used when nonassociated signalling is applied to multiple primary rate access arrangements. This feature can be provided on a subscription basis and is network dependent. F.1HGeneral HIn 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 F1/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 nonassociated signalling on these interfaces results in the example shown in Figure F2/Q.931. HWhen nonassociated signalling is employed, the reliability of the signalling performance for the ISDN interfaces controlled by the D Channel may be unacceptable. To improve the reliability, a D Channel backup procedure employing a standby D Channel is necessary. The next section describes the backup procedure which is optional for endpoints that use nonassociated signalling.  ,Ԍ FIGURE F3/Q.931