WPCL 2BJ|x ` Hx   x|@  6'6' Y  `  @  <AP IX112E AYY  `  @  <AP IX112E AY    ( SECTION 3 ISDN supplementary services Recommendation Q.730 X=ISDN SUPPLEMENTARY SERVICES Hx  8 1.General......................................................... 6 2.Usertouser signalling......................................... 7 3.Closed user group............................................... 12 4.Calling line identification (Presentation and restriction).................................. 28 5.Direct dialling in.............................................. 41 6.Call forwarding................................................. 42 7.Timeout table................................................... 58 Annex A: Signalling System No. 7 signalling procedure for the explicit G!Hinvocation of usertouser signalling services 1, 2 and 3.... 59 Hx2.HUsertouser signalling service 2.1HGeneral description of usertouser service  X HThe Usertouser Signalling Supplementary Service(s) provide(s) a means of communication between two users by using the ISDN User Part or SCCP protocols defined in Recommendations Q.711714 and Q.761764, 766. In order for the services to be usable, the services also have to be provided in the access protocol. HUsertouser signalling is used to exchange I.257 information between two users to provide the Usertouser Services described in Recommendation I.257. This section is specific to Signalling System No. 7 and the general description for services 13 may be found in the last mentioned Recommendation and the functional description in Recommendation Q.87. 2.1.1HUsertouser services HThree usertouser signalling services associated with circuitswitched calls that may be provided by the network users are: H1.  Service 1:  X HHusertouser signalling exchanged during the setup and clearing phases of a call, within ISDN User Part call setup and release messages as defined in Recommendation Q.763;  `  H2.  Service 2:   HHusertouser signalling exchanged during call setup between the Address Complete or Call Progress Messages and the Answer or Connect Messages, within Usertouser Information Messages; and  `  H3.  Service 3:   HHusertouser signalling exchanged while a call is in the active state, within Usertouser Information Messages.  `    HAll three services may be used separately or in any combination within a single call. As an option at call setup, users may be able to specify whether the requested Usertouser signalling service(s) is(are) essential or nonessential for the call (i.e. whether the call should be completed or not if usertouser information cannot be passed). Up to 128 octets of user information may be transferred in a message in each of the three services 1. The 128 octets does not include the usertouser information parameter name, the protocol control indicator or the length octets. 2.1.2HService request HService 1 may be requested implicitly by the presence of the usertouser information parameter in the Initial Address Message. An implicit request is "nonessential" by default. HExplicit requests of Service 1 and 2 must be in the Initial Address Message. Service 3 may be explicitly requested in the Initial Address Message during call setup. When there is an explicit request a single usertouser indicators parameter will be used with one of the following indications for each of the three services: H no information; H requested, nonessential; H requested, essential. 2.1.3HResponse (Confirmation) HIf explicit requests are used there should, in general, be explicit responses in a usertouser indicators parameter with one of the following indications for each of the three services: H no information; H provided; H not provided. HImplicit "not provided" responses occur when: H Service 1 has been implicitly requested and no usertouser information is received in call setup or release messages; or H Service 1, 2 or 3 has been explicitly requested and there is no indication of acceptance or rejection from call control. 2.1.4HFlow control HThe exchange of usertouser signalling is limited by flow control procedures provided on the access by either the user or network. The need for interexchange flow control procedures by the ISDN User Part for usertouser signalling should be evaluated. 2.2HProcedures for usertouser signalling associated with circuitswitched O%Pcalls HThe following sections only specify the signalling procedure used to implicitly invoke the Service 1. Signalling procedures defined to support the other services are specified in Annex A. 2.2.1HUsertouser signalling, Service 1 2.2.1.1 General characteristics HService 1 allows users to communicate with usertouser signalling by transferring usertouser information within ISDN User Part messages during the call setup and clearing phases. The usertouser signalling service provided is not a guaranteed service. If for any reason the combination of the basic plus supplementary service information causes the overall maximum length of the message to be exceeded then if the Usertouser Signalling Service 1 is included, then the service should be rejected. HH2.2.1.2 Usertouser signalling in the call setup phase implicit service request HProcedures for call setup are as described in Recommendation Q.764, Section 2, with the following changes: HService 1 may be invoked by sending the usertouser information parameter of variable length that is specified in Recommendation Q.763, Section 3.34 in an Initial Address Message that is requested in a call setup request from call control. This information parameter is transported across the network and delivered unchanged to the terminating call control for the called user. The usertouser indicators parameter will not be sent. HThe reception of a usertouser information parameter in a call setup ., or release request from the terminating call control is an implicit indication of the acceptance of Service 1. HThe user or network may not be able to interpret incoming usertouser information. In such situations, the user should discard this information without disrupting normal call handling. No specific signalling is provided by the network to accommodate this situation. 2.2.1.3 Interworking HIn the case of interworking with a nonISDN network, the "interworking" protocol control information will be returned to the originating exchange in the first appropriate message, e.g. an Address Complete Message. Two ISDN networks that interwork may have to retain knowledge of the service request until it is clear whether both can support the service. 2.2.1.4 Rejection of implicit service requests HNetworks that cannot provide the service requested may not return a rejection indication. 2.2.1.5 Usertouser signalling in the call clearing phase HA usertouser information parameter may be included in the Release Message. The usertouser information parameter received at the distant exchange in the Release Message is passed to the call control for the remote user. In the case of simultaneous clearing of the call, the Release Message may not reach the distant local exchange and the usertouser information will be lost. 2.2.1.6 Message flow diagrams HThe message flow diagrams are shown in Figure 1/Q.730. Figure 1/Q.730 shows the use of Usertouser Signalling Service 1 when implicitly requested in a pointtopoint configuration. H x H   H   Abbrev. Parameter Name  H  H   UUI usertouser information  H  H   Abbrev.x!Message Name  H  H   ACM Address Complete  H   ANM Answer  H   IAM Initial Address  H   REL Release  H   RLC Release Complete  H   HThe messages shown with dashed lines are not part of the ISDN User Part protocol and are for information only. For detailed information on the access protocol usertouser procedures the ISDN access protocol Recommendation should be examined. HHFIGURE 1/Q.730 HO H0UUS Service 1 (implicit request, called user is pointtopoint)ă HO HO Note 1 In case that an ALERTING indication is carried by a Call Progress Message, the usertouser information parameter may also be transported in the Call Progress Message. Note 2 In case that the called user is an automatic answering terminal user touser information parameter may be transported in a Connect Message. 2.2.2HInteraction with other supplementary services 2.2.2.1 Call forwarding services HInteractions with the call forwarding services are shown in the call forwarding protocol sections. 2.2.2.2 Call waiting service HInteractions with the call waiting service are shown in the call waiting protocol sections. (Call waiting is for further study.) 2.2.2.3 Other services HThere are no known interactions with services other than those listed. 2.2.2.4 State transition diagrams HThe state transition diagrams may be found in Stage 2 descriptions of the Usertouser Service. 3.HClosed user group (CUG)  .,Ԍ3.1HGeneral HThe Closed User Group (CUG) supplementary service enables a group of users to intercommunicate only among themselves or, as required, one or more users may be provided with incoming/outgoing access to users outside the group. HThe stage I definition of the CUG service is given in the Recommendation I.255 and its stage II service definition including network functions are given in the Recommendation Q.85. HThe realization of the CUG facilities is done by the provision of interlock codes and is based on various validation checks as defined in Q.85 at call setup, determining whether or not a requested call to or from a user having a CUG facility is allowed. In particular, a validation check is performed by verifying that both the calling and called parties belong to the CUG indicated by the interlock code. HThe data for each CUG that a user belongs to can either be stored at the local exchange to which the user is connected (decentralized administration of CUG data), or at dedicated point(s) in the network (centralized administration of CUG data). HIn section 3.2 the call setup procedure based on decentralized administration of CUG data is specified making use of the ISDN User Part as defined in Recommendations Q.761764 and Q.766. HIn section 3.3 the call setup procedure based on centralized administration of CUG data is specified making use of the ISDN User Part as defined in Recommendations Q.761764 and Q.766 and the Transaction Capabilities Application Part as defined in Recommendations Q.771775. HIn section 3.4 the application service element (ASE) on top of Transaction Capabilities Application Part for CUG validation check with centralized administration of CUG data is specified. 4.XHGeneral description of the Calling Line Identity Presentation and Restriction service HCalling Line Identification Presentation (CLIP) is a supplementary service offered to the called party which provides the calling party's ISDN number, possibly with additional address information (i.e. subaddress), to the called party. HCalling Line Identification Restriction (CLIR) is a supplementary service offered to the calling party to restrict presentation of the calling party's ISDN number, possibly with additional address information (i.e. subaddress), to the called party. HThe stage 1 definitions for the CLIP and CLIR services are given in the Recommendation I.254 and the stage 2 service definitions including network functions, are given in Recommendation Q.84. This stage 3 description of CLIP and CLIR use the ISDN User Part protocol as defined in Recommendations Q.761764 and Q.766. 4.1HDescription of the Calling Line Identity Presentation (CLIP) service HCalling Line Identity Presentation (CLIP) is a user facility that enables a user to be informed on incoming calls, of the address of the calling party. When provided the facility applies to all incoming calls except for when the calling party has the Calling Line Identity Restriction (CLIR) facility active [see section 4.2 below] or the complete number of the calling party is not available at the destination exchange. HThe Calling Line Identity (CLI) is generally the ISDN number of the calling party (with possible additional address information, i.e. subaddress) which may be provided by the network or partly by the calling party. HIn the case where a national network does not always provide the CLIP facility, the included CLI may be the known part of the ISDN number at the interworking point (e.g. Trunk Code). HIn the case where a calling party is an ISPBX, the network may send the ISDN number of the PABX attendant operator or, if provided by the calling party, the DDI number of the extension as the CLI. HWhen the CLI is provided by the user or ISPBX it is verified or screened for validity by the network, i.e. the CLI provided by the user is within the known number range for that user. Hi)h  If the user provided CLI is valid the Calling Number Parameter field contains the CLI in the Address Signal with the Screening indicator set to "user provided verified and passed". Hii)  If the user provided CLI is not valid or screened the originating exchange defaults to the network provided CLI for the Address Signals of the Calling Party Number parameter field with the Screening indicator set to "network provided". HWhen the CLI is provided by the network the originating exchange includes the stored CLI set against the calling party and sets the screening indicator to "network provided". HThe CLI sent to the called user should contain all the necessary digits to enable a call to be established in the reverse direction. Note This may not always be possible if, for example, the DDI extension of an ISPBX is not provided by the calling party. HInformation indicating that a subscriber has the user access to the CLIP facility is available in the exchange to which the subscriber is connected. 4.1.1HCall setup procedure HThe call control procedure and the information included in Call Control Messages vary depending on whether the CLI is included in the Initial Address Message and also whether the calling party has indicated a request to use the CLIR facility for this call. HTwo different call control procedures can be used to provide the CLIP facility. Both procedures are specified for international use, however, the first method is to be preferred.   4.1.1.1 The Calling Line Identity is included in the Initial Address Message HWhen the CLI is available for insertion in the IAM the systematic inclusion of this parameter, in the IAM, is recommended. However, it is realized that under certain interworking conditions the CLI may only be available subsequent to the transmission of the IAM. HIn this situation, to avoid unnecessary unsuccessful requests for the CLI the following procedures are recommended: Ha)h  If the CLI cannot be included in the IAM (for any reason) but is available and may be requested with a good chance of receiving it, then the optional field "calling party number parameter" should not be included in the IAM. Hb)h  If the CLI cannot be transferred (because it is not allowed to be passed or because the national network cannot provide the number), then the optional field "calling party number parameter" should be included in the IAM with the indication "presentation restricted" or "address not available" set as appropriate in the Address Presentation Restricted Indicator. HThe CLI is sent to the called party in accordance with the usernetwork interface protocol. HFor calls between networks (e.g. an outgoing ISC as referred to in b) above) the outgoing gateway exchange may remove any CLI digits from the IAM and indicate in the calling party number parameter that presentation is restricted. HInterworking exchanges may generate only part of the CLI for inclusion in the IAM (e.g. trunk code). This will be indicated in the number incomplete indicator in the Calling Party Number Parameter field. HIn the case where the destination exchange receives only part of the CLI, (it is assumed to be the most significant part), the CLI is forwarded to the called party with the appropriate indications set. 4.1.1.2 The Calling Line Identity is not included in the Initial Address M$NMessage HIn the case where the CLIP facility is applied, and the IAM has indicated that the CLI may be available, an Information Request Message is sent towards the originating exchange with the Information Request Indicator Parameter field bit set to calling party address requested. HWhen receiving the request for Calling Party Address and the CLI is available, the originating/interworking exchange sends an information message containing the Calling Party Number Parameter field with the appropriate indications and CLI included. xxxx NANNEX A Q C(to Signalling System No. 7) Q 8Signalling procedure for the explicit invocation ofă <usertouser signalling services 1, 2 and 3ă A.1HUsertouser signalling service A.1.1HGeneral description of usertouser service HSee Recommendation Q.730, sections 2.12.2. A.2HProcedures for usertouser signalling associated with circuit switched calls A.2.1HUsertouser signalling, Service 1 A.2.1.1 General characteristics HService 1 allows users to communicate with usertouser signalling by transferring usertouser information within ISDN user part messages during the call setup and clearing phases. The usertouser signalling service provided is not a guaranteed service. If for any reason the combination of the basic plus supplementary service information causes the overall maximum length of the message to be exceeded then if the Usertouser Signalling Service 1 is included the service should be rejected. A.2.1.2 Usertouser signalling, Service 1 explicit service request HProcedures for call setup are as described in Recommendation Q.764, section 2 with the following changes: HOn call setup the Initial Address Message will contain the usertouser indicators parameter with Service 1 indicated as "requested essential/not essential" and Services 2 and 3 indicated as "no information". The service request will be received from call control at the originating exchange and will be passed to the call control at the terminating exchange. HIf the called user or network can support the transfer of usertouser, a Service 1 acceptance will be returned to the originating exchange in an Address Complete or Call Progress Message for the pointtopoint case or the Answer or Connect Message in the pointtomultipoint case with the indication "Service 1 provided" in the usertouser indicators parameter. Services 2 and 3 will be indicated as "no information" in the usertouser indicators parameter. These explicit indications shall be forwarded to the call control at the originating exchange. HUsertouser information may be contained in any of the messages that may be transferred in the call setup phase. A.2.1.3 Interworking HIn the case of interworking with a nonISDN network, the "interworking" protocol control information will be returned to the originating exchange in the first appropriate message, e.g., and Address Complete Message. Two ISDN networks that interwork may have to retain knowledge of the service request until it is clear whether both can support the service. A.2.1.4 Rejection of explicit service requests  H  If the called user or network does not understand the Service 1 request then the Address Complete or Call Progress Message returned to the originating exchange shall not include either a Service 1 acceptance or rejection. This type of response will be taken as an implicit rejection of Service 1. (Note The Study Group XVIII service description does not allow this implicit rejection.) HIf the network or called user cannot support Service 1, and it was requested with a nonessential indication, a Service 1 rejection indication is returned in the Address Complete or Call Progress Message with the indication "Service 1 not provided" in the usertouser indicators parameter. HIf the Service 1 request is indicated as essential and the called user or network cannot support it a Release Message is sent with cause code 50, "requested facility not subscribed", cause code 29, "facility rejected by the network" or cause code 69, "requested facility not implemented" and the diagnostic containing the usertouser indicators parameter. A.2.1.5 Usertouser signalling in the call clearing phase HA usertouser information parameter may be included in the Release Message. The usertouser information parameter received at the distant exchange in the Release Message is passed to the call control for the remote user. In the case of simultaneous clearing of the call the Release Message may not reach the distant local exchange and the usertouser information will be lost. A.2.2HUsertouser signalling, Service 2 A.2.2.1 General characteristics HService 2 allows the users to communicate with usertouser signalling by transferring up to two usertouser information messages in each direction during the call setup phase. As a network option, usertouser information may be delivered to the called party after the call is answered to accommodate situations where the information was sent at approximately the same time as the call was answered. This service allows either an implicit or explicit rejection. HService 2 is only applicable when a pointtopoint configuration exists at the usernetwork interface at the terminating exchange. A.2.2.2 Call setup HProcedures for call setup are as described in Recommendation Q.764, section 2 with the following changes: HOn call setup the Initial Address Message will contain the usertouser indicators parameter with Service 2 indicated as "requested essential/not essential" and Services 1 and 2 indicated as "to information" 2. The service request will be received from call control. The service request will be passed to call control at the terminating exchange. HIf the called user or network can support the transfer of usertouser information, a Service 2 acceptance will be returned to the originating exchange in an Address Complete or Call Progress Message with the indication "Service 2 provided" in the usertouser indicators parameter 3. Services 1 and 3 will be indicated as "no information" in the usertouser indicators parameter. These explicit indications shall be forwarded to the call control at the originating exchange. A.2.2.3 Service rejection A.2.2.3.1 Pointtopoint calls HIf the called user or network does not understand the Service 2 request then the Address Complete or Call Progress Message returned to the originating exchange shall not include either a Service 2 acceptance or rejection. This type of response will be taken as an implicit rejection of Service 2. HIf the network or called user cannot support Service 2, and it was requested with a nonessential indication, a Service 2 rejection indication is returned in the Address Complete or Call Progress Message with the indication "Service 2 not provided" in the usertouser indicators parameter 4. (Note The Study Group XVIII service description does not allow this implicit rejection.) HIf the Service 2 request is indicated as essential and the called user or network cannot support it a Release Message is sent with cause code 50, "requested facility not subscribed" cause code 29, "facility rejected by the network" or cause code 69, "requested facility not implemented" and the diagnostic containing the usertouser indicators parameter. A.2.2.3.2 Pointtomultipoint calls HIf the call is pointtomultipoint then Service 2 cannot be provided at the called party because the user is not identified until the user is connected. Consequently, Service 2 must be rejected using the pointtopoint procedures. The cause value in this case is code 88, "incompatible destination". A.2.2.4 Interworking HIn the case of interworking with a nonISDN network. The "interworking" protocol control information will be returned to the originating exchange in the appropriate message, e.g., an Address Complete Message. Two ISDN networks that interwork may have to retain knowledge of the service request until it is clear whether both can support the service. A.2.2.5 Transfer of messages containing usertouser information HOnce acceptance of Service 2 has been transmitted across the network, both of the involved users can transfer usertouser information between themselves. Within the network the usertouser information parameter will be carried in a Usertouser Information Message. The network provides for the transfer of these messages from the calling to the called side and vice versa. HThe Usertouser Information Message format can be found in Recommendation Q.763, Table 20/Q.763. HIf Service 2 is provided, no more than two Usertouser Information Messages carrying usertouser information parameters may be transmitted in each direction during the call setup phase. If more than two messages are received during call setup, the additional messages are discarded. If only Service 2 has been requested, one of the messages may also be received and passed after the answer state has been reached. HNo transfer of usertouser information can occur until the service is acknowledged. A.2.3  Usertouser signalling, Service 3 A.2.3.1 General characteristics HService 3 allows the users to communicate with usertouser signalling by transferring Usertouser Information Messages in each direction during the active phase of the call. This service allows either an implicit or explicit rejection. HService 3 allows the service to be requested either during call setup or after call setup. However, Service 3 should not be requested after call setup if it has been rejected during the call setup phase. A.2.3.2 Service 3 requested during call setup HProcedures for call setup are as described in Recommendation Q.764, Section 2 with the following changes: HOn call setup the Initial Address Message will contain the usertouser indicators parameter with Service 3 indicated as "requested essential/not essential" and Services 1 and 2 indicated as "no information 5". The service request will be received from call control at the originating exchange. The service request will be passed to the call control at the terminating exchange. HIf the called user or network can support the transfer of usertouser information, a Service 3 Acceptance will be returned to the originating exchange in an Answer or Connect Message with the indication "Service 3 provided" in the usertouser indicators parameter 6. Services 1 and 2 will be indicated as "no information" in the usertouser indicators parameter. These explicit indications shall be forwarded to the call control at the originating exchange. A.2.3.3 Rejection of Service 3 when requested during call setup HIf the called user or network does not understand the Service 3 request then the Address Complete Call Progress Message, Answer or Connect Message, returned to the originating exchange shall not include either a Service 3 acceptance or rejection. This type of response will be taken as an implicit rejection of Service 3. HIf the network or called user cannot support Service 3, and it was requested with a nonessential indication, a Service 3 rejection indication is returned in the Address Complete, Call Progress Message, Answer or Connect with the indication "Service 3 not provided" in the usertouser indicators parameter 7. (Note The Study Group XVIII service description does not allow this implicit rejection.) HIf the Service 3 request is indicated as essential and the called user or network cannot support it a Release Message is sent with cause code 50, "requested facility not subscribed", cause code 29, "facility rejected by the network" or cause code 69, "requested facility not implemented" and the diagnostic containing the usertouser indicators parameter. A.2.3.4 Service 3 requested after call setup HAfter call setup has been completed either the calling or called party may request to transfer Service 3 information. On reception of the request from call control the ISDN User Part sends a Facility Request Message containing the facility indicator parameter indicating usertouser service and a usertouser indicators parameter requesting Service 3 to the distant local exchange using the appropriate transport method. The facility request will contain the usertouser indicators parameter with Service 3 indicated as "requested essential/not essential" and Services 1 and 2 indicated as "no information" 8. On receipt of the Facility Message at the distant exchange call control will be notified which will then notify the remote user. If the user wishes to support Service 3 during the active phase, a Service 3 acceptance will be returned to call control. On notification of the acceptance by call control the ISDN User Part will generate a Facility Accepted Message with the indication "Service 3 provided" in the usertouser indicators parameter1. Services 1 and 2 will be indicated as "no information" in the usertouser indicators parameter. On the receipt of the message this explicit acceptance indication shall be forwarded to call control which will then notify the requesting user. A.2.3.5 Rejection of Service 3 when requested after call setup HIf the requested user or network does not understand the Service 3 request then no message is returned. This response shall be taken as an implicit rejection of the service request. HIf the network or requested user cannot support Service 3, and it was requested with a nonessential indication, a Service 3 rejection indication is returned in the Facility Reject Message with the indication "Service 3 not provided" in the usertouser indicators parameter 9. HIf the call control does not indicate acceptance or rejection the network shall not return any explicit rejection to the exchange. Note 1 The Stage 1 service description does not allow this implicit rejection. Note 2 The handling of essential/non essential Service 3 request is not yet consistent with the Stage 1 service description. A.2.3.6 Interworking HIn the case of interworking with a nonISDN network an "interworking" protocol control indicator will be returned to the originating exchange in the first appropriate message1. If Service 3 was requested after call setup, a Facility Reject Message is returned1. Two ISDN networks that interwork may have to retain knowledge of the service request until it is clear whether both can support the service. A.2.3.7 Transfer of messages containing usertouser information HOnce acceptance of Service 3 has been transmitted across the network, both of the involved users can transfer usertouser information between themselves. Within the network the usertouser information parameter will be carried in a Usertouser Information Message. The network provides for the transfer of these messages from the calling to the called side and vice versa. HThe Usertouser Information Message format can be found in RecommendationQ.763, Table 20/Q.763. A.2.4HRequesting usertouser signalling Services 1, 2 and 3 HThis section describes procedures for requesting Services 1, 2 and 3. Note Usertouser Service 1 implicit request/response procedures are also found in Section 2.2.1. Only explicit Service 1 requests may follow the procedure in this section. A.2.4.1 Call establishment HProcedures for call establishment are described in sections A.2.1.2, A.2.2 and A.2.3.2 with the following modifications: HOn service request one usertouser indicators parameter will be sent with each service being indicated as "requested, essential/non essential". HIf the called user can support the indicated services, then all three services will be indicated as "provided" in the usertouser indicators parameter in the Address Complete or Call Progress Message. Alternatively, the Address Complete or Call Progress Message may indicate "Service 3, no information" and "Service 3 provided" in the Answer or Connect Message as provided in section A.2.3.2. In the case that the call is to multipoint users, the acknowledgement of Services 1 and 3 shall be delayed until the Answer or Connect Message is sent. A.2.4.2 Service Rejection HIf the called user or network does not understand the service requested, then the Address Complete, Call Progress, Answer or Connect Messages returned will not include either service(s) acceptance or rejection. This type of response will be taken as an implicit rejection of all services. HIf the called user or network does not understand a specific service request, that specific service is implicitly rejected following the procedures of sections 2.2.1.6, 2.2.2.3 and 2.2.3.3. Alternatively, if the network or called user cannot support one or more service requests and the service requests were indicated as nonessential, then the rejection may be provided in the Address Complete or Call Progress Messages. (In the case of a call to multi point users only Service 2 may be rejected in this way, Services 1 and 3 must be rejected in the Answer or Connect Message if the called user is furnishing the rejection.) The services may also be rejected following the procedures of sections A.2.1.4, I.2.2.3 and A.2.3.3. HIf any or all of the services requested is indicated as essential and the called user or network cannot support one or more of the services, a Release Message is sent with cause code 29, "facility rejected by the network", cause code 50, "requested facility not subscribed", or cause code 69,"requested facility not implemented" and the diagnostic containing the usertouser indicators parameter. HIf the call control does not indicate Service 1, 2 or 3 acceptance or rejection prior to the sending of the Address Complete, Call Progress, Answer or Connect Message, then no indication of service acceptance or rejection shall be returned for the specific service(s). A.2.4.3 Interworking HIn the case of interworking with a nonISDN network, the "interworking" protocol control information will be returned to the originating exchange in the first appropriate message, e.g., an Address Complete Message. Two ISDN networks that interwork may have to retain knowledge of the service request until it is clear whether both can support the services. A.2.4.4 Transfer of Usertouser information messages HThe procedures for the transfer of Usertouser Information Messages is covered in sections A.2.2.5 and A.2.3.7. A.2.5HUsertouser information transport methods for Services 2 and 3 HThe transport methods for Services 2 and 3 may be found in  3 of Recommendation Q.764. A.2.6HMessage flow diagrams HThe message flow diagrams are shown in Figures A1 to A7. HFor Usertouser Signalling Service 2 and 3 the figures only show ISDN user part messages required for basic call control and usertouser signalling and are not meant to imply any particular transfer method. The parameters and indicators shown are for the Usertouser Signalling Service only, i.e. any parameters or message associated with the various transport methods are not shown. HThe following notes apply to Figures 1 to 7: Note 1 In case that an ALERTING indication is carried by a Call Progress Message the usertouser indicators parameter and/or the usertouser information parameter may also be transported in the Call Progress Message. Note 2 In case that the called user is an automatic answering terminal usertouser indicators parameter and/or usertouser information parameter may be transported in a Connect Message. HFigure A1 shows a successful use of usertouser Signalling Service 1 when explicitly requested in a pointtopoint configuration. HFigure A2 shows both the successful and unsuccessful use of usertouser Signalling Service 2 in a pointtopoint configuration. HFigure A3 shows an unsuccessful use of usertouser Signalling Service 2 in a pointtomultipoint configuration. This unsuccessful case is shown because the network reactions will be the same in all similar cases. HFigure A4 shows both successful and unsuccessful cases for userto user Signalling Service 3 when the service is nonessential in a pointtopoint configuration. HFigure A5 shows a successful use of usertouser Signalling Service 3 after the call is active in a pointtopoint configuration. HFigure A6 shows a successful use of usertouser signalling Services 1, 2 and 3 and where all services are nonessential in a pointtopoint configuration. HFigure A7 shows successful use of usertouser signalling Services 1 and 3 and unsuccessful use of Service 2 in a pointtomultipoint configuration. It should be noted again that Service 2 will not work in a pointtomultipoint configuration. HxРNote During an interim period of time, networks may support a lesser number (e.g. 32 octets) due to protocol restrictions; 32 octets will always be supported. Restrictions may apply to calls requesting usertouser information more than 32 octets. The connection request parameter will be included if COSCCP method is selected, or the call reference parameter will be included if CLSCCP method is selected. The SCCP connection confirm message will be returned if COSCCP method is selected. The SCCP connection refused message will be returned if COSCCP method is selected. The connection request parameter will be included if CLSCCP method is selected or the call reference parameter will be included if CLSCCP method is selected. The SCCP connection confirm message will be returned if COSCCP method is selected. The SCCP connection refused message will be returned if COSCCP method is selected. The Connection Request parameter will be included if COSCCP method is selected, or the Call Reference parameter will be included if CLSCCP method is selected. The SCCP connection refused message will be returned if COSCCP method is selected.