.rs .\" Troff code generated by TPS Convert from ITU Original Files .\" Not Copyright ( c) 1991 .\" .\" Assumes tbl, eqn, MS macros, and lots of luck. .TA 1c 2c 3c 4c 5c 6c 7c 8c .ds CH .ds CF .EQ delim @@ .EN .nr LL 40.5P .nr ll 40.5P .nr HM 3P .nr FM 6P .nr PO 4P .nr PD 9p .po 4P .rs \v | 5i' .sp 2P .LP 3.4 \fIASE for CUG service with centralized administration of CUG data\fR .sp 1P .RT .sp 1P .LP 3.4.1 \fIGeneral\fR .EF '% Fascicle\ VI.8\ \(em\ Rec.\ Q.730'' .OF '''Fascicle\ VI.8\ \(em\ Rec.\ Q.730 %' .sp 9p .RT .PP The application service element (ASE) for CUG service with centralized administration of CUG data provides the procedures between the exchanges and the CUG management centers (CMC) for CUG validation check. .PP Two similar but different procedures are defined for CUG validation check. One is the procedure between the originating exchange of a CUG call and a CMC to check the qualification of the calling user to establish the present CUG call. The other is the procedure between the terminating exchange of a CUG call and a CMC to check the qualification of the called user to accept the present CUG call. One TCAP (Transaction Capabilities Application Part) operation is defined for each of these procedures. .RT .sp 1P .LP 3.4.2 \fIProcedures\fR .sp 9p .RT .PP To check the qualification of the calling user the originating exchange initiates the transaction to the CMC by invocation of the CUG Check\ 1 operation with appropriate parameters. The CMC, in response to this invocation, terminates the transaction with the check result. The check result contains .PP the interlock code and other parameters in case of successful check or an error cause in case of unsuccessful check. Figure\ 4/Q.730 shows the primitive flows between the ASE and the TCAP at the exchange and between the ASE and the TCAP at the CMC for this case. Table\ 3/Q.730 shows the result of the validation check which is performed by the CMC, according to various parameters, concerning the calling user. .PP To check the qualification of the called user, the terminating exchange initiates the transaction to the CMC by invocation of the CUG Check\ 2 operation with appropriate parameters. The CMC, in response to this invocation, terminates the transaction with the check result. The check result contains the index number for the called user and other parameters in case of successful check or an error cause in case of unsuccessful check. Figure\ 5/Q.730 shows the primitive flows between the ASE and the TCAP at the exchange and between the ASE and the TCAP at the CMC for this case. Table\ 4/Q.730 shows the result of the validation check which is performed by the CMC, according to various parameters, concerning the called user. .RT .LP 3.4.3. \fIOperations\fR .sp 1P .RT .sp 2P .LP 3.4.3.1 \fIDescription of operations\fR .sp 1P .RT .sp 1P .LP 3.4.3.1.1 \fICUG Check 1\fR .sp 9p .RT .PP This operation is used between the originating exchange of a call and a dedicated point for CUG validation check of the calling user. .RT .sp 1P .LP 3.4.3.1.2\ \ \fICUG Check 2\fR .sp 9p .RT .PP This operation is used between the terminating exchange of a call and a dedicated point for CUG validation check of the called user. .RT .LP .rs .sp 11P .ad r Blanc .ad b .RT .LP .bp .LP .ce \fBH.T. [T3.730]\fR .ce TABLE\ 3/Q.730 .ce \fBValidation check of CUG call concerning the\fR .ce \fBcalling user\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(36p) | cw(48p) sw(48p) sw(48p) sw(48p) , ^ | c | c | c | c. Calling user class Indication from calling user CUG call with index CUG | | A call with index CUG | | A call without index Non\(hyCUG call _ .T& lw(36p) | cw(48p) | cw(48p) | cw(48p) | cw(48p) . CUG with pref. { CUG call | ua\d\u)\d\ | uc\d\u)\d IC: specified CUG } { CUG call | ua\d\u)\d\ | uc\d\u)\d IC: specified CUG } { CUG call | ua\d\u)\d IC: preferential CUG } CUG call IC: preferential CUG _ .T& lw(36p) | cw(48p) | cw(48p) | cw(48p) | cw(48p) . CUG without pref. { CUG call | ua\d\u)\d\ | uc\d\u)\d IC: specified CUG } { CUG call | ua\d\u)\d\ | uc\d\u)\d IC: specified CUG } Return Error cause ##62 Return Error cause ##62 _ .T& lw(36p) | cw(48p) | cw(48p) | cw(48p) | cw(48p) . CUG | | AI with pref. { CUG | | A | ua\d\u)\d\ | uc\d\u)\d IC: specified CUG } { CUG | | A | ua\d\u)\d\ | uc\d\u)\d IC: specified CUG } { CUG | | A | ua\d\u)\d IC: preferential CUG } { CUG | | A | ub\d\u)\d IC: preferential CUG } _ .T& lw(36p) | cw(48p) | cw(48p) | cw(48p) | cw(48p) . CUG | | AI without pref. { CUG | | A | ua\d\u)\d\ | uc\d\u)\d IC: specified CUG } { CUG | | A | ub\d\u)\d\ | uc\d\u)\d IC: specified CUG } Non\(hyCUG call Non\(hyCUG call _ .T& lw(36p) | cw(48p) | cw(48p) | cw(48p) | cw(48p) . CUG | | AE with pref. { CUG call | ua\d\u)\d\ | uc\d\u)\d IC: specified CUG } { CUG | | A | ub\d\u)\d\ | uc\d\u)\d IC: specified CUG } { CUG | | A | ub\d\u)\d IC: preferential CUG } { CUG call | ub\d\u)\d IC: preferential CUG } _ .T& lw(36p) | cw(48p) | cw(48p) | cw(48p) | cw(48p) . CUG | | AE without pref. { CUG call | ua\d\u)\d\ | uc\d\u)\d IC: specified CUG } { CUG | | A | ub\d\u)\d\ | uc\d\u)\d IC: specified CUG } Non\(hyCUG call Return Error cause ##62 _ .T& lw(36p) | cw(48p) | cw(48p) | cw(48p) | cw(48p) . No CUG Return Error cause ##50 Return Error cause ##50 Return Error cause ##50 Non\(hyCUG call .TE .LP OAE Outgoing access, explicit request required OAI Outgoing access, implicit outgoing access for all calls IC Interlock code of the CUG selected .LP \fINote\fR \ \(em\ As IA (incoming access) attribute of the calling user is of no concern for this validation check, CUG | | A class is equivalent to CUG, and CUG | | A/IA class is equivalent to CUG | | A in this table. .LP | ua\d\u)\d In case of OCB (outgoing calls barred) within the CUG, Return Error with cause\ ##53. .LP | ub\d\u)\d In case of OCB within the CUG, the call is interpreted as a non\(hyCUG call. .LP | uc\d\u)\d In the case where the specified index does not match any of the registered indices, Return Error with cause\ ##90. .nr PS 9 .RT .ad r \fBTableau 3/Q.730 [T3.730], p. 1\fR .sp 1P .RT .ad b .RT .LP .rs .sp 13P .ad r Blanc\fR .ad b .RT .LP .bp .ce \fBH.T. [T4.730]\fR .ce TABLE\ 4/Q.730 .ce \fBValidation check of CUG call concerning the\fR .ce \fBcalled user\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(36p) | cw(30p) | cw(30p) sw(36p) sw(30p) sw(30p) sw(36p) , ^ | ^ | c s | c | ^ , ^ | ^ | c | c | c | c | c. CUG call indication in IAM CUG match check Class of called user CUG CUG | | A No ICB ICB No ICB ICB No CUG _ .T& lw(36p) | cw(30p) | cw(30p) | cw(36p) | cw(30p) | cw(30p) . CUG with OA not allowed Match CUG call Return Error cause\ ##55 CUG call Return Error cause\ ##55 .T& cw(36p) | cw(30p) | cw(30p) | cw(36p) | cw(30p) | cw(30p) . No match Return Error cause\ ##87 Return Error cause\ ##87 Return Error cause\ ##88 _ .T& lw(36p) | cw(30p) | cw(30p) | cw(36p) | cw(30p) | cw(30p) . CUG with OA allowed Match CUG call Return Error cause\ ##55 CUG | | A call Non\(hyCUG call .T& cw(36p) | cw(30p) | cw(30p) | cw(36p) | cw(30p) | cw(30p) . No match Return Error cause\ ##87 Non\(hyCUG call Non\(hyCUG call _ .T& lw(36p) | cw(30p) | cw(66p) | cw(60p) | cw(36p) . Non\(hyCUG \(em Return Error cause\ ##87 Non\(hyCUG call Non\(hyCUG call _ .T& lw(12p) | lw(216p) . IA Incoming access .T& lw(12p) | lw(216p) . OA Outgoing access .T& lw(12p) | lw(216p) . ICB Incoming calls barred .T& lw(24p) | lw(204p) . Match { The interlock code in the received IAM matches one of the CUGs to which the called user belongs. } .T& lw(24p) | lw(204p) . No match { The interlock code does not match any of the CUGs to which called user belongs. } .TE .nr PS 9 .RT .ad r \fBTableau 4/Q.730 [T4.730], p. 2\fR .sp 1P .RT .ad b .RT .LP .rs .sp 15P .ad r Blanc .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure 4/Q.730, p. 3\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure 5/Q.730, p. 4\fR .sp 1P .RT .ad b .RT .LP .bp .sp 2P .LP 3.4.3.2 \fIParameters of operations and outcomes\fR .sp 1P .RT .sp 1P .LP 3.4.3.2.1 \fICUG Check 1\fR .sp 9p .RT .LP .sp 4 .ce \fBH.T. [T5.730]\fR .ce .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(78p) | cw(66p) | cw(36p) | cw(48p) . CUG Check 1 Timer = x seconds Class = 1 Code = 00000001 _ .T& lw(78p) | cw(66p) | cw(36p) | cw(48p) . Parameters with Invoke Optional/ Mandatory Reference (\(sc) _ .T& lw(78p) | cw(66p) | cw(36p) | cw(48p) . { CallingUserIndex CUGCallIndicator CallingPartyNumber } O M M 3.4.3.3.1 3.4.3.3.2 3.4.3.3.3 _ .T& lw(78p) | cw(66p) | cw(36p) | cw(48p) . Parameters with Return Result _ .T& lw(78p) | cw(66p) | cw(36p) | cw(48p) . { CUGInterlockCode CUGCallIndicator } M M 3.4.3.3.5 3.4.3.3.2 _ .T& lw(78p) | cw(66p) | cw(36p) | cw(48p) . Linked Operations _ .T& lw(78p) | cw(66p) | cw(36p) | cw(48p) . Not applicable _ .T& lw(78p) | cw(66p) | cw(36p) | cw(48p) . Errors _ .T& lw(78p) | cw(66p) | cw(36p) | cw(48p) . UnsuccessfulCheck 3.4.3.3.7 _ .TE .nr PS 9 .RT .ad r \fBTable [T5.730], p.\fR .sp 1P .RT .ad b .RT .LP .sp 5 CUGCheck1 \ \ OPERATION .LP PARAMETER SEQUENCE { CallingUserIndex OPTIONAL, CUGCallIndicator, { CallingPartyNumber\ } RESULT SEQUENCE { CUGInterlockCode CUGCallIndicator\ } ERRORS { UnsuccessfulCheck\ } ::= 1 .LP .rs .sp 9P .ad r Blanc .ad b .RT .LP .bp .sp 1P .LP 3.4.3.2.2\ \ \fICUG Check 2\fR .sp 9p .RT .ce \fBH.T. [T6.730]\fR .ce .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(78p) | cw(66p) | cw(36p) | cw(48p) . CUG Check 2 Timer = x seconds Class = 1 Code = 00000010 _ .T& lw(78p) | cw(66p) | cw(36p) | cw(48p) . Parameters with Invoke Optional/ Mandatory Reference (\(sc) _ .T& lw(78p) | cw(66p) | cw(36p) | cw(48p) . { CUGInterlockCode CUGCallIndicator CalledPartyNumber } M M M 3.4.3.3.5 3.4.3.3.2 3.4.3.3.4 _ .T& lw(78p) | cw(66p) | cw(36p) | cw(48p) . Parameters with Return Result _ .T& lw(78p) | cw(66p) | cw(36p) | cw(48p) . { CalledUserIndex CUGCallIndicator } O M 3.4.3.3.6 3.4.3.3.2 _ .T& lw(78p) | cw(66p) | cw(36p) | cw(48p) . Linked Operations _ .T& lw(78p) | cw(66p) | cw(36p) | cw(48p) . Not applicable _ .T& lw(78p) | cw(66p) | cw(36p) | cw(48p) . Errors _ .T& lw(78p) | cw(66p) | cw(36p) | cw(48p) . UnsuccessfulCheck 3.4.3.3.7 _ .TE .nr PS 9 .RT .ad r \fBTable [T6.730], p.\fR .sp 1P .RT .ad b .RT .LP .sp 1 CUGCheck2 \ \ OPERATION .LP PARAMETER SEQUENCE { CUGInterlockCode, CUGCallIndicator, { CalledPartyNumber\ } RESULT SEQUENCE { CalledUserIndex OPTIONAL, CUGCallIndicator\ } ERRORS { UnsuccessfulCheck\ } ::= 2 .sp 2P .LP 3.4.3.3 \fIParameter coding\fR .sp 1P .RT .sp 1P .LP 3.4.3.3.1\ \ The CallingUserIndex is the local index at the calling user to identify a particular CUG he belongs to. .sp 9p .RT .ce \fBH.T. [T7.730]\fR .ce .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(180p) | cw(48p) . CallingUserIndex Code = 10000001 _ .T& lw(78p) | lw(150p) . Contents Meaning _ .T& lw(78p) | lw(150p) . IA5 Character String { One IA5 character represents one digit of the CUG index value } _ .TE .nr PS 9 .RT .ad r \fBTable [T7.730], p.\fR .sp 1P .RT .ad b .RT .LP .sp 1 CallingUserIndex ::= [1]\ IMPLICIT LocalIndex LocalIndex ::= IA5\ STRING \(em\(em\ \fIThe maximum number of digits is four.\fR .bp .sp 1P .LP 3.4.3.3.2\ \ The CUGCallIndicator indicates whether the call is requested or designated as a CUG call and whether outgoing access is requested or allowed. .sp 9p .RT .ce \fBH.T. [T8.730]\fR .ce .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(180p) | cw(48p) . CUGCallIndicator Code = 10000010 _ .T& lw(78p) | lw(150p) . Contents Meaning _ .T& lw(78p) | lw(150p) . 00000000 Non\(hyCUG call \fR .T& lw(78p) | lw(150p) . 00000001\fR Non\(hyCUG call \fR .T& lw(78p) | lw(150p) . 00000010\fR CUG call with outgoing access .T& lw(78p) | lw(150p) . 00000011 { CUG call without outgoing access } _ .TE .nr PS 9 .RT .ad r \fBTable [T8.730], p.\fR .sp 1P .RT .ad b .RT .LP .sp 1 CUGCallIndicator ::= [2] IMPLICIT CallIndicator CallIndicator ::= INTEGER { NonCUGCall (0), NonCUGCall(1), outgoingAccessAllowedCUGCall (2), outgoingAccessNotAllowedCUGCall (3)\ } .sp 1P .LP 3.4.3.3.3\ \ The CallingPartyNumber is the network (e.g.\ E.164) number of the calling party. It is expressed in the same manner as the ISUP Calling party number in \(sc\ 3.8 of Recommendation\ Q.763. The code of this parameter is \*Q10000011\*U. .sp 9p .RT .LP 3.4.3.3.4\ \ The CalledPartyNumber is the network (e.g.\ E.164) number of the called party. It is expressed in the same manner as the ISUP Called party number in \(sc\ 3.7 of Recommendation\ Q.763. The code of this parameter is \*Q10000100\*U. .LP 3.4.3.3.5\ \ The CUGInterlockCode is the code to uniquely identify a CUG inside the network. It is expresed in the same manner as the ISUP CUG interlock code in \(sc\ 3.13 of Recommendation\ Q.763. The code of this parameter is \*Q10000101\*U. .LP 3.4.3.3.6\ \ The CalledUserIndex is the local index at the called user to identify a particular CUG he belongs to. Refer to \(sc\ 3.4.3.3.1. The code of this parameter is \*Q10000110\*U. .sp 1P .LP 3.4.3.3.7\ \ \fIErrors\fR .sp 9p .RT .ce \fBH.T. [T9.730]\fR .ce .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(180p) | cw(48p) . UnsuccessfulCheck Code = 00000001 _ .T& lw(180p) | cw(48p) . Parameters _ .T& lw(180p) | cw(48p) . Cause 3.4.3.3.8 _ .TE .nr PS 9 .RT .ad r \fBTable [T9.730], p.\fR .sp 1P .RT .ad b .RT .LP .sp 1 UnsuccessfulCheck Error PARAMETERS { Cause\ } ::= 1 .bp .sp 1P .LP 3.4.3.3.8\ \ The Cause indicates the reason why the CUG check is unsuccessful. .sp 9p .RT .ce \fBH.T. [T10.730]\fR .ce .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(180p) | cw(48p) . Cause Code = 10000111 _ .T& lw(78p) | lw(150p) . Contents binary (decimal) Meaning _ .T& lw(78p) | lw(150p) . 00110010\ (50) { Requested facility not subscribed } .T& lw(78p) | lw(150p) . 00110101\ (53) { Outgoing calls barred within CUG } .T& lw(78p) | lw(150p) . 00110111\ (55) { Incoming calls barred within CUG } .T& lw(78p) | lw(150p) . 00111110\ (62) { InconsistencyInDesignatedOutgoingAccessInformationAndSubscriberClass } .T& lw(78p) | lw(150p) . 01011010\ (90) Non\(hyexistent CUG .T& lw(78p) | lw(150p) . 01010111\ (87) Called user not member of CUG .T& lw(78p) | lw(150p) . 01011000\ (88) Incompatible destination .T& lw(78p) | lw(150p) . 01101110\ (110) Inconsistency in data _ .TE .nr PS 9 .RT .ad r \fBTable [T10.730], p.\fR .sp 1P .RT .ad b .RT .LP Cause ::= [7]\ IMPLICIT CauseCode CauseCode ::= INTEGER { requestedFacilityNotSubscribed(50), outgoingCallsBarredWithinCUG(53), incomingCallsBarredWithinCUG(55), inconsistencyInDesignatedOutgoingAccessInformationAnd SubscriberClass(62), nonExistentCUG(90), calledUserNotMemberofCUG(87), incompatibleDestination(88), inconsistencyInData(110)\ } .sp 2P .LP \fB4\fR \fBGeneral description of the\fR \fBCalling Line Identity\fR \fBPresentation and Restriction service\fR .sp 1P .RT .PP Calling 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.\ sub\(hyaddress), to the called party. .PP Calling 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.\ sub\(hyaddress), to the called party. .PP The 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.761\(hy764 and Q.766. .RT .sp 1P .LP 4.1 \fIDescription of the Calling Line Identity Presentation (CLIP)\fR \fIservice\fR .sp 9p .RT .PP Calling 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 \(sc\ 4.2 below] or the complete number of the calling party is not available at the destination exchange. .PP The Calling Line Identity (CLI) is generally the ISDN number of the calling party (with possible additional address information, i.e.\ sub\(hyaddress) which may be provided by the network or partly by the calling party. .bp .PP In 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). .PP In 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. .PP When 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. .RT .LP i) 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 \*Quser provided verified and passed\*U. .LP ii) 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 \*Qnetwork provided\*U. .PP When 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 \*Qnetwork provided\*U. .PP The CLI sent to the called user should contain all the necessary digits to enable a call to be established in the reverse direction. .PP \fINote\fR \ \(em\ This may not always be possible if, for example, the DDI extension of an ISPBX is not provided by the calling party. .PP Information indicating that a subscriber has the user access to the CLIP facility is available in the exchange to which the subscriber is connected. .RT .sp 1P .LP 4.1.1 \fICall set\(hyup procedure\fR .sp 9p .RT .PP The 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. .PP Two 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. .RT .sp 1P .LP 4.1.1.1 \fIThe Calling Line Identity is included in the Initial Address\fR \fIMessage\fR .sp 9p .RT .PP When 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. .PP In this situation, to avoid unnecessary unsuccessful requests for the CLI, the following procedures are recommended: .RT .LP a) 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 \*Qcalling party number parameter\*U \fIshould not\fR be included in the IAM. .LP b) 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 \*Qcalling party number parameter\*U \fIshould\fR be included in the IAM with the indication \*Qpresentation restricted\*U or \*Qaddress not available\*U set as appropriate in the Address Presentation Restricted indicator. .PP The CLI is sent to the called party in accordance with the user\(hynetwork interface protocol. .PP For 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. .PP Interworking 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. .PP In 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. .bp .RT .sp 1P .LP 4.1.1.2 \fIThe Calling Line Identity is not included in the Initial\fR \fIAddress Message\fR .sp 9p .RT .PP In 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 the calling party address requested. .PP When 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. .PP In the case where the identity of the calling party is not available or is not allowed to be forwarded outside the network, the response will be an Information message including the Information Indicators Parameter Field indicating the CLI is not available. .PP In 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. .PP The CLI is sent to the called party in accordance with the user\(hynetwork interface protocol. .PP In the case where the destination exchange receives the \*Qpresentation restricted\*U or an \*Qaddress not available\*U, in the Presentation Restriction indicator of the Information message, the calling party address is not forwarded to the called party. .RT .sp 1P .LP 4.1.1.3 \fIMessage Sequence diagrams for CLIP\fR .sp 9p .RT .PP Figures 6/Q.730 and 7/Q.730 describe the message flows for CLIP. .RT .LP .rs .sp 30P .ad r \fBFigure 6/Q.730, p.\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 29P .ad r \fBFigure 7/Q.730, p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 4.2 \fIDescription of the Calling Line Identity Restriction (CLIR)\fR \fIservice\fR .sp 9p .RT .PP Calling Line Identification Restriction (CLIR) is a user facility offered to restrict the presentation of the Calling Line Identity to the Called Party. .PP The Calling Line Identity (CLI) is the ISDN number of the calling party possibly with additional address information. .PP Information that a subscriber has the Calling Line Identity Restriction facility is available at the exchange to which the subscriber is connected. .RT .sp 1P .LP 4.2.1 \fINormal Case\fR .sp 9p .RT .PP When CLIR is applicable the originating exchange will provide the destination node with a notification that the Calling Line Identity is not allowed to be presented at the called party. In this case the Calling Line Identity will be marked as presentation restricted, in the Address Presentation Restricted Indicator, when it is passed across the network, in either an Initial Address Message or Information Message. In the case of CLIR the Calling Line Identity will not be included in the call offering to the called party's installation. .RT .sp 2P .LP 4.2.2 \fIAbnormal Case\fR .sp 1P .RT .sp 1P .LP 4.2.2.1 \fIOverride Category\fR \fIwithin an ISDN\fR .sp 9p .RT .PP As a national option the terminating exchange can override the presentation restriction indication and the CLI presented at the called subscriber for specific called party's categories (e.g.\ Police). .bp .RT .sp 1P .LP 4.2.2.2 \fIOverride Category between ISDN's\fR .sp 9p .RT .PP When a call originates in one ISDN network and terminates in another ISDN network and CLIR is applicable, the rules and regulations of the destination (host) network should apply. .PP For example, if an override category is not available in the originating network but is available in the destination network. The destination network can still override the presentation restriction whenever CLI is available at this network. .PP As a national option the originating network can restrict the CLI to the destination network if the CLIR is applicable. .RT .sp 1P .LP 4.2.2.3 \fIInterworking with non\(hyISDN or via non\(hyISDN\fR .sp 9p .RT .PP On calls to or via non\(hyISDN networks, it cannot be guaranteed that the CLIR indication will be carried to the destination network. .PP As a national option the originating network can restrict the CLI to the destination network if CLIR is applicable. .PP If the destination network receives a Calling Line Identity without any indication of presentation allowed or restricted, the destination network will act according to its rules and regulations. .RT .sp 1P .LP 4.2.2.4 \fIRestriction of Additional Address Information\fR .sp 9p .RT .PP Any additional address information provided by the calling party, i.e.\ sub\(hyaddress, will also be subject to the CLIR supplementary service as indicated in the Presentation Restriction Indicator in the Calling Party Number Parameter field. .RT .sp 1P .LP 4.2.2.5 \fIMessage Sequence diagrams for CLIR\fR .sp 9p .RT .PP Figure 8/Q.730 describes the message flow for CLIR. .RT .LP .rs .sp 27P .ad r \fBFigure 8/Q.730, p.\fR .ad b .RT .sp 1P .LP 4.3 \fINodal signalling function SDLs for CLIP and CLIR\fR .sp 9p .RT .PP Nodal signalling function procedures for CLIP and CLIR are described in Figures\ 9/Q.730 to\ 13/Q.730. .bp .RT .LP .rs .sp 47P .ad r \fBFigure 9/Q.730, p.\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure 10/Q.730, p.\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure 11/Q.730, p.\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure 12/Q.730, p.\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 41P .ad r \fBFigure 13/Q.730, p.\fR .sp 1P .RT .ad b .RT .sp 2P .LP 4.4 \fIInteraction of CLIP with other supplementary services\fR .sp 1P .RT .sp 1P .LP 4.4.1 \fICalling Line Identification Restriction\fR .sp 9p .RT .PP The calling line identification will not be present if the calling user has an arrangement to inhibit the presentation of his number to the called party. .RT .sp 1P .LP 4.4.2 \fICall Forwarding\fR .sp 9p .RT .PP If the call has been redirected the CLI presented to the user will be the originating CLI. .bp .RT .sp 1P .LP 4.4.3 \fICall Waiting\fR .sp 9p .RT .PP No interaction. .RT .sp 1P .LP 4.4.4 \fIClosed User Group\fR .sp 9p .RT .PP No interaction. .RT .sp 1P .LP 4.4.5 \fIDirect Dialling In\fR .sp 9p .RT .PP No interaction. .RT .sp 1P .LP 4.4.6 \fIUser to User Information\fR .sp 9p .RT .PP No interaction. .RT .sp 2P .LP 4.5 \fIInteraction of CLIR with other supplementary services\fR .sp 1P .RT .sp 1P .LP 4.5.1 \fICalling Line Identification Presentation\fR .sp 9p .RT .PP Calling Line Identification Restriction will take precedence over Calling Line Identification Presentation. .PP The only occasion when a user subscribing to Calling Line Identification Presentation can take precedence over Calling Line Identification Restriction is when the user has override category. This is a national option. .RT .sp 1P .LP 4.5.2 \fICall Forwarding\fR .sp 9p .RT .PP If the call has been re\(hydirected the CLI presented to the user will be the originating CLI. When Calling Line Identification Restriction is applicable and activated, the calling party's ISDN number will not be presented to the \*Qforwarded to\*U user unless this user has an override category. The latter is a national option. .RT .sp 1P .LP 4.5.3 \fICall Waiting\fR .sp 9p .RT .PP When Calling Line Identification Restriction is applicable and activated, no number will be presented to a called user subscribing to Call Waiting. .RT .sp 1P .LP 4.5.4 \fIClosed User Group\fR .sp 9p .RT .PP It is an option to allow invocation of Calling Line Identification Restriction in connection with a CUG call. .RT .sp 1P .LP 4.5.5 \fIDirect Dailling In\fR .sp 9p .RT .PP No interaction. .RT .sp 1P .LP 4.5.6 \fIUser to User Information\fR .sp 9p .RT .PP No interaction. .RT .sp 2P .LP \fB5\fR \fBDirect Dialling In (DDI)\fR .sp 1P .RT .sp 1P .LP 5.1 \fIDefinitions\fR .sp 9p .RT .PP \fBDirect Dialling In (DDI)\fR enables a user to call directly another user on a PABX or other private system without attendant intervention, the DDI digit(s) being the least significant digit(s) of the called ISDN number. .PP The stage 1 definition of DDI is to be found in Recommendation\ I.251, \(sc\ A. The stage\ 2 description is included in Recommendation\ Q.81, \(sc\ 1. This stage\ 3 description of DDI compliments the ISDN User Part protocol as defined in Recommendations\ Q.761\(hyQ.764 and Q.766. .bp .RT .sp 1P .LP 5.2 \fIProcedures\fR .sp 9p .RT .PP The procedures to set up a call are in general the same as the basic procedures. A distinction is made whether DDI is applied to an analogue or an ISDN PABX and whether the destination local exchange is aware of the number of DDI digits required by the called PABX. .PP Besides sending the Address Complete Message and possibly Call Progress Message(s) the subsequent messages will be the same as for a normal call without DDI. .RT .sp 1P .LP 5.2.1 \fIAnalogue PABX\fR .sp 9p .RT .PP An Address Complete Message is sent as soon as the destination local exchange has received the complete called party number and has selected a free circuit to the PABX. The Called Line Status is set to \*Qno indication\*U. .PP If the destination local exchange has no knowledge about the number of DDI digits required to set up the call it selects a free circuit, sends the received DDI digits to the PABX and returns an Address Complete Message as soon as it has received a signal to that effect from the PABX. The Called Line Status is set to either \*Qno indication\*U or \*Qsubscriber free\*U according to the signal received from the PABX. .RT .sp 1P .LP 5.2.2 \fIISDN PABX\fR .sp 9p .RT .PP An Address Complete Message is sent as soon as the destination local exchange has received the complete called party number with the Called Line Status set to \*Qno indication\*U. .PP If the destination local exchange has no knowledge about the number of DDI digits required to set up the call it sends an Address Complete Message as soon as it has received the relevant information (Call Proceeding) from the PABX. The Called Line Status is set to \*Qno indication\*U. .PP On receipt of an \*Qalerting\*U indication from the PABX the destination local exchange sends a Call Progress Message with the Called Line Status set to \*Qsubscriber free\*U. .PP If tones and/or announcements are provided from the destination local exchange the transmission path is through connected on receipt of the relevant information (Connect) from the PABX before sending the Answer Message to the preceding exchange. If tones and/or announcements are provided from the PABX the destination local exchange connects the backward path on receipt of an indication to that effect from the PABX and sends a Call Progress Message to the preceding exchange. The transmission path is fully through connected on receipt of the relevant information (Connect) from the PABX. .RT .sp 1P .LP 5.3 \fIInteractions with sub\(hyaddressing\fR .sp 9p .RT .PP The use of DDI has no impact on the use of sub\(hyaddressing and vice versa. .RT .sp 2P .LP \fB6\fR \fBCall Forwarding services\fR .sp 1P .RT .sp 1P .LP 6.1 \fIGeneral description of Call Forwarding services\fR .sp 9p .RT .PP The Call Forwarding services involve the redirection of a call originally intended for one destination, towards another destination. The stage\ 1 definitions for the Call Forwarding services are given in Recommendation\ I.252 and the stage\ 2 descriptions are contained in Recommendation\ Q.82,\ \(sc\ 2. .PP This section gives the ISDN User Part procedures to support the Call Forwarding Unconditional, Call Forwarding Busy, and Call Forwarding No Reply services. The functional description, formats and codes and general procedures for the ISDN User Part are contained in Recommendations\ Q.761\(hy764 and\ Q.766. This section does not cover the optional validation procedure of Recommendation\ I.252. One possible method of performing this validation is to use a courtesy call at call forwarding activation time. .RT .sp 1P .LP 6.2 \fIDefinition of Call Forwarding services\fR .sp 9p .RT .PP The \fBCall Forwarding Unconditional service\fR permits a served user to have the network send all incoming calls, or just those associated with a specified basic service, addressed to the served user's ISDN number to another Number. This forwarding occurs regardless of the condition of the termination (busy or idle) and without the subscriber being given the opportunity to answer the call. .bp .PP The \fBCall Forwarding Busy service\fR permits a served user to have the network send all incoming calls, or just those associated with a specified basic service, addressed to the served user's ISDN number, to another Number if the served user is in the busy state (user busy, either Network Determined User Busy (NDUB) or User Determined User Busy (UDUB). Recommendation\ I.252 contains the definitions for busy in an ISDN environment (NDUB occurs when both B\(hychannels are busy for example). .PP The \fBCall Forwarding No Reply service\fR permits a served user to have the network send all incoming calls, or just those associated with a specified bearer service, addressed to the served user's ISDN number to another Number if the served user does not respond to the alerting within a specified time period. .PP A terminating exchange that determines that Call Forwarding may occur will not discard the setup information until the exchange determines that Call Forwarding will not occur in this particular instance. .RT .sp 1P .LP 6.3 \fIProcedures for Call Forwarding\fR .sp 9p .RT .PP The following three sections detail the ISDN\(hyUser Part procedures associated with the Call Forwarding services. The first section gives a high level view of ISDN User Part Call Forwarding procedures. The section consists of a figure that demonstrates the parameters and parameter values that occur in an Initial Address Message as a call undergoes a series of call forwardings. The second section gives the procedures for an exchange that determines that a call it has received should be forwarded. The third section gives the procedures for notification of the calling user. .RT .sp 1P .LP 6.3.1 \fICall Forwarding related parameters in the Initial Address\fR \fIMessage during Multiple Forwardings\fR .sp 9p .RT .LP .rs .sp 30P .ad r \fBFigure 14/Q.730, p. \fR .sp 1P .RT .ad b .RT .LP .bp .sp 2P .LP 6.3.2 \fIProcedures for an exchange that determines that a call it has\fR \fIreceived should be forwarded\fR .sp 1P .RT .sp 1P .LP 6.3.2.1 \fIGeneral overview\fR .sp 9p .RT .PP When an exchange determines that it must forward a call, it first checks to see if forwarding the call would result in the call exceeding the number of forwardings allowed within the network. The second action that needs to be undertaken, given that the limit was not exceeded, is the setting of the parameters that would be used in an Initial Address Message for the forwarded call. Even if the forwarding is intra\(hyexchange this parameter information is set and retained. The reason for the retention is that, if subsequent forwarding occurs, the information is required to guarantee that the forwarding completes correctly. Finally the exchange attempts to set up the forwarded call. Any parameters received in the Initial Address Message not associated with forwarding (e.g.,\ Calling Number, Higher Layer Compatibility\ etc.) are included unchanged in the Initial Address Message used to set up the forwarded call. .RT .sp 1P .LP 6.3.2.2 \fIChecking the forwarding limit\fR .sp 9p .RT .PP If the call has already undergone forwarding, the redirection counter is examined to see if another forwarding would take the counter above the network specified limit. If it would, but the reason for the forwarding is Call Forwarding No Reply, the call should be left in its current state with the calling party continuing to receive ringing (the call is not cleared as the calling user would get a confusing sequence of tones and announcements\ e.g. ringing to network busy). In all other cases the call is cleared. The cause value used in the Release message depends upon which of the Call Forwarding services it is that would take the call over the limit. The mapping is as follows: .RT .LP a) Call Forwarding Busy, the cause value \*Quser busy\*U is used; .LP b) Call Forwarding No Reply, the cause value \*Qno answer from user\*U is used; .LP c) Call Forwarding Unconditional, the cause value \*Qno user responding\*U is used. .sp 1P .LP 6.3.2.3 \fISetting the parameters associated with call forwarding\fR .sp 9p .RT .PP The parameters to be set depend upon the number of forwardings that the call has undergone. The following three sections give the procedures for the case where this is the first forwarding, the second forwarding and the third or greater forwarding that the call has undergone. .RT .sp 1P .LP 6.3.2.3.1\ \ \fIThis is the first forwarding that the call has undergone\fR .sp 9p .RT .PP There are three parameters to set: the redirection information, the called party number and the original called number. Their values are set as follows: .RT .LP 1) Redirection information. The redirection counter is one. The redirecting reason and redirecting indicator are set according to the forwarding conditions. .LP 2) Original called number. This is equal to the first number that was called. .LP 3) Called party number. This is equal to the number that the call is to be forwarded to. .sp 1P .LP 6.3.2.3.2\ \ \fIThis is the second forwarding that the call has undergone\fR .sp 9p .RT .PP There are three parameters to set: the redirection information, the called party number, and the redirecting number. Their values are set as follows: .RT .LP 1) Redirection information. The redirection counter is two. The redirecting reason and redirecting indicators are set according to the forwarding conditions. .LP 2) Redirecting number. This is equal to the number that is doing the redirecting. .LP 3) Called number. This is equal to the number that the call is to be forwarded to. .sp 1P .LP 6.3.2.3.3\ \ \fIThis is the third or greater forwarding that the call has\fR \fIundergone\fR .sp 9p .RT .PP There are three parameters that must be set: the redirection information, the called party number and the redirecting number. Their values are set as follows: .RT .LP 1) Redirection information. The redirection counter is incremented. The redirecting reason and redirecting indicators are set according to the forwarding conditions. .LP 2) Redirecting number. This is equal to the number that is doing the redirecting. .LP 3) Called number. This is equal to the number that the call is to be forwarded to. .bp .sp 1P .LP 6.3.2.4 \fIForwarding procedures at the forwarding exchange\fR .sp 9p .RT .PP The exchange continues based on the service that is causing the forwarding. The procedures to be followed if the cause of the forwarding was either Busy (Network Determined) or Unconditional are given below. These are followed by the procedures for No Reply. Lastly the procedures for Busy (User Determined) are given. .RT .sp 1P .LP 6.3.2.4.1\ \ \fICall Forwarding Unconditional or Busy (Network Determined)\fR .sp 9p .RT .PP The exchange continues in the following fashion: .RT .LP 1) If the number that the call is to be forwarded to resides at another exchange, an Initial Address Message is sent to continue the call on to that exchange. The incoming trunk or line should be connected to the chosen outgoing trunk immediately. The Initial Address Message includes the parameter information as shown in\ \(sc\ 6.3.1. .LP 2) If the number resides in the same exchange, the exchange tries to set up a call to that number. If the attempt is successful and neither Call Forwarding Busy or Call Forwarding Unconditional occurs, the incoming line or trunk should be connected to the destination line. If Call Forwarding Busy or Call Forwarding Unconditional occurs when the attempt is made, the Call Forwarding procedures should be re\(hyentered. .sp 1P .LP 6.3.2.4.2\ \ \fICall Forwarding No Reply\fR .sp 9p .RT .PP The exchange continues in the following fashion: .RT .LP 1) If the number that the call is to be forwarded to resides at another exchange, an Initial Address Message is sent to continue the call on to that exchange. The incoming trunk or line is not connected to the chosen outgoing trunk yet as it could result in confusing sequences of in band tones or announcements (e.g.,\ ringing going to busy). The Initial Address Message includes the parameter information as shown in\ \(sc\ 6.3.1. If the exchange receives an alerting indication it should connect the incoming trunk or line to the outgoing trunk, in at least the backward direction. If the exchange receives an answer indication it should connect in both directions. If the exchange receives a release indication\ \(em\ called party busy for instance, the current connections should simply be left intact, until timer expiry or calling user disconnect. .LP 2) If the original called user answers prior to receipt of alerting indication from the forwarded\(hyto exchange, this user is awarded the call and the connection toward the forwarded\(hyto exchange is released. .LP 3) If the number resides in the same exchange, the exchange tries to set up a call to that number. If the attempt is successful and neither Call Fowarding Busy or Call Forwarding Unconditional occurs, the incoming line or trunk is connected to the destination line. If Call Forwarding Busy or Call Forwarding Unconditional occurs when the attempt is made, the Call Forwarding procedures should be re\(hyentered. If the exchange cannot complete the call (e.g.,\ destination is busy and No Call Forwarding on Busy active), the current connections are left intact. .sp 1P .LP 6.3.2.4.3\ \ \fICall Forwarding Busy (User Determined)\fR .sp 9p .RT .PP The exchange continues in the following fashion: .RT .LP 1) An Address Complete Message with no indication of the called party's status in the backward call indicators parameter should be returned to the calling party's exchange. .LP 2) If the number that the call is to be forwarded to resides at another exchange, an Initial Address Message is sent to continue the call on to that exchange. The Initial Address Message includes the parameter information as shown in\ \(sc\ 6.3.1. If the exchange receives an alerting indication it should connect the incoming trunk or line to the outgoing trunk. If the exchange receives a release indication\ \(em\ called party busy for instance, the call should be released with the cause value \*Quser busy\*U. .LP 3) If the number resides in the same exchange, the exchange tries to set up a call to that number. If the attempt is successful and neither Call Forwarding Busy or Call Forwarding Unconditional occcurs, the incoming line or trunk is connected to the destination line. If call Forwarding Busy or Call Forwarding Unconditional occurs when the attempt is made, the Call Forwarding procedures should be re\(hyentered. If the exchange cannot complete the call (e.g.,\ destination is busy and no Call Forwarding on Busy active) the call should be released with the cause value \*Quser busy\*U. .bp .sp 1P .LP 6.3.3 \fINotification procedures for the forwarding exchange\fR .sp 9p .RT .PP An exchange forwarding a call sends a call progress message in the backward direction if the forwarding (served) user does not subscribe to notification (to the calling party) of the forwarded\(hyto number. Procedures for users subscribing to the notification of forwarded\(hyto number are for further study. .RT .sp 1P .LP 6.3.3.1 \fIForwarding user subscribes to redirection information\fR \fIpresentation restricted\fR .sp 9p .RT .PP The call progress message contains an event indicator of the \*QEvent Information Presentation Restricted Type\*U. The value is set according to the redirecting reason. .RT .sp 1P .LP 6.3.3.2 \fIForwarding user does not subscribe to redirection information\fR \fIpresentation restricted\fR .sp 9p .RT .PP The call progress message contains an event indicator that is not of the \*QEvent Information Presentation Restricted\*U type. The value is set according to the redirecting reason. .RT .sp 1P .LP 6.3.3.3 \fINofitification for Call Forwarding No Reply\fR .sp 9p .RT .PP If Call Forwarding No Reply is in effect, and the exchange alerts the called party, the Address Complete message sent including the Backward and Optional Backward Call indicators set to the appropriate values. In this case, the Call Progress message is delayed until receipt of an alerting indication from the forwarded\(hyto exchange. .RT .LP 6.4 \fIInteractions with other Supplementary Services where interaction\fR \fIhas ISDN User Part impact\fR .sp 1P .RT .sp 2P .LP 6.4.1 \fIUser\(hyto\(hyUser Signalling\fR .sp 1P .RT .sp 1P .LP 6.4.1.1 \fIDescription of interaction\fR .sp 9p .RT .sp 1P .LP 6.4.1.1.1 \fICall Forwarding Busy (Network Determined) or Call Forwarding\fR \fIUnconditional\fR .sp 9p .RT .PP If the forwarding party does not subscribe to a Service requested as \*Qessential\*U the call is cleared. If the forwarding party inhibits User to User on Forwarded calls and one or more User to User service was requested as \*Qessential\*U, the call is cleared. The cause is \*Qno user responding\*U in the case of Call Forwarding Unconditional and \*Quser busy\*U in the case of Call Forwarding Busy. .PP If call clearing does not occur above and the forwarding party inhibits User to User on Forwarded calls, the forwarding exchange will not include a User to User indicators parameter in the Initial Address Message used to set up the forwarded leg of the call. If the forwarding party does not subscribe to any of the User to User services requested by the calling user, the forwarding exchange will again not include a User to User indicators parameter in the Initial Address Message used to set up the forwarded leg of the call. In both of these cases the normal User to User procedures will ensure that the calling user is informed of the lack of User to User signalling capability. .PP If the forwarding user subscribes to a requested user to user service and does not inhibit it on forwarded calls, the forwarding exchange will try to supply the user to user service requested. This will be accomplished by requesting the user to user service in the outgoing Initial Address Message using the same request information that was contained in the original Initial Address Message. If the attempt is successful, user to user transfer will be available between the calling user and forwarded to user. .bp .RT .sp 1P .LP 6.4.1.1.2\ \ \fICall Forwarding No Reply\fR .sp 9p .RT .PP Call Forwarding No Reply subscribers with Call Forwarding No Reply activated can also be User to User Subscribers. They cannot however use the Alerting (Address Complete) indication to indicate acceptance or rejection of User to User Service requests. The Alerting (Address Complete) indication must show a \*Qno indication\*U response to any User to User service requests. Any other response is a protocol error. Acceptance or rejection of User to User service requests occurs in the Connect (Answer) indication. .PP If a Call is Forwarded No Reply and one or more of any requested User to User services are essential and the forwarding user inhibits user to user on the forwarding leg, then the call is cleared. If the forwarding party does not subscribe to a Service requested as \*Qessential\*U the call is cleared. The cause used in both cases is \*Qno answer from user\*U. .PP Services 1 and 2 are not extended to the forwarded to party in the case of Call Forwarding No Reply. Service\ 3 may be extended to the forwarded to party if the forwarding user subscribes to User to User Service\ 3 and does not inhibit User to User on the forwarded leg. The User to User indicators parameter for service\ 3 in the Forwarding Initial Address Message should be set identically to the values received in the Original Initial Address Message. If the Address Complete Message received on the forwarded leg of the call indicates that service\ 3 was not provided, the call Forwarding No Reply exchange should retain this indicator and insert it in the Answer Message when it is received. If the Address Complete Message received on the forwarded leg of the call indicates that servive\ 3 is provided, the Call Forwarding No Reply exchange should retain this indicator and insert it in the Answer Message when it is received. .RT .sp 1P .LP 6.4.1.1.3\ \ \fICall Forwarding Busy (User Determined)\fR .sp 9p .RT .PP Call Forwarding Busy (User Determined) subscribers can also be User to User Subscribers. The Address Complete Message sent back upon receipt of the release from the originally called party should give \*Qno information\*U in response to any received User to User requests. .PP If a Call is Forwarded Busy (User Determined) and one or more of any requested User to User services are essential and the forwarding user inhibits user to user on the forwarding leg, then the call is cleared. If the fowarding party does not subscribe to a Service requested as \*Qessential\*U the call is cleared. The cause used in both cases is \*Quser busy\*U. .PP Services\ 1 and\ 2 are not extended to the forwarded to party in the case of Call Forwarding Busy (User Determined). Service\ 3 may be extended to the forwarded to party if the forwarding user subscribes to User to User Service\ 3 and does not inhibit User to User on the forwarded leg. The User to User indicators parameter for service\ 3 in the Forwarding Initial Address Message should be set identically to the values received in the Original Initial Address Message. If the Address Complete Message received on the forwarded leg of the call indicates that service\ 3 was not provided, the Call Forwarding Busy (User Determined) exchange should retain this indicator and insert it in the Answer Message when it is received. If the Address Complete Message received on the forwarded leg of the call indicates that service\ 3 is provided, the Call Forwarding Busy (User Determined) exchange should retain this indicator and insert it in the Answer Message when it is received. .RT .sp 1P .LP 6.4.1.1.4\ \ \fIMessage length\fR .sp 9p .RT .PP There is a further implication in that multiple forwarding adds to the length of the Initial Address Message. If the Initial Address Message that is to be used on a call setup is within\ 32 octets of the\ 272\ octet message length limit, the user to user information should be dropped. This will result in a guarantee that the Initial Address Message will not subsequently exceed the length limit. .RT .sp 2P .LP 6.4.2 \fIClosed User Group\fR .sp 1P .RT .sp 1P .LP 6.4.2.1 \fIDescription of interaction\fR .sp 9p .RT .PP Closed User Group restrictions must be met on each leg of the call. In addition, CUG restrictions must be met end\(hyto\(hyend. If the call is forwarded multiple times, CUG restrictions have to be met between the calling user and every intermediate forwarding user. .bp .PP Calling User/Forwarded\(hyto User: When a call is forwarded a new check of the CUG restrictions is made at the forwarded\(hyto destination. The CUG information sent to the forwarded\(hyto destination is the same CUG information that was sent from the originating exchange. .RT .sp 1P .LP 6.4.2.2 \fIActions at a forwarding exchange\fR .sp 9p .RT .PP For a subscriber who has both CUG interlock and Call Forwarding services, checks will have to be made prior to entering the Call Forwarding procedures. The forwarding users CUG interlock code(s) will have to be checked against the calling user CUG interlock code. The check would be done at the exchange for the decentralized case and at a database after a TCAP query response sequence for the centralized case. If the check is passed, the Call Forwarding procedures may be entered. If the call proceeds onwards from the forwarding exchange the CUG interlock code and outgoing access indication, which was included in the Initial Address Message received, is included in the Initial Address Message transmitted. .RT .sp 1P .LP 6.4.2.3 \fIActions at a destination exchange\fR .sp 9p .RT .PP If an exchange receives a call for a CUG member it will have to check against the calling user CUG code. The check would be done at the exchange for the decentralized case and at a database after a TCAP query response sequence for the centralized case. The check would have to be passed for the call to complete. .RT .sp 1P .LP 6.4.3 \fICalling Line Identification Presentation\fR .sp 9p .RT .PP When an exchange receives a call for a Call Forwarding No Reply Subscriber, Address Complete is not returned until alerting is received from the called party. Address Complete messages returned for Call Forwarding No Reply or Call Forwarding (user determined) Busy. Subscribers contain an optional backwards call indicators parameter. The value of this parameter should indicate \*QCall Forwarding may occur\*U. This indication alerts the transit and originating exchanges that the call is not yet in a stable state as Call Forwarding No Reply may occur. This is used to allow the request/response cycle to be used to obtain the calling number for the forwarded to party if Call Forwarding No Reply occurs. .RT .sp 1P .LP 6.5 \fIMessage flow diagrams\fR .sp 9p .RT .PP The messages over the access are included as examples only and are not exhaustive. .PP Call release procedures are as per normal call. .PP Abbreviations used in Figures\ 15/Q.730 to\ 22/Q.730 are the following: .RT .LP IAM Initial Address Message .LP CPG Call Progress Message .LP ACM Address Complete Message .LP ANM Answer Message .LP REL Release .LP RLC Release Complete .LP LE Local Exchange .LP TE Terminal Entity .LP TR Transit Exchange .LP .rs .sp 3P .ad r Blanc .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure 15/Q.730, p. 20\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure 16/Q.730, p. 21\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure 17/Q.730, p. 22\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure 18/Q.730, p. 23\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure 19/Q.730, p. 24\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure 20/Q.730, p. 25\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 24P .ad r \fBFigure 21/Q.730, p. 26\fR .sp 1P .RT .ad b .RT .LP .rs .sp 24P .ad r \fBFigure 22/Q.730, p. 27 \fR .sp 1P .RT .ad b .RT .LP .bp .sp 2P .LP \fB7\fR \fBTime\(hyout table\fR .sp 1P .RT .PP Table 5/Q.730 specifies the timers to be used in conjunction with the supplementary services defined in this Recommendation. (This requires further study.) .RT .ce \fBH.T. [T11.730]\fR .ce TABLE\ 5/Q.730 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(18p) | cw(30p) | cw(30p) | cw(30p) | cw(36p) | cw(30p) | cw(30p) | cw(24p) . Symbol Time\(hyout value Significance Cause for initiation Normal termination At the first expiry At the following expiry Section _ .T& cw(18p) | lw(30p) | lw(30p) | lw(30p) | lw(36p) | lw(30p) | lw(30p) | lw(24p) . T 3 U\(hyU facility request { Receipt of facility Acceptance or reject message } { \*QProtocol error\*U passed to call control } _ .T& cw(18p) | lw(30p) | lw(30p) | lw(30p) | lw(36p) | lw(30p) | lw(30p) | lw(24p) . .T& cw(18p) | lw(30p) | lw(30p) | lw(30p) | lw(36p) | lw(30p) | lw(30p) | lw(24p) . .TE .nr PS 9 .RT .ad r \fBTable 5/Q.730 [T11.730], p. \fR .sp 1P .RT .ad b .RT .LP .bp .ce 1000 ANNEX\ A .ce 0 .ce 1000 (to Recommendation\ Q.730) .sp 9p .RT .ce 0 .ce 1000 \fBSignalling procedure for the explicit invocation of\fR .sp 1P .RT .ce 0 .ce 1000 \fBuser\(hyto\(hyuser signalling services 1, 2 and 3\fR .ce 0 .LP A.1 \fIUser\(hyto\(hyuser signalling service\fR .sp 1P .RT .sp 1P .LP A.1.1 \fIGeneral description of user\(hyto\(hyuser service\fR .sp 9p .RT .PP See \(sc\(sc 2.1 and 2.2. .RT .LP A.2 \fIProcedures for user\(hyto\(hyuser signalling associated with circuit\fR \fIswitched calls\fR .sp 1P .RT .sp 2P .LP A.2.1 \fIUser\(hyto\(hyuser signalling, Service\ 1\fR .sp 1P .RT .sp 1P .LP A.2.1.1 \fIGeneral characteristics\fR .sp 9p .RT .PP Service 1 allows users to communicate with user\(hyto\(hyuser signalling by transferring user\(hyto\(hyuser information within ISDN user part messages during the call set\(hyup and clearing phases. The user\(hyto\(hyuser 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 User\(hyto\(hyuser Signalling Service\ 1 is included the service should be rejected. .RT .sp 1P .LP A.2.1.2 \fIUser\(hyto\(hyuser signalling, Service\ 1\ \(em\ Explicit service request\fR .sp 9p .RT .PP Procedures for call set\(hyup are as described in Recommendation\ Q.764,\ \(sc\ 2 with the following changes: .PP On call set\(hyup, the Initial Address Message will contain the user\(hyto\(hyuser indicators parameter with Service\ 1 indicated as \*Qrequested essential/not essential\*U and Service\ 2 and\ 3 indicated as \*Qno information\*U. 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. .PP If the called user or network can support the transfer of user\(hyto\(hyuser, a Service\ 1 acceptance will be returned to the originating exchange in an Address Complete or Call Progress Message for the point\(hyto\(hypoint case or the Answer or Connect Message in the point\(hyto\(hymultipoint case with the indication \*QService\ 1 provided\*U in the user\(hyto\(hyuser indicators parameter. Services\ 2 and\ 3 will be indicated as \*Qno information\*U in the user\(hyto\(hyuser indicators parameter. These explicit indications shall be forwarded to the call control at the originating exchange. .PP User\(hyto\(hyuser information may be contained in any of the messages that may be transferred in the call set\(hyup phase. .RT .sp 1P .LP A.2.1.3 \fIInterworking\fR .sp 9p .RT .PP In the case of interworking with a non\(hyISDN network, the \*Qinterworking\*U 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. .RT .sp 1P .LP A.2.1.4 \fIRejection of explicit service requests\fR .sp 9p .RT .PP 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. (\fINote\fR \ \(em\ The Study Group\ XVIII service description does not allow this implicit rejection.) .bp .PP If the network or called user cannot support Service\ 1, and it was requested with a non\(hyessential indication, a Service\ 1 rejection indication is returned in the Address Complete or Call Progress Message with the indication \*QService\ 1 not provided\*U in the user\(hyto\(hyuser indicators parameter. .PP If 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, \*Qrequested facility not subscribed\*U, cause code\ 29, \*Qfacility rejected by the network\*U or cause code\ 69, \*Qrequested facility not implemented\*U and the diagnostic containing the user\(hyto\(hyuser indicators parameter. .RT .sp 1P .LP A.2.1.5 \fIUser\(hyto\(hyuser signalling in the call clearing phase\fR .sp 9p .RT .PP A user\(hyto\(hyuser information parameter may be included in the Release Message. The user\(hyto\(hyuser 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 user\(hyto\(hyuser information will be lost. .RT .sp 2P .LP A.2.2 \fIUser\(hyto\(hyuser signalling, Service 2\fR .sp 1P .RT .sp 1P .LP A.2.2.1 \fIGeneral characteristics\fR .sp 9p .RT .PP Service\ 2 allows the users to communicate with user\(hyto\(hyuser signalling by transferring up to two user\(hyto\(hyuser information messages in each direction during the call setup phase. As a network option, user\(hyto\(hyuser information may de 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. .PP Service 2 is only applicable when a point\(hyto\(hypoint configuration exists at the user\(hynetwork interface at the terminating exchange. .RT .sp 1P .LP A.2.2.2 \fICall set\(hyup\fR .sp 9p .RT .PP The Connection Request parameter will be included if CO\(hySCCP method is selected, or the call reference parameter if CL\(hySCCP method is selected. .FE The SCCP connection confirm message will be returned if CO\(hySCCP method is selected. .FE Procedures for call set\(hyup are as described in Recommendation\ Q.764,\ \(sc\ 2 with the following changes: .PP On call set\(hyup the Initial Address Message will contain the user\(hyto\(hyuser indicators parameter with Service\ 2 indicated as \*Qrequested essential/not essential\*U and Services\ 1 and\ 2 indicated as \*Qno information\*U . The service request will be received from call control. The service request will be passed to call control at the terminating exchange. .PP If the called user or network can support the transfer of user\(hyto\(hyuser information, a Service\ 2 acceptance will be returned to the originating exchange in an Address Complete or Call Progress Message with the indication \*QService\ 2 provided\*U in the user\(hyto\(hyuser indicators parameter . Services\ 1 and\ 3 will be indicated as \*Qno information\*U in the user\(hyto\(hyuser indicators parameter. These explicit indications shall be forwarded to the call control at the originating exchange. .RT .sp 2P .LP A.2.2.3 \fIService rejection\fR .sp 1P .RT .sp 1P .LP A.2.2.3.1 \fIPoint\(hyto\(hypoint calls\fR .sp 9p .RT .PP The SCCP connection refused message will be returned if CO\(hySCCP method is selected. .FE If 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. .PP If the network or called user cannot support Service\ 2, and it was requested with a non\(hyessential indication, a Service\ 2 rejection indication is returned in the Address Complete or Call Progress Message with the indication \*QService\ 2 not provided\*U in the user\(hyto\(hyuser indicators parameter . (\fINote\fR \ \(em\ The Study Group\ XVIII service description does not allow this implicit rejection.) .bp .PP If 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, \*Qrequested facility not subscribed\*U cause code\ 29, \*Qfacility rejected by the network\*U or cause code\ 69, \*Qrequested facility not implemented\*U and the diagnostic containing the user\(hyto\(hyuser indicators parameter. .RT .sp 1P .LP A.2.2.3.2\ \ \fIPoint\(hyto\(hymultipoint calls\fR .sp 9p .RT .PP If the call is point\(hyto\(hymultipoint 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 point\(hyto\(hypoint procedures. The cause value in this case is code\ 88, \*Qincompatible destination\*U. .RT .sp 1P .LP A.2.2.4 \fIInterworking\fR .sp 9p .RT .PP In the case of interworking with a non\(hyISDN network, the \*Qinterworking\*U protocol control information will be returned to the originating exchange in the appropriate message,\ e.g., an Address Completed 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. .RT .sp 1P .LP A.2.2.5 \fITransfer of messages containing user\(hyto\(hyuser information\fR .sp 9p .RT .PP Once acceptance of Service\ 2 has been transmitted across the network, both of the involved users can transfer user\(hyto\(hyuser information between themselves. Within the network the user\(hyto\(hyuser information parameter will be carried in a User\(hyto\(hyuser Information Message. The network provides for the transfer of these messages from the calling to the called side and vice versa. .PP The User\(hyto\(hyuser Information Message format can be found in Table\ 20/Q.763. .PP If the Service\ 2 is provided, no more than two User\(hyto\(hyuser Information Messages carrying user\(hyto\(hyuser information parameters may be transmitted in each direction during the call set\(hyup phase. If more than two messages are received during call set\(hyup, 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. .PP No transfer of user\(hyto\(hyuser information can occur until the service is acknowledged. .RT .sp 2P .LP A.2.3 \fIUser\(hyto\(hyuser signalling, Service 3\fR .sp 1P .RT .sp 1P .LP A.2.3.1 \fIGeneral characteristics\fR .sp 9p .RT .PP Service\ 3 allows the users to communicate with user\(hyto\(hyuser signalling by transferring User\(hyto\(hyuser Information Messages in each direction during the active phase of the call. This service allows either an implicit or explicit rejection. .PP Service\ 3 allows the service to be requested either during call set\(hyup or after call set\(hyup. However, Service\ 3 should not be requested after call set\(hyup if it has been rejected during the call set\(hyup phase. .RT .sp 1P .LP A.2.3.2 \fIService 3 requested during call set\(hyup\fR .sp 9p .RT .PP Procedures for call set\(hyup are as described in Recommendation\ Q.764, \(sc\ 2 with the following changes: .PP On call set\(hyup the Initial Address Message will contain the user\(hyto\(hyuser indicators parameter with Service\ 3 indicated as \*Qrequested essential/not essential\*U and Services\ 1 and\ 2 indicated as \*Qno information\*U . 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. .PP If the called user or network can support the transfer of user\(hyto\(hyuser information, a Service\ 3 Acceptance will be returned to the originating exchange in an Answer or Connect Message with the indication \*QService\ 3 provided\*U in the user\(hyto\(hyuser indicators parameter . Services\ 1 and\ 2 will be indicated as \*Qno information\*U in the user\(hyto\(hyuser indicators parameter. These explicit indications shall be forwarded to the call control at the originating exchange. .bp .RT .sp 1P .LP A.2.3.3 \fIRejection of Service\ 3 when requested during call set\(hyup\fR .sp 9p .RT .PP If 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. .PP If the network or called user cannot support Service\ 3, and it was requested with a non\(hyessential indication, a Service\ 3 rejection indication is returned in the Address Complete, Call Progress Message, Answer or Connect with the indication \*QService\ 3 not provided\*U in the user\(hyto\(hyuser indicators parameter . (\fINote\fR \ \(em\ The Study Group\ XVIII service description does not allow this implicit rejection.) .PP If 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, \*Qrequested facility not subscribed\*U, cause code\ 29, \*Qfacility rejected by the network\*U or cause code\ 69, \*Qrequested facility not implemented\*U and the diagnostic containing the user\(hyto\(hyuser indicators parameter. .RT .sp 1P .LP A.2.3.4 \fIService\ 3 requested after call set\(hyup\fR .sp 9p .RT .PP After call set\(hyup 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 user\(hyto\(hyuser service and a user\(hyto\(hyuser indicators parameter requesting Service\ 3 to the distant local exchange using the appropriate transport method. The facility request will contain the user\(hyto\(hyuser indicators parameter with Service\ 3 indicated as \*Qrequested essential/not essential\*U and Services\ 1 and\ 2 indicated as \*Qno information\*U . 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 \*QService\ 3 provided\*U in the user\(hyto\(hyuser indicators parameter . Services\ 1 and\ 2 will be indicated as \*Qno information\*U in the user\(hyto\(hyuser 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. .RT .sp 1P .LP A.2.3.5 \fIRejection of Service\ 3 when requested after call set\(hyup\fR .sp 9p .RT .PP If 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. .PP If the network or requested user cannot support Service\ 3, and it was requested with a non\(hyessential indication, a Service\ 3 rejection indication is returned in the Facility Reject Message with the indication \*QService\ 3 not provided\*U in the user\(hyto\(hyuser indicators parameter . .PP If the call control does not indicate acceptance or rejection the network shall not return any explicit rejection to the exchange. .PP \fINote\ 1\fR \ \(em\ The Stage\ 1 service description does not allow this implicit rejection. .PP \fINote\ 2\fR \ \(em\ The handling of essential/non essential Service\ 3 request is not yet consistent with the State\ 1 service description. .bp .RT .sp 1P .LP A.2.3.6 \fIInterworking\fR .sp 9p .RT .PP In the case of interworking with a non\(hyISDN network an \*Qinterworking\*U protocol control indicator will be returned to the originating exchange in the first appropriate message . If Service\ 3 was requested after call set\(hyup, a Facility Reject Message is returned . Two ISDN networks that interwork may have to retain knowledge of the service request until it is clear whether both can support the service. .RT .sp 1P .LP A.2.3.7 \fITransfer of messages containing user\(hyto\(hyuser information\fR .sp 9p .RT .PP Once acceptance of Service\ 3 has been transmitted across the network, both of the involved users can transfer user\(hyto\(hyuser information between themselves. Within the network the user\(hyto\(hyuser information parameter will be carried in a User\(hyto\(hyuser Information Message. The network provides for the transfer of these messages from the calling to the called side and vice versa. .PP The User\(hyto\(hyuser Information Message format can be found in Table\ 20/Q.763. .RT .sp 1P .LP A.2.4 \fIRequesting user\(hyto\(hyuser signalling Services 1, 2 and 3\fR .sp 9p .RT .PP This section describes procedures for requesting Services\ 1,\ 2 and\ 3. .PP \fINote\fR \ \(em\ User\(hyto\(hyuser Service\ 1 implicit request/response procedures are also found in\ \(sc\ 2.2.1. Only explicit Service\ 1 requests may follow the procedure in this section. .RT .sp 1P .LP A.2.4.1 \fICall establishment\fR .sp 9p .RT .PP Procedures for call establishment are described in\ \(sc\(sc\ A.2.1.2, A.2.2 and\ A.2.3.2 with the following modifications: .PP On service request one user\(hyto\(hyuser indicators parameter will be sent with each service being indicated as \*Qrequested, essential/non essential\*U. .PP If the called user can support the indicated services, then all three services will be indicated as \*Qprovided\*U in the user\(hyto\(hyuser indicators parameter in the Address Complete or Call Progress Message. Alternatively, the Address Complete or Call Progress Message may indicate \*QService\ 3, no information\*U and \*QService\ 3 provided\*U in the Answer or Connect Message as provided in\ \(sc\ A.2.3.2. In the case that the call is to multi\(hypoint users, the acknowledgement of Services\ 1 and\ 3 shall be delayed until the Answer or Connect Message is sent. .RT .sp 1P .LP A.2.4.2 \fIService rejection\fR .sp 9p .RT .PP If 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. .PP If the called user or network does not understand a specific service request, that specific service is implicitly rejected following the procedures of\ \(sc\(sc\ A.2.1.4, A.2.2.3 and\ A.2.3.3. Alternatively, if the network or called user cannot support one or more service requests and the service requests were indicated as non\(hyessential, then the rejection may be provided in the Address Complete or Call Progress Messages. (In the case of a call to multi\(hypoint users only Service\ 2 may be rejected in this way, Service\ 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\ \(sc\(sc\ A.2.1.4, A.2.2.3 and\ A.2.3.3. .PP If 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, \*Qfacility rejected by the network\*U, cause code\ 50, \*Qrequested facility not subscribed\*U, or cause code\ 69, \*Qrequested facility not implemented\*U and the diagnostic containing the user\(hyto\(hyuser indicators parameter. .bp .PP If 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). .RT .sp 1P .LP A.2.4.3 \fIInterworking\fR .sp 9p .RT .PP In the case of interworking with a non\(hyISDN network, the \*Qinterworking\*U protocol 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. .RT .sp 1P .LP A.2.4.4 \fITransfer of User\(hyto\(hyuser Information Messages\fR .sp 9p .RT .PP The procedures for the transfer of User\(hyto\(hyuser Information Messages is covered in\ \(sc\(sc\ A.2.2.5 and\ A.2.3.7. .RT .sp 1P .LP A.2.5 \fIUser\(hyto\(hyuser information transport methods for Services 2 and 3\fR .sp 9p .RT .PP The Transport methods for Services\ 2 and\ 3 may be found in\ \(sc\ 3 of Recommendation\ Q.764. .RT .sp 1P .LP A.2.6 \fIMessage flow diagrams\fR .sp 9p .RT .PP The message flow diagrams are shown in Figures\ A\(hy1/Q.730 to\ A\(hy7/Q.730. .PP For User\(hyto\(hyuser Signalling Service\ 2 and\ 3 the figures only show ISDN user part messages required for basic call control and user\(hyto\(hyuser signalling and are not meant to imply any particular transfer method. The parameters and indicators shown are for the User\(hyto\(hyuser Signalling Service only,\ i.e. any parameters or message associated with the various transport methods are not shown. .PP The following notes apply to Figures\ A\(hy1/Q.730 to\ A\(hy7/Q.730: .PP \fINote\ 1\fR \ \(em\ In cases where an ALERTING indication is carried by a Call Progress Message the user\(hyto\(hyuser indicators parameter and/or the user\(hyto\(hyuser information parameter may also be transported in the Call Progress Message. .PP \fINote\ 2\fR \ \(em\ In cases where the called user is an automatic answering terminal, user\(hyto\(hyuser indicators parameter and/or the user\(hyto\(hyuser information parameter may be transported in a Connect Message. .PP Figure A\(hy1/Q.730 shows a successful use of user\(hyto\(hyuser Signalling Service\ 1 when explicitly requested in a point\(hyto\(hypoint configuration. .PP Figure A\(hy2/Q.730 shows both the successful and unsuccessful use of user\(hyto\(hyuser Signalling Service\ 2 in a point\(hyto\(hypoint configuration. .PP Figure A\(hy3/Q.730 shows an unsuccessful use of user\(hyto\(hyuser Signalling Service\ 2 in a point\(hyto\(hymultipoint configuration. This unsuccessful case is shown because the network reactions will be the same in all similar cases. .PP Figure A\(hy4/Q.730 shows both successful and unsuccessful cases for user\(hyto\(hyuser Signalling Service\ 3 when the service is non\(hyessential in a point\(hyto\(hypoint configuration. .PP Figure A\(hy5/Q.730 shows a successful use of user\(hyto\(hyuser Signalling Service\ 3 after the call is active in a point\(hyto\(hypoint configuration. .PP Figure A\(hy6/Q.730 shows a successful use of user\(hyto\(hyuser signalling Services\ 1,\ 2 and\ 3 and where all services are non\(hyessential in a point\(hyto\(hypoint configuration. .PP Figure A\(hy7/Q.730 shows successful use of user\(hyto\(hyuser signalling Services\ 1 and\ 3 and unsuccessful use of Service\ 2 in a point\(hyto\(hymultipoint configuration. It should be noted again that Service\ 2 will not work in a point\(hyto\(hymultipoint configuration. .bp .PP The following abbreviations are used in the figures: .RT .LP .sp 5 .ce \fBH.T. [T12.730]\fR .ce .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(48p) | cw(120p) . Abbreviations { User\(hyto\(hyuser Indicator Values \fR } _ .T& lw(48p) | lw(120p) . ni no information .T& lw(48p) | lw(120p) . rne requested, non essential .T& lw(48p) | lw(120p) . re requested, essential .T& lw(48p) | lw(120p) . p provided .T& lw(48p) | lw(120p) . np not provided _ .T& cw(48p) | cw(120p) . Abbreviations Parameter name _ .T& lw(48p) | lw(120p) . UUI { user\(hyto\(hyuser information } .T& lw(48p) | lw(120p) . UUI ind. user\(hyto\(hyuser indicators _ .T& cw(48p) | cw(120p) . Abbreviations Message name _ .T& lw(48p) | lw(120p) . ACM Address Complete .T& lw(48p) | lw(120p) . ANM Answer .T& lw(48p) | lw(120p) . FAR Facility Request .T& lw(48p) | lw(120p) . FAA Facility Accepted .T& lw(48p) | lw(120p) . IAM Initial Address .T& lw(48p) | lw(120p) . REL Release .T& lw(48p) | lw(120p) . RLC Release Complete .T& lw(48p) | lw(120p) . USR { User\(hyto\(hyuser Information } _ .TE .nr PS 9 .RT .ad r \fBTableau [T12.730], p. 29\fR .sp 1P .RT .ad b .RT .LP .rs .sp 17P .ad r Blanc .ad b .RT .LP .bp .PP The 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 user\(hyto\(hyuser procedures the ISDN access protocol Recommendation\ Q.931 should be examined. .LP .rs .sp 47P .ad r \fBFigure A\(hy1/Q.730, p. 30\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure A\(hy2/Q.730, p. 31\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure A\(hy3/Q.730, p. 32\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure A\(hy4/Q.730, p. 33\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure A\(hy5/Q.730, p. 34\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure A\(hy6/Q.730, p. 35\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure A\(hy7/Q.730, p. 36\fR .sp 1P .RT .ad b .RT .LP .bp .sp 2P .LP A.2.7 \fIInteraction with other supplementary services\fR .sp 1P .RT .sp 1P .LP A.2.7.1 \fICall forwarding services\fR .sp 9p .RT .PP Interactions with the call forwarding services are shown in the call forwarding protocol sections. .RT .sp 1P .LP A.2.7.2 \fICall waiting service\fR .sp 9p .RT .PP Interactions with the call waiting service are shown in the call waiting protocol sections. (Call waiting is for further study.) .RT .sp 1P .LP A.2.7.3 \fIOther services\fR .sp 9p .RT .PP There are no known interactions with services other than those listed. .RT .sp 1P .LP A.2.8 \fIState transition diagrams\fR .sp 9p .RT .PP The state transition diagrams may be found in the Stage\ 2 description of the User\(hyto\(hyuser Service. .RT .LP .rs .sp 37P .ad r Blanc .ad b .RT .LP .bp .LP \fBMONTAGE: PAGE 184 = BLANCHE\fR .sp 1P .RT .LP .bp